Подсистема проектирующая

Как и любая сложная система, САПР состоит из подсистем. Различают подсистемы проектирующие и обслуживающие. [c.27]

В подсистеме проектируются соответствующие конструкции штампов. Анализируются размеры внутренних контуров штампуемой детали, размеры отверстий в детали, минимальные размеры перемычки между отверстиями, марки и толщины штампуемого материала. По полученным результатам выбирается вид применяемого штампа совмещенного, последовательного или простого действия (для пробивки). Для деталей, которые не могут быть изготовлены в штампе совмещенного действия, определяется минимальное число шагов в штампе последовательного действия или минимальное число переходов в штампе простого действия для пробивки отверстий. Программно решаются разные задачи конструирования расчет габаритов и выбор типоразмеров пакета выбор мест установки шаговых ножей, фиксаторов и упоров компоновка системы выталкивания определение центра тяжести системы точечных масс и усилия вырубки расчет деталей на прочность определение размеров матрицы и пуансона и допу- [c.436]

Для каждого устройства или подсистемы проектирующий ее конструктор или группа конструкторов сами выбирают комплектующие. Однако во многих случаях их целесообразно унифицировать или интегрировать. И тогда возникает задача согласования выбора агрегатов и элементов несколькими заинтересованными конструкторами или группами конструкторов. [c.32]

Исходной информацией для этапа 1 проектирования является информация о детали, для которой проектируется заготовка. Приведенная схема инвариантна к типам штамповочного оборудования, форме и размерам детали, но правила создания каждой подсистемы зависят от ряда факторов, например от конструкции детали, технических требований и др. Это предопределяет создание нескольких локальных подсистем для каждого типа оборудования класса заготовок (поковок). Самые простые детали, для которых проектируются заготовки,— это осесимметричные детали типа тел вращения (класс 1), а наиболее сложные — асимметричные тела произвольной формы (класс 4). В соответствии с этим направление развития САПР в горячештамповочном производстве — переход от автоматизированного проектирования поковок для простых деталей к более сложным [17]. [c.89]

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

В САПР БИС выделено несколько подсистем, имеющих свое программное обеспечение в ЦВК и в ИГК. Основными проектирующими подсистемами САПР БИС являются подсистемы структурно-приборного, схемотехнического, логического и топологического проектирования. [c.88]

Среди выбираемых или планируемых для разработки ПМК должны быть предусмотрены не только проектирующие, но и обслуживающие подсистемы программного обеспечения, например СУБД. [c.358]

Деление САПР на подсистемы, обладающие свойствами и функциями самостоятельных систем, устанавливает ГОСТ 23501.0—79. Проектирующие подсистемы делятся на объектно-ориентированные, зависящие от конкретного объекта проектирования, и объектно-независимые (инвариантные), выполняющие унифицированные проектные процедуры и операции. [c.30]

Проектирующими подсистемами ПО могут быть простые программы, ориентированные па узкий класс объектов и использующие простые аналитические модели. Но чаще проектирующие подсистемы ПО представляют собой универсальные пакеты прикладных программ сложной структуры, обладающие своими мониторами, локальными базами данных и средствами их управления, поэтому ниже наряду с термином проектирующая подсистема ПО будем использовать и другой термин — проектирующий пакет ПО . Некоторые из таких пакетов могут реализовывать не только отдельные проектные операции и процедуры, но и законченные их маршруты, а также допускать множественный доступ (т. е. работу одновременно с несколькими пользователями), в последнем случае они долл ны иметь свои локальные средства поддержки диалогового взаимодействия. [c.26]

Проектирующие и обслуживающие подсистемы [c.27]

Для обеспечения доступа к одной проектирующей подсистеме ПО нескольким пользователям может быть [c.28]

Взаимодействие подсистем. Взаимодействие управляющей подсистемы ПО и мониторов проектирующих пакетов осуществляется через стандартный интерфейс, представляющий собой формальные правила передачи фактических параметров. В проектирующие подсистемы ПО передаются [c.29]

Некоторые проектирующие подсистемы ПО для решения задач высокой размерности требуют больших затрат машинного времени и ОП, например задачи анализа сложных динамических объектов, их параметрическая оптимизация, синтез тестов для цифровых устройств, трассировка печатных плат и т. д. Использование интерактивного режима на этапе счета таких задач нецелесообразно, но он необходим на подготовительных стадиях и при интерпретации результатов. Для таких случаев в составе ПО САПР необходимо иметь обслуживающую подсистему образования фоновых заданий. Если САПР функционирует на вычислительной установке, имеющей связь с другими ЭВМ, то такая подсистема должна обеспечивать возможность передачи фоновых заданий на одну из этих ЭВМ. После завершения фонового задания его результаты могут быть просмотрены и обработаны пользователем средствами проектирующей подсистемы ПО, породившей это задание. [c.30]

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

Организация технического обеспечения САПР оказывает влияние на структуру информационного обеспечения и в первую очередь баз данных. Если БД сконцентрирована в одном узле вычислительной сети, то она называется сосредоточенной, в противном случае — распределенной. Если информационное обслуживание с помощью БД относится ко всей САПР, то БД называют общей (интегрированной или центральной), а если к отдельной проектирующей подсистеме САПР или к отдельному пакету прикладных программ, то локальной БД. [c.56]

Среди проектирующих пакетов различают пакеты-интерпретаторы и пакеты-трансляторы. В пакетах-трансляторах расчету предшествует этап генерации рабочей программы, реализующей необходимый для расчета алгоритм. В пакете-интерпретаторе все расчеты выполняются с помощью универсальной обрабатывающей подсистемы. Пакеты-трансляторы более быстродействующие по сравнению с пакетами-интерпретаторами, но требуют больших затрат памяти. [c.153]

Процесс проектирования в САПР, т. е. непосредственное решение проектных задач, выполняется с помощью проектирующих подсистем 1, 2 (см. рис. 1.1). Каждая проектирующая подсистема имеет почти те же функции, что и САПР в целом, но применительно к более узкому кругу задач. Проектирующая подсистема выполняет самостоятельный этап проектирования в законченной форме, т. е. с выдачей соответствующей документации. Функции проектирующих подсистем реализуются в САПР программным путем. [c.21]

Управление работой проектирующей подсистемы разделяется между центральной подсистемой управления и собственным управлением. Центральное управление организует взаимодействие проектирующей подсистемы с другими подсистемами собственное управление организует автономную работу подсистемы. Из всех подсистем САПР проектирующие подсистемы являются наименее универсальными. Поэтому они обычно называются объектно-зави-симыми подсистемами в отличие от остальных подсистем, называемых объектно-независимыми (инвариантными). [c.21]

Каждая проектирующая подсистема оперирует определенными входными и выходными информационными массивами. При взаимодействии подсистем в процессе проектирования выходная информация одной подсистемы частично используется в качестве входной информации для других подсистем. Для передачи информации от одной подсистемы непосредственно к другой необходимо, чтобы все информационные массивы имели одинаковую структуру. Однако это условие не всегда выполнимо. Как правило, структуры информационных массивов различных проектирующих подсистем существенно отличаются друг от друга. Поэтому проблема информационной согласованности проектирующих подсистем в САПР решается иным путем — путем создания единой информационной основы в виде самостоятельной информационно-поисковой подсистемы (см. рис. 1.1.), называемой также банком данных или автоматизированной базой данных (АБД). [c.21]

Проектирующие подсистемы САПР [c.41]

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

Основные задачи подсистемы АПТАР соответствуют этапам автоматизации технологического проектирования. Сначала определяется исходггая заготовка. Затем проектируются технологический маршрут и операции. Последовательность операций устанавливают, исходя из данных о детали, размере партии и других сведений. [c.147]

САПР создается как иерархическая система, реализующая комплексный подход к автоматизации на всех уровнях проектиро-вапня. Блочно-модульный иерархический подход к проектированию сохраняется при примепении САПР. Так, в технологическом проектнроБаипи механосборочного производства обычно включают подсистемы структурного, функционально-логического и элементного проектирования (разработка принципиальной схемы технологического процесса, проектирование технологического маршрута, проектирование операции, разработка управляющих программ для станков с ЧПУ). Возникает необходимость обеспечения комплексного характера САПР, т. е. автоматизации на всех уровнях проектирования. Иерархическое построение САПР относится не только к специальному программному обеспечению, [c.110]

По назначению подсистемы САПР делятся на проектиру-ющие (например, подсистема проектирования деталей и сборочных единиц, или частей зданий и сооружений, или подсистема технологического проектирования) и обслуживающие [c.30]

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

ПП —/-я проектирующая подсистема ДП — диалоговая подсистема ИП— инструментальная подсистема СУБД — система управления базами данных ГШМГ — подсистема интерактивной машинной графики. [c.24]

Подсистема интерактивной машинной графики ПИМГ (рис. 1.10) занимает промежуточное положение между проектирующими и обслуживающими подсистемами ПО. С одной стороны, средства машинной графики обслуживают ряд проектирующих подсистем (обычно это пакеты функционального проектирования), где ОЛИ используются в основном для наглядного представления исходной и выходной информации (в виде схем, Bip M HHbix диаграмм, гистограмм и т. д.). С другой стороны, во многие подсистемы конструкторского проектирования ПО интерактивной машинной графики входит как основная часть. Поэтому в САПР возможно наличие нескольких пакетов машинной графики (базового в качестве обслуживающего и одного или более в составе проектирующих подсистем конструирования). [c.26]

Программное обеснеченне САПР орнентировлно на раздельное редактирование всех его нодснстем н их динамическую загрузку в ОП по мере надобности. На рис. 1.11 показано распределение доступной зоны ОП при функционировании ПО такой структуры. Монитор и диалоговая подсистема ПО резидентны, т. е. постоянно находятся в ОП. В смежную с ними область динамически загружаются обслуживающие и проектирующие подсистемы ПО, ирн этом обслуживающие подсистемы занимают участки памяти с меньшими адресами. Оставшаяся не занятой область памяти может быть использована для размещения данных. Динамическая структура ПО по сравнению с оверлейной структурой, требующей совместного редактирования всех подсистем ПО, характеризуется легкостью расширения и модификации, а также значительной экономией ОП. Однако для динамической структуры необходимы дополнительные затраты на организацию взаимодействия проектирующих и обслуживающих подсистем. [c.27]

Язык управления монитором САПР достаточно прост, в его основе лежат команды вызова необходимых проектирующих подсистем ПО и задания им управляющих параметров, а также команды, описывающие способ информационного обмена между подсистемами — через оперативную или внешнюю память, посредством подсистемы управления базой данных. Средства этого языка должны позволять создавать макрокоманды, определяющие марщруты выполнения проектирующих подсистем ПО. Языки управления проектирующих пакетов значительно сложнее, поскольку должны отражать все возможн1>1е постановки задач проектирования в конкретных предметных областях, решение которых допускают пакеты. Обычно эти языки имеют процедурный характер (см. 5.3). [c.28]

В общем случае загруженные проектирующие подсистемы ПО могут функционировать либо как обычные подпрограммы, подчиненные управляющей нодснсгсме ПО, либо как иараллелыю выполняемые подзадачи, способные соревноваться между собой и монитором за управление. Функционирование нескольких пакетов одновременно в качестве подзадач оправдано. только в случаях, когда каждый из них в отдельности не способен загрузить процессор ЭВМ и распараллеливание не сказывается на эффективности и удобстве работы каждого из пользователей. Очевидно, что при этом каждая из проектирующих подсистем ПО должна иметь свою локальную подсистему диалогового взаимодействия. Создание подзадач — один из способов обеспечения множественного доступа пользователей к САПР, однако его реализация значительно усложняет управляющую подсистему во-первых, возникает задача динамического расиределения ресурсов ЭВМ во-вторых, появляется потребность в механизме, разрешающем каким-либо образом конфликты в работе подзадач. Такие конфликты могут возникнуть, например, при одновременном обращении нескольких проектирующих пакетов к подсистеме управления базой данных. Конфликты могут быть устранены использованием очередей запросов к СУВД, в которых запросы на обслуживание подсистем ПО базой данных располагаются в порядке поступления и приоритетности. [c.28]

Монитор САПР, получив команду на активизацию какой-либо проектирующей подсистемы ПО, считывает из базы да1И1Ых ее паспорт, проверяет корректность команды и возможность загрузки подсистемы. Далее он помещает в ОП необходимые обслуживающие подсистемы ПО (если их там еще нет), вслед за ними — требуемую проектирующую подсистему, а затем в строгом соответствии с данными из паспорта строится обращение к этой иодсистеме. После окончания работы подсистемы опа удаляется из ОП. [c.29]

Динамическая загрузка проектирующих подсистем не позволяет прямо обращаться из них в обслуживаюник подсистемы. Поэтому для организации связи ц проекти- [c.29]

Более широкое примепепие для создания проектирующих пакетов САПР могут найти генераторы, основанные на инвариантности многих элементов математического обеспечения автоматизированного проектирования к предметным областям [7]. Такие генераторы в качестве ядра будущей проектирующей подсистемы ПО используют модули одного или нескольких методоориентированных пакетов, снабжая их монитором. [c.50]

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

Соответственно трем основным этапам проектирования в САПР ЭМП целесообразно выделить три основные проектирующие подсистемы 1) обоснования принципиальных технических решений 2) расчетного проектирования 3) конструкторско-технологического проектирования. Первая подсистема САПР ЭМП в явной форме до настоящего времени не реализована. Это можно объяс- [c.41]

Энциклопедия по машиностроению XXL

Оборудование, материаловедение, механика и ...