|
|
|
|
|
|
||
5.2. Использование PDM-системы при проектировании
технологических процессов
В разделе 5.1 была показана необходимость и возможность применения современных информационных технологий при проектировании технологических процессов. Рассмотрим более подробно использование PDM - системы при проектировании технологических процессов.
Синтез структуры процесса на уровне маршрута может выполняться с помощью PDM - системы. Для этого все технологические процессы и детали должны быть зафиксированы в дереве проекта PDM - системы.
Для проектирования ТП по дереву проекта выбирается нужный ТП ( унифицированный или единичный) и на его основе создается рабочий технологический процесс. Поиск нужного ТП выполняется либо на основе просмотра дерева проекта, либо на основе поиска по атрибутам учетных карточек на технологические процессы. Наиболее часто применяемые поисковые предписания могут быть зафиксированы в дереве проекта. Поиск единичного процесса дереву проектов целесообразно выполнять на основе поиска детали-аналога по атрибутам учетных карточек на детали, хранимых в электронном архиве. Разработанный рабочий ТП помещается в базу данных в дереве проектов.
Таким образом, реализация смешанного метода проектирования на основе PDM - системы позволяет в максимальной степени использовать принцип преемственности технологических решений.
Такой подход позволяет реализовать смешанный (гибридный) метод проектирования, при котором синтез структуры может идти на основе любых ТП (унифицированных или единичных) и, следовательно, позволяет в максимальной степени реализовать принцип преемственности технологических решений.
При проектировании технологических процессов на уровне операций важной задачей является формирование моделей операционных заготовок ( ОЗ). Современные информационные технологии предоставляют новые возможности для получения моделей ОЗ, как это будет показано в отдельном разделе. Однако необходимо отметить, что принципиально важным является возможность формирования моделей ОЗ на основе трехмерного моделирования объектов. Твердотельные модели операционных заготовок необходимы для получения управляющих программ с помощью современных CAM - систем. Кроме того, твердотельные модели ОЗ могут быть использованы для конструирования технологической оснастки. В настоящее время существуют, например, целый ряд CAD - систем для проектирования прессформ и штампов, использующих трехмерную модель ОЗ в качестве исходных данных. Таким образом, проектирование технологической операции целесообразно завершать проектированием трехмерной модели операционной заготовки с помощью CAD - системы.
Если формирование трехмерной модели ОЗ выполнить сразу после проектирования операции и зарегистрировать ее в дереве проекта (статус документа с ОЗ - " на общем столе"), то это дает возможность доступа к ней специалистов по разработке управляющих программ и конструкторов средств технологического оснащения. Пока технолог будет проектировать следующую операцию, указанные специалисты могут приступить к проектированию УП и технологической оснастки для разработанной операции. Таким образом, возможность параллельной работы над технологическим процессом группе различных специалистов позволяет существенно сократить сроки технологической подготовки производства
При проектировании технологических процессов необходимо выполнять поиск в большом объеме нормативно-справочной информации (НСИ): поиск заготовок, припусков, средств технологического оснащения, режимов резания и т. д. Организация хранения и поиска НСИ наиболее эффективно может быть выполнена на основе электронного архива, что дает возможность использовать удаленные базы данных. Во многих случаях необходим поиск объектов по их общим характеристикам, при этом в качестве универсального механизма поиска целесообразно использовать PDM - систему. Возникает закономерный вопрос: почему PDM - система, а не современные СУБД, обладающие развитыми возможностями для поиска информации и работающие в режиме "клиент-сервер" ?
Во-первых, при поиске в электронном архиве PDM - система обычно использует ядро какой либо СУБД. Например, PDM - система типа " SmarTeam" ориентирована на СУБД "InterBase".
Во-вторых, уникальная возможность доступа к любым документам, связанным с найденным объектом, дает существенные преимущества PDM - системе. Если найдено приспособление или инструмент, то имеется возможность в папке объекта найти файл с эскизом элемента и вывести его на экран. Если найдена деталь-аналог, то можно просмотреть не только чертеж детали или ее трехмерную модель.
В третьих, возможность записи общих характеристик в учетной карточки объекта придает PDM - системе простоту и универсальность поиска в режиме диалога по дереву проекта. Кроме того, простота записи запросов и возможность их хранения в дереве проектов делают PDM - систему уникальным и мощным средством для поиска информации на первом и втором уровне автоматизации проектирования ТП.
Анализ алгоритмов принятия решений при работе с НСИ показывает, что достаточно часто при ручном решении задач используются достаточно сложные одно- и двухвходовые таблицы. Автоматизация поиска по этим таблицам показывает, что принятие решений на основе SQL-запросов, которые используются в архитектуре "клиент-сервер", во многих случаях невозможна либо требует сложной перестройки исходных таблиц перед их вводом в базу данных. Поэтому нужны специальные инструментальные средства для работы с такими таблицами и принятия решений на основе указанной архитектуры.
Практика создания САПР ТП показывает, что для повышения адаптивных свойств системы запись технологических решений целесообразно выполнять с помощью так называемых "табличных алгоритмов" (таблицы решений, алгоритмические и информационно-логические таблицы и т. д.). Использование табличных алгоритмов позволяет достаточно быстро настроить систему на производственные условия конкретного предприятия. Для этого технолог может вызывать из базы знаний эти табличные алгоритмы и выполнять над ними необходимые корректировки. Принятие решений по этим таблицам выполняется с помощью универсальных модулей интерпретирующего типа.
Анализ нормативно-справочной информации показывает, что таблицы НСИ отличаются большим структурным разнообразием: один или два входа; матрица решений или логический базис; получение одного или нескольких решений и т. д. Однако механизмы принятия решений как по этим таблицам, так и по табличным алгоритмам подчиняются единым закономерностям и, следовательно, возможно создание единого аппарата для их обработки. В качестве примера можно привести разработанный в ИТМО комплекс инструментальных средств названный "табличным процессором". В основу табличного процессора положено понятие "таблица соответствий" (ТС). Оно является обобщенным понятием , под которым понимаются все виды таблиц для НСИ и табличных алгоритмов. Для ТС разработан внешний язык для ввода таблиц в базу знаний и определены способы их хранения в базе знаний. Для табличного процессора разработана программная система "ТИС-ТаП", позволяющая не только принимать решения используя ТС, но и осуществлять сопровождение базы знаний, в которых хранятся ТС. "ТИС-ТаП" ориентирована на архитектуру "клиент-сервер" и может работать как с локальной, так и с удаленной базой знаний.
Универсальность табличного процессора, возможность функционирования "ТИС-ТаП" как автономно, так и в составе модулей САПР ТП, открывает широкие возможности для его использования в САПР ТП нового поколения. Описание табличного процессора приведено в приложении 2.
В настоящее время проводятся исследования , в которых предложено использовать экспертные системы для фиксации алгоритмов решения технологических задач . Специфика технологических задач заключается в интенсивном использовании поисковых функций, при этом, чем выше уровень типизации решений, тем более активно используется поиск информации. Встраивание экспертных оболочек в САПР ТП представляет определенные сложности. Чем выше уровень автоматизации, тем сложнее совместное использование экспертных систем и САПР ТП. По этим причинам экспертные системы не получили пока широкого применения при решении технологических задач.
Практика разработки САПР ТП показала, что стыковка отдельных модулей между собой часто затруднена из-за того, что одни и те же признаки объектов выражены разными реквизитами. Базы данных САПР ТП отличаются исключительным структурным разнообразием, при этом имеет место ситуация когда в разных наборах данных используются одни и те же признаки, однако выраженные разными реквизитами, т. е. поля записей для одних и тех же признаков имеют разные атрибуты: наименование, обозначение, тип и длину поля.
Эта ситуация приводит к большому количеству ошибок и к ненадежному функционированию САПР ТП. Поэтому введем понятие "единое информационное пространство", которое подразумевает создание и использование единого словаря данных (параметров). В словаре для каждого реквизита фиксируются его атрибуты, например:
Такой подход позволяет обеспечить информационную стыковку модулей и повысить надежность функционирование САПР ТП. Наличие словаря данных облегчает проектирование ТП на первом и втором уровне автоматизации проектирования. Если технолог вывел на экран набор данных, то с помощью словаря он может разобраться в структуре набора данных и определить по каким полям целесообразно вести поиск нужных записей. При использовании табличного процессора словарь используется для контроля входных данных, что повышает надежность функционирования поискового модуля. Словарь данных необходим при выводе документа на основе его модели, т. к. в модели технологического документа фиксируется обозначение реквизита, значение которого заносится в оформляемый документ независимо от способа его получения
Для удобства дальнейшего изложения будем использовать понятие "модель проблемной среды", под которой будем понимать совокупность баз данных и знаний, а также словаря данных для их обслуживания. В эту же модель входят и все текстовые и графические файлы с документами, относящимися к объектам производственной среды. Модель проблемной среды отображает производственную среду предприятия с той степенью детализации, которая необходима для САПР ТП и другим подсистемам АСТПП.
Составной частью модели проблемной среды является база данных со средствами технологического оснащения (СТО). Для базы СТО характерно наличие сотен наборов данных, относительно небольших по объему, но различающихся своей структурой. Ввиду важности задачи назначения технологического оснащения рассмотрим общие принципы поиска СТО.
Методика назначения технологического оснащения, изложенная в предыдущих разделах, рекомендует поиск оснащения выполнять в три этапа:
На первом этапе поиск может выполняться либо в режиме диалога, либо в автоматическом режиме. Поиск вида объекта в режиме диалога выполняется на первом и втором уровнях проектирования ТП. Поиск, как было показано выше, целесообразно выполнять с помощью PDM - системы. Сначала в дереве проекта находится папка "Базы данных", в ней выбирается, например, папка "Режущий инструмент", далее папка "Сверла цилиндрические с цилиндрическим хвостовиком короткой серии" и так далее до папки с набором типоразмеров сверл. Для ускорения поиска вместо спуска по дереву проекта можно использовать постоянные запросы, также хранимые в дереве проекта.
Если исходить их принципа последовательного повышения уровня автоматизации, то по мере накопление знаний о выборе вида оснащения и заполнения базы знаний выбор тех или иных видов оснащения выполняется автоматизированном режиме с использованием табличного процессора.
На втором этапе поиск типоразмера объекта может выполняться в режиме диалога, при котором на экран выводится набор с типоразмерами. При необходимости используется словарь данных. Большинство PDM - систем имеет большую библиотеку процедур для просмотра как файлов, применяемых в основных промышленных СУБД, так и графических файлов, формируемых в CAD - системах.
Автоматический поиск осуществляется на основе табличного процессора. Необходимо отметить, что ссылка на нужных набор данных может содержаться в параметрической модели технологического процесса, что дает возможность автоматически сформировать запрос к табличному процессору, получить от него результаты выбора и занести их обратно в модель ТП.
На третьем этапе возможность применения найденных типоразмеров обычно определяется в режиме диалога, т. к. все обстоятельства, препятствующие использованию найденного объекта, формализовать практически не удается.
После проектирования технолоического процесса,результаты проектирования фиксируются с помощью PDM - системы. Для этого в дереве со структурой изделия находится папка с деталью, для которой разрабатывался технологический процесс, и в ней регистрируется папка для технологического процесса. В свою очередь в этой папке регистрируются файлы с комплектом технологических карт, файлы с параметрической моделью ТП, графические файлы с операционными эскизами и картами наладки оборудования и т. д. При регистрации на каждый документ заводится учетная карточка. В этой карточке кроме общих характеристик объекта фиксируется и статус (состояние) документа. Например, для PDM - системы " SmarTeam" определены следующие статусы:
- "У автора";
- "На общем столе";
- "На изменении";
- "Утвержден";
- "В хранилище".
Перевод документа из одного состояния в другое выполняетсяс помощью следующих специальных процедур PDM - системы:
- "Сдать на рассмотрение";
- "Взять на рассмотрение (изменение)";
- "Сдать после рассмтрения (изменения)";
- "Взять для создания новой версии";
- "Сдать в хранилище".
Используя статус документа и процедуры для его изменения можно отслеживать жизненный цикл документа. Схема жизненного цикла документа приведена на рис.5.2.1.
Как видно из рисунка, вновь созданный и зарегистрированный документ имеет статус "У автора". Если создатель документа закончил его разработку, то он присваивает документу статус "На общем столе". В этом состоянии документ становится доступным для всех лиц, которые должны продолжить работу над документом. Лицо, первое захвативщее документ, присваивает ему статус "На изменении" и начинает над ним работать. Все остальные лица, которым это разрешено, могут лишь просматривать документ. Проведение изменений может выполняется на основе приема "красный карандаш" (RedLine) либо составляется служебная записка на выполнение изменений. Если требуется доработка документа,то ему присваивается статус "На общем столе" и документ захватывается автором документа для проведения изменений. В противном случае документ считается утвержденным и ему присваивается статус "Утвержден". В этом состоянии документ не может быть изменен. Цикл "просмотр - изменение" выполняется по всем подразделенииям, ответственным за выпуск этого документа. Если после утверждения документа все же понадобится его изменение, например после изготовления опытного образца, то создается его новая версия. Старая версия по прежднему хранится в электронном архиве. Прсматривая версии документа можно проследить историю его изменений.
Не нужным документам присваивается статус "В хранилище" Это состояние означает, что документ не используется и не входит ни в одно изделие.
| Вывод: Использование PDM - системы повышает эффективность работы технолога и создаваемые САПР нового поколения должны работать под управлением таких систем. |