Электронная библиотека диссертаций и авторефератов России
dslib.net
Библиотека диссертаций
Навигация
Каталог диссертаций России
Англоязычные диссертации
Диссертации бесплатно
Предстоящие защиты
Рецензии на автореферат
Отчисления авторам
Мой кабинет
Заказы: забрать, оплатить
Мой личный счет
Мой профиль
Мой авторский профиль
Подписки на рассылки



расширенный поиск

Разработка и исследование методов управления данными в САПР изделий приборостроения Донецкая, Юлия Валерьевна

Разработка и исследование методов управления данными в САПР изделий приборостроения
<
Разработка и исследование методов управления данными в САПР изделий приборостроения Разработка и исследование методов управления данными в САПР изделий приборостроения Разработка и исследование методов управления данными в САПР изделий приборостроения Разработка и исследование методов управления данными в САПР изделий приборостроения Разработка и исследование методов управления данными в САПР изделий приборостроения
>

Диссертация - 480 руб., доставка 10 минут, круглосуточно, без выходных и праздников

Автореферат - бесплатно, доставка 10 минут, круглосуточно, без выходных и праздников

Донецкая, Юлия Валерьевна. Разработка и исследование методов управления данными в САПР изделий приборостроения : диссертация ... кандидата технических наук : 05.13.12 / Донецкая Юлия Валерьевна; [Место защиты: С.-Петерб. гос. ун-т информац. технологий, механики и оптики].- Санкт-Петербург, 2011.- 156 с.: ил. РГБ ОД, 61 11-5/2020

Содержание к диссертации

Введение

Глава 1. Обзор САПР и задачи методов управления данными изделий приборостроения 12

1.1 Состояние вопроса управления данными изделий приборостроения , 13

1.2 Обзор существующих методов и средств автоматизации проектирования 15

1.3 Классификация и особенности методов автоматизации проектирования и управления данными об изделии 30

1.4 Постановка задачи 32

1.5 Выводы 33

Глава 2. Математическая модель управления данными в САПР изделий приборостроения 35

2.1 Требования к системам автоматизации проектирования 36

2.2 Управление данными проектирования

2.2.1 Представление данных проектирования 40

2.2.2 Организация доступа к данным 43

2.2.3 Структурная схема хранилища данных

2.3 Выбор средств моделирования 54

2.4 Математическая модель управления данными в САПР изделий приборостроения 58

2.5 Выводы 6

Глава 3. STR 4ONG Методы и алгоритмы управления данными в САПР изделий приборостроения STRONG 65

3.1 Метод управления данными в САПР 66

3.1.1 Формирование электронной структуры изделия 69

3.1.2 Формирование и изменение табличных документов 81

3.1.3 Создание технического документа 90

3.1.4 Редактирование электронной структуры изделия

3.2 Методика интеграции программных средств 102

3.3 Методика организации хранения и управления данными проектирования

3.3.1 Описание структуры данных 105

3.3.2 Распределение атрибутов по видам объектов 113

3.4 Методика анализа и оптимизации процедуры обработки данных проектирования 117

3.5 Алгоритмы автоматизации формирования данных об изделии 122

3.6 Выводы 133

Глава 4. STRONG Разработка программного комплекса для автоматизации проектирования изделий

приборостроения и внедрение результатов STRONG 135

4.1 Функциональные требования к реализации программного комплекса 136

4.1.1 Подсистема «Редактор электронной структуры изделия» 136

4.1.2 Подсистема «Редактор табличных документов» 139

4.1.3 Подсистема «Загрузчик технических документов» 141

4.2 Реализация 144

4.2.1 Организация взаимодействия подсистем программного комплекса 144

4.2.2 Выбор форматов обмена и представления данных 148

4.3 Результаты внедрения 149

Заключение 151

Литература

Классификация и особенности методов автоматизации проектирования и управления данными об изделии

Все атрибуты разделены на обязательные и необязательные атрибуты. В данной работе не будут описываться стандартные атрибуты, уже описанные в ГОСТ 2.104 [26]. Тем не менее, в процессе описания приведем лишь самые основные из них.

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

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

Заметим, что для объектов из категории «Справочники» этого атрибута не существует, поэтому для этих объектов атрибут не заполняется;

Наименование (обязательный атрибут). Атрибут состоит из двух частей наименования изделия и/или его составной части и вида документа. Данный атрибут, состоящий из двух частей, необходим для загрузки документов. Однако если создается элемент ЭСИ или загружается модель, то атрибут состоит только из наименования изделия и/или его составной части;

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

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

Вид изделия (необязательный атрибут). Значение этому атрибуту присваивается в процессе формирования элемента ЭСИ в PDM-системе для идентификации изделия и/или его составной части;

Ограничение по дате выдачи технического задания - ТЗ или ограничение по ТЗ (необязательный атрибут). Заполняется в том случае, если на элемент из категории «Справочники» накладываются ограничения по их использованию в разработках. Иными словами, заполнение атрибута производится в том случае, когда необходимо разрешить использование некоторого элемента для изделий, заключение контракта на проектирование и разработку или выдача ТЗ на разработку которых производилось не позднее указанного в атрибуте срока.

Значение этого атрибута может использоваться при распределении доступа к элементам категории «Справочники»; Дата выдачи ТЗ (необязательный атрибут). Ввод значения этого атрибута производится при формировании изделия в PDM-системе; Ограничение по применению (необязательный атрибут). Заполняется при создании или корректировке записи об элементе из категории «Справочники».

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

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

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

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

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

Ранее уже отмечалось, что любые данные, любая информация, загружаемая в PDM-систему, имеет ограничение на использование. Это определяется, реализуется и управляется разграничением прав доступа к информации. Оно осуществляется как на уровне атрибутов (как это приведено в предыдущем разделе - 2.2.1), так и на уровне определения прав на запись, чтение и изменение.

Методика распределения прав доступа на уровне записи, чтения и изменения данных не является новой. Она применяется во множестве реализаций, среди которых вьщелим системы электронного документооборота [27], различные Интернет-порталы на основе систем управления контентом [28] и некоторые другие [29], а также научных изданиях, посвященных данной методике [30, 31]. На этой основе опишем распределение прав доступа, характерное для выполняемого исследования. В соответствии с тем, что все данные разделены на три категории, выделим следующие категории доступа:

Доступ к данным изделия ограничивается двумя условиями: доступом к области изделия, организованной в PDM-системе, и правами, определенными состоянием объекта изделия и/или его составной части. Областью изделия в PDM-системе будем называть выделенный раздел в базе данных, в котором создаются записи об объектах проектируемого изделия и его составных частей. Область идентифицируется в базе данных по обозначению и наименованию проектируемого изделия. При этом формируется т.н. верхний или основной уровень ЭСИ, соответствующий непосредственно изделию. Определяется состав (список) сотрудников организации или предприятия, которые имеют возможность просматривать, изменять и создавать объекты в системе (модели, документы и элементы ЭСИ), соответствующие проектируемому изделию и содержащие информацию о нем и его составных частях. Следовательно, каждый пользователь (сотрудник предприятия или организации, зарегистрированный в PDM-системе) имеет возможность вносить информацию о проектируемом им изделии. Однако отметим, что даже если доступ к информации об изделии не предполагает конфиденциальности, то всегда существует, как минимум, две категории пользователей: пользователи, имеющие права «читать», «создавать» и «изменять» информацию об изделии и пользователи, имеющие права «читать» эту информацию. Следовательно, первоначальное разделение прав, независимо от вида информации, осуществляется по двум типам: «Чтение-Запись» и «Только Чтение».

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

В разработке. Начальное состояние, которое получает любая версия объекта, помещаемая в PDM-систему. Это состояние характеризует то, что в PDM-системе создан объект, для которого заданы значения атрибутов. При этом не обязательно, что этому объекту соответствует файл содержательной части электронного документа. Отметим, что под содержательной частью понимается файл или набор файлов, рассматриваемых как единое целое, и содержащих необходимую информацию об изделии [25]. То есть нельзя однозначно утверждать необходимость соответствия объекту файла текстового, двумерного графического документа или модели, или иных документов. Примером таких объектов является элемент ЭСИ. Отметим, что в этом состоянии объекты системы могут создаваться, изменяться или удаляться;

На проверке. Это состояние объекта является обобщенным, так как под ним на каждом предприятии может пониматься любое количество состояний, характеризующих объект при прохождении им маршрута согласования. Вместо этого состояния указывается любой перечень других состояний, однозначно определяющих стадию подписания объекта. Оно подразумевает «Только Чтение» объектов;

На доработке. Состояние, характеризующее распределение доступа к объекту, направленному на доработку по маршруту согласования. При этом автор версии объекта должен иметь возможность изменять объект;

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

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

Представление данных проектирования

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

SADT-модель дает полное, точно и адекватное описание системы, которое имеет конкретное назначение. Это назначение называется целью модели. Цель модель - это формулировка совокупности вопросов, на которые должны быть получены ответы в процессе анализа. Иными словами, создаваемая модель содержит в себе ответы на заданные вопросы, а сами вопросы руководят созданием модели и направляют его. В результате, полученная модель должна дать ответы с заданной степенью детализации, на все вопросы, обозначенные в цели. Если модель, по каким-то причинам, не дает ответы на все поставленные вопросы или ответы неточны, то считается, что цель модели недостигнута [34].

С описанием модели связана позиция, с которой наблюдается система и ведется создание ее модели. При этом для SADT обязательным условием является рассмотрение модели с одной и той же позиции. Такая позиция называется точкой зрения. Уточним, что точка зрения позволяет описать систему согласно представлениям человека или системы. Четкое определение точки зрения помогает яснее представлять процессы.

На основе поставленной цели и выбранной точки зрения осуществляется итерационный процесс моделирования системы. При этом цель является критерием для завершения моделирования, а точка зрения определяет объем и содержание представляемой информации о субъекте [34].

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

Методология IDEF0 [34, 35] (Integration Definition for Function Modeling — Функциональное моделирование процессов) является подмножеством методологии SADT. Принципом моделирования IDEF0 является построение функциональной модели предприятия или процесса. Это означает, что вся описываемая деятельность или любая ее часть декомпозируется в виде отдельных функций или бизнес-процессов.

Очевидно, что декомпозиция может проводиться множество раз для более детального описания процессов. Ее результатом является иерархическая модель анализируемой деятельности. С каждым уровнем детализации в модели будут увеличиваться декомпозируемые блоки. Очевидно, что их большое количество приводит к затруднениям в понимании модели и сложностям при ее модернизации. Поэтому, в методологии рекомендуется создавать не более 4-6 уровней декомпозиции [35].

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

Для достижения наилучшего результата при моделировании, методология IDEFO предписывает определение цели, точки зрения, области и степени детализации модели.

В отличие от стандарта IDEF0, представляющего моделируемую систему как совокупность видов деятельности, IDEF3 [35] позволяет моделировать деятельность как последовательность событий и участвующих в этих событиях объектов.

Рассматриваемый стандарт удобен для подробного моделирования отдельных видов деятельности. Для этого используются работы, стрелки, перекрестки и ссылочные объекты.

IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей. IDEF3 - это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе [35].

Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Работы, рассматриваемые в диаграммах, являются центральными компонентами модели. Для организации взаимоотношения работ используются связи и стрелки. Для их изображения применяют четыре типа стрелок: прецедент — обозначает, что работа, из которой выходит стрелка, предшествует предыдущей; поток работ — обозначение потока материальных объектов; ссылка — обозначение связи данной работы с материальным объектом, участвующим в этой деятельности и отношение — обозначение какого-либо другого влияния одной работы на другую.

Отметим, что на диаграммах IDEF3 стрелки не соединяются с границами диаграммы. Это не позволяет четко описать какой ресурс (человек или машина) осуществляет тут или иную работу. При этом теряется наглядность процесса, что, в свою очередь, не позволяет описать процесс с необходимой степенью детализации [35]. 2.3.4 Язык моделирования UML

Язык UML [36, 37] является общецелевым языком визуального моделирования. Он был разработан для спецификации, документирования и проектирования компонентов программного обеспечения, бизнес-процессов и других систем.

С использованием UML предоставляются следующие основные возможности [36]:

1. Простота и легкость представления и восприятия моделей при документировании процессов для сложных систем. Язык UML позволяет легко представлять систему на различных уровнях детализации. Довольно большой спектр диаграмм различного назначения, позволяет проанализировать моделируемый процесс с различных точек зрения и в соответствии с теми задачами, которые необходимо решить в настоящий момент времени.

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

Моделирование не зависит от того, с использованием каких языков программирования будет проводиться реализация системы. Это дает аналитикам возможность моделировать систему так, чтобы не зависеть от среды и языка программирования

Следовательно, UML предоставляет большие возможности моделирования систем за счет использования разнообразных диаграмм [37]. Каждая диаграмма позволяет рассмотреть процессы, происходящие в системе, под определенным углом или определенной точкой зрения.

Такой подход является наиболее эффективным, так как позволяет более точно описывать процессы.

Использование математического аппарата при описании моделей управления данными так же важно, как и рассмотренные ранее языки моделирования. При этом появляется возможность комплексного описания разрабатываемых методов. Поскольку в работе требуется описывать абстрактные, с точки зрения науки, понятия — методы управления данными, то использовать математический аппарат в виде формул, аксиом и теорем не представляется возможным, так как нельзя описать абстракцию в виде формул. Наиболее удобным является математическое описание с использованием теории матриц [38, 41] и теории множеств [39, 40].

Итак, для наилучшего понимания процессов управления данными в САПР и решения поставленной задачи, в процессе описания будем использовать диаграммы IDEF0, язык моделирования UML и математический аппарат теории множества и матриц. Таким образом, можно будет достичь наиболее полного представления процесса управления.

Формирование и изменение табличных документов

Доступ к данным изделия ограничивается двумя условиями: доступом к области изделия, организованной в PDM-системе, и правами, определенными состоянием объекта — изделия и/или его составной части. Областью изделия в PDM-системе будем называть выделенный раздел в базе данных, в котором создаются записи об объектах проектируемого изделия и его составных частей. Область идентифицируется в базе данных по обозначению и наименованию проектируемого изделия. При этом формируется т.н. верхний или основной уровень ЭСИ, соответствующий непосредственно изделию. Определяется состав (список) сотрудников организации или предприятия, которые имеют возможность просматривать, изменять и создавать объекты в системе (модели, документы и элементы ЭСИ), соответствующие проектируемому изделию и содержащие информацию о нем и его составных частях. Следовательно, каждый пользователь (сотрудник предприятия или организации, зарегистрированный в PDM-системе) имеет возможность вносить информацию о проектируемом им изделии. Однако отметим, что даже если доступ к информации об изделии не предполагает конфиденциальности, то всегда существует, как минимум, две категории пользователей: пользователи, имеющие права «читать», «создавать» и «изменять» информацию об изделии и пользователи, имеющие права «читать» эту информацию. Следовательно, первоначальное разделение прав, независимо от вида информации, осуществляется по двум типам: «Чтение-Запись» и «Только Чтение».

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

В разработке. Начальное состояние, которое получает любая версия объекта, помещаемая в PDM-систему. Это состояние характеризует то, что в PDM-системе создан объект, для которого заданы значения атрибутов. При этом не обязательно, что этому объекту соответствует файл содержательной части электронного документа. Отметим, что под содержательной частью понимается файл или набор файлов, рассматриваемых как единое целое, и содержащих необходимую информацию об изделии [25]. То есть нельзя однозначно утверждать необходимость соответствия объекту файла текстового, двумерного графического документа или модели, или иных документов. Примером таких объектов является элемент ЭСИ. Отметим, что в этом состоянии объекты системы могут создаваться, изменяться или удаляться;

На проверке. Это состояние объекта является обобщенным, так как под ним на каждом предприятии может пониматься любое количество состояний, характеризующих объект при прохождении им маршрута согласования. Вместо этого состояния указывается любой перечень других состояний, однозначно определяющих стадию подписания объекта. Оно подразумевает «Только Чтение» объектов;

На доработке. Состояние, характеризующее распределение доступа к объекту, направленному на доработку по маршруту согласования. При этом автор версии объекта должен иметь возможность изменять объект;

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

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

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

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

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

Из выше описанного следует, что при распределении прав доступа к области изделия должны учитываться и признаки, например признак литеры. В этом случае, документ всегда принимает состояние «Сдано в архив», однако от версии к версии признак установленной литеры должен присутствовать в перечне атрибутов документа.

Эта группа прав доступа так же, как и предыдущая делит доступ к данным на две категории — «Чтение-Запись» и «Только Чтение». В этом случае категория прав «Только Чтение» присваивается всем сотрудникам тематических отделов предприятия или организации, занимающихся разработкой и проектированием изделий. Эти сотрудники имеют право на применение элементов в своих разработках. Заметим, что применяться могут не все элементы, так как их применение ограничивается множеством факторов, выраженных в виде атрибутов в системе. За заполнением атрибутов, а так же проверку записи элемента в системе по нормативным документам, отвечают уполномоченные сотрудники, имеющие права на запись, изменение и удаление элементов из базы данных системы. Права доступа этих сотрудников относятся к категории прав «Чтение-Запись».

В процессе управления записями в справочниках используется ряд признаков и атрибутов, ограничивающих применение элементов в разработках. Атрибуты и признаки позволяют ограничить элементную базу таким образом, чтобы выделить подмножество элементов, которые можно применять в различных разработках, учитывая дату записи элементов в БД и дату выдачи ТЗ на разработку изделия.

Подсистема «Редактор электронной структуры изделия»

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

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

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

При описании метода используются несколько потоков данных. Как было описано ранее, эти потоки называются стрелками и включают в себя: входные, выходные и управляющие потоки. Заметим, что здесь мы опишем только общие потоки, которые используются во всем методе. Потоки, актуальные в приделах описания того или иного процесса, будут описаны в этих процессах.

Входной поток представлен начальными данными. Здесь описаны наборы параметров, которые необходимы для управления данными. К ним относятся: описание данных проектирования, структура базы данных и математическая модель.

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

Выходной поток представлен несколькими результатами работы метода: — первым результатом работы метода, является ЭСИ. Она формируется на основе данных схемотехнического проектирования, как при проектировании новых изделий или их составных частей, так и при их корректировке; — еще одним результатом, получаемым при использовании метода, является формирование табличных документов. Они формируются на основе данных ЭСИ, и являются техническими документами, представляемыми в виде таблиц. При работе с ЭСИ для получения этого вида документов формируются как новые документы, так и осуществляется их корректировка; — последним результатом, получаемым при использовании метода, является технический документ. Он позволяет получить в PDM-системе графический или текстовый документ, оформленный в соответствии с требованиями, предъявляемыми к техническим документам на предприятии или в проектной организации, и добавленный в состав структуры того изделия или его составной части, к которой относится документ.

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

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

Структура описываемых процессов представлена на рисунке 9 и содержит полную декомпозицию разрабатываемого метода. Зй-М Pjn"OManiaipoBaTbr oeitTtipoE Mi icaen(fitvi6cipocTpo HH3 SO СФОРМИРОВАТЬ Э СИ

Отредактировать записи О Записать измененные данные в буфер О Добавить новые записи Е2 Изменитьиспсльзуеїчьеэлементы О Указать редактируемый элемент Изменить клличеспюалвмвнтоа -13 Изменить позиционные обозначения І-Ш Записать результаты в буфер -Ш Цда отьисгюльзуемыеэлемгнты О Сохранить ЗСИ ts-O Заменить технический документ

Задать исходные данные для редактирования Е ЕЗ Найти редактируемый технический документ Ш еделишглстояниедокумонте О Определить отреджгирсеанныЛ Файл pj И вменить технический документ Е О Взять на изменение "Документ" П Сформировать новое имя Файла О Опреоелить новью значения атрибутов Щ Соэдатьновуювера те»м«сы дтумента О Загрузить измененный технический документ

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

На рисунке 10, укрупнено, представлено описание процесса формирования ЭСИ при проектировании электрической схемы в виде декомпозиции в методологии IDEF0. Представленный процесс формирования ЭСИ позволяет разработчику: — получить список элементов, которые он может использовать для разработки электрической схемы, в соответствии с данными проектируемого изделия или его составной части; указать и отобразить на схеме количество выбранных элементов и их позиционные обозначения; записать все введенные данные об элементе в структуру изделия или его составной части.

Похожие диссертации на Разработка и исследование методов управления данными в САПР изделий приборостроения