Что такое сапр тп. Отечественные сапр тп. Анализ математических методов принятия технологических решений в условиях многокритериального выбора
Читайте также:
|
При разработке САПР выполняются следующие стадии.
Предпроектные исследования проводятся для обследования организации на готовность к автоматизации процесса проектирования. Результатом должен быть ответ на вопрос: рационально ли функционирование САПР в данной организации на текущий период или необходимо провести комплекс подготовительных работ?
Техническое задание (ТЗ) является исходным документом для создания САПР, который должен содержать наиболее полные исходные данные и требования. Этот документ разрабатывает организация - головной разработчик системы. Техническое задание должно содержать следующие основные разделы:
1. «Наименование и область применения» - полное наименование системы и краткую характеристику области ее применения;
2. «Основание для создания» - наименование директивных документов, на основании которых создается САПР;
3. «Характеристика объекта проектирования» - сведения о назначении, составе, условиях применения объекта проектирования;
4. «Цель и назначение» - цель создания САПР, ее назначение и критерий эффективности функционирования;
5. «Характеристика процесса проектирования» - общее описание процесса проектирования; требования к входным и выходным данным, а также требования по разделению проектных процедур (операций), выполняемых с помощью неавтоматизированного и автоматизированного проектирования;
6. «Требования к САПР» - требования к САПР в целом и к составу £ £ подсистем, к использованию в составе САПР ранее созданных подсистем и компонентов САПР и т.п.;
7. «Технико-экономические показатели» - затраты на создание САПР, пики получения экономии и ожидаемую эффективность от применения
Техническое предложение, эскизное и техническое проектирование являются стадиями выбора и обоснования вариантов для принятия окончательных решений. На этих этапах производят следующие основные работы:
· выявляют процесс проектирования (его алгоритм), где принимают
основные технические решения;
· разрабатывают структуру САПР и взаимосвязь ее с другими системами, где определяют состав проектных процедур и операций по подсистемам, уточняют состав подсистем и взаимосвязи между ними; разрабатывают схему функционирования САПР;
· при принятии решений по математическому, лингвистическому, техническому, информационному и программному обеспечению САПР в целом
и подсистемам определяют: состав методов, математических моделей для проектных операций и процедур; состав языков проектирования; состав информации, объем, способы ее организации и виды машинных носителей информации; состав общего и специального программного обеспечения; состав
технических средств (ЭВМ, периферийных устройств и других вычисляющих управляющих комплексов), рассчитывают технико-экономические поели САПР.
При создании САПР стадии технического предложения и эскизного, проектирования не являются обязательными, а входящие в них работы могут подняться на последующей стадии.
Рабочее проектирование является стадией оформления всей документации, необходимой для создания и функционирования САПР.
Затем компоненты САПР изготовляют (получают) и отлаживают. Производят монтаж, наладку и испытание комплекса технических средств автоматизации проектирования и подготавливают организацию к вводу в действе САПР.
Проектирование – процесс составления описания, необходимого для создания в заданных условиях еще не существующего объекта на основе его написания или алгоритма его функционирования.
Автоматизир-м называют проектир-е с применением ЭВМ.
САПР – это комплекс средств автоматизации проектирования, взаимосвязь с необходимыми подразделениями проектной организации и коллективом специалистов (пользователей системы), выполняемых автоматизированное проектирование.
При создании САПР и их составных частей необходимо руководствоваться принципами:
1.системного единства; 2.совмест-ти; 3.типизации; 4.развития.
Принципы системного единства обеспечивают целостность системы иерархичность проектирования отдельных частей и объекта в целом.
Принцип совместимости обеспечивает совместное функционирование составных частей САПР и сохраняет открытой систему в целом.
Принцип типизации предусматривает разработку и использование типовых и унифицированных элементов САПР. Типизируются элементы, имеющие перспективу многократного использования.
Принцип развития дает возможность пополнения, совершенствования и обновления составных частей САПР.
Современные САПР, в том числе и САПР ТП, базируются на информационных технологиях, поэтому для них характерен ряд признаков:
1. объектно-ориентированное взаимод-е человека и ЭВМ;
2. сквозная информационная поддержка на всех этапах обработки информации на основе интегрированной базы данных;
3. бумажный процесс обработки информации;
4. интерактивный режим решения задач, который выполняется в режиме диалога с ЭВМ;
САПР ТП в компьютерно-интегрир-ном производстве. Элементы интегрированных систем
Усложнение конструкции машин, рост треб-й к качеству требует принятия сложных и эффективных решений в миним-е сроки. Это возможно лишь при автоматизации процесса принятия решений.
Современные информац технологии IT дают возм-ть создания интегр системы поддержки всего ЖЦИ. Последнее нашло отражение в разраб-ке CALS-технологий. Это современные IT, обесп-е автоматизир-ю поддержку решений на отд-х этапах ЖЦИ. CALS-технологии состоят из набора приемов, методич-х и программных продуктов. Чтобы достичь должного уровня взаимод-я промышл автоматизир-х и информац-х систем требуется созд-е единого информац-го пространства. Единое информац-е пространство созд-ся благодаря унификации как формы, так и содерж-я информации о конкретных изд-ях на разных этапах ЖЦИ.
Унификация формы достигается благодаря исп-ю стандартных форматов и языков предст-я инфы при докум-и и межпрограммных обменах.
Унификация содержания обесп-ся разраб-й приложений, закр-х в прикладных CALS-протокалах.
Система международных CALS-стандартов оч широка. Центр-е место в ней занимает стандарт ISO 10303. Этот стандарт опред-т средства описания промышл-х изделий на всех этапах ЖЦИ.
Интегрированная система, имеющ-я единую БД назыв компьютерное интегрированное произв-во.
Элементы интегрированной системы САПР ТП.
CAD – автоматизирован-е проект-е изделий.
CAE – автоматизир-е расчеты и анализ (ANSYS, NASTRAN)
CAM – автоматизир-я технол-я подготовка произв-ва (подготовка программ для станков с ЧПУ): ADEM, SprutCAM, PowerMill.
CAPP – автоматизир-е проект-е ТП: ADEM CAPP, Вертикаль, Компас – Автопроект, ТFLEX – технология.
PDM – управление данными о продукте: Лоцман.
PLM – управление ЖЦИ: Team Center.
ERP – планиров-е и упр-е предпр-ем: Галактика, Мах +
MRP-2 – планир-е произв-ва.
MES – произв-я исполн-я система.
SCM – упр-е цепочками поставок.
SCAD A – диспетчерское упр-е ПП.
CNC – комп-е числовое упр-е.
В структуре компьютерно-интегрированного производства выделяются 3 основные иерархические уровня:
1. уровень (верхний) – уровень планирования (подсистемы планирования).
2. уровень (средний) – уровень проектирования.
3. уровень (нижний) – уровень управления производством (включает подсистему управления производственным оборудованием).
Построение компьютерно-интегрированного производства позволяет решает задачи:
1. информационного производства (отход принципа централизации и переход к необходимой децентрализации на каждом из рассматриваемых уровней).
2. обработки информации (стыковка и адаптация программного обеспечения различных подсистем);
3. физических связей подсистем (создание интерфейсов, т.е. стыковка аппаратных средств ЭВМ).
Стадии разработки САПР ТП
Сложность процесса проектирования зависит от конкретного объекта, размеров и структуры проектной организации. На начальной стадии проектирования принимаются решения, в основе которых лежат эвристические (опытные) соображения с учетом неполных знаний об их влиянии на обеспечение конечной цели. Эта часть проектирования называется СИНТЕЗОМ.
На окончательной стадии проектирования выполняют анализ. Проектирование является циклическим процессом. Между операциями анализа и синтеза существует обратная связь.
Линейная структура (переход к следующему этапу только по завершению предыдущего).
Позволяет вернуться на предыдущий этап
Состав и структура САПР ТП
Составными структурными частями САПР ТП являются подсистемы. В каждой подсистеме решается функционально законченная последовательность задач. САПР ТП состоит из подсистем:
1) подсистемы проектирования;
2) подсистемы обслуживания.
Подсистема – совокупность взаимосвяз-х эл-в, спос-х вып-ть относительно независимые ф-ции и реализовывать подцели, направл-е на достиж-е общей цели системы.
Подсистемы проектирования выполняют процедуры и операции получения новых данных. Они имеют объектную ориентацию и реализуют определенный этап проектирования или группу взаимосвязанных проектных задач, например, подсистема проектирования детали, ТП и т.д.
Обслуживания подсистем имеют общее системное применение и служат для обеспечения функции проектирований систем, например, систем управления БД, системы ввода/вывода данных, передачи данных и т.д.
Виды обеспечения САПР ТП
1. Методическое обеспечение – совокупность документов, устанавливающих состав и правила отбора и эксплуатации средств обеспечения проектирования.
2. Информационное обеспечение – совокупность данных, необходимых для проектирования, представленных в заданной форме.
3. Математическое обеспечение – совокупность математических методов, математических моделей, алгоритмов, необходимых для проектирования.
4. Программное обеспечение – совокупность машинных программ, необходимых для программирования, представленных в заданной форме на машинных носителях.
5. Техническое обеспечение – совокупность взаимосвязанных и взаимодействующих технических средств, предназначенных для автоматизации проектирования.
6. Лингвистическое – совокупность языков проектирования, включая термины и определения, правила формализации и методы развертывания и сжатия текстов, необходимых для проектирования, представленных в заданной форме.
7. Организационное обеспечение – совокупность документов, устанавливающих состав проектной организации и её подразделений, связи между ними, функции, а также форму представления и рассмотрения проектных документов, необходимых для проектирования.
1Здравствуйте! Я работаю инженером-технологом на одном из крупнейших предприятий города Минска в области машиностроения. В своей работе, да и в процессе учебы, сталкивался с разного рода САПР ТП. Практически все, в чем мне приходилось работать (TechCard, ADEM, Вертикаль и пр.), а также читать и слышать, это, так называемые, "оформлялки" технологических процессов. Я, как человек увлекающийся программированием, называю их еще программы-КОМПИЛЯТОРЫ .
Работа с этими системами - это издевательство над инженерами-технологами в век современных технологий!!!
Возможно лет этак надцать назад это было бы актуально, но сегодня???
Мне посчастливилось познакомиться и пообщаться с людьми которые стояли у истоков разработки программного обеспечения для задач автоматизации технической подготовки производства (технологического проектирования) в ЦНИИТУ(Центральный научно-исследовательский и проектно-технологический институт организации и техники управления) на просторах Союза в далеких 60-х годах. Их задумки, идеи и их реализация меня просто поразили.
Уже тогда, когда ни у кого еще не было персонального компьютера, они разрабатывали и внедряли на предприятиях программу-ИНТЕРПРИТАТОР построения ТП, работа которого основана на таблицах принятия решений.
Я сам немного работал в таких программах, реализованых еще под DOS, где вводишь исходные данные(размеры, точность поверхностей, шероховатость, термообработку) и получаешь технологический процесс.
Только вдуматься, 50 лет назад, уровень САПР ТП был гораздо выше, чем сейчас, в век современных технологий.
А самое страшное это то, что дальнейшее развитие САПР ТП идет по пути появления новых или улучшения существующих "программ-оформлялок" ТП.
______________________________________________________________________________________
P.S.: Уважаемые разработчики САПР ТП, когда вы начнете разрабатывать интеллектуальные системы проектирования технологических процессов???
Изменено 20 октября, 2015 пользователем AlexanderSa
Итак, запускаем её.
Давайте попробуем прикинуть, какие входные данные нам потребуются для реализации подобной большой красной кнопки:
На начальном этапе развития данного направления, я считаю, их количество должно быть минимальным . Обойдемся двумя: квалитет точности размера (лучше конечно сам размер с отклонениями, а комп будет определять квалитет сам) и шероховатость поверхности.
Если это единичное, мелкосерийное производство и нам нужен маршрутный ТП, данные выводятся на бланк маршрутной карты (МК). Или, возможно, инженер-технолог немного "колдует" над ними (например, ставит основное время и др.) и выводит на печать.
Это ли ни есть автоматизация ТП и конкуренция Ms Word?)))
Если это среднесерийное, крупносерийное, массовое производства наши операции отправляются в программу-оформлялку (например, TechCard) и появляюся там в виде операций. А дальше как обычно, начинает трести бубном технолог)))
Возможно вы скажите, так какая тут автоматизация (сокращение времени проектирования)? Она может и не большая, но это открывает для нас дальнейшие возможности для автоматизации на следующем этапе.
Этапы, автоматизации:
1)программы-оформлялки;
2)внедрение "Большой Красной Кнопки" в программы оформлялки (то про что сейчас речь);
и 3)Чертеж конструктора - это параметрическая модель с исходными данными (размерами, шероховатостью, твердостью) и т.д. Вот тогда количество входных данных в "Большую Красную Кнопку" можно делать максимальным (их же вводит конструктор, создавая чертеж, а не технолог)))). А далее эти данные передаются в программу-оформлялку.
Другими словами "Большая Красная Кнопка" - это искусственный интеллект, который возможно для разных производств, следует, специализировать. То есть разрабатывать, например, для инструментального производства свой, для ремонтного свой и т.д. Или предоставлять инструменты для его разработки пользователям.
_________________________________________________________________
Вот как то так.
Возможно это не лучшая идея реализации и кто-то придумает лучше, но идея я считаю верная: САПР ТП должны развиваться в сторону интеллектуальных САПР ТП.
1 462
модель с исходными данными
трехмерной модели с аннотациями PMI
За этим будущее. Но много ли сейчас НЕ предприятий-гигантов делают нечто подобное?
NGM 205
На начальном этапе развития данного направления, я считаю, их количество должно быть минимальным. Обойдемся двумя: квалитет точности размера (лучше конечно сам размер с отклонениями, а комп будет определять квалитет сам) и шероховатость поверхности. Далее получив маршрутный технологический процесс обработки инженер-технолог редактирует его (например, нам надо добавить термическую обработку, так как твердость мы не указывали и т.д.) Если это единичное, мелкосерийное производство и нам нужен маршрутный ТП, данные выводятся на бланк маршрутной карты (МК). Или, возможно, инженер-технолог немного "колдует" над ними (например, ставит основное время и др.) и выводит на печать.
Мои поздравления - вы бодрым шагом маршируете по граблям, об которые в 80-х годах разработчики разнообразных сапртыпэ оббили себе всё, что можно и нельзя.
Назвать это автоматизацией ТП - нельзя, автоматизация техпроцессов - это ЧПУ, роботы и иже с ними. Назвать это автоматизацией подготовки производства - можно с огромной натяжкой. Ваша БКК применима только для конкретного производства и для очень узкой номенклатуры. И чем больше вы будете расширять эту номенклатуру, тем сильнее вы будете привязываться к условиям конкретного предприятия/цеха. Еще раз - никто не мешает вам это делать. Но не стоит ждать, что подобные системы будут разрабатываться для массового пользования.
Другими словами "Большая Красная Кнопка" - это искусственный интеллект, который возможно для разных производств, следует, специализировать.
Искусственный интеллект? Он будет самообучаем? Он сможет моделировать неформальное мышление? Не путайте экспертную систему с искусственным интеллектом. Это родственные понятия, но между ними огромный разрыв. Кое-кто даже к пенсии не может понять этого...
Как говорит мой преподаватель по программированию: "Вы должны разрабатывать такие программы, которые будут писать другие программы. Вот это вышка...")))
NGM 205
Или даже так: что нужно предприятию, чтобы реализовать такую схему проектирования?
Шаг №1 - ввести положение, по которому трехмерная электронная модель изделия будет являться подлинником.
Назвать это автоматизацией ТП - нельзя, автоматизация техпроцессов - это ЧПУ, роботы и иже с ними. Назвать это автоматизацией подготовки производства - можно с огромной натяжкой. Ваша БКК применима только для конкретного производства и для очень узкой номенклатуры. И чем больше вы будете расширять эту номенклатуру, тем сильнее вы будете привязываться к условиям конкретного предприятия/цеха.
Вы конечно во многом правы. Но я говорю об автоматизации технологической подготовки производства.
Еще раз - никто не мешает вам это делать. Но не стоит ждать, что подобные системы будут разрабатываться для массового пользования.
Проблема вся в том, что инженеры-технологи, не знающие языков программирования и не являющиеся программистами, не могут сами разработать эти БКК под свои производства. Поэтому, почему бы, например, как вариант, в рамках программы-оформлялки, не разработать какие-либо инструменты для этого. То есть например некий язык программирования, понятный инженеру технологу и в котором он мог бы создать эту БКК под специфику своего производства. Или отредактировать БКК написанную кем-то.
Например, если не ошибаюсь, NX содержит в себе такое решения для автоматизации подготовки производства как создание управляемых знаниями приложений (Knowledge Fusion).
Я не говорю, что БКК должна полностью выдавать готовый ТП. Но если она уменьшит время на разработку ТП, хотя бы на какой-то небольшой промежуток времени, это уже будет хоть какая-то автоматизация. А главное, что это создаст предпосылки, для широкого внедрения "трехмерной модели с аннотациями PMI".
Так как, например, начертил конструктор трехмерную модель с параметрами в CAD-системе. И что дальше с ней делать? Одно дело, когда по ней технолог написал программу обработки на какой-либо один обрабатывающий центр в CAM-системе и все ОК (это конечно идеальный вариант, но много ли у нас таких производств?). Другое, когда эта деталь обрабатывается на множестве станков, то есть операций много, и надо знать какой операции какие параметры передать. А кто это будет делать? Пока это все делается по сути вручную.
Например, там где я работал раньше, конструктор чертит 3D модель(чертеж) в CAD-е. Далее цеховой технолог, знающий свое оборудование, отрабатывает ее на технологичность(война за уменьшение точности))) и возможность её изготовить в принципе), и пишет маршрутный ТП ВРУЧНУЮ РУЧКОЙ! на поле чертежа. Так как это наиболее эффективный и быстрый способ. Обработка включает множество операций, часть из которых выполняют станки с ЧПУ. И для этих операций другой технолог, пишущий программы ЧПУ, по бумажным эскизам цехового технолога! (не по CAD-модели конструктора, так как эти операции промежуточные) на эти операции разрабатывает программу обработки.
Тут конечно можно, возражать, по поводу организации производства и её уровня. Но давайте спустимся на землю и будем реалистами.
А вот если бы между конструктором, разработавшим CAD-модель с параметрами и технологом, пишущим программу на ЧПУ, существовала БКК под надзором цехового технолога, появилась бы возможность автоматизировать труд инженера-технолога пишущего программу с ЧПУ, в полной мере воспользовавшись преимуществами 3D модели с параметрами.
Или предоставлять инструменты для его разработки пользователям.
Как говорит мой преподаватель по программированию: "Вы должны разрабатывать такие программы, которые будут писать другие программы. Вот это вышка...")))
Опять же - мечты многих "автоматизаторов" 70-80 годов. Программист должен разрабатывать программы, которые будут выполнять требуемые функции и обеспечивать необходимый функционал, а не "писать другие программы".
Я имею ввиду это в таком контексте: Большинство заказов в отечественных IT-компаниях, ориентировано на разработку программного обеспечения задач, информационных систем и технологий по модели аутсорсинга (доработка, сопровождение, тестирование разработанных и функционирующих за рубежом информационных систем). То есть наши программисты задействованы на выполнение "черновой" работы. Программное обеспечение с высокой добавленной стоимостью разрабатывают зарубежные компании, зачастую с помощью наших специалистов. То есть системное ПО, языки программирования и др. нам продают для разработки прикладного ПО и внедрении информационных систем в организации нашей страны.
Мы с вами можем много спорить о том, какими на самом деле крутыми были программисты, алгоритмизаторы и разработчики в СССР, но давайте смотреть правде в глаза - пока они думали над тем, как создать кнопку, по нажатию которой из принтера полезет техпроцесс, на западе и в США думали об организационных вопросах производства и обработке на станках с ЧПУ. Наверное, не будь так силен культ чертежа и техпроцесса, мы бы сейчас имели достойного отечественного конкурента NX, Creo и CATIA. А имеем мы то, что имеем...
Я придерживаюсь принципа, что развиваться нужно во всех направлениях. И каждый должен заниматься своим делом. И говорю в контексте проблем развития САПР ТП (программ-оформлялок).
Можно конечно говорить много как у "них" все хорошо, и как мы отстали и ждать когда придумают что-то еще новое. А можно самим попытаться что-то придумать и реализовать)
560В машиностроении все шире используют системы автоматизированного проектирования технологических процессов (САПР ТП), что вызывается все возрастающим ростом объема машиностроения, усложнением конструкций изделий и технологических процессов, сжатыми сроками технологической подготовки производства и ограниченной численностью инженерно-технических кадров. САПР ТП позволяет не только ускорить процесс проектирования, но и повысить его качество путем рассмотрения большего числа возможных вариантов и выбора самого лучшего по определенному критерию (по себестоимости, производительности и др.).
Автоматизация проектирования предусматривает систематическое использование ЭВМ в процессе проектирования и в обоснованном распределении функций между технологом-проектировщиком и ЭВМ.
Использование автоматизированного проектирования не только повышает производительность труда технолога, но и способствует улучшению условий труда проектировщиков; количественной автоматизации умственно-формальных (нетворческих) работ; разработке имитационных моделей на воспроизведение деятельности технолога, его способности принимать проектные решения в условиях частичной или полной неопределенности в возникающих ситуациях проектирования.
Проектирование технологического процесса включает ряд уровней: разработку принципиальной схемы технологического процесса, проектирование технологического маршрута, проектирование операций, разработку управляющих программ для оборудования с числовым программным управлением.
Проектирование сводится к решению группы задач, которые относятся к задачам синтеза и анализа. Понятие «синтез» технологического процесса в широком смысле этого слова близко по содержанию к понятию «проектирование». Однако здесь есть разница, которая заключается в том, что проектирование означает весь процесс разработки технологического процесса, а синтез характеризует создание варианта технологического процесса, не обязательно окончательного. Синтез как задача может выполняться при проектировании много раз, сочетаясь с решением задач анализа. Анализ технологического процесса или операции – это изучение их свойств; при анализе не создаются новые технологические процессы или операции, а исследуются заданные. Синтез направлен на создание новых вариантов технологических процессов или операций, а анализ используется для оценки этих вариантов.
Технологический процесс механосборочного производства и его элементы являются дискретными, поэтому задача синтеза сводится к определению структуры. Если среди вариантов структуры отыскивается не любой приемлемый, а в некотором смысле наилучший, то такую задачу синтеза называют структурной оптимизацией.
Расчет оптимальных параметров (режимов резания, параметров качества и др.) технологического процесса или операции при заданной структуре с позиции некоторого критерия называют параметрической оптимизацией.
На каждом уровне процесс технологического проектирования (проектирование технологических процессов и их оснащения) представляется как решение совокупности задач (рис. 5.1). Проектирование начинается с синтеза структуры по техническому заданию (ТЗ). Исходный вариант структуры генерируется, а затем оценивается с позиции условий работоспособности (например, по обеспечению заданных параметров качества изделия). Для каждого варианта структуры предусматривается оптимизация параметров, так как оценка должна выполняться по оптимальным или близким к оптимальным значениям параметра.
В современных условиях совершенно очевидна необходимость системного подхода к автоматизированному проектированию, представляющему собой комплекс средств автоматизации в его взаимосвязи с необходимыми подразделениями проектной организации или коллективом специалистов (пользователи системы), выполняющих проектирование. Можно формулировать ряд принципов, которые используются при создании систем автоматизированного проектирования, в том числе проектирования технологических процессов согласно ГОСТ 22487– 77:
САПР создается как автоматизированная система, где проектирование ведется с помощью ЭВМ и важным звеном которого является инженер-проектировщик;
САПР строится как открытая развивающаяся система. Разработка САПР занимает продолжительное время, и экономически целесообразно вводить ее в эксплуатацию по частям по мере готовности. Созданный базовый вариант системы может расширяться. Кроме того, возможно появление новых, более совершенных математических моделей и программ, изменяются также и объекты проектирования;
Рисунок 5.1 - Схема процесса проектирования на 1-м уровне
САПР создается как иерархическая система, реализующая комплексный подход к автоматизации на всех уровнях проектирования. Блочно-модульный иерархический подход к проектированию сохраняется при применении САПР. Так, в технологическом проектировании механосборочного производства обычно включают подсистемы: структурного, функционально-логического и элементного проектирования (разработка принципиальной схемы технологического процесса, проектирование технологического маршрута, проектирование операции, разработка управляющих программ для станков с ЧПУ). Возникает необходимость обеспечения комплексного характера САПР, т. е. автоматизации на всех уровнях проектирования. Иерархическое построение САПР относится не только к специальному программному обеспечению, но и к техническим средствам (центральному вычислительному комплексу и автоматизированным рабочим местам);
САПР как совокупность информационно-согласованных подсистем означает, что обслуживание всех или большинства последовательно решаемых задач ведется информационно-согласованными программами. Плохая информационная согласованность приводит к тому, что САПР превращается в совокупность автономных программ.
Структурными частями САПР являются подсистемы. Подсистема – выделяемая часть системы, с помощью которой можно получить законченные результаты. Каждая подсистема содержит элементы обеспечения. Предусматриваются следующие виды обеспечения, входящие в состав САПР:
методическое обеспечение – совокупность документов, устанавливающих состав и правила отбора и эксплуатации средств обеспечения автоматизированного проектирования;
информационное обеспечение – совокупность сведений, представленных в заданной форме, необходимых для выполнения проектирования (совокупность каталогов, справочников и библиотек на машинных носителях);
математическое обеспечение – совокупность математических методов, математических моделей и алгоритмов, представленных в заданной форме и необходимых для автоматизированного проектирования;
лингвистическое обеспечение – совокупность языков проектирования, включая термины и определения, правила формализации естественного языка и методы сжатия и развертывания текстов, представленных в заданной форме и необходимых для автоматизированного проектирования;
программное обес печение – совокупность машинных программ, представленных в заданной форме, необходимых для выполнения проектирования. Программное обеспечение делят на две части: общее, которое разрабатывается для решения любой задачи и специфику САПР не отражает, и специальное программное обеспечение, включающее все программы решения конкретных проектных задач;
техническое обеспечение – совокупность взаимосвязанных и взаимодействующих технических средств, предназначенных для автоматизированного проектирования. Наиболее успешно эти требования могут быть удовлетворены на основе применения ЭВМ единой серии (ЕС ЭВМ);
организационное обеспечение – совокупность документов, устанавливающих состав проектной организации и ее подразделений, связи между ними, их функции, а также форму представления результатов проектирования и порядок рассмотрения проектных документов, необходимых для выполнения проектирования.
Работа САПР проводится в двух режимах – пакетном и диалоговом.
Режим пакетной обработки (автоматический) предусматривает автоматическое решение задачи по составленной программе без вмешательства проектировщика в ход решения. Оператор, пользуясь терминалом, вводит необходимые данные. Этот режим применяют в тех случаях, когда удается заранее предусмотреть все возможные ситуации при решении и формализовать выбор продолжений решений в точках ветвления алгоритма, а также когда требуется большое время счета между точками ветвления.
Диалоговый режим (оперативный или интерактивный) используется в случаях, когда: 1) существуют трудно-формулизируемые правила и процедуры для принятия решения (например, распределение переходов по позициям многооперационных станков, выбор баз и другие решения); 2) объем числовой информации, подлежащий вводу в ЭВМ в процессе диалога, невелик (при большом объеме информации диалог затягивается и аппаратура используется малоэффективно); 3) время ожидания решений должно составлять от нескольких секунд, - для часто повторяющихся процедур, до нескольких минут - для редко встречающихся процедур.
Классификация САПР
Установлены следующие признаки классификации САПР (ГОСТ 23501.108–85): тип объекта проектирования; разновидность объекта проектирования; сложность объекта проектирования; уровень автоматизации проектирования; комплексность автоматизации проектирования; характер выпускаемых документов; число выпускаемых документов; число уровней в структуре технического обеспечения.
По каждому признаку имеются классификационные группировки САПР и их коды, которые определяют принадлежность создаваемой системы к определенному классу САПР.
Коды классификационных группировок различают по признакам сложности объекта проектирования, уровню автоматизации проектирования, комплексности автоматизации проектирования и по числу выпускаемых документов определяют по отраслевым нормативно-техническим документам.
Уровень автоматизации проектирования показывает, какую часть процесса проектирования (в %) выполняют с использованием средств вычислительной техники; комплексность автоматизации проектирования характеризует широту охвата автоматизацией этапов проектирования определенного класса объектов.
По первому признаку – тип объекта проектирования – установлены три кода классификационной группировки для машиностроения (ГОСТ 23501.108– 85):
САПР изделий машиностроения – для проектирования изделий машиностроения;
САПР технологических процессов в машиностроении – для проектирования технологических процессов в машиностроении;
САПР программных изделий – для проектирования программ ЭВМ, станков с ЧПУ, роботов и ТП.
Код и наименование классификационной группировки по признаку «Разновидность объекта проектирования» определяют по действующим классификаторам на объекты, проектируемые системой:
для САПР изделий машиностроения и приборостроения – по классификаторам ЕСКД или Общесоюзному классификатору промышленной и сельскохозяйственной продукции (ОКП);
для САПР технологических процессов в машиностроении и приборостроении – по классификатору технологических операций в машиностроении и приборостроении или по отраслевым классификаторам.
Сложность объектов проектирования определяется пятью кодами классификационной группировки: САПР простых объектов (технологическая оснастка, редуктор), САПР объектов средней сложности (металлорежущие станки), САПР сложных объектов (трактор), САПР очень сложных объектов (самолет) и САПР объектов очень высокой сложности.
Существуют три классификационные группировки уровня автоматизации проектирования: система низко-автоматизированного проектирования, когда уровень автоматизации проектирования составляет до 25 %; система средне-автоматизированного проектирования – уровень автоматизации проектирования составляет 25 ... 50 %; система высокоавтоматизированного проектирования – уровень автоматизации проектирования составляет свыше 50 %.
Одноэтапная, многоэтапная, комплексная САПР определяет комплексность автоматизации проектирования.
Установлено три кода классификационной группировки уровней в структуре технического обеспечения САПР: одноуровневая – система, построенная на основе средней или большой ЭВМ со штатным набором периферийных устройств, включая средства обработки графической информации; двухуровневая – система, построенная на основе средней или большой ЭВМ и взаимосвязанных с ней одного или нескольких автоматизированных рабочих мест (АРМ), имеющих собственную ЭВМ; трехуровневая – система, построенная на основе большой ЭВМ, нескольких АРМ и периферийного программно-управляемого оборудования для централизованного обслуживания этих АРМ, или на основе большой ЭВМ и группы АРМ, объединенных в вычислительную сеть.
Пример формализованног о описания САПР
Коды классификационных группировок САПР – Станки:
1.041000.2.1.2.1.1.1.2.
| Номер классификационной группировки САПР | Код классификационной группировки | Наименование классификационной группировки | Классификаторы, стандарты, методики или др. документы, в соответствии с которыми определены коды классификационных группировок |
| 1 2 3 4 5 6 7 8 | 1 041000 2 1 1 1 1 2 | САПР изделий машиностроения Станки и линии для обработки резанием (кроме деревообрабатывающих) САПР объектов средней сложности Система низкоавтоматизированного проектирования. Уровень автоматизации проектирования 22.5 «/о САПР, одноэтапная. Выполняет один этап конструкторского проектирования (конструирования) САПР, выпускающая документы на бумажной ленте и листе ПОИСК ПО САЙТУ: |
И занявшую второе место.
Зинина Инна Николаевна , кандидат технических наук, доцент кафедры «Технология машиностроения» Московского государственного технического университета «МАМИ»
Практически все производители САПР ТП в настоящее время развивают и усовершенствуют известные подходы к проектированию технологических процессов (ТП). Системы обрастают множествами дополнительных модулей и, в то же время, настоящей автоматизации труда технолога мы так и не видим. В данной статьерассматриваются возможные варианты развития автоматизации процесса проектирования технологий. По мнению автора статьи, многое из этого можно было бы воплотить на существующей математической базе программных продуктов ВЕРТИКАЛЬ и КОМПАС от АСКОН.
Системы автоматизированного технологического проектирования, в том числе ВЕРТИКАЛЬ, остаются продуктами,облегчающими труд технолога, но не автоматизирующими его. О чем идет речь, спросите вы? Давайте разберемся.
Разработка технологии изготовления или сборки является процессом непростым и многовариантным как по возможному набору операций, так и применяемому оборудованию, оснастке. Сегодня проектирование техпроцессас использованием САПР сводится к двум возможностям – проектирование с использованием процесса-аналога (типового, группового, обобщенного) или с использованием баз данных по отдельным операциям, переходам, оборудованию и т.п.
Рассмотрим первый вариант – процесс-аналог. В машиностроении в советские годы были разработаны и внедрялись, практически централизовано, типовые техпроцессы. Позволю себе напомнить, что под типовым ТП понимается технологический процесс, разработанный для изготовления (или сборки) изделия-представителя, которое включает в себя все возможные конструкторские элементы, свойственные данному конструктивному типу изделий. Типовые ТП были собраны в справочники и альбомы, которые издавались и были доступны промышленным предприятиям. Сейчас ценность старых изданий не очень велика, а новых просто не существует. Изменилось оборудование, инструмент, а, следовательно, и подходы к изготовлению тех же самых изделий. Самостоятельное создание типовых ТП, в рамках одного предприятия, занятие крайне трудоемкое, требующее высокой квалификации технологов. Использование типовых ТП наиболее оправдано на предприятиях с ограниченной номенклатурой изделий, не сильно отличающихся конструктивно.
Аналогичная ситуация просматривается и для групповых ТП. Для них характерна не только конструктивная общность, но и общность используемого оборудования и оснастки. Групповые техпроцессы всегда были выгодны при поточной организации производства. В отличие от типовых, групповые ТП разрабатываются только на конкретном предприятии. Эти ТП требуют разработки групповой заготовки и групповой детали, которая включает в себя все конструктивные элементы деталей, входящих в группу. И здесь опять требуется серьезная квалификация технолога и дополнительная работа конструктора.
Еще один вариант процесса-аналога это обобщенный технологический процесс. Если говорить просто, этот процесс склад всех возможных технологических операций, которые нужны для изготовления конструктивно схожих деталей. В отличие от типового, такой ТП избыточен, по нему не возможно изготовить никакого изделия без серьезной предварительной редакции. Такой ТП легко создать, объединив несколько единичных ТП, но не просто редактировать. Обобщенный ТП можно рассматривать как своего рода базу данных по обработке (сборке) конкретного вида изделий.
Каковы недостатки процессов-аналогов с точки зрения их использования в автоматизированном проектировании? Первый и очевидный недостаток – необходимость формирования базы данных по таким процессам. Чаще всего для этого на заводе переписываются старые, «бумажные» ТП с внесением необходимого количества неизбежных ошибок при переписывании. Второй недостаток связан с типом производства. Если завод, к примеру, выпускает N-ое количество типов поршневых насосов, то этот недостаток там заметен не будет. Он проявится на многономенклатурных предприятиях, где большинство изделий имеют специфическую конструкцию, и следовательно, разработка типовых или групповых процессов не оправдывает затрат на неё.
Второй вариант – создание единичных технологических процессов с использованием баз данных. В целом этот вариант представляет собой самый обычный процесс разработки ТП. Обычный в том смысле, что он ничем не отличается от написания вручную. Время экономится на том, что текст переходов в той или иной мере уже присутствует в базе данных, новыбор стратегии обработки, оборудования и инструмента, остается в руках технологов. И здесь придется упомянуть, еще одну, третью по счету, но не по важности, российскую проблему – очень низкий уровень компьютерной грамотности большинства технологов. На любых отечественных заводах бросается в глаза состав технологических бюро – сотрудники пенсионного возраста и совсем молодые люди, вчерашние или нынешние студенты. Первые в силу возраста и устоявшихся представлений привыкли работать с бумагой, а вторые, хорошо владея компьютером, не обладают достаточным технологическим опытом. В результате низкая эффективность от внедрения технологических САПР.
Для людей в возрасте, никогда не работавших на компьютере проще и быстрей проектировать так, как они привыкли, т.е. на бумаге. Вчерашние студенты (конечно, не все) создают малоудачные, как в плане стратегии, так и в плане конечного результата, техпроцессы. При этом старшим необходимо контролировать их, т.к. САПР этого не делает. Контроль, чаще всего, идет по распечаткам, т.е. теряется преимущество безбумажного документооборота и время на перепроверку.
Есть и третий путь. Использование модульной технологии проектирования, разработанной профессором ИМАШ им. Благонравова РАН Базровым Б.М. В ВЕРТИКАЛЬ этот подход реализован через понятие конструкторско-технологических элементов. Это очень интересный путь проектирования. Любое изделие можно представить как набор стандартных элементов – цилиндров, плоскостей, фасок и др. Каждому стандартному элементу в зависимости от размеров, квалитета точности и шероховатости можно сопоставить перечень последовательных операций. Основной проблемой здесь является этот перечень. В системе имеется некое количество КТЭ с вариантами их обработки, но их крайне мало. Предполагается, что на предприятии сами могут продолжить создание КТЭ, а главное, создание стратегий обработки каждого из них. И здесь, озвученная выше проблема номер три становится проблемой номер один. Технолог должен обладать большим опытом и знанием технологий в целоми модульной технологии в частности, а так же знать оборудование и оснастку. В результате самый продуктивный, на мой взгляд, вариант проектирования ТП остается мало востребованным.
Из всего вышесказанного просматривается два вывода. Один из них никак не связан с САПР как таковой, поскольку речь идет о подготовке технологов. И здесь самое разумное это не столько критиковать, сколько порекомендовать руководителям предприятий, регулярно повышать квалификацию технологов через обучение. Второй вывод, собственно тот, ради которого и затевалась данная статья – существующие САПР ТП не автоматизируют труд технолога, поскольку никак не влияют на принятие им технологических решений. Следовательно, все ошибки, свойственные бумажному проектированию, остаются и в проектировании электронном. Ошибки при проектировании ТП это низкое качество конечного продукта при значительных затратах времени и средств. Внедрение более широкой автоматизации при проектировании ТП позволит отчасти снять остроту вопроса квалификации технолога за счет формирования первичного ТП на основе известных технологических правил, не дающих совершить серьезные промахи.
Существует объективная причина сложившейся ситуации. Разработка ТП является процессом творческим, т.е. малоформализуемым. Его очень трудно свести к математике как таковой, лежащей в основе любой САПР. Учитывая научный характер данной проблемы, её не удастся решить силами одной компании-разработчика САПР, даже такой уважаемой, как АСКОН. Что можно бы изменить на следующем этапе развития ВЕРТИКАЛЬ и КОМПАС, исходя из того что уже сделано и не залезая в научные дебри?
Во-первых, хотелось бы увидеть работу САПР ТП не только на этапе написания технологии. Проектирование ТП начинается с оценки технологичности конструкции. Это звено связывает работу конструктора и технолога с условиями предприятия, на котором будет производиться изделие. Отработка на технологичность один из ответственных и сложных этапов. Читая курс технологии машиностроения в машиностроительном ВУЗе, могу сказать, что это одна из сложнейших тем, следовательно, уровень понимания и освоения её технологами без большого производственного опыта крайне низок. Отработка обычно проводится в два этапа. Первый - качественный анализ конструкции с точки зрения возможности еёизготовления на данном предприятии исходя из существующего оборудования и оснастки. Второй этап – количественная оценка технологичности по формальным показателям. В настоящее время отработки на технологичность в рамках САПР не производится вовсе. Какие пути видятся в решении этой проблемы? Наиболее простым этапом для автоматизации является этап количественной оценки. Несложными для расчета и довольно информативными показателями на этом этапеявляются коэффициенты. Для оценки технологичности детали ГОСТ 14.201 рекомендует следующие:
Коэффициент использования материала уже рассчитывается в ВЕРТИКАЛЬ. Для определения других коэффициентов достаточно чертежа или модели с размерами и техусловиями. Квалитеты точности присутствуют на чертеже в виде допусков и/или посадок. Для устранения ручного подсчета необходимо, чтобыCAD-система передавала сведения о количестве поверхностей (граней) детали, количестве и квалитете точности размеров. В КОМПАС есть справочник, из которого конструктор выбирает допуски и посадки (Рисунок 1), а значит, существует принципиальная возможность подсчета использованных допусков и посадок. Аналогичная ситуация и с коэффициентом шероховатости, если шероховатость проставляется на чертеже или модели с использованием справочника. Коэффициент унификации конструкторских элементов показывает количество унифицированных поверхностей. Этот коэффициент можно сравнительно легко определить, если при конструировании использовался модуль КОМПАС-Shaft 2D или 3D. Библиотечные элементы, создаваемые с помощью модуля, стандартны и унифицированы (Рисунок 2) и их количество, использованное в конструкции, не сложно подсчитать. Значения всех коэффициентов сравниваются с нормативными с учетом типа производства. Результат – подсказка технологу, что по такому-то показателю деталь нетехнологична, недостаточно технологична, технологична. Решение принимает технолог, но время на принятие решения уже значительно сокращается за счет автоматизированного расчета.
Рисунок 1
Приведенные коэффициенты не исчерпывают всего существующего перечня оценок технологичности, но являются наиболее удобными с точки зрения математических расчетов, данные для которых можно получить с модели детали.Оценка основных показателей технологичности, а именно трудоемкости изготовления и технологической себестоимости, до разработки ТП может производиться только по процессам-аналогам, что составляет определенную трудность. Определение технологичности сборочной единицы является еще более сложной задачей, и останавливаться на показателях и их возможном определении в рамках данной статьи я не буду.
Рисунок 2
Автоматизация, даже частичная, качественной отработки конструкции детали на технологичность довольна проблематична. Здесь, в настоящий момент, возможен, по моему мнению, только один вариант – сравнение в автоматизированном режиме заданного квалитета точности с технологическими возможностями оборудования. Для этого в справочнике по оборудованию следует предусмотреть возможность указания паспортных данных по точности каждого экземпляра оборудования. Кроме того требуется разработать процедуру сравнения данных чертежа (модели) с данными справочника. Например, при указании на поверхность размера Xс квалитетом Yсистема должна показать технологу все оборудование его участка, обеспечивающее такую точность при обработке указанного размера. Эта процедура в дальнейшем может существенно упростить стратегию обработки, за счет исключения избыточных операций.
Во-вторых, автоматизация всего процесса создания ТП, на мой взгляд, более вероятна при переходе на модульную технологию, т.е. проектирование через КТЭ. Причем и традиционное проектирование с использованием процессов-аналогов может быть автоматизировано с большей вероятностью при использовании для отбора аналога и его редактирования модели изделия, сформированной из конструкторско-технологических элементов.
Для развития автоматизации проектирования техпроцессов на основе КТЭ необходимо решить следующие вопросы: разбивать деталь на КТЭ в автоматическом режиме при передаче её из CAD-системы, расширить базу данных по КТЭ с сопоставлением операций обработки, связать выбор стратегии обработки КТЭ с оборудованием, существующим на участке (в цехе). Учитывая, что технология может разрабатываться под новое, еще не приобретенное оборудование, следует предусмотреть возможность указать этот факт при проектировании, например, путем отключения фильтрации операций по оборудованию. Тогда начальный этап автоматизированного проектирования единичного ТП может выглядеть так, как показано на рисунке 3.
Рисунок 3
Первичный ТП подлежит редактированию для создания из переходов обработки операций. Можно формировать первичный техпроцесс и на уровне операций, если добавить автоматическое объединение переходов на базе общности используемого оборудования. Однако здесь возможно возникновение большого числа ошибок. Число ошибочных объединений переходов может быть уменьшено за счет учета схем установки заготовки. Автоматизация создания таких схем на сегодняшний день не возможна, но схемы могут создаваться пользователем в диалоговом режиме с указанием базовых поверхностей на модели или чертеже.
Еще один вопрос – это автоматизация выбора инструмента. Если каждому виду КТЭ можно сопоставить очередность операций обработки, то каждой операции можно сопоставить тип используемого инструмента. Это и сейчас происходит при проектировании в ВЕРТИКАЛЬ, но вот выбор конкретного экземпляра инструмента опять зависит от пользователя. Что можно автоматизировать? По материалу заготовки можно произвести выборку инструмента по режущему материалу с фильтрацией по наличию в цехе. По схеме установкиопределить ориентацию инструмента при обработке (правый, левый, симметричный). По данным станка тип, размер, форму сечения и длину державки, необходимость использования переходных втулок. Размер режущей части обычно определяется по величине снимаемого припуска. Если номенклатура инструмента на производстве ограничена, то это может быть опущено при выборе, путем отмены фильтрации по припуску. Вид обработки (черновая, чистовая и др.) и условия позволяют определить геометрию режущей части.
Таким образом, увеличив процент автоматизации принятия технологических решений на начальном этапе, мы получим на выходе «заготовку» технологического процесса, максимально соответствующую условиям существующего производства. На этапе редактирования технологи должен будет добавить оснастку, вспомогательные материалы и выполнить расчет режимов резания. Автоматизированный этап позволит уменьшить число грубых ошибок и сэкономит время на разработку стратегии изготовления. Первичных ТП может быть сформировано несколько, и лучший вариант будет отбираться путем оптимизации.
Рассматривая вопросы проектирования технологии, традиционно останавливаются на механической обработке или отдельно сварке, литье, штамповке. Процессы сборки можно считать в этом отношении нелюбимым пасынком. Хотелось отчасти компенсировать этот недостаток, хотя бы потому, что в России сейчас развивается очень много автосборочных производств.
К техпроцессам сборки в основном применимы все те проблемы автоматизации, которые уже были упомянуты, но есть и специфика. В ВЕРТИКАЛЬ V4 был решен вопрос передачи сведений о комплектности сборочной единицы из спецификации в технологию, что значительно упростило процесс комплектования. Следующее решение, которое хотелось бы увидеть это автоматизации получения схем сборки. Уже сейчас за счет интеграции ВЕРТИКАЛЬ и КОМПАС можно было бы сделать определенные шаги в этом направлении.
Основой для разработки сборочного процесса является схема сборки, т.е. определение базовых и присоединяемых деталей на каждом этапе и разделение её на подсборки. Для этого используются два комплекса условий: базирования и доступа к месту установки элемента. Условие базирования при установке элемента выполняется, если среди установленных ранее элементов есть такие, которые образуют хотя бы один состав сборочной базы. Условие доступа к месту установки элемента, выполняется, если среди установленных ранее нет элементов, препятствующих установке данного элемента. Варианты декомпозиции сборки, определяемые этими условиями, могут стать основой для разработки схемы.
Определение базовых и присоединяемых деталей, а, следовательно, варианта декомпозиции, можно было бы производить по сопряжениям, которые накладываются в сборке и порядку их наложения. Так как в сборочной операции основным переходом, определяющим качество сборки, является выполнение соединения, при декомпозиции следует отдельно учитывать операции соединения.
В отличие от сопряжения, соединение может образовываться только при использовании крепежных деталей, веществ или специальных поверхностей. Определение крепежных деталей не составляет трудности и сегодня. Для решения проблем с веществами и поверхностями можно предложить следующее. В КОМПАС-3D в сборочном модулепредусмотреть отдельную функцию соединения с использованием вещества. Например, сопрягая две поверхности фланцев по плоскостям указать наличие герметика, который будет выбираться из справочника материалов, в такой последовательности: Сопряжение – По плоскости – С материалом(Без) – Полимер (Металл) - Выбрать(Справочник материалов) . Аналогичным образом можно указыватьналичие сварного шва, пайки, клеевых соединений. В случае указанияБез материала получим обычное сопряжение, с материалом – соединение.
Специальные поверхности для сборки это зубья, резьбы, шлицы, РК-профиль, конусы, поверхности под посадки и т.п. Большинство сопряжений с ними может быть классифицировано как соединение по указанным посадкам и/или допускам и особенностям формирования при проектировании (резьба). Сложности возникают при наличии на одномэлементе нескольких сопряжений, например ось и торец. Поэтому и для таких случаев представляется разумным использовать разделение на сопряжение и соединение. Для возможного кинематического анализа конструкций соединения можно разделять на подвижные и неподвижные.
После декомпозиции и получения схем сборки технолог может начать разрабатывать варианты ТП, соответствующие предложенным схемам. При этом каждая операция будет автоматически комплектоваться деталями в соответствии с используемой схемой. Более полная автоматизация проектирования ТП сборки возможна только при автоматизации самого производства, т.е. при использовании автоматических линий с известными техническими параметрами.
Предложения, изложенные в данной статье, не являются открытиями в области автоматизации. Они в виде общих идей существуют не один год. Многие из них можно реализовать уже сейчас, другие после более детальной проработки.Совершенствование уже существующих подходов является тупиковым вариантом развития САПР ТП, поскольку предполагает наращивание баз данных, но не знаний. Давайте перестанем бояться новых идей и двинем их вперед или вверх, по ВЕРТИКАЛИ.