CC BY
10И. И. Маркеев, В. Б. Геннадиник
ЗАДАЧИ АВТОМАТИЗИРОВАННОГО СБОРА И КОНТРОЛЯ ПЕРВИЧНОЙ ИНФОРМАЦИИ В УПРАВЛЕНИИ ОХРАНОЙ ОКРУЖАЮЩЕЙ СРЕДЫ
Рассматриваются элементы технологии автоматизированного сбора и контроля первичной информации на примере компонента системы управления состоянием окружающей среды территориального органа государственного регулирования, предназначенного для организации процесса согласования разрешений на выбросы в атмосферный воздух.
Автоматизированный сбор, технология, первичная информация, экология территории, управление.
Введение
Эффективность информационных систем в управлении охраной окружающей среды (УООС) низка, что связано не в последнюю очередь с особенностями сбора и анализа экологической информации [6]. Особенностью данного класса систем можно считать большое количество источников первичной информации (практически все юридические лица, а зачастую и физические, в той или иной степени являются субъектами хозяйствования, чья деятельность нормируется и согласуется органами УООС).
В иерархических управленческих системах внесение данных происходит преимущественно на нижнем уровне иерархии, т. е. функции внесения данных пытаются максимально перенести на объект управления (в случае УООС — на природопользователей). Соответственно на верхнем уровне информационной системы происходит смещение функции от внесения данных (OLTP системы) к контролю достоверности и анализу данных (OLAP системы) [1, 5].
1. Система управления состоянием атмосферного воздуха
В качестве показателей состояния атмосферного воздуха, как правило, используются определяемые методами аналитической химии концентрации загрязняющих веществ. Нормирование состояния атмосферного воздуха заключается в определении предельно допустимых концентраций (ПДК), превышение которых считается опасным для окружающей среды (ОС) и здоровья [10].
Источники выбросов в атмосферу делятся на две группы: стационарные и передвижные (автомобили), отличающиеся как механизмом воздействия, так и способами управления (выбросы от передвижных источников не нормируются). Стационарные источники делятся по форме (точечные, линейные и площадные) и мощности (четыре категории опасности). От мощности источника зависит регламент его контроля.
Воздействие на ОС со стороны источников обычно определяется расчетным методом в соответствии с утвержденными методиками [3], учитывающими вид деятельности, оборудование и условия производства. Характеристики источников техногенного воздействия на ОС могут быть разделены на две группы: квазипостоянные, определяемые оборудованием и часто сырьем, и переменные, зависящие от режимов эксплуатации, времени года и т. п.
Процесс нормирования заключается в разработке природопользователем типовой производственной деятельности, по материалам которой формиру-
ются Оценки воздействия на ОС (ОВОС) в целом и проекты по отдельным природным средам (том предельно допустимых выбросов — том ПДВ), утверждаемые в ходе государственной экологической экспертизы. Итогом нормирования является определение ПДВ загрязняющих веществ от источников, при которых не будут превышены уровни ПДК.
По данным проектов ПДВ разрабатываются оперативные нормативные документы — разрешения, определяющие сроком на год огрубленные нормативные воздействия на ОС с учетом текущих переменных характеристик источников воздействия [4]. В случае превышения ПДВ природопользователь оплачивает его по прогрессивной шкале.
Оперативный контроль воздействий, состояния ОС и соответствующие управляющие воздействия на природопользователей осуществляются органами государственного УООС и заключаются в проверке соответствия технологий объявленным параметрам, выполнении природоохранных мероприятий и инструментальных замерах концентраций загрязняющих веществ в выхлопах и в контрольных точках, определенных в томах ПДВ (рис. 1).
Загрязнение ОС по норматив-Разрешения и плановые ным воздействиям
Рис. 1. Система УООС районного уровня
Таким образом, в существующей системе природопользования и охране ОС предусмотрены три этапа государственного управления:
— нормирование воздействий — оценка воздействия на ОС (разработка томов ПДВ);
— оперативное нормирование воздействий в соответствии с проектными документами и с учетом сложившейся ситуации (выдача разрешений на выброс);
— контроль воздействий и состояния ОС.
Соответственно типовой территориальный (уровня субъекта Федерации) экологический орган управления имеет процессно-ориентированную структуру и, наряду с остальными, включает в себя:
— «отдел экспертизы», осуществляющий экологическую экспертизу проектов и участвующий в нормировании воздействий;
— «отдел нормирования», собирающий первичную информацию, нормирующий воздействия (выдающий разрешения на выброс);
— «инспекторский отдел», проводящий натурные проверки воздействий и проверки состояния ОС.
2. Автоматизированная система регулирования воздействий
на атмосферный воздух
Автоматизированный сбор и контроль первичной информации описан на примере компонента информационной системы управления состоянием окружающей среды, предназначенного для организации процесса согласования разрешений на выбросы в атмосферный воздух.
Под компонентом системы понимается совокупность автоматизированного рабочего места (АРМ) «Выбросы в атмосферный воздух» и информационной системы (ИС) «Согласование разрешений на выброс в атмосферный воздух».
2.1. Требования к инструменту сбора первичной информации
Эффективность информационной технологии определяется успешностью ее внедрения. Внедрению способствует сокращение рутинных операций по внесению и обработке информации. Как уже отмечалась, для контролирующих органов наиболее трудоемким является этап внесения первичных данных, в нашем случае определенных в томе ПДВ природопользователя нормативов выбросов по источникам и загрязняющим веществам. В этой ситуации очевидное решение заключается в передаче функции внесения заявки на разрешение непосредственно природопользователям.
Упрощенная схема внесения данных делает необходимым создание мощной системы приема информации. В процессе приема заявки должны проходить следующие стадии проверки [8]:
— соответствие структурных признаков заявки — ее формы (наличие таблиц в заявке, строк и столбцов в таблицах);
— проверка и привязка к БД (базе данных) реквизитов-признаков заявки (определение природопользователя и временного интервала);
— актуальность справочных архивов: местных (участки) и федеральных (классификатор загрязняющих веществ);
— семантический контроль — проверка правильности написания, сверка со списком синонимов;
— проверка на нахождение значений в допустимых диапазонах;
— проверка на внутреннюю противоречивость данных (верность расчета вычисляемых полей, соблюдение балансов);
— сравнение с ранее принятыми связанными данными и нормативами;
— сравнение с аналогичными данными за предыдущий временной интервал.
На двух последних этапах проверки сравнивается передаваемая информация с данными, имеющимися в распоряжении контролирующего органа. Для имеющихся данных возможно определение допустимых диапазонов значений, выход согласуемых показателей за пределы определенных диапазонов сигнализирует о «подозрительных» ситуациях, требующих дополнительного рассмотрения.
Перенос функций внесения первичной информации на нижний уровень управления требует изменения структуры БД контролирующего органа. Все принимающие таблицы дополняются полем «Согласование данных», определяющим статус информации. В случае приема данных несколькими операторами необходимо добавить в таблицы время согласования и идентификатор оператора. Как правило, удобнее сразу записывать в БД все переданные све-
дения, анализировать их и согласовывать. Изменение задач сотрудников системы УООС влечет за собой изменение функций программного обеспечения — с OLTP на OLAP и, возможно, уплощение структуры БД.
В свою очередь, собственно к инструменту сбора первичной информации предъявляются требования:
— безопасность и обеспечение конфиденциальности передаваемых данных;
— наличие актуальных справочных архивов;
— узнаваемость электронных форм и документов.
Наличие встроенных в систему сбора первичной информации актуальных справочных архивов, совпадающих с архивами контролирующего органа, обеспечивает правильность заполнения заявок и их последующее успешное согласование.
Условием успешного внедрения на нижнем уровне новой схемы сбора данных является использование в качестве основы для разрабатываемых электронных документов существующей «бумажной» отчетности. Даже в случае нелогичности и/или избыточности существующих отчетов эффект их узнаваемости сотрудниками отчитывающихся с помощью новых технологий предприятий-природопользователей необходим хотя бы на первоначальном этапе [2, 5, 9].
2.2. АРМ «Выбросы в атмосферный воздух»
Используемое сотрудниками территориального экологического органа управления АРМ предназначено для учета, нормирования и контроля выбросов загрязняющих веществ в атмосферу субъектами природопользования. АРМ хранит и осуществляет анализ информации: о стационарных и передвижных источниках выбросов, нормативных и фактических выбросах, состоянии воздухоохранной деятельности на предприятиях, эффективности использования попутного газа, проектных и нормативных документах.
АРМ формирует по архивам и справочникам и распечатывает или передает в Microsoft Word или Excel следующие документы и отчеты:
— разрешения на выброс;
— список предприятий, отчитывающихся за выбросы в атмосферу;
— отчеты «2-ТП воздух»;
— сводные отчеты «2-ТП воздух» для произвольной выборки предприятий;
— отчет сотрудника о проделанной работе за произвольный период;
— отчет «Баланс по газу».
2.3. ИС «Согласование разрешений на выброс в атмосферный воздух»
Разработанная система является дополнением существующего АРМ «Выбросы в атмосферный воздух». С помощью ИС природопользователи могут самостоятельно подготовить заявку на разрешение и отправить его на проверку сотруднику соответствующего отдела контролирующего органа.
Пользователь Ис выполняет авторизацию (указывает логин и пароль), заполняет личную (контактную) информацию.
После этого он может просмотреть, но не корректировать перечень имеющихся в БД органа управления разрешений для своего предприятия (рис. 2).
На рис. 2 приведена экранная форма страницы просмотра и выбора разрешений. В верхней строке таблицы — согласованное разрешение с номером 45. Редактирование данного разрешения запрещено, но возможен просмотр данных. В следующей строке — разрешение, редактируемое в данный момент. Пользователь системы может продолжить редактирование данных разрешения (рис. 3), скопировать данные из предшествующего разрешения (№ 45) или очистить разрешение от записей.
Рис. 2. Управление разрешениями
На рис. 3 — экранная форма страницы редактирования разрешения. Пользователь изменяет значения максимального разового и валового ПДВ/ВСВ. В момент внесения производится проверка корректности введенных данных (порядок чисел, вхождение чисел в диапазон, соответствие ранее введенным данным).
Рис. 3. Редактирование данных разрешения
Заявка на новое разрешение может быть сформирована на основе одного из ранее созданных разрешений (рис. 3). В этом случае все нормируемые вещества, ПДВ и ВСВ будут перенесены из ранее существовавшего документа и могут быть изменены пользователем ИС. Добавление новых нормируемых веществ осуществляется из справочника контролирующего органа (рис. 4).
На рис. 4 — экранная форма справочника загрязняющих веществ, сформированного из имеющегося в БД департамента полного справочника загрязняющих веществ. Пользователю предлагается сокращенная форма справочника, содержащая наиболее часто употребляемые сведения о загрязняющих веществах.
После формирования заявки она может быть отправлена на согласование в департамент. После принятия решения (отклонение или согласование) пользователь получает уведомление.
Наименование предприятия: ЗАО "Проектстройконструкцня" Сводный участок Отметьте флажкам вещества вторые трубуется добавить! Название источника:
Наименование вещества Код Тип
азота двуокись 0301 rf*
азота окись 0304 гк
]акролеин 1301 ЛОС
■акрилонитрил 2001 лос
альдегид пропионоаый 1314 ЛОС
альпегил масляный 1310 лос
Пользователь: Пользователь/
Класс опасности
2
3
2
2
3
3
Рис. 4. Справочник загрязняющих веществ
Рассматриваемая ИС построена с учетом требований, описанных в предыдущей части статьи.
Программное решение построено на базе трехзвенной архитектуры и «тонкого клиента». Достоинствами предлагаемого решения перед «толстым клиентом» являются [7]:
— простота модификации (нет необходимости обновлять программу на компьютерах пользователей);
— доступность (браузеры есть во всех распространенных операционных системах на большинстве аппаратных платформ).
Недостатками тонкого клиента можно считать:
— сложность программирования (для большинства сред визуального программирования под архитектуру толстого клиента процесс сводится к использованию примитивов, которые настраиваются под контекст);
— избыточность в описании презентационной логики (разные браузеры по-разному интерпретируют один и тот же набор CSS свойств и HTML тэгов).
Ввиду того, что разные браузеры поддерживают различные варианты отображения данных, и для повышения доступности было принято решение ориентироваться на работу приложения в наиболее распространенных браузерах [12]:
— Internet Explorer 5.5 и более поздних (далее — «+»);
— Opera 8 +;
— Mozilla Firefox 2 +;
— Safari 3.1 +.
Указанные браузеры на момент написания статьи существуют для перечисленных в табл. наиболее распространенных операционных систем [13].
Работа пользователя с системой подразумевает частое сохранение малых порций данных (число, группа чисел, удаление строки из таблицы и пр.). Подобные операции могут быть существенно упрощены за счет использования принципов AJAX (Асинхронный Javascript и XML). Однако программное решение должно работать и без AJAX. По соображениям безопасности на некоторых компьютерах отключена поддержка javascript [11].
Современный подход к разработке программных систем часто подразумевает использование высокоуровневых технологий, таких как объектно-реляционная проекция (ORM, Object-relational mapping). ORM — технология программирова-
ния, которая связывает БД с концепцией объектно-ориентированного языка программирования, создавая «виртуальную объектную базу данных».
Соответствие наиболее распространенных браузеров и операционных систем
Win 2000 Win XP Win Vista Mac 10.4 Mac 10.5
Firefox 3.+ + + + + +
Firefox 2.+ + +
IE 7.0 + +
IE 6.0 + +
Opera 9.5+ + +
Safari 3.1 + + +
ORM позволит логической части программного решения взаимодействовать с частью данных (реляционной БД) по «правилам» языка программирования. Преимущество такого подхода можно проиллюстрировать на следующем примере: исходная таблица БД PRM (рис. 5) проецируется в объект Prm (Листинг 1).
PRM
PRMID
STAFFJD
FN
NOMER
DATE0
DATE1
DATE2
OK
PRMjOONDjI D
ANNUL
ANNUL_DATE
ANNU LjSTAFFjI D
ANNULjWHYJD
REQUESTjDATE
USERjID
REQUEST_NOTE
REQUESTjDEOLI NEjNCTE
REQUESTjOK
Рис. 5. Таблица БД PRM
Листинг 1 — Описание объектной проекции таблицы PRM:
class Prm(models.Model):
prm_id = models.IntegerField(u'ИН разрешения', primary_key=True)
staff_id = models.IntegerField(u'ИН сотрудника выдавшего разрешение')
fn = models.ForeignKey(Plant, db_column='fn', verbose_name=u'ИН предприятия')
nomer = models.CharField(max_length=10, verbose_name=u'номер разрешения')
date0 = models.DateField(verbose_name=u'действительно от')
date1 = models.DateField(verbose_name=u'срок действия до')
date2 = models.DateField(verbose_name=u'дата выдачи')
prm_cond_id = models.IntegerField(max_length=6, blank=True)
annul = models.CharField(u'аннулирован?', max_length=3, choices=YES_NO)
annul_date = models.DateField(u'дата аннулирования')
annul_staff_id = models.IntegerField(u'ИН аннулировавшего', max_length=6)
annul_why_id = models.IntegerField(u'ИН причина аннулирования')
ok = models.CharField(max_length=3, choices=YES_NO_CHOICE)
request_date = models.DateField(u'дата заявки', db_column=u'request_date')
request_ok = models.CharField(max_length=3, choices=YES_NO)
request_note = models.CharField(max_length=254,verbose_name=u'коментарий')
request_decline_note = models.CharField(u'коментарий', max_length=254)
В свою очередь, для объекта Prm вводится категоризация (наследование) на два класса потомка. Первый потомок, «writeablePrm», используется на презентационном уровне, на странице списка разрешений (рис. 2), а второй, «readablePrm»,— для просмотра уже выданных разрешений. Различие их — в разном уровне доступа к одним и тем же данным, исключающем ошибки ввода и злонамеренную подмену данных, и в разной логике обработки полученных от клиента данных.
Листинг 2 — Пример использования ORM классов:
class Prm():
class readablePrm (Prm): def _is_editable (self):
If not(self.is_solved()) and (self.request_date is None): return True return False class writeablePrm(Prm): def save(self):
return False # Сохранение невозможно.
Заключение
Описанные в статье принципы организации автоматизированного сбора и контроля первичной информации, а именно: передача функции внесения заявки на разрешение непосредственно природопользователям, сокращение рутинных операций по внесению и обработке информации (использование справочников, повторное использование внесенных данных), подробные проверки вносимых данных (порядок чисел, вхождение чисел в диапазон, соответствие ранее введенным данным) и пр. — могут быть учтены и использованы при построении систем для обработки большого количества исходных данных.
Описанные технологии позволят разработчикам аналогичных систем сконцентрироваться на прикладных задачах предметной области, отделить разные слои приложения (хранения, обработки и визуализации данных).
Использование ORM-технологий даст возможность на этапе описания модели хранимых данных определить часть логики обработки корректности вводимых пользователями данных (порядок чисел, вхождение чисел в диапазон, соответствие ранее введенным данным).
Приведенные в статье требования к доступности программного решения на базе тонкого клиента опираются на статистические данные [11-13].
1. Маглинец Ю. А. Анализ требований к автоматизированным информационным системам. — М.: Изд-во «Интернет-университет информационных технологий — ИН-ТУИТ.ру», БИНОМ. Лаборатория знаний», 2008. — 200 с.
2. Граничин О. Н., Кияев В. И. Информационные технологии в управлении. — М.: «Интернет-университет информационных технологий — ИНТУИТ.ру», БИНОМ. Лаборатория знаний, 2008. — 336 с.
3. ОНД 86. Госкомгидромет. Методика расчета концентраций в атмосфере воздуха вредных веществ, содержащихся в выбросах предприятий. — 1987.
4. Постановление Правительства РФ от 2 марта 2000 г. № 183 «О нормативах выбросов вредных (загрязняющих) веществ в атмосферный воздух и вредных физических воздействий на него».
5. Бабушкин А. Г., Ядрышников И. Н. Построение систем электронного сбора информации для органов Госкомэкологии // Вестн. кибернетики. — 2003. — Вып. 2. — С. 19-24.
6. Соловьев И. Г. Проблемы информатизации государственного управления природными ресурсами и охраной окружающей среды // Там же. С. 4-9.
7. Гоекул В. И., Денищенко Г. Н., Коровкина Н. Л. Проектирование информационных систем. — М.: «Интернет-университет информационных технологий — ИНТУ-ИТ.ру», БИНОМ. Лаборатория знаний, 2008. — 304 с.
8. Геннадиник В. Б. Сбор первичной информации в экологии // Налоги. Инвестиции. Капитал. — Тюмень, 2003. — № 5-6. — С. 163-168.
9. Гоекул В. И., Денищенко Г. Н., Коровкина Н. Л. Управление внедрением информационных систем — М.: «Интернет-университет информационных технологий — ИНТУ-ИТ.ру», БИНОМ. Лаборатория знаний, 2008. — 224 с.
10. Федеральный закон об охране атмосферного воздуха (в ред. от 31.12.2005 № 199-ФЗ).
11. Нильсен Л. Web-дизайн: удобство использования Web-сайтов. — М.: Вильямс, 2007.
12. http://www.w3schools.com/browsers/browsers_stats.asp.
13. http://www.w3schools.com/browsers/browsers_os.asp.
I. I. Markeyev, V. B. Gennadinik
GOALS OF AUTOMATED COLLECTION AND CONTROL OF INITIAL DATA UNDER ENVIRONMENTAL MANAGEMENT
The article considers elements regarding methods of automated collection and control of initial data illustrated with a component of environmental management system by a territorial board of state regulation intended to arrange coordination on permissions for atmospheric emissions.
Automated collection, technology, initial data, territorial ecology, management.
