На правах рекламы:
ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Авторитетность издания

ВАК - К1
RSCI, ядро РИНЦ

Добавить в закладки

Следующий номер на сайте

2
Ожидается:
16 Июня 2024

Моделирование информационной инфраструктуры комплексной САПР

Статья опубликована в выпуске журнала № 1 за 2007 год.
Аннотация:
Abstract:
Авторы: Ачкасов В.Н. () - , Стариков А.В. () - , Куцько П.П. () -
Ключевое слово:
Ключевое слово:
Всего комментариев: 2
Количество просмотров: 12017
Версия для печати
Выпуск в формате PDF (1.53Мб)

Размер шрифта:       Шрифт:

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

Информационная инфраструктура может иметь различный уровень сложности, определяемый рядом факторов, важнейшими среди которых являются: сложность объектов и задач проектирования, реализуемая методология разработки проекта, структура и состояние среды проектирования. Необходимо отметить, что для современных процессов проектирования сложных технических объектов характерны:

-    высокая информационная сложность объектов проектирования, что приводит к необходимости декомпозиции проекта на составные части, к разработке каждой части проекта по отдельности с последующим объединением частных проектных решений в единый совокупный проект;

-    высокая функциональная сложность решаемых задач, что обусловливает необходимость декомпозиции процесса проектирования на этапы и выполнения каждого этапа с помощью соответствующей функциональной (проектирующей) подсистемы;

-    распределенный характер обработки, который реализуется функциональными (проектирующими) подсистемами, расположенными в различных узлах распределенной среды проектирования;

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

Теоретически обоснованная декомпозиция проекта на составные части  предусматривает использование блочно-иерархического подхода к проектированию. Данный подход основывается на структурировании описаний объекта проектирования с разделением описаний на ряд иерархических, или горизонтальных уровней, каждому из которых присущи свой уровень детальности отображения свойств объекта, математические модели, языки и алгоритмы проектирования, а также форма представления проектной документации.

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

В качестве адекватного математического представления для информационной модели проекта может быть выбран конечный гиперграф , где X - множество n вершин , ассоциированных с разрабатываемыми частями проекта в различных аспектах; E - множество m ребер , представляющих отношения между вершинами, то есть между частями проекта;  - логическая функция (инцидентор), определенная для ,  и принимающая значение «истина» (1), если  и  инцидентны, или «ложь» (0) - в противном случае.

Подпись:  
Рис. 1. Гиперграф модели
проекта
Схематично гиперграф информационной модели проекта можно представить в виде совокупности «слоев» - информационных проекций или аспектов проектируемого объекта, «пронизанных» вектором обработки, который задает общее направление  обработки проекта и может быть представлен пронумерованным перечнем аспектов проектирования (рис. 1).

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

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

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

Асинхронный режим функционирования конвейера проектирования обусловлен стохастическим характером временных затрат, требуемых каждой проектной процедуре на выработку проектного решения, и обеспечивается за счет использования хранилища информационных контейнеров. Наличие хранилища контейнеров с проектными решениями позволяет объединить в одном технологическом маршруте проектные процедуры различной производительности и обеспечить максимальную загрузку конвейера.

В современных комплексных САПР обеспечивается мультипроектный режим работы, для которого можно выделить следующие три уровня параллельности:

-    одновременное выполнение ряда проектных процедур для обработки одного и того же проекта;

-    параллельная обработка различных частей одного и того же проекта;

-    одновременное выполнение нескольких различных проектов.

Для моделирования первых двух из указанных уровней параллельной обработки проектов в рамках асинхронного конвейера проектирования необходимо выполнить процедуру суперпозиции (наложения) , где H - гиперграф проекта; G - орграф технологического маршрута проектирования, определенный для проекта. Фактически суперпозиция заключается в привязке частей проекта к соответствующим проектным процедурам; в результате формируется обобщенная информационная модель P процесса проектирования, математическим представлением которой является ациклический орграф сложной структуры.

Для идентификации каждой из проектных процедур, входящих в состав модели P, определены следующие атрибуты (внешние реквизиты, не зависящие от существа выполняемых процедурой действий): идентификаторы проектной процедуры, проектируемого узла, типа проектного решения, ответственного исполнителя, проектирующего подразделения; временные параметры функционирования (планируемые и фактические сроки выполнения); код рабочего состояния (определены следующие состояния проектной процедуры: пассивное, ожидания, выполнение, приостановленное, локально завершенное, глобально завершенное); входные ссылки (идентификаторы проектных процедур, которые формируют проектные решения, поступающие на вход данной процедуры).

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

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

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

Необходимость выполнения откатов предопределяет наличие в орграфе  трех подмножеств дуг : - прямые связи между смежными вершинами (рис. 2); D2 - ближние обратные связи между смежными вершинами; D3 - дальние обратные связи между вершинами, которые не являются смежными, то есть между ними отсутствуют прямые связи, но существует опосредствованная информационная связь.

Перегруженность орграфа  дугами приводит к увеличению накладных расходов при его формировании, хранении и обработке. Например, проектная процедура ПП9 (рис. 2) при трех прямых связях (ПП6-ПП9, ПП7-ПП9, ПП8-ПП9) имеет соответственно три ближних (ПП9-ПП6, ПП9-ПП7, ПП9-ПП8) и пять дальних (ПП9-ПП5, ПП9-ПП3, ПП9-ПП4, ПП9-ПП2, ПП9-ПП1) обратных связей.

Анализ информационных связей между проектными процедурами в технологическом маршруте (глубокий откат) показывает, что дуги, соответствующие дальним обратным связям, можно исключить из рассмотрения без ущерба для общности решения задачи. Учет ближних обратных связей обеспечивает возможность обхода ор­графа в двух направлениях. Если при решении задачи глубокого отката выбрать только одно направление, соответствующее прямым информационным связям в технологическом маршруте проектирования, то из рассмотрения можно исключить и ближние обратные связи проектных процедур.

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

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

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


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=424
Версия для печати
Выпуск в формате PDF (1.53Мб)
Статья опубликована в выпуске журнала № 1 за 2007 год. Версия для печати с комментариями

Возможно, Вас заинтересуют следующие статьи схожих тематик: