Обеспечения САПР

Основные компоненты ПО САПР.Варианты организации ПО САПР разнообразны и зависят от многих факторов, главными из которых являются:

1) предметная область, аспекты и уровни создавае­мых с помощью ПО описаний проектируемых объектов;

2) степень автоматизации отдельных проектных опе­раций и процедур;

3) архитектура и состав технических средств, режим функционирования;

4) ресурсы, отпущенные на разработку ПО.

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

К обслуживающим подсистемам ПО относятся: диалоговая ЦП, управления базами данных СУБД, инстру­ментальная ИП, а также монитор, обеспечивающий взаимодействие всех остальных подсистем и управление их выполнением.

Рис. 1.10. Архитектура специального программ­ного обеспечения САПР:

ПП_i — i-я проектирующая подсистема; ДП — диало­говая подсистема; ИП— инструментальная подсисте­ма; СУБД — система управления базами данных; ПИМГ — подсистема интерактивной машинной гра­фики

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

Подсистема уп­равления базами данных СУБД реализует единообразный доступ к об­щей базе данных (БД) САПР и к индивидуальным БД пользователей. Назначение БД следующее: 1) хранение сведений нормативно-справочного характера (о норма­лях, ГОСТах, унифицированных изделиях, типовых про­ектных решениях, ранее выполненных разработках и т. д.); 2) хранение результатов выполненных этапов те­кущего проекта; 3) обеспечение информационной согла­сованности различных подсистем САПР.

■ Примечание. Эти аспекты использования рассматриваются в гл. 2 и 3.

Инструментальная подсистема прог­раммирования, основу которой составляет генера­тор прикладных программ, синтезирующий новые прог­раммы из унифицированных модулей и подпрограмм, разработанных пользователем, необходима для достиже­нии открытости ПО САПР. Генератор прикладных прог­рамм включает в себя также средства автоматической разработки трансляторов для входных языков проекти­рующих подсистем САПР.

■ Примечание. Использование генераторов прикладных про­грамм как одного из мощных средств разработки ПО рассмат­ривается в § 1.3.

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

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

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

■ П р и м е ч а н и е. В гл. 5 рассматриваются принципы построения проектирующих подсистем на примере программного комплекса автоматизации схемотехнического проектирования.

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

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

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

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

1) прием и интерпретация обращенных к ним команд пользователя;

2) загрузка и активизация компонентов ПО, органи­зация маршрутов их выполнения;

2) установление взаимодействия между подсисте­мами;

3) динамическое распределение памяти;

4) обработка прерываний от дисплея пользователя;

5) сервисные функции (регистрация пользователей, сбор статистики, ведение службы времени, обработка сбоев и т. д.).

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

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

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

■ Примечание. Этот способ еще более сложен, чем предыду­щий, но его применение в подсистемах, ориентированных на ин­тенсивный диалог с пользователем, дает значительный эффект (если, конечно, речь идет об ЭВМ с небольшим объемом ОП).

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

параметры, задающие режим функционирования;

адреса точек входа в обслуживающие подсистемы ПО;

адреса динамически распределенных областей памя­ти, предназначенных для информационного обмена меж­ду различными подсистемами ПО.

Каждый проектирующий пакет, входящий в состав САПР, имеет паспорт, хранящийся в базе данных САПР. Паспорт содержит следующие сведения о проектирую­щем пакете: 1) размер занимаемой области ОП; 2) име­на требуемых обслуживающих подсистем ПО; 3) имена режимных параметров и их значения по умолчанию; 4) имя языка программирования, в стандарте которого пакет использует представление структур данных; 5) ме­стонахождение в пакете обработчика прерываний от дисплея пользователя (если он предусмотрен); 6) указа­тели на возможные способы обмена информацией с дру­гими проектирующими подсистемами ПО (через ОП, базу данных или файловую систему ЭВМ) и т. д.

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

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

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

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

Средства динамического распределения памяти — обязательные компоненты всех современных операцион­ных систем (ОС) и имеются во многих языках програм­мирования (за исключением языков ФОРТРАН и КО­БОЛ).

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

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

Эту проблему решает режим разделения времени, но его реализация средствами прикладного ПО САПР пред­ставляет собой сложную задачу. Более целесообразна реализация режима разделения времени с помощью об­щего программного обеспечения — соответствующих ОС ЭВМ.

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