- •«Технологии искусственного интеллекта в асутп»
- •Оглавление
- •1. Сферы применения экспертных систем реального времени (эсрв) в задачах асутп 6
- •2. Промышленные внедрения эсрв в асутп 18
- •3. Инструментальные средства синтеза эсрв 134
- •Список сокращений
- •1. Сферы применения экспертных систем реального времени (эсрв) в задачах асутп
- •2. Промышленные внедрения эсрв в асутп
- •2.1. Микро-эсрв интеллектуальных оконечных устройств
- •Полевая шина
- •2.2. Применение эсрв в контроллерном слое асутп
- •2.2.1. Мини-эсрв в контроллерах фирмы Fisher-Rosemount
- •2.3. Эсрв верхнего уровня асутп
- •2.3.1. Система свбу
- •2.3.2. Система спек
- •2.3.3. Система «компакс»
- •4. Модуль базы данных выполняет функции:
- •Модуль формирования отчетов по состояниям Агрегатов и Планированию ремонтов
- •2.4. Использование эсрв в комплексных решениях
- •2.4.1. Решения корпорации Siemens
- •2.4.2. Концепции Plant Intelligence корпорации Wonderware
- •2.4.3. Модели Plant Intelligence и ipm корпорации ge Fanuc
- •2.4.4. Комплексные решения Emerson
- •3. Инструментальные средства синтеза эсрв
- •3.1. Среды разработки и эксплуатации эсрв
- •3.1.1. Платформа g2
- •3.1.2. Система sdb
- •3.1.3. Инструментальная среда «оператор»
- •3.1.3.1. Язык представления знаний абис
- •1) Особенности дедуктивной системы, реализованной в языке abis
- •1.1) Общая структура системы
- •1.2) Предложения языка и база данных
- •1.3) Управление работой дедуктивной системы
- •1.4) Метод согласования
- •2) Структура языка abis
- •2.1) Базовые типы данных
- •2.2) Правила
- •2.3) Структура программы на языке abis
- •3) Логика выполнения программы на языке abis
- •3.1) Выполнение программы на уровне модулей
- •3.2) Выполнение программы на уровне правил
- •3.3) Обработка условия
- •3.4) Текущая достоверность
- •3.5) Обработка следствия правила
- •3.6) Выполнение оператора согласования в условии правила
- •3.6.1) Выполнение оператора согласования без квантора или с квантором all.
- •3.7) Особенности использования переменных при обработке правила
- •3.2. Разработка эсрв на базе универсальных языков высокого уровня
- •3.2.1. Инструментальный комплекс ais
- •Заключение
- •Управление предприятием Сервер бд асуп Сервер приложений эс а6
- •Мини-эсрв а2
- •Управление
- •Производством
- •Управление
- •Процессом
- •Управление
- •Оборудованием
- •Клиент эсрв а2
- •Клиент эсрв а4
- •Сервер приложений эсрв а4
- •Клиент эсрв а4
- •Эсрв а3
- •Микро-эсрв а1
- •Бд асутп
- •Сервер бд асуп Управление предприятием Координатор-агент а2 Координатор-агент а2
- •Агент а1
- •Агент а1
- •Агент а1
- •Координатор-агент а1
- •Агент а2
- •Координатор- агент а1
- •Агент а1
- •Шлюзовой агент а2
- •Агент а2
- •Агент а2
- •Приложений асуп
- •Агент коммуни-каций а1
- •Приложений асутп
- •Управление
- •Производством
- •Управление
- •Процессом
- •Управление
- •Оборудованием
- •Бд асутп
- •Список литературы
3.1. Среды разработки и эксплуатации эсрв
В области АСУТП/АСУП использование сред разработки и эксплуатации ЭСРВ (т.е., оболочек ЭСРВ, функционирующих на фазе эксплуатации вместе с целевой системой) является преобладающим подходом. Поэтому именно данный класс инструментальных средств преобладает в представленных далее примерах. При этом основным критерием выбора конкретно рассматриваемых систем являлось стремление отразить как можно более широкий спектр концепций, на которых может основываться построение современных инструментов соответствующего типа применительно к специфике ЭСРВ в АСУТП и АСУП.
В настоящее время известно значительное количество самых разнообразных инструментальных средств поддержки проектирования ЭСРВ. Это такие системы и комплексы, как G2, RTworks, Picon, RTexpert, RTES, PROCON, RT/AI, Rocky в США, COMDALE/C в Канаде, EIXAX, ERIC, EXTKERNEL, Acekit, EXCORE в Японии, ILOG Rules, ADS, Escort, COGSYS в Европе, ЭКСПЕРТ, ЭКСПЕРТИЗА,САТУРН-ПЗ в России и многие др. Выполняется значительное количество масштабных научно-исследовательских и практических программ и проектов, связанных с инструментарием интеллектуальных систем реального времени.
Более 50% мирового рынка ЭСРВ на данный момент захвачено инструментальным комплексом G2 (Gensym Inc., США), который рассматривается в п.3.1.1. Однако, далее в п.3.1.2 и 3.1.3 применительно к тематике АСУТП и АСУП рассматриваются и другие возможные подходы к организации разработки и поддержки эксплуатации ЭСРВ, связанные с методологией системного моделирования (на примере системы SDB) и систем специализированных языков инженерии знаний (на примере отечественной системы ОПЕРАТОР и языка ABIS).
3.1.1. Платформа g2
История создания G2 началась в 1985 г., когда фирма Lisp Machine Inc. выпустила систему Picon для символьных ЭВМ Symbolics. Успех этого инструментального средства привел к тому, что группа ведущих разработчиков Picon в 1986 г. образовала частную фирму Gensym, которая, значительно развив идеи, заложенные в Picon, в 1988 г. вышла на рынок с системой G2, версии 1.0. В настоящее время функционирует версия 8.2.
С отставанием от Gensym на 2 – 3 года другие фирмы начали создавать свои ИС для создания ЭС РВ. С точки зрения независимых экспертов NASA, проводивших комплексное исследование характеристик и возможностей некоторых средств синтеза ЭСРВ, в настоящее время безусловным лидером считается G2, а следующие места со значительным отставанием (реализовано менее 50% возможностей G2) занимают RTworks (Talarian, США), COMDALE/C (Comdale Tech., Канада), COGSYS (SC, США), ILOG Rules (ILOG, Франция).
G2 поддерживает построение и эксплуатацию ЭСРВ для широкого класса задач:
- мониторинг в реальном времени, обнаружение неисправностей и аварийная сигнализации;
- управление процессами на верхнем и нижнем уровнях АСУТП и в среде АСУП (частично – на уровне бизнес-приложений);
- диагностика и прогнозирование;
- планирование и составление расписаний;
- оптимизация на всех уровнях управления;
- поддержка функций оперативной консультации и принятия решений;
- поддержка моделирования и анализа;
- поддержка интеллектуальных человеко-машинных интерфейсов;
- проектирование АСУТП/АСУП.
Решения на базе G2 способны поддерживать модели не только статических, но и динамических предметных областей (причем, моделирование управляемой системы, внешней среды и самой АСУ и эксплуатация приложения могут производиться параллельно во времени, а также взаимно влиять друг на друга). Особо следует также отметить, что G2 совмещает в себе черты развитой оболочки и САПР ЭСРВ, поскольку поддерживает не только непосредственное исполнение приложения в целевой среде, но и портацию «минимального ядра» исполнительной системы G2 на широкий круг аппаратно-программных платформ (полный перечень платформ, поддерживаемых ядром G2 приведен в табл.2.).
Таблица 2. Платформы, поддерживаемые G2
Фирма-производитель |
Вычислительная система |
Операционная система |
Digital Equipment |
VAX Зххх - 9ххх |
VMS |
DECstation Зххх, бххх |
ULTRIX |
|
DEC Alpha APX |
Open VMS, OSF/1, Windows NT |
|
SUN Microsystems
|
SUN-4 |
Sun OS |
SPARC 1, 2, 10, LX, Classic |
Sun OS/Solaris 1, Solaris 2.x |
|
Hewlett Packard |
НР9000/4хх, 7хх, 8хх |
HP-UX |
IBM |
RISC 6000 |
AIX |
Data General |
AViiON |
DG/UX |
Silicon Graphics |
IRIS, INDIGO |
IRIX |
Motorola |
Motorola 88000 |
UNIX |
NEC |
EWS 4800 |
EWS-UX/V |
* |
* |
Windows NT/2000/2003/XP, Red Hat Linux, Linux Enterprise, Compaq Tru64 UNIX |
Общими «плюсами» G2 можно считать:
- поддержку широкой номенклатуры промышленных стандартов (ActiveX/COM, .NET, CORBA, Java RMI, SQL, ODBC, RPC, JMS, OPC, XML, SNMP, HTTP и др.) и, как следствие, – высокую интегрируемость с внешними приложениями, СУБД, сетевыми ресурсами, аппаратными средствами нижнего уровня АСУТП и т.д. (см. рис.38). Применительно к АСУТП следует особо отметить наличие «прямых» и «быстрых» интерфейсов (с непосредственным связыванием данных) со значительным числом популярных линий ПЛК ведущих фирм-производителей, промышленных серверов технологических данных, а также корпоративными серверами баз данных Oracle, Informix, Sybase и др. (без использования ODBC-драйверов). Внешние взаимодействия базируются на специальных программных компонентах (G2 Bridges – «мостах», соединениях), которые могут выбираться из широкого набора поставляемых продуктов, или независимо разрабатываться на основе развитых API (основные – для C и Java);
- высокую степень независимости от вычислительной платформы (в части миграции баз знаний – практически полную, т.к. последние могут храниться в виде ASCII-текстов);
- совместимость снизу-вверх с предыдущими версиями комплекса;
- широкий спектр универсальных возможностей, не зависимых от решаемых задач;
- обеспечение технологической основы для построения прикладных систем различного назначения и архитектуры;
- комфортную среду разработки и эксплуатационный сервис;
- распределенную архитектуру «клиент-сервер»;
- высокую производительность приложений (при рекомендуемых конфигурациях станций – тысячи продукций и процедур в секунду, с возможностью параллельного исполнения правил и процедур, обработки моделей, с поддержкой фокусировок, механизмов приоритетов и т.п.).
Функциональность G2 обеспечивает возможность параллельного решения задач моделирования и анализа, проектирования (в т.ч., динамического перепроектирования), планирования и исполнения приложений в реальном времени с поддержкой многопользовательских распределенных режимов работы, управления физическим размещением данных и программ, а также структурой информационных потоков, и т.д.
Рис.38. Взаимодействие G2 с аппаратно-программным окружением
Важным достоинством G2 для российских пользователей является также возможность ее применения в качестве интегрирующего компонента, позволяющего за счет открытости интерфейсов и поддержки широкого спектра вычислительных платформ эффективно объединить уже существующие, разрозненные средства автоматизации в единую комплексную систему управления, охватывающую все аспекты производственной деятельности – от бизнес-стратегии до управления технологическим процессом на нижнем уровне АСУТП.
ЭСРВ в среде G2 состоит из базы знаний, машины вывода, подсистемы моделирования и планировщика.
База знаний
Все знания в G2 хранятся в двух типах файлов: базы знаний и библиотеки знаний. В файлах первого типа хранятся знания о приложениях: определения (типизация) всех объектов, сами объекты, правила, процедуры и т.п. В файлах библиотек хранятся общие знания, которые могут быть использованы более, чем в одном приложении, например, определение стандартных объектов. Файлы баз знаний могут преобразоваться в библиотеки знаний и обратно. В целях обеспечения повторной используемости приложений реализовано средство, позволяющее объединять с текущим приложением ранее созданные базы и библиотеки знаний. При этом конфликты в объединяемых знаниях выявляются автоматически.
Знания структурируются: предусмотрены иерархия классов, иерархия модулей, иерархия рабочих пространств.
Сущности и иерархия классов
Класс, базовое понятие объектно-ориентированного подхода, является основой представления знаний в G2. Структуры данных представляются в виде классов объектов (или определений объектов), имеющих определенные атрибуты (в том числе – процедуры, являющиеся методами класса). Классы наследуют атрибуты от суперклассов и передают свои атрибуты подклассам. Каждый класс (исключая корневой) может иметь конкретные экземпляры класса. Допускается множественное наследование.
Все, что хранится в базе знаний и с чем оперирует система, является экземпляром того или иного класса. Более того, все синтаксические конструкции G2 являются классами. Для сохранения общности даже базовые типы данных - символьные, числовые, булевы и истинностные значения нечеткой логики - представлены соответствующими классами. Описание класса включает ссылку на суперкласс и содержит перечень атрибутов, специфичных для класса.
Иерархия модулей и рабочих пространств
Для структуризации G2-приложений используются «модули» и «рабочие пространства». Несмотря на то, что функции этих конструкций схожи, между ними есть существенные различия.
Приложение может быть организовано в виде одной или нескольких баз знаний, называемых модулями. В последнем случае говорят, что приложение представлено структурой (иерархией) модулей. На верхнем уровне - один модуль верхнего уровня. Модули следующего уровня состоят из тех модулей, без которых не может работать модуль предыдущего уровня. Структурирование приложений позволяет разрабатывать приложение одновременно нескольким группам разработчиков, упрощает разработку, отладку и тестирование, позволяет изменять модули независимо друг от друга, упрощает повторное использование знаний.
Рабочие пространства являются контейнерным классом, в котором размещаются другие классы и их экземпляры, например, объекты, связи, правила, процедуры и т.д. Каждый модуль (база знаний) может содержать любое число рабочих пространств. Рабочие пространства образуют одну или несколько древовидных иерархий с отношением «is-а-part-of» («является частью»). С каждым модулем ассоциируется одно или несколько рабочих пространств верхнего (нулевого) уровня; каждое из них - корень соответствующей иерархии. В свою очередь, с каждым объектом (определением объекта или связи), расположенным в нулевом уровне, может ассоциироваться рабочее пространство первого уровня, «являющееся его частью» и т.д.
Различие между модулями и рабочими пространствами состоит в следующем. Модули разделяют приложение на отдельные базы знаний, совместно используемые в различных приложениях. Они полезны в процессе разработки приложения, а не его исполнения. Рабочие пространства, наоборот, выполняют свою роль при исполнении приложения. Они содержат в себе различные сущности и обеспечивают разбиение приложения на небольшие части, которые легче понять и обрабатывать.
Рабочие пространства можно устанавливать (вручную или действием в правиле/ процедуре) в активное или неактивное состояние (при этом сущности, находящиеся в этом пространстве и в его подпространствах, становятся невидимыми для механизма вывода). Данный механизм используется, например, при наличии альтернативных групп правил, когда активной должна быть только одна из них.
Кроме того, рабочие пространства используются для определения пользовательских ограничений, определяющих разное поведение приложения для различных категорий пользователей.
Структуры данных
Сущности в базе знаний с точки зрения их использования можно разделить на структуры данных и выполняемые утверждения. Примерами первых являются объекты и их классы, связи (connection), отношения (relation), переменные, параметры, списки, массивы, рабочие пространства. Примерами вторых - правила, процедуры, формулы, функции.
Выделяют объекты (и классы), встроенные в систему и вводимые пользователем. При разработке приложения, как правило, создаются подклассы, отражающие специфику данного приложения. Среди встроенных подклассов объектов наибольший интерес представляет подкласс данных, включающий подклассы переменных, параметров, списков и массивов.
Особая роль отводится переменным. В отличие от статических систем переменные делятся на три вида: собственно переменные, параметры и простые атрибуты. Параметры получают значения в результате работы машины вывода или выполнения какой-либо процедуры. Переменные представляют измеряемые характеристики объектов реального мира и поэтому имеют специфические черты: время жизни значения и источник данных. Время жизни значения переменной определяет промежуток времени, в течение которого это значение актуально, по истечении этого промежутка переменная считается не имеющей значения.
Выполняемые утверждения
Основу выполняемых утверждений баз знаний составляют правила и процедуры. Кроме того, есть формулы, функции, действия и т.п. Правила в G2 имеют традиционный вид: левая часть (антецедент) и правая часть (консеквент). Кроме if-правила, используется еще четыре типа правил: initially («изначально»), unconditionally («безусловно»), when («когда») и whenever («всякий раз, когда»). Каждое из типов правил может быть как общим, т.е. относящимся ко всему классу, так и специфическим, относящимся к конкретным экземплярам класса.
Возможность представлять знания в виде общих, а не только специализированных, правил позволяет минимизировать избыточность базы знаний, упрощает ее наполнение и сопровождение, сокращает число ошибок, способствует повторной используемости знаний (общие правила запоминаются в библиотеке и могут использоваться в сходных приложениях).
Несмотря на то что продукционные правила обеспечивают достаточную гибкость для описания реакций системы на изменения окружающего мира, в некоторых случаях, когда необходимо выполнить жесткую последовательность действий, например, запуск или остановку комплекса оборудования, более предпочтителен процедурный подход. Язык программирования, используемый в G2 для представления процедурных знаний, является достаточно близким родственником языка Pascal. Кроме стандартных управляющих конструкций язык расширен элементами, учитывающими работу процедуры в реальном времени: ожидание наступления событий, разрешение другим задачам прерывать ее выполнение, директивы, задающие последовательное или параллельное выполнение операторов. Еще одна интересная особенность языка - итераторы, позволяющие организовать цикл над множеством экземпляров класса.
Машина вывода, подсистема моделирования и планировщик
Главный недостаток прямого и обратного вывода, используемых в статических экспертных системах, - непредсказуемость затрат времени на их выполнение. С точки зрения динамических систем, полный перебор возможных к применению правил - непозволительная роскошь. В связи с тем, что G2 ориентирована на приложения, работающие в реальном времени, в машине вывода должны быть средства для сокращения перебора, для реакции на непредвиденные события и т.п. Для машины вывода G2 характерен богатый набор способов возбуждения правил. Предусмотрено девять случаев инициации:
1. Данные, входящие в антецедент правила изменились (прямой вывод - forward chaining).
2. Правило определяет значение переменной, которое требуется другому правил или процедуре (обратный вывод - backward chaining).
3. Каждые n секунд, где n - число, определенное для данного правила (сканирование - scan).
4. Явное или неявное возбуждение другим правилом - путем применения действий фокусирования и возбуждения (focus и invoke).
5. Каждый раз при запуске приложения.
6. Входящей в антецедент переменной присвоено значение, независимо от того, изменилось оно или нет.
7. Определенный объект на экране перемещен пользователем или другим правилом.
8. Определенное отношение между объектами установлено или уничтожено.
9. Переменная не получила значения в результате обращения к своему источнику данных.
Если первые два способа достаточно распространены и в статических системах, а третий хорошо известен как механизм запуска процедур-демонов, то остальные являются уникальной особенностью системы G2. В связи с тем, что G2-приложение управляет множеством одновременно исполняемых задач, необходим планировщик. Хотя пользователь никогда не взаимодействует с ним, планировщик контролирует всю активность, видимую пользователем, и активность фоновых задач. Планировщик определяет порядок обработки задач, взаимодействует с источниками данных и пользователями, запускает процессы и осуществляет коммуникацию с другими процессами в сети.
Подсистема моделирования G2 - достаточно автономная, но важная часть системы. На различных этапах жизненного цикла прикладной системы она служит достижению различных целей. Во время разработки подсистема моделирования используется вместо объектов реального мира для имитации источников информации (например, показаний датчиков). На этапе эксплуатации прикладной системы процедуры моделирования выполняются параллельно функциям мониторинга и управления процессом, что обеспечивает следующие возможности:
- верификация входной информации (например, от датчиков) во время исполнения приложения;
- подстановка модельных значений переменных при невозможности получения реальных значений (выход из строя датчика или длительное время реакции на запрос).
Как видим, играя роль самостоятельного агента знаний, подсистема моделирования повышает жизнеспособность и надежность приложений. Для описания внешнего мира подсистема моделирования использует уравнения трех видов: алгебраические, разностные и дифференциальные (первого порядка).
Отдельной обширной областью анализа является рассмотрение инструментальных средств, предоставляемых G2 для разработки приложений. Представляется удобным разделение всего инструментария на следующие группы поддерживаемых задач:
- разработка информационно-программной инфраструктуры приложения;
- реализация базовой функциональности ЭСРВ;
- разработка пользовательских интерфейсов.
Проектирование информационно-программной инфраструктуры целевой системы подразумевает формирование общей архитектуры приложения, определение внешних интерфейсов, формирование моделей целевой среды и автоматизируемых (управляемых) процессов и т.п. Все соответствующие проектные действия в G2 поддержаны развитыми, полностью интегрируемыми графическими и диалоговыми средствами. Полная целостность (в функциональном, информационном и программном аспектах) выполняемого разработчиком проекта гарантируется поддержкой в G2 единой объектно-ориентированной технологии, в которой на общей основе представляются любые сущности (объекты, системы, процессы) предметной области, модели проектируемой системы и ее окружения, пользовательские интерфейсы и т.п. Примерами мощных инструментов «системного проектирования» различного уровня, реализованных в G2, являются GDA (G2 Diagnostic Assistant), компоненты G2 ReThink и G2 NeurOn-Line (NOL), BatchDesign_Kit (BDK), G2GL (G2 Graphical Language) и многие др. средства, дополняющие базовый набор стандартных сервисов «системного архитектора» (в первую очередь связанных с интерфейсом для работы с объектно-ориентированными моделями приложения – объектами, классами, иерархиями классов, рабочих пространств, модулей, с базами и библиотеками знаний и т.д.).
Так, компонент GDA представляет собой среду визуального программирования (на базе соответствующего графического языка) для создания и описания механизмов обработки моделей технологических процессов (на фазе проектирования) и поддержки реализации запрограммированных действий (на фазе эксплуатации приложения) при решении задач диагностики, мониторинга, статистического и логического анализа данных в реальном времени. За счет использования «сквозной» объектно-ориентированной технологии, охватывающей методы визуального представления и использования объектов, формирование и программирование моделей в GDA сводится к выбору необходимых объектов из набора типовых (сотни) или пользовательских блоков, представляющих входные точки, фильтры данных, операции математической и логической обработки, управляющие воздействия и т.д. и соединению их в среде графического конструктора: связи обеспечивают информационные взаимодействие объектов, а программирование системы заключается в простом конфигурировании и связывании объектов. В runtime среде GDA служит сервером знаний, вырабатывающим оперативные рекомендации, корректирующие действия и управляющие команды. Аналогично устроен и BatchDesign_Kit (BDK), предназначенный для проектирования и реализации batch-систем (АСУ процессами смешения и дозирования) и многие другие функциональные подсистемы G2.
Проектирование и реализацию ядра ЭСРВ в среде G2 практически невозможно выделить в независимую составляющую единого проектного процесса, поскольку построение моделей предметной области, среды эксплуатации и пользовательских интерфейсов (т.е., моделей, являющихся неотъемлемыми компонентами синтезируемых баз знаний G2) неразрывно связано (и производится совместно, параллельно) с разработкой процедурной составляющей ЭСРВ (наборов продукционных правил, процедур, функций и т.п.) и базируется на общей глобальной объектно-ориентированной модели системы «объект автоматизации + G2 + внешняя среда» и общей инструментальной среде. Поэтому выделим в классе инструментов «непосредственного проектирования и реализации» ЭСРВ лишь развитую систему программирования G2-приложений. Среда разработки G2-программ полностью соответствует облику развитых современных RAD-инструментов, обладает многофункциональными графическими интерфейсами, многоуровневыми системами основных и контекстных меню и панелей инструментов, наборами toolbox, конструкторов и шаблонов, средствами автоматизации кодирования, оптимизации, динамического моделирования, планирования, самонастройки, отладки, инспекции, функциями автоматического контроля синтаксиса, структурирования, справочными online-средствами и т.д. Особого внимания заслуживает сам язык представления знаний G2.
На рис.39 приведены иллюстративные примеры описания различных типов продукционных правил (рис.39-а) и пример отдельной процедуры (рис.39-б)) на языке G2.
С точки зрения внешнего представления данный язык может быть охарактеризован как структурированный англо-подобный естественный язык («деловая проза»). Однако, его семантика существенно отличается от универсальных языков инженерии знаний аналогичного назначения. По сути дела G2 имеет мощный встроенный универсальный алгоритмический и объектно-ориентированный язык, расширенный средствами представления и обработки знаний. Выразительная мощность языка чрезвычайно высока. Наиболее важными отличительными особенностями этого языка являются:
- сквозная поддержка единой объектно-ориентированной модели G2 (все проектные примитивы, от элементарных сущностей до целостных приложений, включая базы знаний, рабочие пространства, модули, продукционные правила, процедуры и т.д., являются объектами соответствующих классов, а следовательно, могут содержать программно управляемые свойства и методы, использовать механизмы наследования, гибко агрегироваться в сложные структуры и проч.);
- мощные средства описания временных процессов реального времени и управления ими (с абсолютными, относительными, номинальными, интервальными и др. шкалами, с различными способами межпроцессного взаимодействия, организации циклических, последовательных, параллельных, дискретных, непрерывных, периодических схем выполнения действий, с гибкой интеграцией с событийными моделями и проч.);
- мощные средства типообразования и оперирования типами наравне с объектами с применением всех возможностей объектно-ориентированного подхода, аппарата контекстов, базовых механизмов структуризации и агрегирования и др.;
- широкое многообразие средств описания процедурных составляющих приложения (методы классов, правила, процедуры, функции, формулы, выражения, действия, операции), поддерживающих сложные схемы атрибутирования, управления исполнением и т.д.;
- развитое множество общесистемных управляющих инструкций («действий» - action), которые могут непосредственно использоваться в программах;
(а)
(б)
Рис.39. Внешнее представление программных описаний в G2: (а) – примеры продукционных правил; (б) – текст процедуры
- множество системных и пользовательских библиотек функций и классов, ActiveX- и COM-компонентов, программных шаблонов и др. готовых проектных примитивов;
- богатые возможности по описанию наборов продукционных правил и методов их обработки в модельном и реальном времени, включая спецификации схем исполнения, способов фильтрации, фокусировки, актуализации, динамической реструктуризации, разрешения конфликтов и многое др.;
- прямое включение в синтаксис и семантику языка элементов логики и алгебры нечетких множеств, а при использовании NeurOn-Line – и средств работы с нейро- и нейро-fuzzy моделями в совокупности с продукционными методами;
- значительное разнообразие выразительных средств отображения квантификации, модальности, логических композиций, теоретико-множественных отношений, видов неопределенности и т.п., позволяющих гибко описывать элементы знаний;
- полная и прямая интеграция программ с моделями пользовательских интерфейсов, предметной области, среды исполнения и самой среды разработки, включая адекватное отражение всех аспектов динамики работы приложения (в т.ч. – динамики изменения баз знаний, состояния имитационных и прогнозирующих моделей, перепрограммирования в реальном масштабе времени и проч.).
Разработка пользовательских интерфейсов в G2 также поддержана многочисленными сервисными функциями – библиотеками стандартных графических объектов, возможностями использования анимации, аудио- и видео-элементов с неограниченными возможностями по расширению стандартных средств на базе ActiveX, COM и т.п. (см. рис. 40). В комплект поставки G2 входит ряд утилит для разработчиков которые позволяют достичь единообразия, совместимости и надежности приложений – «Среда разработки пользовательского интерфейса G2 / Библиотека пользовательских интерфейсов» (GUIDE / UIL), «Система меню G2» (GMS), «Динамические индикаторы G2» (GDD) (набор циферблатов, счётчиков и индикаторов, основанных на пиктограммах G2, которые можно использовать непосредственно или как классы-родители), «Интерфейс разработки G2» (GDI) (содержит шаблоны стандартных меню и диалогов; GDI можно использовать как основу для разработки новой системы меню или для простого использования одного из множества типовых диалогов GDI, таких как выбор файлов, печать, управление модулями, и т.п.), «Электронные таблицы G2 XL» (GXL) (создание таблиц для отображения и правки широкого спектра списков, массивов и сложных структур данных и др.). Поскольку любые возможности пользовательских интерфейсов и их отдельных элементов реализуются в G2 на базе единой объектно-ориентированной технологии, разработчику предоставляются все возможности видоизменения, настройки и расширения функциональности и дизайна интерфейса за счет использования обычных методов работы с классами и объектами, которые обеспечиваются платформой G2.
Рис.40. Примеры элементов пользовательского интерфейса G2
Кроме того, приложение может управлять динамической реконфигурацией интерфейсов (например, интерактивной графикой, динамикой цветовых палитр и т.п.), многопользовательскими режимами их работы (с разделением прав доступа, персональными предпочтениями и т.п.) и проч. (см. рис.41,42).
Рис.41. Пример интерфейса с «динамической графикой»
Рис.42. Пример интерфейса с интерактивной графикой
Следует также отметить, что все процессы, связанные с разработкой приложений в G2, могут корректно реализовываться непосредственно в ходе эксплуатации продукта. Надежность соответствующих методов модернизации в первую очередь обеспечивается способностью G2 к поддержке комплексных моделей среды эксплуатации, а следовательно – возможностью адекватного моделирования, анализа, тестирования, настройки и согласования процессов функционирования и обновления среды в реальном времени.
Функциональным расширением поставок G2 является набор дополнительных системных компонентов. Для версии 8.2 этот набор включает:
G2 ReThink (автоматизация бизнес-процессов);
G2 Optegrity (решение задач планирования и прогнозирования);
G2 NeurOn-Line (поддержка нейросетевых моделей в различных задачах);
G2 e-SCOR (управление цепочками поставок)
G2 webSCOR (web-ориентированный инструмент управления цепочками поставок);
G2 Integrity (сетевая интеграция).
G2 ReThink, представляет собой целостный многофункциональный программный инструмент для графического проектирования, моделирования и оперативного управления бизнес-процессами. В отличие от большинства систем и инструментальных средств классов BRE (Business Rule Engine – «машина бизнес-правил») и BPM (Business Process Management – «управление бизнес-процессами»), ReThink функционально охватывает весь жизненный цикл бизнес-процессов – от исходного описания бизнес-моделей и комплекса бизнес-правил, их моделирования и настройки, до развертывания системы в реальной целевой среде, интеграции с программным окружением (включая контуры АСУТП и АСУП), адаптации и модернизации (в т.ч., – в реальном масштабе времени). При этом, в качестве важных дополнительных достоинств ReThink можно отметить поддержку многосценарного моделирования, возможность одновременного запуска нескольких моделей с одним сценарием и т.п.
В ReThink объединены возможности целого ряда развитых технологий: графический объектно-ориентированный язык для описания моделей и проектов, средства анимации и имитационного моделирования реконструируемых процессов, поддержка различных методов искусственного интеллекта для полного и адекватного представления экспертных знаний о процессах. Все это открывает доступ к непосредственному моделированию и реконфигурированию бизнес-процессов новой группе пользователей – менеджерам, которые могут пользоваться функциональностью данной системы без привлечения программистов и технологов вплоть до стадии реализации идей в виде работающих моделей процессов.
Для представления моделей бизнес-процессов используются диаграммы, состоящие из блоков и соединений (см. рис.43). Блоки представляют задачи в бизнес-процессах, а соединения - потоки сущностей: документов, информации, а также предметов, фигурирующих в описании процесса, - например, запасных частей, комплектующих и т.п. В системе реализован ряд стандартных блоков, которые могут быть использованы в качестве сборочных элементов для построения работающих моделей практически любых процессов, например: «источник заявок», «принятие решения», «обработка задания» и т.д. Свойства и поведение блоков могут описываться как точными, так и случайными или нечеткими величинами. В случае необходимости разработчик переопределяет поведение блоков или задает новые их классы с помощью встроенных базовых средств.
Объектная ориентация системы ReThink позволяет создавать понятные и довольно наглядные модели бизнес-процессов, что упрощает освоение и использование системы непрограммирующими пользователями. Объекты, построенные в результате моделирования бизнес-процессов, становятся естественной основой для проектирования информационных систем поддержки этих процессов. В этом смысле средства системы ReThink могут рассматриваться как развитие CASE-средств.
ReThink поддерживает анимацию потоков работ (workflow) в ходе моделирования деятельности компании. Благодаря этому менеджер имеет возможность непосредственно наблюдать функционирование моделей, что повышает степень его доверия к результатам моделирования. Данная система обеспечивает создание иерархических моделей, позволяющих описывать процессы с различной степенью детализации. Это гарантирует простоту и естественность при создании сложных моделей больших компаний.
Рис.43. Пример внешнего представления моделей в ReThink
Все элементы моделей, включая ресурсы процессов, могут модифицироваться непосредственно во время исполнения. Результаты изменений можно увидеть сразу же после их введения.
Система ReThink позволяет формировать стоимостные и временные характеристики различных проектов для их объективного сравнения, а также проверять гипотезы типа «что, если». Для анализа работы моделей предусмотрен целый набор инструментариев: блоки-датчики для сбора данных, блоки-установщики значений атрибутов сущностей, графики для наглядного отображения результатов моделирования, всевозможные просмотровые табло из стандартных средств комплекса G2. С помощью датчиков можно снимать такие показатели, как длительность цикла обработки сущности на том или ином этапе, стоимость обработки, а также другие свойства, определенные разработчиком модели. Для отсева шумов и выявления тенденций можно использовать специальные блокифильтры.
Для проверки гипотез «что, если» в системе реализован механизм сценариев. Сценарии позволяют исследовать зависимость поведения одной и той же модели от поведения внешнего мира, (например, частота поступления заявок, их сложность и т.д.), а также от каких-либо параметров этой модели (например, количества транспортных средств или численности служащих). Варьируемые параметры и измеряемые показатели выносятся на отдельное окно сценария, после чего в результате прогона модели автоматически формируется отчет. Кроме этого, система позволяет использовать сценарии для объективного сравнения альтернативных проектов: один и тот же сценарий, описывающий некоторое заранее заданное поведение внешнего мира, может применяться для прогона различных моделей. Результаты вынесенные в отчет, являются основой для сопоставления и оценки этих моделей.
Основа данной системы - поддержка коллективной работы с приложениями на основе архитектуры «клиент-сервер» с помощью системы Telewindows комплекса G2, которая обеспечивает множественный доступ к централизованному приложению на сервере с других рабочих станций. Коллективная разработка и использование приложений имеет принципиальное значение при проведении глобального реинжиниринга крупной компании или их объединения в рамках отрасли.
Средства стандартных интерфейсов с внешними приложениями (GSI - G2 Standard Interface) комплекса G2 позволяют использовать в моделях данные реального времени. Это обеспечивает надежность при тестировании, а кроме того, превращает графические модели, создаваемые средствами системы ReThink, в идеальную основу для мониторинга бизнес-процессов, управления информационными потоками, непрерывного инкрементального реконструирования текущих процессов, а также поддержки принятия решений в оперативном управлении. Полученные приложения естественным образом стыкуются с технологическими приложениями диагностики и мониторинга производственных процессов, разработанными на базе комплекса G2.
В части сервисных функций (графика, поддержка проектирования и моделирования, интерфейсы с внешними информационно-программными ресурсами и т.п.) ReThink полностью реализует все способности базовой платформы G2. Следует также отметить, что ReThink способен полностью интегрироваться с другим компонентами поставки G2 – системами e-SCOR и webSCOR.com, которые позволяют распространить всю функциональность ReThink на задачи логистического контура управления и технологии SCM (Supply Chains Management – «управление цепочками поставок»). В совокупности перечисленные компоненты G2 покрывают задачи всех уровней информационной поддержки управления корпорациями: на оперативном уровне управления - синхронизацию бизнес-процессов в цепочках поставок (SCM-технологии), на тактическом уровне управления - планирование использования ресурсов в бизнес-процессах (технологии MRP/DRP, JIT, SIC), на стратегическом уровне управления - планирование изменений бизнес-процессов с учетом прогнозирования потребностей клиентов (CRM-технологии).
Еще одним значительным функциональным расширением конфигурации комплекса G2 следует считать систему NeurOn-Line. Данное средство ориентировано на поддержку использования аппарата нейронных сетей в широком спектре задач управления, моделирования, обучения, прогнозирования, адаптации и др. При этом NeurOn-Line полностью интегрирован (на функциональном, информационном и программном уровнях) со всеми прочими компонентами G2. Наиболее характерными и часто решаемыми с применением NeurOn-Line задачами являются:
- прогнозирование и управление на базе прогнозирующих моделей (особенно актуальными данные функции становятся при обслуживании процессов с трудно измеряемыми параметрами или неточными критериями оценки качества);
- параметрическая оптимизация процессов на основе нейросетевых моделей;
- валидация информационных каналов и устройств (например, оценка достоверности данных, поступающих от датчиков) на базе сравнения программно моделируемых и физически регистрируемых данных;
- имитация отсутствующих источников информации (например, имитация передачи данных от неисправных датчиков с подменой отсутствующих данных прогнозируемыми и т.п.) и др. имитационные методы парирования отказов оборудования и резервирования с использованием программных прогнозирующих и имитационных моделей;
- получение (извлечение) новых знаний о процессах на базе анализа чувствительности моделей и их ретроспективного исследования.
К существенным преимуществами G2 NeurOn-Line в плане быстрого и эффективного синтеза и развертывания исполняемых моделей в целевой среде можно считать:
- мощные средства импорта данных и визуализации, позволяющей в комфортном интерактивном режиме целенаправленно формировать обучающие выборки данных для построения эффективных нейросетевых моделей;
- автоматический выбор архитектуры нейросетевых моделей, обеспечивающей их высокую точность и эффективность алгоритмов прогнозирования;
- поддержка ансамблей моделей, которая позволяет на основе композиции нескольких наиболее «удачных» моделей строить робастные нейросети, способные работать в широком диапазоне условий протекания моделируемого процесса;
- применение оригинальных методов быстрого обучения нейросетей на базе массивов статистических данных;
- способность к оптимизации в реальном времени по заданным показателям качества с соблюдением мягких и жестких ограничений;
- гибкое развертывание и использование моделей, либо на базе средств, предоставляемых G2, либо на базе ActiveX.
Принципиальным отличием NeurOn-Line от многочисленных примеров инструментальных нейросетевых систем аналогичного назначения (и более универсальных) является композиция аппарата нейронных моделей с продукционными методами представления и обработки знаний и с общими функциональными возможностями машины вывода G2, ориентированной на работу в реальном времени. К результатам подобной композиции можно отнести ряд достаточно редких качеств приложений, построенных на основе G2 NeurOn-Line. Это:
- способность к выявлению и реагированию на появление «необычных» данных, способных сильно повлиять на точность нейросетевого анализа;
- возможность эффективной валидации источников данных с использованием сравнений реальных и прогнозируемых значений;
- возможность заблаговременного выявления дефектов и нарушений условий протекания процессов на основе нейросетевого прогноза;
- возможность формирования оперативных рекомендаций или управляющих воздействий для предотвращения прогнозируемых с применением нейросетевых подходов аварийных, нештатных и «нежелательных» ситуаций в развитии управляемого процесса.
В прочих отношениях (развитость среды разработки, интерактивные графические возможности, гибкость интерфейсов и т.д. и т.п.) NeurOn-Line полностью соответствует общему уровню сервиса, предоставляемого G2 (на рис.44 представлен пример экрана разработчика при решении задачи построения и обучения нейросети на базе статистической информации).
Т.о., G2 представляет собой практически самодостаточную среду для разработки, внедрения и сопровождения приложений (ЭСРВ) в широком диапазоне предметных и проблемных областей. G2 объединяет в себе как универсальные технологии построения современных информационных систем (стандарты открытых систем, архитектура «клиент – сервер», объектно-ориентированное программирование, использование операционных систем, обеспечивающих параллельное выполнение программ в реальном времени), так и специализированные методы (рассуждения, основанные на правилах, рассуждения, основанные на динамических моделях, имитационное моделирование, процедурные рассуждения, активная объектная графика, структурированный естественный язык для представления базы знаний), а также интегрирует технологии систем, основанных на знаниях, с современными технологиями традиционного программирования.
Все это позволяет с помощью данной оболочки создавать приложения практически любой сложности значительно быстрее, чем с использованием традиционных методов программирования, и снижать трудозатраты на сопровождение, модернизацию и эксплуатацию готовых решений, а также на их тиражирование (в т.ч., с портацией на другие аппаратно-программные платформы).
Рис.44. Пример пользовательского интерфейса в NeurOn-Line
В заключение следует отметить, что на счету G2 – десятки тысяч инсталляций и сотни широко известных успешных внедрений в промышленных проектах повышенной сложности. В перечне наиболее заметных «потребителей» программной продукции Gensym такие корпорации, как ABB, Siemens, IBM, HP, British Petroleum, Motorola, Nokia, Toyota, Nissan, Ericsson, Ford, Hitachi, DuPont, ExxonMobil, Dow Chemical, El Paso Energy, Eli Lilly, JEA, Alcan, Lafarge, Panama Canal, Tokyo Electric and Power и многие др., а также NASA, Пентагон и многие правительственные учреждения США.
Для показательного сравнительного анализа G2 с «ближайшими конкурентами» кратко охарактеризуем систему RTworks фирмы Talarian, которая занимает второе место в рейтинге инструментальных средств соответствующего класса, реализуя при этом, по мнению аналитиков, менее 50% функциональных возможностей G2 (причем без учета дополнительных компонентов поставок).
Классы задач, для которых предназначена система RTworks:
- мониторинг в реальном режиме времени;
- системы управления верхнего и нижнего уровней;
- системы обнаружения неисправностей;
- диагностика;
- составление расписаний;
- планирование;
- оптимизация;
- системы – советчики оператора;
- системы проектирования.
Представление знаний:
Базу знаний (БЗ) RTworks можно условно разделить на структуры данных, с которыми работает система, и выполнимые утверждения, которые обеспечивают манипулирование данными. В части структурирования данных, как и в G2 используется объектно-ориентированный подход, однако модель знаний охватывает только предметную область и не связана с целевой средой или пользовательскими интерфейсами. В RTworks разрешено множественное наследование для классов, но каждый конкретный экземпляр может быть представителем только одного класса. То есть экземпляр производного класса не может рассматриваться как экземпляр класса-родителя, что не позволяет записывать обобщенные утверждения, оперирующие сразу с множеством классов. Атрибутом класса не может быть экземпляр другого класса.
Выполняемые конструкции:
Система RTworks не обладает возможностью описания процедурных знаний; для создания процедур пользователю предлагается разрабатывать их на языке С и подключать в качестве внешних программных модулей. В части обработки наборов продукционных правил RTworks позволяет использовать только механизмы построения прямой и обратной цепочек рассуждения и сканирования правил. Сам язык представления знаний на порядок менее выразителен, чем в G2.
Среда разработки:
Система RTworks не обладает встроенными средствами редактирования базы знаний. Приложение должно быть сначала записано в виде ASCII-файла и затем подвергнуто грамматическому разбору средствами RTworks. Очевидно, что отсутствие интерактивных средств разработки увеличивает стоимость и продолжительность этапа создания приложения.
Интерфейс с конечным пользователем:
RTworks не обладает собственными средствами для отображения текущего состояния управляемого процесса. Разработчик приложения вынужден использовать систему Dataview фирмы VI Corporation, что в значительной степени ограничивает его возможности. Поддержка динамических интерфейсов также затруднительна. Кроме того, определение прямых информационных связей между моделями предметной области и элементами пользовательского интерфейса с использованием базовых системных возможностей невозможно.
Архитектура приложения:
RTworks базируется на возможностях операционной системы Unix для организации распределенной работы. Приложения на базе RTworks имеют модульную структуру, которая включает в себя следующие процессы:
- коммуникационный сервер (RTserver);
- подсистему получения данных (RTdaq);
- подсистему логического вывода (RTie);
- человеко-машинный интерфейс (RThci).
Наличие интерфейса с внешними процедурами, написанными на Си, и использование среды Unix обеспечивает относительную открытость RTworks, однако непосредственная работа процедурной составляющей RTworks-приложения с внешним программным окружением крайне затруднительна. Спектр прочих программных интерфейсов системы также небогат. Кроме того, распределенная архитектура RTworks дорого обходится разработчику. Во-первых, если заключение машины вывода отображается процессом RThci, это должно быть специфицировано специальной командой машины вывода. Недостаточно просто изменить значение в базе знаний – разработчик обязан еще указать имя переменной в RThci и послать измененное значение коммуникационному серверу, который передаст его процессу RThci. Во-вторых, разработка интерфейса RThci, базы разделяемых данных и базы знаний, отличающихся друг от друга, требует от разработчика знания трех различных программных интерфейсов. В-третьих, эти различные среды разработки часто требуют избыточных описаний. Например, каждая переменная RThci должна быть описана как в среде разработки RThci, так и в спецификации базы разделяемых данных. На разработчика возлагается ответственность за то, чтобы оба описания были идентичны и при внесении изменений перекомпиляции были подвергнуты оба модуля. Чтобы задача стала еще более трудной, перечень описаний в базе разделяемых данных хранится в алфавитном порядке, а в RThci - в порядке ввода. Недостатком RTworks является и односторонняя передача данных через процесс RTdaq. Невозможность послать через RTdaq запрос на получение данных делает задачу верификации показаний и диагностики неисправности датчиков практически неразрешимой.
Переносимость прикладных систем:
Система RTworks доступна на широком спектре Unix-платформ. Однако отсутствие поддержки Open VMS для рабочих станций фирмы DEC, Windows NT для систем на базе процессоров DEC Alpha и Intel и некоторых др. несколько ограничивает возможность переносимости RTworks-приложений.
Т.о., даже на уровне «беглого» сопоставления нескольких базовых функциональных возможностей и эксплуатационных характеристик можно сделать вывод о значительной «дистанции», разделяющей G2 и RTworks.
В ряде источников проводится более обширный сравнительный анализ оболочек ЭСРВ, к которому относится G2. Среди наиболее распространенных представителей данного класса инструментальных средств искусственного интеллекта принято относить такие системы, как RTworks (Talarian), COGSYS (COCSYS Ltd), ILOG Rules (ILOG), COMDALE/C (Comdale Technologies), Rocky (Expert Edge), RTES (Knowledge Systems), RT expert (Integrated Systems), RT/AI (IntellSys), TDC Expert (Honeywell), Mercury (Artificial Intelligence Tech.), Escort (PA Consultants), Activation Framework (Real Time Intelligent Systems), SNAP (Template Software) и некоторые др. Все перечисленные продукты не реализуют, по крайней мере, следующих возможностей, воплощенных в G2:
- поддержка единого пространства моделей предметной области, целевой среды, приложения и пользовательского интерфейса;
- интеграция с динамическими моделями предметной области и динамическая реконфигурация базы знаний;
- интеграция с нейросетевыми моделями;
- поддержка решения задач оптимизации, адаптации, прогнозирования, планирования, обучения;
- сочетание элементов процедурных, объектно-ориентированных и структурированных естественных языков для описания знаний и методов их обработки;
- оперирование с классами (типами) объектов, всестороннее множественное наследование, инкапсуляция типов и т.п.;
- автоматизация инспекции баз знаний;
- представление баз знаний в ASCII-коде с портацией на любые платформы;
- фильтрация, фокусировка и применение метаправил при обработке наборов продукций;
- визуализация, автоматизация кодирования, online-проверка синтаксиса и др. функции развитого интерфейса разработчика для языка представления знаний;
- поддержка развитого пользовательского интерфейса на уровне единой объектной модели и среды разработки приложений.
Вероятно, данный перечень может быть значительно расширен (особенно при парных сопоставлениях). Однако, результат интегрального сравнения G2 с функциональными аналогами в любом случае представляется однозначным. Тем не менее, нельзя не отметить и весомых «минусов» G2. Это:
- высокая стоимость;
- достаточно высокие требования к вычислительным ресурсам;
- сложность освоения разработчиками;
- «непрозрачность» механизмов работы ядра;
- недостаточно развитая сеть технической поддержки;
- сложность сопровождения проектов и поставок продукта в России.
Несмотря на перечисленные обстоятельства, количество внедрений решений на базе G2 в нашей стране продолжает расти. Развивается и «ниша», связанная с разработкой инструментальных средств поддержки синтеза ЭСРВ, основанных на использовании G2 в качестве базовой платформы. Кроме того, известен и ряд примеров тиражирования решений, использующих G2.
