Системы автоматизированного проектирования относятся к числу наиболее сложных и наукоемких автоматизированных систем (АС). Наряду с выполнением собственно проектных процедур необходимо автоматизировать также управление проектированием, поскольку сам процесс проектирования становится все более сложным и зачастую приобретает распределенный характер. На крупных и средних предприятиях заметна тенденция к интеграции
САПР с системами управления предприятием и документооборота. Для управления столь сложными интегрированными системами в их составе имеется специальное ПО — системная среда САПР или АС.
Первые системные среды САПР, называвшиеся мониторными подсистемами или Framework (FW), появились на рубеже 70...80-х г.г. В настоящее время основными функциями системных сред САПР являются управление данными, управление проектированием, интеграция ПО, реализация интерфейса с пользователем САПР, помощь в разработке и сопровождении ПО САПР.
Термин Framework применительно к системным средам САПР был введен в 1980 г. фирмой Cadence — одним из пионеров в создании системных сред САПР. Кроме Cadence, тематикой Frameworks для САПР электронной промышленности занималось несколько ведущих в этой области фирм (Mentor Graphics, IBM, DEC, Sun Microsystems и др.), создавших международную ассоциацию CFI (CAD Framework Initiative). Широкую известность получили такие системные среды, как Falcon Framework фирмы Mentor Graphics, Design Framework-2 фирмы Cadence и JCF (Jessy-Common Framework) европейской программы ESPRIT.
Важно отметить, что проблема системных сред САПР, зародившаяся в процессе становления САПР электронной промышленности, получила развитие при реализации CALS-технологии в различных отраслях машиностроения.
В типичной структуре ПО системных сред современных САПР можно выделить следующие подсистемы.
Ядроотвечает за взаимодействие компонентов системной среды, доступ к ресурсам ОС и сети, возможность работы в гетерогенной среде, настройку на конкретную САПР (конфигурирование) с помощью специальных языков расширения.
Подсистемауправленияпроектом, называемая также подсистемой сквозного параллельного проектирования CAPE (Concurrent Art-to-Product Environment), выполняет функции слежения за состоянием проекта, координации и синхронизации, параллельно выполняемых процедур разными исполнителями. Примерами подсистем управления проектами в машиностроении могут служить Design Manager в САПР Euclid, UG/Manager в Unigraphics. Иногда в отдельную подсистему выделяют управление методологией проектирования. При этом под методологиейпонимают совокупность методов и средств образования маршрутом проектирования — последовательностей проектных операций и процедур, ведущих к цели проектирования.
Методы построения маршрутов проектирования (workflow) зависят от типа проектных задач. Различают простые задачи, выполняемые одной программой, линейные, в которых нет разветвлений в межпрограммных связях, и комплексные. Методы построения маршрутов могут быть основаны на предварительном описании задач или на предварительном описании правил конструирования задач. В описании задач фигурируют порты, с которыми соотнесены данные. Порты могут быть обязательными и необязательными, порождающими дополнительные данные или данные нового объекта. Описания задач даются в виде графов или на языках расширения.
Подсистемауправленияметодологиейпроектированияпредставлена в виде базы знаний. В этой базе содержатся такие сведения о предметной области, как информационная модель (например, в виде диаграмм сущность-отношение), иерархическая структура проектируемых объектов (например, в виде И-ИЛИ-дерева), описания типовых проектных процедур, типовые фрагменты маршрутов
проектирования — так называемые потоки процедур, соответствие между процедурами и имеющимися пакетами прикладных программ, ограничения на их применение и т.п. Часто такую БЗ дополняют обучающей подсистемой, используемой для подготовки специалистов к использованию САПР.
Современные системыуправленияпроектнымиданныминазывают PDM ( Product Data Manager), иногда применительно к АСУ используют название EDM (Enterprise Data Manager). PDM предназначены для информационного обеспечения проектирования и выполняют следующие функции:
— хранение проектных данных и доступ к ним, в том числе ведение распределенных архивов документов, их поиск, редактирование, маршрутизация и визуализация;
— управление конфигурацией изделия, т.е. ведение версий проекта, управление внесением изменений;
— создание спецификаций;
— защита информации;
— интеграция данных (поддержка типовых форматов, конвертирование данных).
Основной компонент PDM — банкданных(БнД). Он состоит из системы управления базами данных и баз данных (БД). Межпрограммный интерфейс в значительной мере реализуется через информационный обмен с помощью банка данных. PDM отличает легкость доступа к иерархически организованным данным, обслуживание запросов, выдача ответов не только в текстовой, но и в графической форме, привязанной к конструкции изделия. Поскольку взаимодействие внутри группы проектировщиков в основном осуществляется через обмен данными, то в системе PDM часто совмещают функции управления данными и управления параллельным проектированием.
ПодсистемаинтеграцииПОпредназначена для организации взаимодействия программ в маршрутах проектирования. Она состоит из ядра, отвечающего за интерфейс на уровне подсистем, и оболочек процедур, согласующих конкретные программные модули, программы и/или программно-методические комплексы (ПМК) со средой проектирования.
Интеграция ПО базируется на идеях объектно-ориентированного программирования. Следует различать синтаксический и семантический аспекты интеграции. Синтаксическая интеграция реализуется с помощью унифицированных языков и форматов данных, технологий типа ODBC для доступа к общему банку данных или компонентно-ориентированных (CBD — Component-Based Development) технологий. Пример унифицированного формата — TES (Tool Encapsultion Specification), предложенного консорциумом CFI. Информация из TES используется для создания оболочек модулей при инкапсуляции. Семантическая интеграция подразумевает автоматическое распознавание разными системами смысла передаваемых между ними данных и достигается значительно труднее.
Подсистема пользовательского интерфейсавключает в себя текстовый и графический редакторы и поддерживается системами многооконного интерфейса типа Х Window System или Open Look.
ПодсистемаCASEпредназначена для адаптации САПР к нуждам конкретных пользователей, разработки и сопровождения прикладного ПО. Ее можно рассматривать как специализированную САПР, в которой объектом проектирования являются новые версии подсистем САПР, в частности, версии, адаптированные к требованиям конкретного заказчика. Другими словами, такие CASE-подсистемы позволяют пользователям формировать сравнительно с малыми затратами усилий варианты прикладных ПМК из имеющегося базового набора модулей под заданный узкий диапазон конкретных условий проектирования. В таких случаях СASE-подсистемы называют инструментальными средами.
CASE-система, как система проектирования ПО, содержит компоненты для разработки структурных схем алгоритмов и “экранов” для взаимодействия с пользователем в интерактивных процедурах, средства для инфологического проектирования БД, отладки программ, документирования, сохранения “истории” проектирования и т.п. Наряду с этим, в CASE-подсистему САПР входят и компоненты с специфическими для САПР функциями.
Так, в состав САПР Microstation (фирма Bentley Systems) включена инструментальная среда Microstation Basic и язык MDL (Microstation Development Language) c соответствующей программной поддержкой. Язык MDL — С-подобный, с его помощью можно лаконично выразить обращения к проектным операциям и процедурам. В целом среда Microstation Basic близка по своим функциям к среде MS Visual Basic, в ней имеются генератор форм, редактор, конструктор диалога, отладчик.
САПР Спрут (российская фирма Sprut Technologies) вообще создана как инструментальная среда для разработки пользователем потоков задач конструкторского и технологического проектирования в машиностроении с последующим возможным оформлением потоков в виде пользовательских версий САПР. Сконструированный поток поддерживается компонентами системы, в число которых входят графические 2Dи 3Dподсистемы, СУБД, продукционная экспертная система, документатор, технологический процессор создания программ для станков с ЧПУ, постпроцессоры.
Управление данными в САПР.В большинстве автоматизированных информационных систем применяют СУБД, поддерживающие реляционные модели данных.
Среди общих требований к СУБД можно отметить: 1) обеспечение целостности данных (их полноты и достоверности); 2) защита данных от несанкционированного доступа и от искажений из-за сбоев аппаратуры; 3) удобство пользовательского интерфейса; 4) в большинстве случаев важна возможность распределенной обработки в сетях ЭВМ.
Первые два требования обеспечиваются ограничением прав доступа, запрещением одновременного использования одних и тех же обрабатываемых данных (при возможности их модификации), введением контрольных точек (checkpoints) для защиты от сбоев и т.п.
Банкданныхв САПР является важной обслуживающей подсистемой, он выполняет функции информационного обеспечения и имеет ряд особенностей. В нем хранятся как редко изменяемые данные (архивы, справочные данные, типовые проектные решения), так и сведения о текущем состоянии различных версий выполняемых проектов. Как правило, БнД работает в многопользовательском режиме, с его помощью осуществляется информационный интерфейс (взаимодействие) различных подсистем САПР. Построение БнД САПР — сложная задача, что обусловлено следующими особенностями САПР:
1. Разнообразие проектных данных, фигурирующих в процессах обмена как по своей семантике (многоаспектность), так и по формам представления. В частности, значительна доля графических данных.
2. Нередко обмены должны производиться с высокой частотой, что предъявляет жесткие требования к быстродействию средств обмена (полагают, что СУБД должна работать со скоростью обработки тысяч сущностей в секунду).
3. В САПР проблема целостности данных оказывается более трудной для решения, чем в большинстве других систем, поскольку проектирование является процессом взаимодействия многих проектировщиков, которые не только считывают данные, но и изменяют их, причем в значительной мере работают параллельно. Из этого факта вытекают следствия: во-первых, итерационный характер проектирования обычно приводит к наличию по каждой части проекта нескольких версий, любая из них может быть принята в дальнейшем в качестве основной, поэтому нужно хранить все версии с возможностью возврата к любой из них; во-вторых, нельзя допускать использования неутвержденных данных, поэтому проектировщики должны иметь свое рабочее пространство в памяти и работать в нем автономно, а моменты внесения изменений в общую БД должны быть согласованными и не порождать для других пользователей неопределенности данных.
4. Транзакции могут быть длительными и трудоемкими. Транзакциейназывают последовательность операций по удовлетворению запроса. В САПР внесение изменений в некоторую часть проекта может вызвать довольно длинную и разветвленную сеть изменений в других его частях из-за существенной взаимозависимости компонентов проекта (многошаговость реализации запросов). В частности, транзакции могут включать в себя такие трудоемкие операции, как верификация проектного решения с помощью математического моделирования. В результате транзакции могут длиться даже несколько часов и более. Одна из трудностей заключается в отображении взаимозависимости (ассоциативности) данных. При хранении компонентов проекта во внешней памяти затраты времени на обработку запросов оказываются значительно выше, чем в большинстве других автоматизированных систем, с менее выраженными взаимозависимостями данных.
5. Иерархическая структура проектных данных и, следовательно, отражение наследования в целях сокращения объема базы данных.
В определенной мере названные особенности учитываются в СУБД третьего поколения, в которых стали применяться черты объектно-ориентированных (объектных) СУБД. В них наборы данных, характеризующих состояние предметной области (состояние проекта в случае САПР), помещаются в отдельные файлы. Интерпретация семантики данных осуществляется с помощью специальных процедур (методов), сопровождающих наборы. Наследование свойств объектов предметной области выражается с помощью введения категорий класса, надкласса, подкласса. Информационные модели приложений для таких СУБД разрабатываются на основе методик типа IDEF1X.
Объектные БД выгодны, во-первых, тем, что данные по конкретным объектам проектирования не разбросаны по множеству таблиц, как это имеет место в реляционных БД, а сосредоточены в определенных местах. Во-вторых, для каждого объекта могут быть назначены свои типы данных. В результате проще решаются задачи управления и удовлетворения запросов.
Наряду с чисто объектными СУБД (pure ODBMS), применяют СУБД объектно-реляционные. В последних происходит объединение свойств реляционных и объектно-ориентированных СУБД: объектно-ориентированная СУБД снабжается непроцедурным языком запросов или в реляционную СУБД вводятся наследование свойств и классы. Непроцедурность входного языка обеспечивается использованием языка SQL. Его операторы непосредственно включаются в программы на языке С. Возможно написание дополнительных программ, интерпретирующих SQL-запросы.
Отличительные особенности СУБД третьего поколения: расширенный набор возможных типов данных (это абстрактные типы, массивы, множества, записи, композиции разных типов, отображение величин с значениями разных типов), открытость (доступность из разных языков программирования, возможность обращения к прикладным системам из СУБД), непроцедурность языка (общепринятым становится язык запросов SQL), управление асинхронными параллельными процессами, состояние которых отражает БД. Последнее свойство позволяет говорить о тесной взаимосвязи СУБД и подсистемы управления проектами DesPM.
Названные особенности управления данными в САПР нашли свое выражение в современных подсистемах управления проектными данными PDM.
В PDM разнообразие типов проектных данных поддерживается их классификацией и соответствующим выделением групп с характерными множествами атрибутов. Такими группами данных являются описания изделий с различных точек зрения (аспекты). Для большинства САПР машиностроения характерными аспектами являются свойства компонентов и сборок (эти сведения называют Bill of materials — BOM), модели и их документальное выражение (основными примерами могут служить чертежи, 3Dмодели визуализации, сеточные представления для конечно-элементого анализа, текстовые описания), структура изделий, отражающая взаимосвязи между компонентами и сборками и их описаниями в разных группах.
Вследствие большого объема проектных данных и наличия ряда версий проектов PDM должна обладать развитой системой поиска нужных данных по различным критериям.
Рассмотренные особенности банков данных в САПР позволяют квалифицировать их как системы Data Warehouse (DW), т.е. хранилища данных. Для хранилищ данных характерен ряд особенностей, совпадающих с названными выше особенностями банков данных САПР: 1) длительное хранение информации, отражающей историю разработок; 2) частота операций чтения данных выше частоты операций обновления данных; 3) использование единых форматов для однотипных данных, полученных из различных источников (например, от разных программно-методических комплексов). Эти особенности позволяют управлять конфигурацией проектов, что, в частности, означает хранение в САПР всех версий проекта и, возможно, данных по проектам предыдущих разработок, удовлетворение сложных запросов, для ответа на которые требуется извлечение и обработка данных из различных частей хранилища (так называемая многомерная обработка). Модели данных в DW отличаются от реляционных моделей (RM): в RM использованием нормальных форм стремятся максимально уменьшить избыточность данных, что приводит к увеличению числа таблиц, но уменьшенных размеров, однако многомерный поиск, требующийся в DW, в множестве таблиц затруднен. Поэтому в DW чаще используется модель данных “звезда”, в которой имеется общая таблица фактов (Fact Table) и каждому факту ставится в соответствие несколько таблиц с необходимыми атрибутами. Целостность данных в DW обеспечивается проверкой и трансформацией данных (data cleaning), вводимых из внешних источников, наличием дисциплины обновления данных, централизованным хранением основной базы, при этом достаточное быстродействие поддерживается передачей копий определенных частей базы в локальные базы, называемые киосками данных (Data Mart) и ориентированные на отдельные группы пользователей.
Программные средства управления проектированием САПР.Всистемных средах САПР управления проектированием возлагается на подсистему CAPE, в некоторых системах обозначаемую как DesPM (Design Process Manager). DesPM должна включать в себя компоненты: комплексы базовых знаний по тем предметным областям, которые определяются объектом проектирования, а также знаний о языках представления характеристик и ограничений; средства для генерации плана (маршрута проектирования), определения наличия средств и ресурсов для реализации плана; средства выполнения плана; средства оценки результатов. DesPM позволяет выбирать объекты проектирования, производить декомпозицию моделей, для каждого компонента выбирать проектные процедуры из имеющегося набора.
По каждому объекту DesPM выдает сообщения, примерами которых могут быть: “объект проектируется другим разработчиком”, “проектирование преждевременно, не выполнены предшествующие процедуры”, “не подготовлены исходные данные”. Одной из важнейших функций DesPM является помощь в реализации параллельного проектирования. Желательно в DesPM предусмотреть возможности создания “суперпроцедур” — командных файлов для выполнения часто повторяющихся фрагментов маршрутов проектирования.
Расширение возможностей управления проектированием и адаптация системной среды к конкретным САПР связано с применением языков расширения. Языкрасширения— это язык программирования, позволяющий адаптировать и настраивать системную среду САПР на выполнение новых проектов. Язык расширения должен обеспечивать доступ к различным компонентам системной среды, объединять возможности базового языка программирования и командного языка, включать средства процедурного программирования.
Управление процессом проектирования включает в себя большое число действий и условий, поддерживающих параллельную работу многих пользователей над общим проектом. Управление выполняется на основе моделей вычислительных процессов. Используются спецификации моделей, принятые в CASE-системах, например, диаграммы потоков данных, ориентированные графы. Сначала модели составляют для задачного уровня, а затем система осуществляет их покрытие. Применяют также описания на языках расширения или 4GL. В системной среде Ulyses спецификации даны в виде набора модулей с указанием условий их активизации, что близко к представлению моделей в сис-
темах, управляемых знаниями. Так, каждый проектирующий программный модуль может быть активизирован только в том случае, если входные данные готовы. Для этого специальная программа управления модулямисистемной среды отслеживает соблюдение отношений следования между проектными операциями и процедурами, заданными в маршруте проектирования. На эту же программу возлагаются функции регулирования прав доступа к модулям, сбор статистики (протоколирование) по обращениям к модулям и некоторые другие.
Необходимо обеспечение синхронизации изменения данных, разделяемых многими пользователями. Для этого, во-первых, пользователи подразделяются на классы (администрация системы, руководство проектом и частями проекта, группы исполнителей-проектировщиков) и для каждого класса вводят определенные ограничения, связанные с доступом к разделяемым данным; во-вторых, обеспечивают средства ведения многих версий проекта; в-третьих, для выполнения работ в отдельных ветвях параллельного процесса пользователям выделяют свои рабочие области памяти. Данным могут присваиваться различные значения статуса, например, “правильно”, “необходимо перевычисление”, “утверждено в качестве окончательного решения” и т.п. Собственно синхронизация выполняется с помощью механизмов типа рандеву или семафоров, рассматриваемых в пособиях по параллельным вычислениям.
В общем случае полная формализация управления проектированием не может быть достигнута, поэтому полезную роль играют системыподдержкирешений, принимаемых людьми, DSS (Decision Support Systems). В качестве таких систем часто используют хранилища данных и OLAP-средства (On-Line Analytical Processing).
Использование хранилищ данных имеет ряд преимуществ в управлении большими объемами данных: имеется единое ядро, что исключает чрезмерно разветвленные и длительные транзакции, легче синхронизировать внесение изменений, поддерживать единство форматов данных, хранить предыдущие версии и т.п.
OLAP-средства должны обеспечивать оперативный доступ к данным, на основе которого выявляются зависимости между параметрами (измерениями в многомерной модели приложения). В OLAP-системах на реляционных СУБД аналитическая обработка, или, другими словами, многомерный динамический анализ данных требует просмотра большого числа записей из разных таблиц. По-
этому производительность оказывается невысокой. В специализированных OLAP-системах, обеспечивающих более быстрый многомерный анализ, но с более существенными ограничениями на объем БД, данные хранятся в виде гиперкубов или поликубов — многомерных таблиц с постоянным или переменным числом ячеек соответственно.
Примеры подсистем управления данным и проектированием. В ряде системных сред САПР (прежде всего САПР в машиностроении) в подсистемах PDM объединяются функции управления данными и проектированием. Пример такой PDM — подсистема Design Manager в САПР Euclid Quantum. Функциями этой PDM являются управление потоками проектных данных, версиями проекта, взаимодействием разработчиков, защита информации, конфигурирование и адаптация версий системы для конкретных пользователей.
В системной среде NELSIS CAD Framework имеются части: 1) DMS (Design Management Services) для поддержки иерархии данных, управления версиями и потоками задач; 2) DMI (Design Management Interface) с функциями открытия и закрытия баз данных, вызова и пересылки данных, доступа к DMS; 3) FUS (Framework User Services), включающая ряд браузеров для визуализации информации.
