CC BY
20
РА7 (*,Т) =
(I (г), ^ (г + г)) + (О, Г, (г + г))
Гк ' а2 (5,(0) +от2 №(0)
_ Соу(Х(0, Х(! + г)) + Соу(£(0? ^ + г)) , +
Д2 V4' "> " ) п / Туг/^ЧЧ ^ / / чч > V > / — О , л . чч
о- СГЧ^(О)
Из этих соотношений следует, что Р (t > т) и Ртк (Л О значительно ближе между собой, чем
Р Аг (А О и О > когда X (() принадлежит к классу ^.(7), а остатки компенсации £(7) ве-
лики. Поэтому распознавание РС с использованием зашумления эталонов может оказаться более надёжным в условиях существенных различий между шумом У, (/) и опорным шумом У2 (/) .
Проведенные испытания распознавания реальных РС в условиях сильных шумов от транспортных средств показали, что описанный метод существенно повышает вероятность правильного распознавания в сравнении с распознаванием, использующим компенсацию шума.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Левин, Б. Р. Теоретические основы статистической радиотехники / Б. Р. Левин. - М.: Радио и связь, 1989. -656 с.
2. Васильев, К. К., Крашенинников, В. Р. Адаптивные алгоритмы обнаружения аномалий на последовательности многомерных изображений // Компьютерная оптика. - 1995. - Вып. 14-15. - 4.1. - С.125-132.
3. Сапожков, М. А. Речевой сигнал в кибернетике и связи / М. А. Сапожков. - М.: Связьиздат, 1963. -452 с.
4. Крашенинников, И. В. Устойчивое к шумам распознавание речевых сигналов // Тез. докл. 32-й науч.-техн. конф. УлГТУ. - Ульяновск: УлГТУ, 1998. -Ч.2.-С. 9-10.
Крашенинников Виктор Ростиславович, доктор технических наук, профессор кафедры САПР УлГТУ. Имеет работы в области статистических методов обработки случайных сигналов и изображений.
Армер Андрей Игоревич, студент экономико-математического факультета УлГТУ.
УДК 004.896
А. Ф. ПОХИЛЬКО, А. В. УДОВИЧЕНКО
ОБРАБОТКА И ХРАНЕНИЕ ПРОЕКТНЫХ РЕШЕНИЙ В ИИС
Рассматриваются возможности выделения из проектной деятельности структур проектных, решений, построения моделей классов объектов проектирования, а также хранения, отображения и дальнейшего использования информации в контексте интегрированной инструментальной среды.
ВВЕДЕНИЕ
Реальные задачи проектирования не сводятся к «электронизации» накопленной инженерной документации. Это серьёзный процесс согласованного труда инженеров, управленцев, программистов и т. д. Причём выпуск и передача документации на следующий этап - далеко не определяющая во всем цикле «проектирование - изготовление» составляющая. Главной составляющей автоматизированного проектирования должно являться создание такого информационного описания проектируемого изделия, которое позволяло бы уловить логику каждого проектного решения, оперативно осуществлять изменение проекта, использовать в дальнейшем полученные ранее проектные решения, даже относящиеся к дру-
© Похилько А. Ф.> Удовиченко А. В., 2004
гой области проектирования. Основной проблемой здесь выступает разработка механизма приобретения, сохранения и применения в другой ситуации проектных знаний, полученных при достижении некоторого проектного решения. Всё это говорит о том, что необходимо создание программных инструментальных средств, позволяющих на основе базовых САПР программировать модули для решения ряда специфичных задач пользователя, так как традиционные методы автоматизации приводят к «жёсткому» программированию с резким ограничением функциональности.
ПОСТАНОВКА ЗАДАЧИ
Исходя из вышесказанного задачу можно сформулировать следующим образом: необходимо создать интегрированную инструментальную среду, которая
Припож. 1
Управляющие
воздействия
пользователя.
Модуль 1
Модуль N
Идейное наполнение
Выдача информации по запросам
Ф ормализ ация и преобразование проектных решений
пр отоколиров ание
Рис. 1. Общая схема макета ИИС
бы обеспечивала выполнение следующих требований:
- возможность интеграции разнородных приложений образом, удобным для пользователя;
-«развязка» разнородной информации для обработки в специализированных приложениях;
-работа с содержимым проектного решения, его идейным наполнением;
- «контекстность» предоставляемой пользователю информации;
- «отвязка» от конкретных форматов данных и их преобразований.
Для возможности создания интегрированной инструментальной среды необходимо разделить информационные потоки между модулями системы с тем, чтобы обеспечить работу специализированных приложений только с характерной для них информацией, также разработать и реализовать базу данных и модуль управления, которые'бы обеспечивали:
- хранение проектных решений;
-динамическое наполнение множества проектных решений;
-хранение сопутствующей информации (описаний, вычислений и пр.);
-управление внешними функциональными мо-дулями-компонентами среды, обмен данными между модулями и их сохранение;
-выдачу и отображение в удобном виде хранящейся информации;
- удобное управление проектами со стороны пользователя.
МОДЕЛЬ И СОДЕРЖАНИЕ РЕШЕНИЯ
Как показывает практика, создание системы, удовлетворяющей всем возникающим требованиям
(используя единую информационную среду, обеспечивающую однородность данных и автоматизацию обмена данными на протяжении всего процесса проектирования, причём не только проектирования, но и всего жизненного цикла изделия), могут позволить себе лишь очень крупные концерны. Отсутствие возможности, на данный момент, создать систему, которая бы удовлетворяла всех, приводит к мысли о создании инструмента, позволяющего объединять существующие в настоящее время и используемые в процессе проектирования и всего жизненного цикла изделия, приложения. Упрощённая схема такой системы приведена на рис. 1.
Далее встаёт вопрос о модели представления процесса получения проектных решений. Проводившиеся ранее исследования и работы показывают эффективность и доступность для пользователя и программиста метода представления процесса проектирования в виде И-ИЛИ-графа. Вершинами графа являются элементы ТС и их признаки, а дуги показывают иерархическую соподчинённость между элементами и их признаками, а также принадлежность признаков элементам. В вершинах множества И располагаются элементы, выполняющие различные функции, а также признаки элементов, относящихся к разным группам признаков. Вершины ИЛИ объединяют альтернативные элементы, выполняющие одинаковые или очень близкие функции, и признаки, характеризующие индивидуальные особенности каждой ТС.
Множество путей достижения технического решения (прохождение по вершинам И-ИЛИ-графа) может быть представлено в виде логической записи (предиката), где при выполнении всех условий при-
нимается значение «истина», в противном случае -«ложь». Форма записи следующая:
P(A&(BuCuD)&F) = [0;1], (1)
где A, F - элементы, выполняющие различные функции; В, С, D - альтернативные элементы, выполняющие близкие функции. Решение системы уравнений, представленных в предикатной форме, это и есть удовлетворяющее ТЗ техническое решение. Пример дерева дан на рис.2.
Недостатки существующих реализаций этого метода:
- неполнота набора вариантов ТС;
- невозможность внесения изменений;
% m
- невозможность добавления новых решений.
Другим подходом может стать динамическое наполнение множества проектных решений, т. е. построение и наращивание графа во время самого процесса проектирования, что сразу же снимает вышеописанные недостатки, но накладывает более жёсткие требования по обработке и хранению данных. В ходе анализа задачи были выделены несколько сущностей, реализация и использование которых дали бы возможность динамически строить граф проекта, использовать полученные решения ТС, удобно отображать сопутствующую проекту служебную и справочную информацию.
- Проект (Пр) - наибольшая абстракция, которая включает в себя дерево решений и всю сопутствующую информацию.
- Проектная операция (ПО) - некое действие, выполняемое пользователем и выделяемое им в отдельную смысловую единицу. Она разделяется в свою очередь на три элемента:
-операция muni (ОХ) - операция, являющаяся выполнением некоторых действий, которые лишь в совокупности обладают смыслом для пользователя, т. е. применительно к разрабатываемой системе - это набор строчек макроса, выполнение которых внешним модулем или другой программой приводит к некоему результату, имеющему смысл для пользователя ( скажем, отрисовка окружности с последующей вытяжкой (для SolidWorks));
- операция «назначения» (тип2) (02) - операция, являющаяся назначением параметру приложения, «участвующего» в системе, значения (например назначение размеру некоторого числа);
-условие (У) - операция проверки истинности некоторого условия, задаваемого в ходе работы с проектом. Обеспечивает «ветвление дерева проекта». Накладывается на параметр (см. термин ниже), может быть нескольких типов (существование, равенство, различные неравенства и принадлежность диапазону);
- Параметр (П) - некая абстракция, интерпретируемая в зависимости от контекста. По смыслу близка к переменной. В реализуемой системе может содержать в себе постоянную величину, расчёт, SQL-запрос, интерактивный запрос. В перспективе может
хранить любую информацию, интерпретация которой
Рис. 2. Пример построения графа
МУФТА
Ti = 120Hm
Ф ормрты
п апр авление
процесса
проектирования
результат
будет зависеть от контекста, в котором применяется параметр (например рисунок).
Основу модели составляют: - множество проектов, Пр{Пр1<кеу, Name, Desc>}, где key - уникальное число-идентификатор проекта (уникальное числовое значение записи в БД, (далее будет опускаться)); Name - имя проек-та(краткое смысловое содержание); Desc - описание содержания проекта;
-множество проектных операций ПО{ПО| <Рго-jlD, Type, Name, Desc, NOPl, NOP2>}, где Type -тип элемента множества (1-01,2- 02, 3 -У); Name -имя элемента, отражающее смысловое наполнение; Desc - подробное описание; N0P1 - уникальное число, пределяющее элемент множества, на который происходит переход после выполнения данного; N0P2 - уникальное число, определяющее элемент множества, на который происходит переход после невыполнения данного;
-множество операций тип1 01{01i<0pID, Con-ten^}, где OpID - уникальное число, определяющее
элемент множества ПО. с которым однозначно связан данный элемент; Content - содержимое элемента (текст макроса, скрипта и т. п.);
-множество операций тип2 02{02i<0pID, ParamID^, где OpID - уникальное число, определяющее элемент множества ПО. с которым однозначно связан данный элемент; ParamID - уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества 02;
-множество условий У{УКОрШ, ParamID, Ра~ ramlDl, ParamID2, Condition>}, где OpID - уникальное число, определяющее элемент множества ПО, с которым однозначно связан данный элемент; ParamID - уникальное число, определяющее элемент множества П, числовое значение на которое будет накладываться условием; ParamID 1 - уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества У (левая граница диапазона); ParamID2 - уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества У (правая граница диапазона); Condition - собственно условие, налагаемое на элемент множества П;
-множество параметров Il{ni<ProjID, Name, Type, Content, Desc, Value>}, где ProjID - уникальное число, определяющее принадлежность данного элемента к проекту; Name - имя элемента; Туре -тип(число), согласно которому интерпретируется содержимое элемента; Content - содержимое элемента; Desc - описание элемента; Value - числовое значение, возможно получаемое при интерпретации содержимого элемента.
Процесс проектирования можно представить в виде совокупности элементов множества ПО. Каждый элемент множества nOi представляет собой отдельную реализованную подзадачу проектирования. Таким образом, существует возможность описать проект Пр, используя реализованные проектные решения:
Пр = 011 &02 ! &У ! ((01 &02 j&... ) or (У k( ...)))> (2)
где i, j, k — индексы элементов множеств, адекватные проектным ситуациям.
Создание нового и пополнение проектного решения начинается с выделения некоторой области задач, в которую будет вписываться проект (создание или выбор элемента множества Пр). Далее следует пополнение и (или) изменение элементов всех остальных множеств в контексте данного проекта, что позволяет автоматически поддерживать связь между элементами множеств. Посредством этих связей в дальнейшем становится возможным восстановление дерева проекта.
Воспроизведение проектного решения заключается в выборе элемента Ilpi и дальнейшем прохож-
дении по ветвям дерева с обработкой элементов множества ПО.
Для реализации вышерассмотреного подхода была смакетирована система, состоящая из трёх компонентов: центрального модуля (он же модуль работы с БД) и интерфейсных модулей для моделлера SolidWorks и матпроцессора MathCAD. Для хранения и обработки данных была создана база данных на основе Paradox7. Структура БД показана на рис.3.
АПРОБАЦИЯ
Результатом реализации стал макет программного комплекса из трёх компонентов Core, SWService, MCService. После создания макета системы была проведена её апробация. В качестве исходного примера была взята одна из олимпиадных задач. В задачу входили как задание в текстовом виде, так и графическая часть и математический расчёт. В ходе работ выяснилась принципиальная работоспособность системы, её возможность сохранять накопленные проектные решения. Были проверены функциональные возможности данной системы. К недостаткам построенного макета можно отнести слабую наглядность отображения собственно дерева решений
ЗАКЛЮЧЕНИЕ
К направлениям для дальнейшей работы можно отнести усовершенствование механизма проведения расчётов и наглядное отображение дерева проекта.
ТБД проектов jprojects.db
ТБД деревьев проектов trees.db
PRIMARY \
ID
Name
Desc
ТБД
параметров
_parameters.db
PRIMARY у
4
PRIMARY ProjID _ Number
1ml
Name Desc
NÖP1 N0P2
Name_ Contení. Desc
1ml
Value
InpN ame ÖutName
Служебные ТБД
ТБД
«непр ерывных»
операций _operaiions_l.cîb
PRIMARY
Content
ТБД операций «назначения» _operations_2.db
ТБД связей as so dations, db
PRIMARY
PRIMARY
OpID
»»'У" *--« • - • ». -1 ■ Ш
ParamID
ParamID
ТБД условий conditions .db
P a* ameter
PRIMARY
PafamID ParatrtÍDÍ
Типов пар-ров T^tjparameters.db t ParamID^
-m»/« r
i Типов операций j __t_operaiions.db < Condition
Типов полей
Условий
WW*"' y ~ WVAV
Справ. ТБД
г
I
t fields.db
, _t_conditions.db
1
«¿Vt^-VrЛАУ> S. v<vrI>■■.■— ■•—..
t tables.db
construct, db
Рис.3. Структура базы данных
Произведённый программный эксперимент, несмотря на некоторые недоработки в ИИС в целом, в связи с согласованием работы отдельных компонентов показал возможность создания подобных интегрированных сред и успешного хранения не только сопровождающей проектной информации, но и информации, касающейся «идейного» наполнения проекта; эффективно решать задачи построения модели процесса проектирования моделирования классов объектов проектирования.
Перспективы развития:
-улучшение механизма расчётов в матпроцессо-
ре;
- добавление возможностей параметризации не только размеров, но других величин (в т. ч. нечисленных);
- обеспечение работы не только с деталями, но и со сборками, т. е. включение других проектов как подветвей;
- оптимизация взаимодействия с пользователем;
- расширение набора служебных модулей для взаимодействия с другими приложениями;
- переход к новой модели хранения проектных решений в виде потокового графа.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Похилько, А. Ф. Технология представления проектной деятельности в интегрированной среде САПР // Вестник УлГТУ. Сер. Информационные технологии. - 2000. - №3.
2. Похилько, А. Ф. Построение модели классов объектов и типовых методик проектирования в интегрированной интероперабельной среде САПР // Вестник УлГТУ. Сер. Информационные технологии. -2001. -№4.
3. Похилько, А. Ф., Удовиченко, А. В. Работа с базами данных при поддержке процесса проектирования в графических средах // Сборник трудов третьей ВНПК «Современные проблемы создания и эксплуатации радиотехнических систем». М., - 2001.
Похилько Александр Фёдорович, ка}1дидат технических наук, профессор кафедры «Системы автоматизированного проектирования» УлГТУ. Имеет статьи в области информационных технологии проектирования САПР, методах и моделях принятия решений.
Удов и чей ко А шпон Владимирова ч, аспирант кафедры САПР УлГТУ Имеет работы в области информационных технологий.
