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

Автоматизация подготовки всевозможных паспортов, регламентирующих работу шахтовых специалистов в процессе деятельности угледобывающих предприятий, является одной из самых используемых областей применения средств вычислительной техники. Аналогичные подсистемы разрабатывались и реализовыва-лись на различных типах ЭВМ уже неоднократно. Успех их практического использования, как правило, определяется качеством методического обеспечения, положенного в основу реализации той или иной системы, а также соответствием реализации опыту работы шахтовых специалистов. Однако отрицательные черты подавляющего большинства существующих реализаций связаны прежде всего с тем, что функционируют такие системы, как совокупности несвязанных между собой модулей. Данный подход легче реализовать, но часто он приводит к тому, что пользователь системы вынужден в каждом из модулей в значительной мере дублировать необходимую для выполнения определенных расчетов информацию. А это, в свою очередь, является источником неточностей и/или ошибок, что в конечном счете, ставит под сомнение эффективность использования как отдель-ных модулей, так и всей системы в целом.

Программно-аппаратный базис разработки

В общем контексте всех работ по созданию интеллектуальной системы компьютеризации угольных шахт предполагается, что основой программно-аппаратного базиса будет неоднородная сеть рабочих станций к ПЭВМ, поддерживающих концепции "комнаты принятия решений" и ''локальной сети подготовки решений". Однако в силу задержек с развертыванием аппаратуры, было решено первые функциональные подсистемы разрабатывать на ПЭВМ, но при этом обеспечить такое проектирование, которое бы гарантировало мобильность создаваемого программного обеспечения при смене программно-аппаратной платформы. При такой постановке задачи единственным реальным кандидатом на аппаратную поддержку является семейство персональных компьютеров PC 386/387. Такой выбор определяется следующими соображениями: машины типа PC 386/387 предполагается использовать в общей системе в качестве тяжелых терминалов и/или в качестве процессорных элементов в тех узлах локальной сети, которые не предъявляют серьезных .требований к графике; ПЭВМ этого типа уже имеются на шахтах и в коллективах разработчиков; разработка прототипов вполне допускает реализацию на машинах средней мощности.

Исходя из требований мобильности прото типа при смене аппаратной платформы необхо димо, чтобы программное окружение системы отвечало основным требованиям архитектуры открытых систем. Поэтому, хотя операционная система, под которой создавался прототип под системы ПВУ - MS DOS, сама операционная обстановка экранирована от MS DOS графичес кой оболочкой Microsoft Windows [1]. Такой подход позволяет разработчикам эксперимен тального прототипа отработать все основные концепции создания следующей версии системы на рабочих станциях уже в процессе работы на персональных компьютерах. Таким образом, нижний уровень базового программного окру жения при создании экспериментального прото типа интеллектуальной системы компьютериза ции угольных шахт составляют: операционная система MS DOS (версия 5) и графическая обо лочка MicroSoft Windows (версия 3.1). Следую щий слой инструментария составляет базисная система программирования. Опять же учитывая требования мобильности и перспективу пере хода на рабочие станции, в качестве базисной системы программирования нужна ориентация на язык Си. В настоящее время из доступных на ПЭВМ систем программирования на базе языка Си реальными кандидатами являются PWB фирмы MicroSoft и Turbo C++ фирмы Borland, причем входной язык программирования Си в этих системах практически один и тот же. Вместе с тем инструментальная среда фирмы Borland, на наш взгляд, более развита. В пользу выбора последней говорит и то, что здесь в рамках одной и той же среды поддерживаются, по-существу, два языка - ANSI С и язык объ ектно-ориентированного          программирования C++, который предполагается использовать в дальнейшем.

Следующим аспектом, который безусловно должен учитываться, является ориентация системы на общую базу данных и знаний с эксплицитным представлением их структур на уровне входного языка описания данных. Такой подход не зависит от той конкретной СУБД, которая используется при реализации системы, но получает точные спецификации только на уровне выбора последней. Представляется, что промышленная версия системы будет опираться на объектно-ориентированную СУБД. Однако в настоящее время такие системы разработчикам прототипа недоступны. Вместе с тем в распоряжении разработчиков имеется система Frame/2, которая реально поддерживает (правда, только на ПЭВМ и в несетевом режиме) работу с фреймовой базой данных и знаний [2]. Вот почему в качестве инструментария организации и сопровождения базы данных и знаний был выбран этот пакет. При развитии системы это проектное решение, по-видимому, будет пересмотрено, но эксплицитное описание базы на входном языке этой СУБД послужит хорошей отправной точкой для новой версии. Над пакетом Frame/2 авторам экспериментального прототипа пришлось разработать специализированный инструментарий работы с таблицами, аналогичный Microsoft Exel.

И, наконец, несколько замечаний о графическом инструментарии. Как и при выборе остальных компонент, основным критерием для разработчиков здесь была мобильность разработанного программного обеспечения при смене программно-аппаратной платформы.. Такой подход потребовал четкой стратификации графических средств и инкапсуляции каждого уровня. Учитывая вышесказанное, в качестве базовых графических примитивов разработчики использовали графическую библиотеку 2D среды Windows, что позволяет при переходе на рабочие станции практически сохранить прикладную часть без изменений. Кроме того, потребовалось создание специализированного графического инструментария (когнитивного графического редактора FrameBrush). В качестве альтернативы рассматривалось использование мощных систем типа AutoCAD [3]. Однако авторам пришлось отказаться от подобных проектных решений, во-первых, в силу того, что системы автоматизации проектирования в значительной мере закрыты для имплантации их в другие программные среды, и, во-вторых, потому что все они предъявляют весьма серьезные требования к памяти и быстродействию компьютера, на котором используются. Немаловажным является и то, что квалификация пользователей систем типа AutoCAD существенно превышает квалификацию шахтовых специалистов. Так что практическое использование таких систем в рамках интеллектуальной системы компьютеризации угольных шахт представляется проблематичным.

Резюмируя рассмотренные проектные решения по аппаратно-программному базису разработки экспериментального прототипа, можно констатировать следующее:

1)   прототип реализуется на ПЭВМ типа PC

386/387 в рассмотренной выше конфигурации;

2)  базисные программные средства реализации

представлены MS DOS, MicroSoft Windows и Turbo C++ фирмы Borland;

3)   организация и поддержка базы данных и зна-

ний прототипа опирается на пакет Frame/2;

4)  в качестве базисных графических примити-

вов используются средства 2D библиотеки среды Windows;

5)   для поддержки функционирования приклад-

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

Архитектура и функциональные возможности подсистемы ПВУ

Основные принципы разработки и реализации прототипной версии подсистемы ПАСПОРТ ВЫЕМОЧНОГО УЧАСТКА (ПВУ) следующие: она должна проектироваться как интегрированная среда, основными компонентами которой являются общая база данных и знания о том, каким образом формируется паспорт выемочного участка шахтовыми специалистами; равноправным компонентом системы должна быть активная графика, естественным образом состыкованная с базой данных и знаний; архитектура системы должна допускать функционирование в современной многозадачной среде и естественным образом интегрироваться в парадигму клиент-сервер; в общей базе должны явно специфицироваться как собственно структура шахты и нормативно-справочная информация, так и конкретные описания технологических схем и приемов формирования того или иного паспорта; прикладные процессы должны работать асинхронно и интегрироваться через общую базу.

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

1.   Текстовые листы

•      Титульный

•      Лист ознакомления

•      Лист утверждения

2.   Набор таблиц, в которые сведены наибо лее информативные горно-геологические и тех нико-экономические показатели выемочного участка

•      Проектные показатели горно-геологичес- кого прогноза

•      Проектные технико-экономические пока затели выемочного участка

•      Проектные показатели проведения и крепления штрека, монтажной камеры, сбоек

•      Проектные показатели ремонта подзем ной выработки

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

•      Горно-геологический прогноз

•      Проведение и крепление конвейерного штрека

•      Ремонт конвейерного штрека

•      Выемка угля, крепление и управление кровлей в очистном забое

•      Схема вентиляции и дегазации

•      Противопожарная защита

•      Технологические схемы предварительно го увлажнения угольного массива и оро шения, параметры и оборудование

•      Транспорт угля, породы, материалов и оборудования и перевозка людей

•    Схема электроснабжения Формирование каждой из перечисленных

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

Разработка и реализация подсистемы ПВУ

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

-    Горно-геологический прогноз;

-    Технологическая схема, включая

•      Выбор технологической схемы и

•      Охрану.недр;

-  Подготовка участка, в том числе

•      Проведение подготовки участка,

•      Крепь и

•      Ремонт;

-  Добыча участка, которая распадается на

подзадачи

•      Выемка и

•      Монтаж-демонтаж;

-    Вентиляция;

-    Транспорт

•      Угля,

•      Породы,

•      Оборудования и

•      Людей;

-    Охрана труда;

-    Безопасность и

-    Энергоснабжение

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

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

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

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

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

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

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

лизмом представления знаний, используемым в системе.

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

Рассмотренная организация подсистемы ПВУ является достаточно общей и обеспечивает развитие и интеграцию с другими компонентами. Н-диаграмма пользовательского уровня архитектуры подсистемы описывается следующим образом:

В момент загрузки подсистемы пользователь получает окно, общая структура которого ! представлена на рисунке 1. Оглавление разде- лов паспорта, визуализированное в отдельном окне, по существу, задает номенклатуру при- кладных модулей и групп модулей подсистемы.

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

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

Примером фрейма-экземпляра для шахт АНП (Ассоциации Независимых Предприятий) "Белово" может быть следующая структура:

Описание характеристик пласта существенно более объемно и здесь не приводится. Мы рассмотрели лишь некоторые из прототипов и экземляров фреймового описания базы данных и знаний, используемой в подсистеме ПВУ. Общий ее объем без учета формируемой шахтовыми специалистами информации более 300 Кб. Дополнительно к рассмотренной в подсистеме ПВУ используется нормативная база данных и знаний. В настоящее время ее объем соизмерим с базой описания шахт, но при развитии системы можно ожидать, что нормативная база будет по объему на порядок больше.

Функциональные модули ПВУ предназначены для расчета наиболее важных технико-экономических и горно-геологических характеристик по выемочному участку в соответствии с методиками, разработанными специалистами горного дела. С точки зрения пользователя подсистемы процесс работы с такими модулями

осуществляется при вызове следующих разделов ПВУ: "Проектные показатели горно-геоло-гического прогноза", "Проектные технико-экономические показатели выемочного участка", "Проектные показатели проведения и крепления штрека, монтажной камеры, сбоек", "Проектные показатели ремонта подземной выработки".

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

Второе подмножество составляют поля функциональных таблиц, которые требуют выбора значений из заданного набора или набора, формируемого в' соответствии с определенными для данного поля критериями. Примерами такого рода полей могут служить "Тип мех-комплекса", "Марка угля" и т.д. Их реализация в значительной мере та же, что и для элементов первого подмножества, и потому здесь не рассматривается.

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

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

С точки зрения БД/БЗ подсистемы рассмотренного выше разбиения полей на подмножества не существует. Все они представляются и обрабатываются единообразно. Каждое поле представляется в виде множественного слота определенного фрейма, описывающего экранное представление соответствующей таблицы. Множество значений такого слота состоит, по крайней мере, из двух элементов: имени фрейма и имени слота. Тем самым задается адрес в базе системы, где хранится значение для поля. Кроме перечисленных необходимых компонент, указанное множество может включать еще по крайней мере, два элемента. Первый определяет тип поля. Типами полей, которые поддерживаются в системе в настоящей версии являются: редактируемое (CT_EDIT), просматриваемое (CT_VIEW) и вычисляемое (CT_CALC). По умолчанию все поля функциональных таблиц являются просматриваемыми. Второй элемент указывает имя функции, "привязанной" к полю. Таким образом, необходимая схема работы подсистемы реализуется в значительной мере декларативно и может быть модифицирована при коррекции базы знаний системы.

Выше мы обсудили лишь некоторые из функций подсистемы ПВУ, реализованные в рамках экспериментального прототипа. Общий обьем разработанных программ составляет около 918 Кб исходного текста. Главный модуль подсистемы, резидентно {с точностью до свопинга самой среды Windows) требует 122 Кб основной памяти. Дополнительно к этому модулю динамически подкачиваются разработанные в рамках данной реализации библиотеки типа DLL общим объемом около 912 Кб.

Рассмотренная выше подсистема ПВУ принята к опытной эксплуатации на шахтах АНП "Беловоуголь". Однако сами разработчики счи-

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

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

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

Список литературы

1.    Petzold С. Programming in Windows 3.0. N-Y: Addison- Wcsley, 1990,- 942 p.

2.    Подсистема FRAME/2. Меморандум разработчиков по проекту ИСПЗ-191, Коломна: НТТМ "Интеграл", 1990, - 67 с.

3.    AutoCAD USER GUIDE, ver. 12, AutoDESK, 1992.