Дмитрий Докучаев
Источник: http://www.sapr.ru
Предприятие относится к отрасли, сильной своими традициями. Более того, эти традиции помогли сохранить его «технологическую устойчивость» в условиях быстро меняющейся рыночной среды и, соответственно, обеспечить требуемый уровень качества продукции. Таким образом, автоматизация подготовки производства прежде всего должна сохранить преемственность традиций — нельзя устраивать революции. Но переход к «электронному» проектированию и выпуску документации неизбежно диктует собственные законы, иногда находящиеся в серьезном противоречии с законами, действующими при работе с бумажными документами.
Проиллюстрируем сказанное на примерах. В данном случае среди особенностей предприятия, которые существенно повлияли на способы решения задач, характерных для предметной области, можно отметить следующие:
- управление составом изделия — особенности предприятия требуют управления двумя видами состава: конструкторским и технологическим. При этом процесс управления должен обеспечить их неразрывную взаимосвязь и определенную последовательность преобразования;
- технологическое проектирование и выпуск документации — требуется обеспечить возможность параллельной работы цеховых технологических бюро со своими техпроцессами, а также предусмотреть эффективные механизмы согласования действий подразделений в процессе разработки и проведения изменений. В ряде случаев требования безопасности ограничивают доступ к информации (в том числе на просмотр) смежных участников процесса.
Анализ данных требований вызвал серьезные сомнения относительно возможности применения стандартных подходов, предлагаемых системой TechnologiCS.
Традиционно для управления составом изделия система TechnologiCS имеет всего один инструмент — версии спецификаций с возможностью управлять их статусами и связанными документами.
Так же традиционно TechnologiCS предлагает использование версий сквозного техпроцесса. Это значит, что можно управлять только статусом версии целиком, при этом не обеспечивается независимое управление цеховыми техпроцессами, так как они, с одной стороны, представляют собой фрагменты сквозного, а с другой — соответствуют разным комплектам документации. Возможность выпуска различных комплектов технологической документации в рамках сквозной версии создает лишь иллюзию управления.
Использование на предприятии самостоятельной производственной системы (ERP) дает возможность проявить определенную вольность в обращении со структурой информации — не будут связаны требованиями производственного модуля TechnologiCS.
Процесс формирования состава изделия заключается в последовательном выполнении двух этапов:
- разработка конструкторского состава — выполняется традиционно, и в нашем случае функциональность системы позволяет стопроцентно обеспечить управление этим процессом, включая работу с документацией, электронное согласование и утверждение состава;
- анализ конструкторских спецификаций и принятие решения о необходимости преобразования состава — выполняется технологическими службами. При этом отдельные позиции спецификаций могут быть объединены в так называемые технологические узлы (сборочные единицы, являющиеся реальными объектами производственного планирования и учета, но не имеющие собственного чертежа). Технологические узлы могут объединять детали и сборочные единицы с разных уровней входимости в изделие. В отдельных случаях появляются технологические детали — они не остаются в изделии (могут быть разрушены в процессе изготовления), но при этом требуют технологической проработки и изготовления.
Таким образом, можно сформулировать задачу:
- сборочные единицы должны иметь управляемую пару версий спецификаций, при этом технологическая версия должна хранить информацию о том, на основании какой именно конструкторской версии она создана. Конструкторская версия при этом играет роль оригинала и служит объектом проведения изменений, а технологическая — ее порождением;
- необходимо обеспечить последовательную обработку двух версий спецификации разными службами, при этом выполнив требования безопасности: разделение прав доступа и управление статусами этих версий. Спецификация, видимая в системе по умолчанию, должна соответствовать действующей на данный момент технологической версии (если таковой нет, то конструкторской). Все спецификации, находящиеся в разработке, должны быть доступны только кругу лиц, причастных к этому процессу в рамках прав, определенных системой;
- преобразование состава необходимо автоматизировать, так как «ручной» способ формирования технологической спецификации может привести к возникновению ошибок, особенно в случае больших объемов информации.
Как ни странно, для решения задачи предложено использовать не две, а три версии спецификации! Кроме того, поскольку TechnologiCS позволяет иметь только «плоский» список версий, пришлось организовать их иерархическую зависимость с использованием так называемых управляющих документов, связанных с версиями. Напомним, что документы TechnologiCS позволяют организовать между ними связи типа «входимость» и «применяемость». Управляющие документы, непосредственно связанные с версиями, были названы картами ввода, поскольку именно они отражают процесс поэтапного ввода в действие соответствующего объекта (в данном случае спецификации) и позволяют отследить все стадии процесса:
Структура версий спецификации, управляющих документов и их отражение в системе
Стадия конструкторской разработки:
1. Создается пустая версия спецификации, не связанная с управляющим документом. Она имеет наименование «Версия в разработке» и статус «Активная — утверждена» — следовательно, видна по умолчанию. Ее назначение — служить своеобразной «ширмой», за которой будет происходить процедура разработки и согласования «настоящей» спецификации.
2. Одновременно создается версия, связанная с документом «Карта ввода» и имеющая статус «Редактирование». Версия проходит последовательные этапы разработки, выпуска документов, электронного согласования и утверждения, при этом получает статус «Архив». (Она по-прежнему не видна по умолчанию!) Управление процессом передается технологическим службам.
Стадия технологической проработки:
1. В случае, если анализ конструкторской документации выявил необходимость создания технологических узлов, создается еще одна версия спецификации (копия конструкторской), связанная с собственной картой ввода (технологической). Статус версии при этом — «Редактирование». Технологическая карта ввода входит в конструкторскую, отражая иерархию версий.
2. Происходит автоматизированное преобразование состава с выделением технологических узлов — новых номенклатурных позиций, имеющих собственные спецификации и соответствующие карты ввода. Спецификация, ведомая картой ввода, проходит необходимые стадии согласования и утверждения.
3. Маршрут обработки документа «Карта ввода» предусматривает обязательную стадию «Ввод в действие». Когда вся информация готова и документ принимает соответствующий статус, связанная с ним версия меняет состояние на «Активная — утверждена» и становится видимой по умолчанию. Понятно, что в отсутствие технологической версии данный статус примет конструкторская. Пустая версия, созданная на старте процесса, при этом автоматически переходит в архив как выполнившая свою роль:
Схема последовательного создания и обработки конструкторского и технологического состава (версий спецификаций)
Отметим, что принятая структура при всей ее логичности и полном соответствии сформулированным требованиям достаточно сложна. Управление такой структурой с использованием штатных средств системы было бы крайне затруднительным. Поэтому в ходе проекта было разработано целое семейство скриптовых модулей, облегчающих работу конструкторов и технологов. По сути эти модули являются макрофункциями, автоматизирующими рутинные последовательности выполнения определенных действий. Кроме того, использование макрофункций если не исключает совсем, то снижает до минимума риск возникновения ошибок. Функция конструктора и технолога в данном процессе сводится к выбору определенного сценария из меню и следованию указаниям, которые предоставляет соответствующий модуль:
Скриптовые модули для работы с составом изделия
Модули, автоматизирующие преобразование состава
Как уже было отмечено, версии сквозного техпроцесса не совсем подходят для обеспечения согласованного управления процессами технологического проектирования и выпуска документации при децентрализованном способе подготовки производства. Прежде всего это происходит потому, что в данном случае не удается обеспечить однозначного соответствия объектов TechnologiCS (версий техпроцессов) и порожденных ими комплектов технологической документации. Отношение получается «один ко многим». Комплект технологической документации как носитель юридического статуса обязательно требует синхронного управления с электронным техпроцессом. Данное утверждение приобретает особый смысл в условиях повышенных требований к документации, процессу ее разработки, согласования и утверждения, диктуемых отраслевой принадлежностью предприятия.
Формулируем задачу:
- предприятие использует децентрализованный способ подготовки производства, при котором службы главного технолога отвечают за предварительный маршрут (расцеховку) и координируют процессы технологического проектирования в цеховых технологических бюро (выполняют роль диспетчера);
- разработка маршрутной и операционной технологий производится в цехах, при этом состав и формы документации очень сильно разнятся в зависимости от вида обработки, действующих стандартов и сложившихся устойчивых традиций;
- маршрутная карта цеха (впрочем, как и комплект цеховой документации) объединяет весь перечень операций, производимых данным цехом над данной деталью, — независимо от того, является ли этот маршрут непрерывным или имеет выходы для обработки в других цехах. В рамках цехового комплекта операции имеют сквозную нумерацию;
- проектирование технологии в цехах ведется параллельно, при этом для смежных операций в подавляющем большинстве случаев согласуются лишь граничные условия и технические требования (входные и выходные параметры);
- процедура согласования и утверждения комплектов технологической документации цеховыми техбюро также осуществляется параллельно и в ряде случаев даже независимо друг от друга.
Таким образом, напрашивается решение: сформировать в системе TechnologiCS информационный объект, однозначно соответствующий цеховому комплекту технологической документации, обеспечить одинаковые права доступа к данному объекту и связанному с ним документу, а также синхронное управление ими.
Анализ технологической документации предприятия позволил выявить определенные закономерности, которые помогли нам правильно сформулировать требования к такому объекту. Вот некоторые из них:
- по отношению к процессу изготовления любой детали или сборочной единицы (ДСЕ) всегда можно определить цех, отвечающий за ДСЕ в целом. При этом остальные цеха, принимающие участие в обработке, действуют в рамках граничных условий (технических требований), которые определены ответственным цехом;
- другими словами, по отношению к конкретной ДСЕ всегда можно выделить цех-изготовитель, остальные причастные к ее изготовлению цеха будут являтьсяцехами-соисполнителями;
- Комплекты технологической документации цехов содержат «обобщенные» операции, выполняющиеся в других цехах и содержащие те самые технические требования, которые должен обеспечить цех-соисполнитель. Эти операции, в свою очередь, раскрываются в виде соответствующих комплектов документации соисполнителей.
В результате перечень требований к новому объекту (сущности) TechnologiCS получился следующим:
- объект должен представлять собой номенклатурную позицию, имеющую собственные версии технологического процесса для обеспечения раздельного, независимого управления;
- технологический процесс данного объекта должен объединять все операции, выполняемые данным цехом над данной деталью в рамках сквозного техпроцесса;
- объект сам по себе должен иметь возможность быть использованным в техпроцессе (быть включенным в техпроцесс в виде операции). Данное требование диктуется еще и необходимостью обеспечения единства (неразрывной связи) расцеховки и операций техпроцесса.
Объект представляет собой специфическую сущность, которая, являясь номенклатурой, в то же время используется в техпроцессе и обрабатывается как операция, а также, в свою очередь, имеет собственный техпроцесс изготовления.
Для наименования этого объекта был предложен термин «Цеходеталь», который мы позаимствовали у наших коллег, внедряющих ERP-систему. Уникальное обозначение цеходетали формируется путем добавления определенного суффикса к обозначению детали. Хотя цеходеталь является виртуальной номенклатурой (фантомом), это не создало дополнительных трудностей у технологов — напротив, они получили собственный, понятный им объект, однозначно соотносящийся с комплектом документации и позволяющий обеспечить реальное разделение прав доступа к нему.
Сквозной техпроцесс в системе TechnologiCS
Пространственная структура технологического процесса
Упрощенно метаморфозу структуры технологической информации, представляющую собой переход от линейной (плоской) структуры сквозного техпроцесса к пространственной, совмещающей принципы иерархической модели и обеспечивающей параллельное управление, можно представить так, как показано на рисунках выше.
Следует заметить, что при такой структуре для обеспечения требований управления процессами проектирования понадобилась еще более сложная, иерархически организованная совокупность управляющих документов — появились специфические карты ввода техпроцесса цеха-изготовителя и карты ввода цехов-соисполнителей.
В свою очередь, для организации управления разработкой техпроцесса ДСЕ в целом возникла необходимость в еще одном управляющем документе — карте ввода техпроцесса, который объединяет все объекты, относящиеся к техпроцессу изготовления ДСЕ:
Структура версий цеховых техпроцессов и управляющих документо
Подобная структура позволила решить еще одну важную задачу — процедура проведения технологических изменений стала более компактной и логичной по отношению к стандартной, предусмотренной системой TechnologiCS. Действительно, изменение технологии цеха влечет за собой появление новой версии только объекта изменения (техпроцесса соответствующей цеходетали), не затрагивая остальные объекты. При этом устанавливаются новые связи между управляющими документами, обеспечивающие хранение истории изменений и восстановление состояния ДСЕ на момент, соответствующий выбранному извещению об изменении (при этом не важно, были это изменения прошлых периодов или изменения, которые планируются для внедрения в будущем).
Не вдаваясь в подробности, отметим лишь, что для управления процессами технологического проектирования использовались те же принципы, которые были описаны выше (управление версиями спецификаций и связанными с ними документами). Подобное единообразие позволит специалистам предприятия достаточно быстро освоить логику управления и овладеть приемами работы с электронными объектами и документами.
Электронный ТП в системе TechnologiCS является не просто документом или файлом – в первую очередь это структурированное описание процесса изготовления соответствующей детали (узла) с указанием последовательности и места выполнения технологических операций, применяемого оборудования и средств оснащения, необходимых материалов и норм их расхода, трудоемкости. С одной стороны, электронный ТП служит основой для автоматического формирования различных описывающих его документов (комплектов документов), а с другой – для планирования и контроля производственного процесса.
TechnologiCS позволяет вести технологическую подготовку, нормирование:
• работа с БД конструкторских спецификаций и чертежей (непосредственно при проектировании технологии и в любом другом режиме работы), с учетом прав доступа;
• разработка технологических процессов, поддержка различных вариантов организации технологической подготовки: с расцеховкой, без предварительной расцеховки, разработка сквозных техпроцессов, коллективная разработка техпроцесса несколькими технологами (бюро) и т.п., возможность эффективной разработки ТП для различных видов производства;
• разработка техпроцессов с различной степенью детализации в зависимости от задач предприятия: маршрутная, маршрутно-операционная, операционная технология; возможность наличия нескольких альтернативных техпроцессов изготовления для одной детали;
• различные режимы для эффективной разработки техпроцессов: диалоговый, с использованием мастеров проектирования, по аналогу, из фрагментов ТП других деталей, на основании ТП комплексной детали и т.д.;
• возможность при необходимости глубокой настройки системы для автоматизации проектирования ТП: создание и использование скриптов для подбора оборудования и инструмента, генерации текстов переходов и т.д.;
• автоматизированное формирование комплектов технологической документации различного назначения и степени сложности (более 50 настроенных бланков документов в соответствии с ЕСТД + возможность создавать свои бланки документов и комплекты);
• встроенная подсистема расчетов режимов для механической обработки (расчет режимов резания), возможность встраивать собственные алгоритмы для проведения различных расчетов;
• возможность глубокой интеграции с CAM системами: запуск приложения для разработки УП для станков с ЧПУ непосредственно из режима редактирования техпроцесса в TechnologiCS, передача CAM-системе из БД TechnologiCS параметров детали и необходимых для разработки программы файлов (чертеж или модель), сохранение результата работы в виде технологической операции в ТП TechnologiCS с указанием переходов, инструмента, режимов обработки и связанной с данной операцией программой для станка с ЧПУ;
• создание единой БД технологических процессов и решений, справочника типовых элементов технологических процессов для быстрого проектирования ТП на новые детали;
• ведение электронной картотеки средств оснащения: инструмента, приспособлений, оснастки, с указанием характеристик, связью с чертежами заявками и др. документами, отслеживанием применяемости и т.д.;
• средства для организации эффективного взаимодействия подразделений в процессе технической подготовки производства;
• планирование и контроль процесса подготовки производства.
• материальное и трудовое нормирование:
o автоматизированный расчет массы заготовки и нормы расхода для деталей из сортового металлопроката, труб, листов; возможность подключения собственных алгоритмов для расчета норм расхода;
o различные способы ведения норм расхода вспомогательных материалов, норм расхода материалов по типовым и групповым техпроцессам (нанесение покрытий, сварки и т.д.);
o автоматическое формирование различных сводных материальных ведомостей: специфицированных, подетальных, по цехам-потребителям, по изделиям и т.д.;
o различные варианты нормирования трудоемкости: вручную, по нормировочным таблицам (в т.ч. с применением поправочных коэффициентов), автоматически с использованием предварительно заданных алгоритмов расчета;
o встроенная подсистема расчета технически обоснованной трудоемкости для механической обработки для серийных производств;
o автоматический расчет сводной трудоемкости и формирование различных ведомостей: по изделию, подетальные, по цехам/участкам, по видам работ, по моделям оборудования и т.д.;
o ведение БД материальных и трудовых нормативов в строгом соответствии с применяемыми технологическими процессами изготовления;
o проведение сводной калькуляции нормативных материальных и трудовых затрат на деталь/узел/изделие/заказ.
Общий вид ТП в электронном виде
Как видно из рисунка, в данном ТП содержится следующая основная информация: маршрут прохождения детали по цехам, материал заготовки, последовательность операций с указанием оборудования, выполняемых технологических переходов, необходимого инструмента и оснастки. На небольшом предприятии или в маленьком технологическом бюро и разработка ТП, и нормирование могут выполняться одним специалистом.
На крупных заводах разработкой маршрута обычно занимается один отдел, материальным нормированием – другой, непосредственно разработкой операционного ТП и подготовкой основной технологической документации – третий, а нормированием трудоемкости – четвертый. Система TechnologiCS поддерживает различные способы организации работы с электронным ТП, определяемые принятым на предприятии порядком проведения ТПП.
Насколько детально описывается в электронном виде технологический процесс, также зависит от требований конкретного предприятия и определяется в основном:
· требованиями к выпускаемой технологической документации;
· требованиями к полноте информации, которая заносится в систему на стадии технологической подготовки, с точки зрения дальнейшего использования электронных ТП для задач планирования и управления производством.
Состав информации, которая отображается на основном экране при редактировании или просмотре технологического процесса, можно настроить для пользователей системы индивидуально. Такой подход позволяет специалисту видеть на одном экране и общую последовательность изготовления детали, и необходимые именно ему уточняющие данные. В то же время экран не перегружен информацией, ненужной этому пользователю.
Разработанного в таком виде технологического процесса вполне достаточно, чтобы выпустить маршрутную карту и ведомость оснастки, рассчитывать потребность в материалах и сводную трудоемкость для изделий, содержащих данную деталь, планировать загрузку оборудования и осуществлять пооперационный контроль изготовления, что будет показано далее.
Маршрутно-операционная карта
Так например для детали 2СПТМ.01.142 Втулка с использованием TechnologiCS разработан операционный технологический процесс. На рисунке ниже показана детально проработанная токарная операция детали 2СПТМ.01.142 Втулка с указанием технологических переходов, инструмента, режимов обработки:
Операционный ТП для детали 2СПТМ.01.142 Втулка в электронном виде
На эту деталь выпускается и соответствующий комплект документации:
На основании разработанного в системе TechnologiCS электронного ТП для детали 2СПТМ.01.142 Втулка формируется комплект документации: маршрутная карта, операционная карта для операции 005, комплект карт эскизов
Немного подробнее остановимся на разработке ТП и нормировании с применением единой ИС TechnologiCS. Как уже сказано, в простейшем случае весь технологический процесс может быть разработан и пронормирован одним специалистом. Такой режим работы характерен для небольших предприятий, опытных и инструментальных производств. Более сложный вариант, характерный для крупных предприятий, предполагает параллельную разработку технологического процесса специалистами нескольких отделов (бюро). В таком случае перед разработкой ТП для цехов (по бюро) определяется маршрут (расцеховка). Разработка маршрута выполняется специалистом соответствующего бюро (отдела) с использованием предназначенных специально для этого функций системы. При расцеховке новой детали можно составить ее маршрут как с нуля, так и на основе стандартного маршрута изготовления для деталей подобного типа.
Непосредственно для разработки ТП с применением TechnologiCS в системе предусмотрены несколько основных режимов. Простейший режим – диалоговый, когда элементы ТП последовательно выбираются из соответствующих справочников системы. Например, выбирается технологическая операция, назначается оборудование, выбираются технологические переходы и редактируется их текст, выбираются инструмент и оснастка и т.д.
Такой режим работы с системой очень прост и весьма эффективен. Как показывает опыт реальных внедрений, работу с TechnologiCS в диалоговом режиме осваивают, причем за короткий срок, даже слабо владеющие компьютером технологи. При правильной настройке ПО они уже через несколько дней самостоятельно и достаточно быстро разрабатывают ТП в электронном виде, автоматически получают для них комплекты документов. Для упрощения и ускорения процесса разработки ТП в диалоговом режиме желательно выполнить ряд несложных настроек. Например, указать в системе, какие станки могут применяться для выполнения тех или иных технологических операций, какой режущий и вспомогательный инструмент должен использоваться совместно и т.п.
Такого рода настройки выполняются на каждом предприятии индивидуально – по мере освоения возможностей системы при проектировании техпроцессов. Это не требует познаний в области структуры БД или программирования: все настройки выполняются визуально с использованием интерфейсов, встроенных в систему. Кроме того, для ускорения разработки электронных ТП в системе можно использовать Мастера проектирования, заранее определяющие последовательность шагов пользователя: например, чтобы после выбора технологической операции сразу же предлагался выбор соответствующего оборудования, затем переходов и т.д.
Наиболее популярный среди технологов способ разработки – проектирование ТП на основе аналога. Используя систему TechnologiCS, специалист имеет возможность, с одной стороны, быстро заимствовать ранее разработанные фрагменты ТП и корректировать их, а с другой – различными способами подбирать необходимые аналоги:
· подбирая похожую деталь. При этом используются параметры деталей, средства поиска и выборки деталей как по обозначению и наименованию, так и по характеристикам, эскизы и чертежи деталей и т.п.
· используя функцию отслеживания применяемости материалов, оборудования, оснастки и т.д. в техпроцессах, имеющихся в системе;
· используя библиотеку стандартных фрагментов техпроцессов
Как показывает практика, возможности быстрой разработки ТП в диалоговом режиме, быстрого поиска подходящих аналогов, копирования и корректировки фрагментов ТП плюс удобное представление информации на экране в большинстве случаев являются необходимыми и достаточными условиями быстрой и эффективной работы с электронными ТП. При желании можно выполнять настройку для более глубокой автоматизации процесса разработки ТП (вплоть до автоматической генерации ТП на основе ТП Комплексной детали), но этот путь, безусловно, сопряжен с длительной и трудоемкой настройкой системы, а эффективен далеко не для всех предприятий.
На многих (особенно серийных) предприятиях при разработке операционных ТП выполняется множество различных расчетов. Для их автоматизации предусмотрена возможность использования специализированных расчетных модулей. Например, в базовый комплект поставки системы включен модуль расчета режимов резания, позволяющий с учетом характеристик материала, оборудования и инструмента рассчитывать скорость, подачу и время обработки для точения, сверления, фрезерования, шлифования и других видов механической обработки
После завершения работы с электронным техпроцессом технологи автоматически получают из системы необходимые комплекты технологической документации. Для каждого пользователя (или бюро) администратор системы может настроить свои комплекты документов, которые тот будет получать из системы на своем рабочем месте. Комплекты могут составляться из различных бланков и иметь довольно сложную структуру (например: титульный лист + маршрутная карта + операционные карты + карты эскизов + карты контроля + ведомость оснастки). В комплект базовой поставки системы входит около пятидесяти уже готовых бланков технологической документации, настроенных в соответствии с требованиями ЕСТД. При необходимости можно самостоятельно вносить изменения в имеющиеся бланки и создавать свои собственные. В качестве генератора отчетов TechnologiCS использует стандартные средства MS Office, поэтому для редактирования существующих и разработки новых форм выходных документов (во всех режимах работы системы) необходимо и достаточно владеть основными возможностями пакетов MS Access и MS Excel. Подробная документация по настройке и созданию собственных форм документов поставляется вместе с системой.