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

Применение существующих систем для разработки моделей знаний в области проектирования схем технической реализации систем управления технологическими объектами связано с трудностями их ориентации на проблемную область, заключающимися в поиске скрытых правил вывода [1]. Например, для использования системы SALT (разработка университета Carnegie Mellon) необходима базовая модель понятийной системы проблемной области. Опыт использования подобных систем практически не способствует выявлению латентных знаний, свойственных для проектирования схем [2]. Быстрое обновление приборного ряда современных технических средств, отличающихся значительной номенклатурой и числом дополнительных свойств при схожих функциональных характеристиках, приводит к необходимости модификации знаний и к значительным затратам по ведению БД технических средств и систем управления.

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

Использование программной системы в процессе структуризации знаний

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

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

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

Ex®Na®Scº({Eа}È{(Ei, Ei+1)}),

Nai=Sim(Naj), Nai=Dif(Nak),                                (1)

где Ex – примеры схемных описаний, генерируемые программной системой; Nai, Naj, Nak – термины, используемые для кодирования основных понятий и отношений; Dif – операторы поиска различий; Sim – операторы поиска подобия; {Eа} – множество типов абстрактных элементов; {(Ei, Ei+1)} – множество межэлементных связей на поле схемы.

Каждый тип элемента Eа является формальным эквивалентом системного компонента концепции структуризации. На множестве типов элементов составляется таксономия с возможностью задания отношений связи (соединения) Rс таким образом, чтобы множество {Еа, Rс} однозначно и адекватно отображало структурные свойства технической реализации алгоритмов управления.

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

Pr1=<класс Cl имеет свойство Atr>,

Pr2=<свойство Atr предназначено

для связи элементов классов

Cl1 и Cl2>,                                                   (2)

Pr3=<соединение Ei с Ej приводит

к появлению свойства Atr>,

где Cl, Atr, E – переменные.

Новизной подхода является рассмотрение классов элементов на разных уровнях абстрагирования и детализации. Решаемые при диалоге с программной системой задачи формулируются как четыре формы представления технического обеспечения одной АСУТП: {текст}, {функциональная схема}, {принципиальная схема}, {схема соединений}. В чем различие описаний? Что одинакового в описаниях? Имеется набор схем технического обеспечения разных АСУТП. Отыскать соответствие в схемных описаниях и со- ответствующих им технических реализациях. Решение осуществляется на основе анализа выражения (1).

На основе выражений (2) находится решение задач, которые формулируются в виде: имеется набор элементов для построения технического обеспечения АСУТП. Какие свойства позволяют отличать элементы? Какие свойства элементов одинаковы? Имеется схема технического обеспечения АСУТП. Выявить правила для установки связи между элементами.

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

Алгоритм извлечения знаний

Рассматриваемые алгоритмы были предложены и апробированы в ходе разработки прототипов программных систем для проектирования:

-    функциональных схем технической реализации измерительных, управляющих цепей и цепей сигнализации систем управления температурой и расходом в объектах непрерывных технологических линий пищевой, рыбной и стекольной промышленности (FDсS – functional design of control system);

-    принципиальных схем технической реализации измерительных и управляющих систем управления технологическими объектами (ASED – automatic synthesis of electric diagrams);

-    тренажерных комплексов для обучения автоматизированному проектированию систем управления температурой, расходом, давлением, уровнем при подготовке специалистов по направлению «Автоматизация и управление» (TADCS – trainers for automated design of control systems).

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

Алгоритм извлечения знаний предусматривает следующее.

Шаг 1. Подбор вариантов подсистем АСУТП. Ведение БД технических заданий.

Шаг 2. Поиск и выбор технических средств для реализации функциональной структуры выбранных подсистем. Ведение БД, технических средств.

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

Шаг 4. Исследование наследования свойств в ветвях таксономии элементов в БД. Возврат к шагу 2 при нарушении наследования при переходе с уровня элементов на уровень разъемов элементов.

Шаг 5. Выявление наследуемых свойств и необходимости их представления при разработке функциональной структуры в выбранном элементно-параметрическом базисе.

Шаг 6. Задание области поиска для работы правил выбора элементов в БД по результатам оценки общего числа вариантов, соотношения правильных и неправильных вариантов.

Шаг 7. Проверка непротиворечивости правил вывода для синтеза межэлементных связей и их агрегации.

Шаг 8. Проверка сходимости алгоритма синтеза функциональной структуры в частично заданном элементно-параметрическом базисе.

Шаг 9. Переформулирование правил вывода на основе обобщения полученных примеров и выделенных отношений. Возврат к шагу 2.

Шаг 10. Выбор варианта схемной реализации технического обеспечения. Сохранение его в БД типовых решений.

Шаг 11. Для выбранного варианта генерация описаний принципиальной схемы.

Шаг 12. Проверка соответствия описаний и непротиворечивости правил преобразования схем.

Шаг 13. Проверка сходимости алгоритма синтеза описания принципиальной схемы для выбранной функциональной схемы.

Шаг 14. Переход к шагу 10.

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

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

При создании моделей в области построения и проектирования технического обеспечения АСУТП предполагается, что в системе используются известные понятия, образующие информационное пространство для представления рассматриваемой области с использованием известных терминов. Разработанный автором алгоритм формирования обобщенного понятия в области АСУТП базируется на подходе В.П. Гладуна, развитом В.Н. Вагиным и предусматривающем выделение в качестве определяющих понятий свойства объектов [4].

Шаг 1. Формирование понятия, соответствующего объектам множества АСУТП или их частей.

Шаг 2. Раскрытие объема понятия через определяющие его свойства.

Шаг 3. Выделение свойства, одно из значений которого соответствует всем объектам рассматриваемого класса.

Шаг 4. Выделение объектов других классов, имеющих такое же значение выделенного свой- ства.

Шаг 5. Составление примеров из описания объектов, выделенных на предыдущем шаге.

Шаг 6. Оценка по примерам принадлежности объекта к обобщенному понятию.

Отличие рассматриваемого алгоритма от существующих заключается в следующем: на шаге 2 в качестве базовых выбираются свойства, определяющие возможность совместимости технических элементов; на шаге 3 последовательно рассматриваются свойства, выделенные в количественных и порядковых шкалах; на шаге 4 обобщаются линейно связанные свойства и объединяются в новые свойства. Итогом оценки является гипотеза, которая представляется в виде логической функции, полученной в результате выделения понятий. В случае принятия гипотезы функция в дальнейшем является решающим правилом классификации при построении таксономии абстрактных элементов.

Выделение отношений в проектировании систем управления

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

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

Пример формирования композиционного отношения «измерять»: R=R21 º R51 º R42(R43(xj)) º º R41(R24(R22(R91 º R25(xj)))), где Rij – отношения: R – «измерять», R21 – часть–целое (преобразователь и регулятор являются частью системы измерения); R25 – соответствия (физический параметр является входом для измерительного преобразователя); R22 – соединяться с (выход преобразователя соединяется с входом регулятора); R24 – настраиваться (регулятор настраивается на тип преобразователя); R41 – иметь свойство (регулятор имеет свойство индикации); R43 – быть причиной (изменение параметра является причиной изменения показаний); R42 – целевое назначение (индикация служит для информирования оператора о значении физического параметра); R51 – предшествовать (преобразователь предшествует регулятору в линейной структуре системы); R91 – род–вид (преобразователь является видом класса «измерительные преобразователи»).

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

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

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

Литература

1. Дюк В.А., Самойленко А.В. Data Mining: учебный курс. СПб: Питер, 2001. 232 с.

2. Осипов Г.С. Приобретение знаний интеллектуальными системами. М.: Наука. Физматлит, 1997. 112 с.

3. Шенк Р. Обработка концептуальной информации. М.: Энергия, 1980. 360 c.

4. Вагин В.Н. Дедукция и обобщение в системах принятия решений. М.: Наука, 1988. 384 с.

5. Поспелов Д.А. Ситуационное управление: теория и практика. М.: Наука, 1986. 288 с.