Обработка и хранение класса проектных решений в интегрированной инструментальной среде

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

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

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

• -    возможность интеграции разнородных приложений образом, удобным для пользователя;

• -    «развязку» разнородной информации для обработки в специализированных приложениях;

• -    работа с содержимым проектного решения, его идейным наполнением;

• -    «контекстность» предоставляемой пользователю информации;

• -    «отвязку» от конкретных форматов данных и их преобразований.

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

• -    хранение проектных решений;

• -    динамическое наполнение множества проектных решений;

• -    хранение сопутствующей информации (описаний, вычислений и пр.);

• -    управление внешними функциональными модулями-компонентами среды, обмен данными между модулями и их сохранение;

• -    выдачу и отображение в удобном виде хранящейся информации;

• -    удобное управление проектами со стороны пользователя.

Модель и содержание решения

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

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

Рис. 1. Упрощенная схема ИИС

Рис. 2. Пример дерева решения

Множество путей достижения решения (прохождение по вершинам И-ИЛИ-графа) может быть представлено в виде логической записи (предиката), где при выполнении всех условий принимается значение «истина», в противном случае – «ложь». Форма записи следующая:

P( A1], (1)

где A, F – элементы, выполняющие различные функции; B, C, D – альтернативные элементы, выполняющие близкие функции. Решение системы уравнений, представленных в предикатной форме, это и есть искомое техническое решение. Пример такого дерева приведен на рис. 2.

Недостатки существующих реализаций этого метода:

• -    неполнота набора вариантов ТС;

• -    невозможность внесения изменений;

• -    невозможность добавления новых решений.

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

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

• -    проектная операция (ПО) – некое действие, выполняемое пользователем и выделяемое им в отдельную смысловую единицу. Она разделяется в свою очередь на 3 элемента:

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

• -    операция «назначения» (тип 2) (О2) – операция, являющаяся назначением параметру приложения, «участвующего» в системе, значения (например назначение размеру некоторого числа);

• -    условие (У) – операция проверки истинности некоторого условия, задаваемого в ходе

работы с проектом. Обеспечивает «ветвление дерева проекта». Накладывается на параметр (см. термин ниже), может быть нескольких типов (существование, равенство, различные неравенства и принадлежность диапазону);

• -    параметр (П) – некая абстракция, интерпретируемая в зависимости от контекста. По смыслу близка к переменной. В реализуемой системе может содержать в себе постоянную величину, расчет, SQL – запрос, интерактивный запрос. В перспективе может хранить любую информацию, интерпретация которой будет зависеть от контекста, в котором применяется параметр (например, рис. 2).

Основу модели составляют:

• -    множество проектов, Пр{Прi}, где key – уникальное число-идентификатор проекта (уникальное числовое значение записи в БД, (далее будет опускаться)); Name – имя проекта(краткое смысловое содержание); Desc – описание содержания проекта;

• -    множество проектных операций ПО{ПОi }, где Type – тип элемента множества (1 – О1, 2 – О2, 3 – У); Name – имя элемента, отражающее смысловое наполнение; Desc – подробное описание; NOP1 – уникальное число, определяющее элемент множества, на который происходит переход после выполнения условия У; NOP2 – уникальное число, определяющее элемент множества, на который происходит переход после невыполнения данного условия;

• -    множествооперацийтип1О1{О1i}, где OpID – уникальное число, определяющее элемент множества ПО, с которым однозначно связан данный элемент; Content – содержимое элемента (текст макроса, скрипта и т.п.);

• -    множество операций тип 2 О2{О2i}, где OpID – уникальное число, определяющее элемент множества ПО, с которым однозначно связан данный элемент; ParamID – уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества О2;

• -    множество условий У{Уi}, где OpID – уникальное число, определяющее элемент множества ПО, с которым однозначно связан данный элемент; ParamID – уникальное число, определяющее элемент множества П, числовое значение на которое будет накладываться условие; ParamID1 – уникальное число, определяющее

элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества У (левая граница диапазона); ParamID2– уникальное число, определяющее элемент множества П, числовое значение которого будет использовано при выполнении данного элемента множества У (правая граница диапазона); Condition – собственно условие, налагаемое на элемент множества П;

• -    множество параметров П{Пi}, где ProjID – уникальное число, определяющее принадлежность данного элемента к проекту; Name – имя элемента; Type – тип(число), согласно которому интерпретируется содержимое элемента; Content – содержимое элемента; Desc – описание элемента; Value – числовое значение, возможно получаемое при интерпретации содержимого элемента.

Процесс проектирования можно представить в виде совокупности элементов множества ПО. Каждый элемент множества ПОi представляет собой отдельную реализованную подзадачу проектирования. Таким образом, существует возможность описать проект Пр, используя реализованные проектные решения:

1 1 (2)

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

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

Для реализации вышерассмотренного подхода была смакетирована система, состоящая из трех компонентов: центрального модуля (он же модуль работы с БД) и интерфейсных модулей для мо-деллера SolidWorks, и матпроцессора MathCAD. Для хранения и обработки данных была создана база данных на основе Paradox7. Структура БД показана на рис. 3.

Рис.3. Структура БД

Апробация

Результатом реализации стал макет программного комплекса из трех компонентов Core, SWService, MCService и проведена ее апробация на множестве типовых задач проектирования машиностроительных деталей и узлов.В исходном виде процесс проектирования описывается как типовая методика, включающая описание как задачи в текстовом виде, так и графических эскизов и последовательности математического расчета. Подтверждена принципиальная работоспособность системы, ее возможность сохранять накопленные проектные решения. Функциональные возможности системы соответствуют исходным предположениям.

Заключение

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

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

Перспективы развития:

• -    улучшение механизма расчетов в матпроцес-соре;

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

• -    обеспечение работы не только с деталями, но и со сборками,то есть включение других проектов как подветвей;

• -    оптимизация взаимодействия с пользователем;

• -    расширение набора служебных модулей для взаимодействия с другими приложениями;

• -    переход к новой модели хранения проектных решений в виде потокового графа.