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

Для систем мониторинга вообще ожидаемыми результатами разработки можно считать следующее:

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

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

1. Разработка аппаратного, программного обеспечений и баз данных.

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

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

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

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

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

Существует множество причин, по которым расширения функций информационных систем делались и будут делаться. Все их не перечислить. Следует отметить, что надо обязательно следить, чтобы в процессе постоянных модернизаций системы, она не стала бы неработоспособной или "тяжелой" в эксплуатации. Чтобы избежать подобной ситуации целесообразно периодически проводить профилактический реинжиниринг системы в целом (примеры функциональных расширений см. в Приложении № 9).

В ходе эксплуатации любой информационной системы изменяются законодательство, отраслевые требования к документам, требования к форме и содержанию документов организации, поэтому необходимо получать отчеты, не предусмотренные первоначальной версией системы. Отчеты могут быть различных форматов, формироваться на различных этапах разработки и эксплуатации системы мониторинга. Они могут быть статистическими и аналитическими, текстовыми, графическими или комбинированными, периодическими или по запросу пользователей и т.д.. Например, в Oracle-подобных системах наиболее распространенные форматы отчетов - это MS Excel, MS Word, и Crystal Reports. Первые два формата можно использовать для нестандартных отчетов: от оперативных отчетов о текущем состоянии контролируемых объектов (в т.ч. и статистических отчетов с возможностью получения графиков и итоговых диаграмм) до отчетов по различным видам экспертиз, производимых по сложным расчетно-аналитическим методикам. Третий формат удобен для формирования документов, требуемых различными законодательными актами, отраслевыми инструкциями и инструкциями организации (пример отчета см. в Приложении № 8).

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

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

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

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

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

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

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

2. Разработка учетных подсистем.

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

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

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

Пример учетной системы представлен в Приложении № 4.

3. Разработка подсистем автоматизации расчетов.

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

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

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

Пример расчетно-аналитической системы приведен в Приложении № 3.

4. Разработка информационных подсистем.

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

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

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

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

5. Разработка средств автоматизации для подсистем управления.

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

В этом то и кроется основная проблема автоматизации управления.

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

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

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

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

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

Пример повышения достоверности данных приведен в Приложении № 7.

6. Разработка экспертных систем.

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

Основными направлениями эволюционирования экспертных систем в ходе разработки являются:

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

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

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

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

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

Пример экспертной системы приведен в Приложении № 2.

7. Разработка систем мониторинга за состоянием окружающей среды.

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

Для демонстрации возможностей системы мониторинга можно использовать web-мониторинг за состояния окружающей среды, реализованный в рамках проекта "IDP-Аналитика WM" (см. Приложении № 1).

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