Программные продукты и системы

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

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

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

Невозможность полноценного обмена между различными системами связана с частичным или полным отсутствием интероперабельности. Поэтому достижение интероперабельности остается серьезной проблемой, создающей трудности для полноценного обмена результатами проектной деятельности между различными САПР. Предлагаемые подходы к решению данной проблемы не могут быть реализованы по нескольким причинам: все автоматизированные системы твердотельного проектирования никогда не будут иметь абсолютно одинаковый набор конструктивных элементов, так как потеряют свои конкурентные преимущества так же, как невозможно в рыночных отношениях заставить всех пользоваться только одной и той же САПР [5].

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

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

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

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

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

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

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

–      отвязка от конкретных форматов данных и их преобразований;

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

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

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

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

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

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

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

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

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

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

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

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

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

Множество путей достижения технического решения (прохождение по вершинам И-ИЛИ-графа) может быть представлено в виде логической записи (предиката), где при выполнении всех условий принимается значение «истина», а в противном случае – «ложь». Форма записи следующая: P(A&(BÈCÈD)&F)=[0; 1], где A, F – элементы, выполняющие различные функции; B, C, D – альтернативные элементы, выполняющие близкие функции. Решение системы уравнений, представленных в предикатной форме, и есть удовлетворяющее ТЗ техническое решение.

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

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

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

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

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

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

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

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

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

–      проектов, Пр{Пр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 представляет собой отдельную реализованную подзадачу проектирования. Таким образом, существует возможность описать проект Пр, используя реализованные проектные решения: Пр=П11&П21&У1((П1i&П2j& …) or (Уk(…))), где i, j, k – индексы элементов множеств, адекватные проектным ситуациям.

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

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

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

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

Апробация

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

Одной из задач, рассмотренных во время апробации, была задача проектирования резцов. Выбор различных ветвей общего дерева решений позволяет на выходе получить различные приложения (рис. 3) – «ФА САПР Призматический резец», то есть инструмент проектирования объектов класса призматический резец, либо «ФА САПР Круглый резец» для проектирования объектов класса круглый резец. Если же выбрать ветви дерева решений, соответствующие обоим резцам, то будет сгенерирована ФА САПР для построения резцов обоих типов, то есть класс объектов, которые можно будет проектировать с помощью такого инструмента, еще более расширится.

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

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

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

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

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

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

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

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

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

Дальнейшее развитие технологии и разработка полноценной математической системы на основе математического ядра, построенного по принципу геометрического ядра Open CASCADE, откроет возможность реализации полнофункциональной интерактивной системы построения функционально адаптированных САПР. Такая система не только обеспечит разработчиков эффективным средством обмена проектными решениями, но и откроет возможности для быстрой автоматизации рабочих мест специализированными инструментами проектирования на основе функционально адаптированных САПР.

Литература

1.     Судов Е.В. Интегрированная информационная поддержка жизненного цикла машиностроительной продукции. Принципы. Технологии. Методы. Модели. М.: МВМ, 2003. 264 с.

2.     Sobolewski M. Foreword Next Generation Concurrent Engineering: Smart and Concurrent Integration of Product Data, Services, and Control Strategies, 2005, ISPE, 620 p.

3.     Похилько А.Ф. Четырехуровневая иерархия процессов обработки процедурных знаний в интегрированной информационной среде автоматизации проектной деятельности // AIS-IT'09: тр. конгр. М.: Физматлит, 2009. Т. 2. С. 52–53.

4.     Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. М.: Вильямс, 2008. 720 с.

5.     Hamilton P. Азбука технологий моделирования в MCAD-системах. Ч. III. Как технологии MCAD влияют на процесс разработки изделия // CAD/CAM/CAE Observer. 2008. № 2 (38). C. 34–36.

6.     Похилько А.Ф. Инструментарий представления процессов проектной деятельности в функционально адаптируемой форме // AIS-IT'010: тр. конгр. М.: Физматлит, 2010. Т. 2. С. 104–106.