Разработка системы мониторинга сети для внутренних нужд предприятия ОАО 'Хабаровскэнерго'

Разработка системы мониторинга сети для внутренних нужд предприятия ОАО 'Хабаровскэнерго'

Введение

мониторинг телекоммуникация сеть кабельный

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

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

Существуют специальные стандарты моделей управления сетями, что позволяет облегчить управление большими разнородными сетями. Для управления сетями передачи данных по протоколу IP существует протокол управления сетью SNMP (Simple Network Manager Protocol), который обеспечивает поддержку правил взаимодействия управляющей станции и объектов управления. А данные управления хранятся внутри объекта. Таким образом протокол SNMP позволяет управлять самыми разными объектами сети централизованно.

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

1. Обзор существующих технологий мониторинга в телекоммуникациях

.1 Протокол управления сетью SNMP

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

В целях создания единого подхода к управлению оборудованием, подключенным к сетям IP, был разработан простой протокол сетевого управления (Simple Network Management Protocol - SNMP).

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

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

В SNMP-совместимых объектах управления реализован специальный программный модуль, который называется агент. Агенты собирают информацию об управляемых устройствах, в которых они работают, и делают эту информацию доступной для систем управления сетями (network management systems - NMS) с помощью протокола SNMP. Основной концепцией протокола является то, что вся необходимая для управления устройством информация хранится на самом устройстве - будь то сервер, модем или маршрутизатор - в так называемой административной базе данных (MIB - Management Information Base). SNMP как непосредственно сетевой протокол предоставляет только набор команд для работы с переменными MIB. Для того чтобы проконтролировать работу некоторого устройства сети, необходимо просто получить доступ к его MIB, которая постоянно обновляется самим устройством, и проанализировать значения переменных. Функции анализа и обработки данных, принятия решений о состоянии объекта возложены на управляющую систему. Описанная выше модель управления SNMP представлена на рисунке 1.1.

Технология SNMP состоит из трех частей:

-    структура управляющей информации (Structure of Management Information, SMI);

-    базы управляющей информации (Management Information Base, MIB);

-       сам протокол SNMP, определяющий правила взаимодействия менеджера и агента.

Структура управляющей информации определяет правила описания управляющей информации. Формальное описание объектов осуществляется с помощью языка Abstract Syntax Notation One (ASN.1). Для задания имени объекта достаточно указать его идентификатор (OBJECT IDENTIFIER), представляющий собой последовательность целых чисел. Все идентификаторы организуются в виде листьев дерева. На верхнем уровне дерева присутствуют три узла: iso, ccitt и joint-iso-ccitt, которые принадлежат разным стандартным организациям. В поддереве iso присутствует идентификатор org (узел, являющийся корнем для поддеревьев различных организаций), один из подузлов которого - Министерство обороны США (Department of Defence - DOD). Считается, хотя официально это и не зафиксировано, что первым узлом в поддереве DOD является Internet. Таким образом, объект "internet" имеет идентификатор "1.3.6.1": internet OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) 1}.

Для правильной интерпретации объекта одного идентификатора недостаточно. Необходимо указать тип объекта и дать его смысловое определение. Для этого служит информационная база управления (Management Information Base - MIB). В ней описаны все объекты в соответствии с грамматикой ASN.1. Наличие текстового представления базы MIB на стороне системы управления позволяет не только правильно интерпретировать получаемые данные, но и давать пользователю пояснения об объектах на основе описания, присутствующего в базе. Для объекта управления нет необходимости в наличии текстового варианта базы MIB.

Для наглядности структуру MIB принято представлять в виде дерева. Рассмотрим пример. На рисунке 1.2 приведен фрагмент дерева MIB, по которому можно найти расположение переменной sysDescr. У ветви internet (1) всего шесть поддеревьев. Это:

-    Directory (1) - каталог OSI;

-    mgmt (2) - стандартные объекты RFC;

-       Experimental (3) - эксперименты с internet;

-       Private (4) - зависит от производителя;

-       Security (5) - безопасность;

-       snmp V2 (6) - описание работы SNMP.

Нужная нам переменная sysDescr находится в ветви mgmt (2), так как она относится к применению SNMP для управления устройствами. Далее располагается ветвь mib-2, с которой, в сущности, и начинается база MIB.

Далее, под термином "значение переменной" будем понимать значение объекта, имеющего заданное имя (идентификатор). Использование только объектов, требуемых по спецификации протокола SNMP, не позволяет задействовать некоторые возможности управляемой аппаратуры. Например, маршрутизаторы фирмы Cisco поддерживают многочисленные сетевые протоколы, отличные от IP. С помощью стандартных объектов, описанных в базах MIB, невозможно получить информацию, касающуюся этих протоколов. Для разрешения подобного конфликта в дереве объектов существует специальный узел private (internet 4), одним из подузлов которого является узел "предприятия" (enterprises, private 1). Все объекты, которые фирма-производитель желает сделать доступными по протоколу SNMP, описываются в поддеревьях соответствующей фирмы.

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

-    Get_request - получить значение указанной переменной или информацию о состоянии сетевого элемента;

-       Get_next_request - получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);

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

-       Get_response - отклик на Get_request, Get_next_request и Set_request. Содержит также информацию о состоянии (коды ошибок и другие данные);

-       Trap - отклик сетевого объекта на событие или на изменение состояния.

Рисунок 1.1 - Модель управления SNMP

Рисунок 1.2 - Поиск sysDescr (1) в MIB

Схема взаимодействия менеджера и агента по протоколу SNMP приведена на рисунке 1.3.

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

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

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

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

Рисунок 1.3

SNMPv3. В версии 3 протокол SNMP значительно усложнился. Но сохранил поддержку предыдущих версий. На языке версии 3 устройства и компоненты управления называются "сущностями" (entities). Одна сущность (прежде известная как агент) находится на маршрутизаторе, а другая (в прошлом менеджер) - занимается опросом приложений. Каждая сущность имеет SNMP-ядро и приложение. Ядро SNMP составляют четыре функции: контроль доступа, безопасность, обработка сообщений и диспетчер. В модули процессора сообщений и диспетчера включены также функции версий SNMPv1 и 2, в том числе для обработки команд set и get, и для форматирования блоков данных SNMP или PDU (protocol data unit). Диспетчер исполняет роль привратника, т. е. все входящие/выходящие сообщения проходят через него. Обрабатывая SNMP-сообщение, диспетчер определяет, к какой версии протокола оно принадлежит, и отсылает его соответствующему модулю-процессору для анализа. Если диспетчер не может определить версию, например из-за некорректного формата пакета, он регистрирует ошибку. Процессор сообщений пересылает сообщение подсистеме безопасности или подсистеме контроля доступа, а затем отсылает обратно диспетчеру, который и передает его SNMP-приложениям.

Основным достижением версии 3 стал усовершенствованный механизм безопасности. Для обеспечения аутентификации и конфиденциальности используется модель безопасности, ориентированная на пользователя (User-Based Security Model - USM). Модель USM состоит из модулей аутентификации, временного контроля и конфиденциальности. Модули аутентификации и конфиденциальности обеспечивают целостность данных, их достоверность и защиту. Модуль временного контроля призван следить за синхронизацией времени между SNMP-сущностями с целью пресечения взломов типа replay attack - он блокирует пакеты с устаревшими метками времени.

В USM-модели применен алгоритмы MD5 и SHA, и другие алгоритмы хэширования. В качестве меры предосторожности пароль по сети не пересылается. Вместо этого PDU-блок дважды подвергается хэшированию с использованием двух ключей, сгенерированных из закрытого ключа, затем первые 12 октетов выступают в роли кода аутентификации сообщения (Message Authentication Code - MAC), который добавляется к этому сообщению. Такой же процесс, но в обратном порядке происходит на другом конце.

В SNMPv3 определено три уровня аутентификации и конфиденциальности. Первый - это просто отсутствие конфиденциальности, обозначается "noAuthNoPriv". Он аналогичен строковым паролям доступа, передаваемым открытым текстом, которые применяются в версии 1 и 2, и используется в период отладки или когда SNMP-сущности находятся в защищенной среде. Второй уровень - это аутентификация без конфиденциальности, или "authNoPriv". Третий уровень - "authPriv" - это не только аутентификация, но и шифрование SNMP-данных. Для шифрования данных применяется алгоритм DES.

В SNMPv3 также входит модель разделения доступа на базе представлений (VACM - View-based Access-Control Model), позволяющая ограничить доступ к переменным MIB (базы управляющей информации). В модели VACM "представление" (view) определяет, какая часть базы MIB доступна, и устанавливает связь между пользователями и этим представлением. Механизмы VACM требуют, чтобы представление и группа создавались на каждом сетевом устройстве, причем представление определяет доступную часть MIB, а группа - привязывает входящих в нее пользователей к этому представлению.

.2 Технология RMON

имеет два главных компонента: транспортный механизм для перемещения данных управления по сети и схему или шаблон данных, известный как база управляющей информации, или MIB. Удаленный мониторинг (RMON - Remote Monitoring) - это расширенная база управляющей информации для поддержки приложений, которым необходимо больше данных, чем SNMP MIB-2 способна предоставить.

Базы RMON состоят из набора статистических, аналитических и диагностических данных, обеспечивая независимость от производителя аппаратуры. Отличие RMON от SNMP состоит в характере собираемой информации, если в MIB-2 эта информация характеризует только события происходящие на узле где установлен агент, то данные RMON характеризуют трафик любых (и неинтеллектуальных) сетевых устройств. Ключевым моментом в эффективности мониторинга RMON является возможность сохранять статистические выборки данных в разные моменты времени в самом зонде, а также в том, что агенты (зонды) RMON производят частичную обработку данных (фильтрацию и сортировку).тандарт RMON работает на физическом и уровне связи сетевой модели OSI и включает 10 групп баз:

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

-       History - базируясь на группе Statistics, эта группа предназначена для анализа поведения сети во времени, выработки базовой линии, сравнения происходящих в сети изменений в разное время. Зонд может сохранять определяемое пользователем количество статистических выборок (зависит от величины оперативной памяти зонда) через определенный пользователем интервал времени (от 1 сек до 3600 сек) для сбора как кратковременной так и долговременной статистики;

-       Alarms - дает возможность пользователям устанавливать или абсолютные, или относительные пороговые значения переменных в базах MIB, при пересечении которых зонд будет генерировать предупреждения (Traps) управляющей станции в соответствии с установками в группе Events;

-       Hosts - в табличном формате предоставляется статистика по трафику для каждого сетевого узла, базируясь на его MAC-адресе;

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

-       Matrix - производит отслеживание величины трафика или количества ошибок между двумя устройствами в соответствии с их MAC-адресами;

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

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

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

-       Token Ring обеспечивает получение набора статистических данных для сетей Token Ring.

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

.3 Решения компании Cisco в области управления сетями

На основе протокола SNMP и технологии RMON существует большое количество программных и аппаратных решений для управления сетями и их мониторинга. Большие коммерческие комплексы позволяют решать широкий спектр вопросов. Компании-производителя сетевого оборудования предлагают свои программные продукты. Для примера можно назвать системы HP OpenView фирмы Hewlett-Packard, NetView for AIX фирмы IBM, SunNet Manager производства одного из подразделений Sun компании SunConnect, Spectrum компании Cabletron System и NetWare Management System компании Novell (применяется главным образом для организации работ в локальных сетях, построенных на базе семейства операционных систем NetWare).

Так же существует большое количество бесплатных программ, которые обычно решают какие-то более узкие задачи (например, утилиты для просмотра MIB устройства, или программы для сбора значений переменных MIB и записи их в базу данных и др.). Хотя есть и бесплатные аналоги коммерческих платформ управления. Например, программа BlueBird (OpenNMS).

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

Cisco предлагает серию программных продуктов под общим названием CiscoWorks, которая делиться на два типа:

. Решения CiscoWorks2000 представляют собой набор полномасштабных решений для средних и больших сетей (enterprise). Эти решения фокусируются на трех основных областях: управление глобальными сетями (WAN), управление локальными сетями (LAN) и управление на уровне предоставления услуг.

Для предоставления законченных решений (end-to-end) в этих областях Cisco предлагает следующие наборы программных продуктов:

-    CiscoWorks2000 LAN Management Solution (LMS) - решение для управления локальными коммутируемыми сетями;

-    CiscoWorks2000 Routed WAN Management Solution (RWAN) - решение для управления маршрутизируемыми территориальными сетями;

-    CiscoWorks2000 Small Network Management Solution (SNMS) - решение для управления локальными сетями небольшого размера;

-    CiscoWorks2000 VPN/Security Management Solution (VMS) - решение для управления системой сетевой безопасности;

-    CiscoWorks IP Telephony Environment Monitor (ITEM) - решение для управления мультисервисными сетями, поддерживающее Cisco IP Telephony и приложения IP телефонии.

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

-    CiscoWorks for Windows (CWW) - облегченная версия сетевого управления, в которой предусмотрены все возможности, необходимые для управления сетью малого предприятия, предприятия средних размеров или рабочей группы;

-    CiscoWorks QoS Policy Manager - программный комплекс, облегчающий внедрение дифференцированных услуг и поддержки качества услуг (Quality of Service, QoS) на основе централизованной политики;

-    CiscoWorks Wireless LAN Solution Engine - программно-аппаратный комплекс, решающий задачи повседневного мониторинга и управления инфраструктурой беспроводных локальных сетей Cisco Aironet;

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

ПО CiscoWorks основано на стандартном протоколе сетевого управления Simple Network Management Protocol (SNMP), что позволяет надежно управлять оборудованием Cisco в самых разнообразных разнородных сетях. В случае установки в качестве дополнения к уже имеющейся платформе сетевого управления CiscoWorks других отдельных компонентов позволяет расширить ее возможности.

Рассмотрим более подробно состав решения для локальных сетей - CiscoWorks2000 LAN Management Solution, так как в данном дипломном проекте рассматривается локальная сеть:

- Campus Manager (CM) - для обнаружения и управления L2/L3 (Layer2/Layer3 - второго и третьего уровня модели OSI - Open System Interconnection) коммутаторами, конфигурирования и управления VLAN (Virtual Local Area Network - виртуальные локальные сети) и ATM LANE (Asynchronous Transfer Mode LAN Emulation - эмуляция ЛВС поверх ATM), а также определения подключения пользователей и IP телефонов;

-       Device Fault Manager (DFM) - обеспечивает в режиме реального времени обнаружение и определение причин сбоев сетевого оборудования;

-       Cisco nGenius Real-Time Monitor - инструмент для сбора и отображения RMON статистики, генерируемой коммутаторами Catalyst, модулями сетевого анализа Network Analysis Module и внешними пробниками RMON;

-       Resource Manager Essentials - для управления критичными сетевыми ресурсами через Интернет с использованием Web-интерфейса. Предоставляет набор инструментов для поиска и устранения неисправностей в сети, сбора детализированных отчетов, централизованного обновления программного обеспечения и конфигураций устройств, управления и конфигурации VPN, CallManager и др.;

-       CiscoView (CD-One) - графическое средство управления устройствами;

-       CiscoWorks2000 Management Server - общее управление интеграцией со сторонними системами сетевого управления, контролем административного доступа и сервисами для всего семейства решений CiscoWorks2000.

.4 Системы тарификации для УАТС

Современная УАТС имеет возможность выдавать информацию о звонках, идущих через нее, на специальный аппаратный порт, называемый обычно SMDR (Station Message Detail Recording) или CDR (Call Detail Recording). Если к этому порту подключить персональный компьютер, то полученную информацию можно принимать, сохранять и обрабатывать. Но для этого на нем должно быть установлено специальное программное обеспечение - тарификационная система.

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

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

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

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

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

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

Рынок тарификационных систем в настоящее время весьма разнообразен. Условно все учрежденческие тарификационные системы можно разделить на три основные категории:

-    простейшие тарификаторы;

-       системы, поставляемые в комплекте с УАТС;

-       универсальные тарификационные системы.

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

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

Универсальные тарификационные системы независимых разработчиков ПО, как правило, отвечают современным требованиям и ориентированы на поддержку АТС различных производителей. Часто они имеют дополнительные возможности для организации учета и обработки накопленной информации, а также для ведения счетов, поэтому иногда их называют еще биллинговыми системами (Billing System). Примерами биллинговых систем зарубежного производства могут служить такие продукты, как Ringmaster (Ирландия), BackTrack (США), PhonEx Pro (Израиль) и CallMaster (Канада).

Особо следует отметить российские разработки - они не только не уступают по качеству зарубежным аналогам, но и лучше адаптированных к российскому рынку, кроме того, выгодно отличаются от остальных своей стоимостью. Примерами таких систем являются "Барсум" (фирма "Рексофт", Санкт-Петербург), PhoneTax (фирма ITSoft, Казань), "ТелеМастер" (фирма "АМТ Ком", Москва).

2. Анализ фрагмента ведомственной сети ОАО "Хабровскэнерго"

.1 Общая характеристика фрагмента сети. Кабельная система

Схема фрагмента ведомственной сети ОАО "Хабаровскэнерго" представлена на странице 88.

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

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

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

Основные характеристики кабельной системы сведем в таблицу 2.1.

Таблица 2.1

.2 Характеристика фрагмента телефонной сети

Телефонная сеть на рассматриваемом участке представлена учережденческими цифровыми автоматическими станциями Hicom фирмы Siemens и станцией NEAX фирмы NEC (схема на странице 88).

Узел А оснащен станцией типа Hicom 382, на узле В используется станция типа Hicom 350E, на узлах C и D - станции типа Hicom 3x3, на узле Е - станция типа NEAX 2000 IPS.

Связь станций друг c другом организована по потокам E1. Для этого во всех станциях установлены платы PRI ISDN.

Связь узла А с узлом В организована по двум потокам Е1, объединенных в модуль STM-1 иерархии SDH, через мультиплексоры STM-1/STM-4 Metropolis AMU фирмы Lucent Technologies. Каждое соединение Е1 между станцией и мультиплексором осуществляется по кабелю витая пара, соединение между мультиплексорами организовано по волоконно-оптической линии.

Так же организовано соединение узлов А и Е, но используется один поток Е1, который включен в узле А в тот же мультиплексор Metropolis AMU. Данный мультиплексор имеет 16 интерфейсов для подключения потоков Е1 по кабелю витая пара и два оптических интерфейса STM-1. Таким образом можно организовать две волоконно-оптические линии в двух направлениях.

Узлы А и С соединены по одному потоку Е1 через мультиплексоры DLC-1100E фирмы НАТЕКС. В конфигурацию данного мультиплексора входят модуль для работы с АТС по интерфейсу Е1 и оптический приемопередатчик.

Узлы А и D соединены по потоку Е1 напрямую, через оптические интерфейсы станций Hicom 382 и Hicom 3x3, без использования мультиплексоров.

.3 Характеристика фрагмента сети передачи данных

Сеть передачи данных построена на коммутаторах фирмы Cisco (схема на странице 88).

В узлах B, C, D, E используются коммутаторы Catalyst 2950T-24, с 24 портами для подключения сетевых устройств по технологии Ethernet 10/100BaseT. Данная технология предполагает скорость соединения 10 или 100 Мбит/с и использование кабеля витая пара. Коммутаторы Catalyst 2950T являются устройствами второго уровня модели OSI/ISO. Это означает, что при возможности организации виртуальных локальных сетей на данном коммутаторе, коммутация между этими сетями невозможна. Для этого необходимо устройство третьего уровня модели. Поэтому в узле А используется коммутатор Catalyst 3550T-24, являющийся коммутатором третьего уровня. Catalyst 3550T-24 также имеет 24 порта 10/100BaseT.

Для связи коммутаторов между собой по волоконно-оптической линии используются медиаконверторы, которые преобразуют среду 100BaseT (кабель витая пара) в 100BaseFX (волоконно-оптический кабель). Для связи между узлами А и B, D, E используются медиаконверторы AT-MC103XL фирмы Allied Telesyn для одномодового кабеля. А между узлами А и С проложен многомодовый кабель, но там коммутаторы включены в мультиплексоры DLC-1100Е, в конфигурацию которых входит модуль передачи данных с интерфейсом 10/100BaseT. Таким образом, между узлами А и С используется одна пара волокон для телефонии и передачи данных.

2.4 Характеристика оборудования с позиции мониторинга

На коммутаторах Catalyst 2950-24T в узлах B, C, D и E установлено программное обеспечение Cisco IOS версии 12.1(20) ЕА1а. На коммутаторе Catalyst 3550 в узле А установлено ПО Cisco IOS версии 12.1(11) ЕА1.

Обе версии программного обеспечения поддерживают ряд средств для мониторинга оборудования. Поддерживаются следующие версии протокола SNMP - v1, v2C (Classic), v3. Выбор версии осуществляется при настройке. Таким образом, обеспечивается гибкость уровня безопасности - от доступа к агенту SNMP только по уровню сообщества до поддержки авторизации и шифрования пересылаемых данных. Кроме того, при использовании протокола SNMP с версии 2С, коммутатор сам может выступать в качестве менеджера и таким образом, быть частью иерархической структуры управления сетью.

Кроме возможности использования разной модели безопасности (SNMPv1, SNMPv2C, SNMPv3) в модели SNMPv3 еще возможны различные уровни безопасности. Для коммутаторов Catalyst эти уровни приведены в таблице 2.2.

Таблица 2.2

Так же есть возможность настроить коммутаторы таким образом, чтобы они посылали SNMP-сообщения, называемые "ловушками" при специфичных событиях (например, при изменениях в настройке SNMP на коммутаторе).

Коммутаторы Cisco поддерживают технологию RMON. В ПО Cisco IOS реализовано четыре группы RMON:

-       Statistics - сбор статистических данных о трафике, проходящем через интерфейс;

-       History - сбор статистических выборок через определенный интервал;

-       Alarm - установка некоторым переменным MIB пороговых значений и генерация сообщений (если это определено группой Event) на управляющую станцию;

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

Мультиплексоры Metropolis AMU фирмы Lucent Technologies и DLC-1100E фирмы НАТЕКС также поддерживают протокол SNMP. Но в мультиплексор DLC-1100E необходимо дополнительно установить для этого модуль сетевого управления NMI.

Все станции Hicom и NEAX предусматривают выдачу тарификационной информации на терминальный порт (в данном случае это com-порт). Кроме того, станции Hicom могут накапливать эту информацию на своих внутренних жестких дисках, а временный буфер (на несколько сотен записей) имеют и станции NEAX. Поддерживаются разные форматы выдаваемой информации, которые можно настроить с терминала управления станцией. Станции Hicom 382, 3х3, 350Н имеют по три com-порта, станция NEAX 2000IPS имеет один com-порт.

3. Разработка структуры системы мониторинга

.1 Выбор решения для мониторинга сети передачи данных

Согласно заданию, организуемая система мониторинга должна обеспечивать контроль состояния коммутаторов Cisco Catalyst 2950T-24 и Catalyst 3550-24T и их интерфейсов. Под контролем состояния коммутаторов подразумевается сбор статистики о загрузке центрального процессора, объема свободной памяти и времени наработки на отказ (up-time). Под контролем состояния интерфейсов подразумевается сбор статистики о количестве всех переданных через интерфейс пакетов, о количестве пакетов с ошибками. Необходимо так же организовать оперативное оповещение администратора об изменении статуса интерфейса (up или down).

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

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

Рассматриваемый спектр задач слишком узок для использования специализированных программных комплексов, предлагаемых, например, компанией Cisco. Эти решения, к тому же, являются достаточно дорогими (в среднем от 5 до 30 тысяч долларов США в зависимости от функциональности).

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

Более подходящим решением видится написание собственной программы. На выбор такого решения повлияло ряд факторов:

-       поддержка оборудованием единого протокола управления SNMP и наличие на сайте производителя оборудования www.cisco.com списка всех переменных MIB, поддерживаемых оборудованием;

-       опыт программирования на языке Perl и наличие готовых модулей для Perl для работы с протоколом SNMP;

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

.2 Выбор решения для тарификационной системы

Согласно заданию, необходимо организовать сбор тарификационной информации со станций Hicom и NEAX, и ее хранение для возможности дальнейшей обработки и анализа.

Счета за телефонный трафик ОАО "Хабаровскэнерго" предоставляется самим провайдером (в данном случае это Хабаровская ГТС), но в них отображается информация только по внешним звонкам, звонки внутри ведомственной телефонной сети не фиксируются. К тому же, при соединении с провайдером по потокам Е1 тарификация может учитываться по пилотному номеру, то есть по одному номеру для всех каналов Е1. В данном случае невозможно определить, кому конкретно из абонентов УАТС предоставить счет. Кроме этого, информация о звонках внутри сети позволит определить нагрузку на телефонную сеть, что позволит определить эффективность использования оборудования и каналов связи, а так же прогнозировать дальнейшее развитие сети.

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

В рамках данного дипломного проекта должны быть решены следующие задачи:

-    сбор информации о звонках со станции и загрузка ее в базу данных;

-       отображение в виде графика нагрузки на определенное направление.

.3 Выбор общей схемы системы мониторинга

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

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

Передача информации о состоянии коммутаторов Cisco Catalyst 2950 и Catalyst 3550 по протоколу SNMP происходит по сети передачи данных. Для удаленного управления УАТС Hicom и NEAX возможно подключение к станциям по модему. Поэтому одним из вариантов организации системы сбора информации является установка в центральном офисе выделенного компьютера и написание программ, которые бы по очереди опрашивали по сети передачи данных все коммутаторы и также, по очереди подключаясь к станциям по телефонной сети через модем, скачивали тарификационную информацию. Схема подключения для такого варианта построения системы приведена на рисунке 3.1. Выделенный компьютер подключается по интерфейсу RS-232 (com-порт) к станции, находящейся в центральном узле (узел А), и по такому же интерфейсу подключается к модему, через который можно подключаться к модемам удаленных станций. Так же компьютер подключен к порту коммутатора ЛВС (локальной вычислительной сети), который имеет связь с остальными коммутаторами ведомственной сети. Структурная схема приведена на рисунке 3.2. Вся информация в данном случае собирается в базы данных (БД), находящиеся на выделенном компьютере, где так же могут располагаться программы обработки и отображения полученной статистической информации.

Подобное решение имеет ряд существенных недостатков. Главным недостатком является то, что УАТС NEAX, которая располагается в узле Е имеет всего один порт RS-232 и поэтому периодическое подключение по модему, соединенному с этим портом, для сбора тарификационной информации затруднит удаленное управление этой станцией. К тому же модемное соединение обеспечивает низкую скорость и надежность и увеличивает нагрузку на потоки Е1, которыми соединены станции, а нагрузка на межстанционные соединения в данной сети без того достаточно большая.

Решением этих проблем могло бы стать использование так называемых консольных серверов - устройств, при помощи которых по сети передачи данных возможно подключение к консольным портам различных устройств. Например, компания Digi Internation предлагает широкий спектр оборудования для удаленного доступа к консольным интерфейсам различного оборудования. Для наших целей мог бы послужить так называемый девайс-сервер Digi One TS (примерно 400 долларов США), у которого имеется один интерфейс RS-232 и один интерфейс 100BaseT. При помощи этого устройства управление и сбор информации для тарификации осуществляется по сети передачи данных, что ускоряет оба действия. Кроме этого, обеспечивается большая безопасность при подключении к станциям за счет доступа по паролю к консольному серверу.

Схема подключения для решения с использованием консольных серверов приведена на рисунке 3.3, а структурная схема - на рисунке 3.4.

Рисунок 3.1

Рисунок 3.2

Рисунок 3.3

Рисунок 3.4

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

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

Схема подключения оборудования при использовании выделенного компьютера в каждом узле приведена на рисунке 3.5. Персональный компьютер (ПК) в каждом узле имеет два интерфейса RS-232 (com-порт) и оборудован сетевым адаптером FastEthernet (10/100BaseT), таким образом обеспечивается подключение к консольному порту учрежденческой телефонной станции и к порту коммутатора Cisco Catalyst. Нужно отметить, что коммутаторы ЛВС во всех узлах имеют свободные интерфейсы, что позволяет подключать дополнительные устройства к сети передачи данных. При таком подключении персональный компьютер играет роль и консольного сервера, поэтому достоинства удаленного управления УАТС по сети передачи данных в этом случае сохраняются.

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

В данном проекте было выбрано решение об организации системы мониторинга с выделенными ПК в каждом узле.

Рисунок 3.5

Рисунок 3.6

.4 Выбор оборудования и программного обеспечения

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

-     процессор Intel Pentium с частотой не выше 300 МГц;

-       не более 64 Мбайт оперативной памяти;

-       наличие свободного дискового пространства - не более 1 Гбайта.

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

Таблица 3.1

Цены на комплектующие предоставлены компанией "Офисная техника".

Согласно схеме организации системы мониторинга (рисунок 3.5), выделенные компьютеры должны иметь интерфейс RS-232 и сетевой адаптер 10/100BaseT для подключения к сети передачи данных. Наличие консоли (монитора и клавиатуры) не нужно, так как не предполагается совмещать эти компьютеры с рабочими местами персонала, а доступ к ним будет осуществляться удаленно. Выбор процессора Intel Pentium 4 обусловлен соображениями надежности. Два модуля оперативной памяти, по 256 Мбайт каждый, для всех компьютеров необходимы для того, чтобы объем оперативной памяти не стал узким местом для производительности компьютера, в случае, если в дальнейшем на него будут возложены дополнительные функции.

Во всех узлах рассматриваемой сети коммутаторы ЛВС располагаются в специальных телекоммуникационных шкафах. В узлах B, C, D, E УАТС и шкафы с коммутаторами располагаются в одной комнате. В узле А УАТС и шкаф с коммутатором располагаются в разных комнатах. Установка выделенных компьютеров для мониторинга предполагается в шкафы с коммутаторами, кроме узла А, где компьютер будет располагаться в комнате с УАТС. Это обусловлено ограничением на длину кабеля RS-232, которым должны соединятся станция и компьютер, в 9 метров максимум.

Из программного обеспечения компьютеров необходимо следующее:

-     операционная система;

-       интерпретатор языка Perl;

-       система управления базами данных (СУБД).

Язык программирования Perl является интерпретируемым языком, то есть для запуска программ, написанных на этом языке, необходимо дополнительно ПО - интерпретатор. Собственно сам выбор данного языка программирования обусловлен следующими факторами:

-     универсальность языка, позволяющая использовать его для разных задач;

-       наличие бесплатных и небольших интерпретаторов, а так же быстрота выполнения программ;

-       широкий спектр дополнительных модулей (в частности, для работы с базами данных, с протоколом SNMP и с com-портом, что необходимо для решения задач данного проекта);

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

-       наличие встроенного интерпретатора во всех операционных системах Linux и Unix.

Для хранения информации мониторинга необходима база данных, приспособленная для хранения текстовой информации и быстрого добавления информации. Поэтому в качестве СУБД предлагается использовать MySQL. Данная СУБД имеет ряд достоинств, существенных для конкретных задач:

-     распространяется бесплатно, имеет хорошую поддержку;

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

-       имеет интерфейс с языком программирования Perl;

-       имеет клиент-серверную архитектуру, клиенты могут подключаться по сети TCP/IP (в данном случае это необходимо при выполнении программ обработки статистической информации);

-       поддерживает различные операционные системы.

Таким образом, можно сделать вывод, что особых требований к операционной системе нет. Интерпретаторы Perl существуют и для систем Windows, СУБД MySQL так же могут работать в различной среде. В данном проекте была выбрана операционная система Linux.

4. Разработка программного обеспечения

.1 Разработка программы для мониторинга коммутаторов ЛВС

Программа мониторинга коммутаторов ЛВС согласно заданию и выбранному в разделе 3 решению должна обеспечивать:

-     сбор необходимой информации из переменных базы MIB коммутатора по протоколу SNMP;

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

-       извещение администратора об изменении статуса интерфейсов коммутатора.

Прежде чем приступать к написанию программы, работающей по протоколу SNMP, необходимо настроить SNMP-агента, находящегося на коммутаторе. Для рассматриваемых коммутаторов Cisco Catalyst 2950 и Catalyst 3550 в простейшем случае для активации SNMP-агента необходимо задать имя сообщества. Для менеджера и агента при установлении соединения эти имена должны совпадать. Так реализован простейший механизм авторизации. Рассматриваемые коммутаторы, как было сказано в разделе 2, поддерживают более сложные механизмы безопасности. В конфигурационном файле коммутатора строка настройки имени сообщества выглядит следующим образом:

snmp-server community public RO

(Read-only) означает, что по такому имени сообщества к данному агенту можно подключиться только для чтения информации из переменных MIB. Так же существуют еще уровни RW (Read-write) для изменения значений всех переменных MIB на коммутаторах, кроме изменения имени сообщества, и Read-write-all для изменения всех переменных. Но задача ставится только собрать определенную информацию, а не изменять ее, поэтому выбран уровень RO. В данном случае роль менеджера будет выполнять разрабатываемая программа. Структурная схема алгоритма работы программы представлена на рисунке 4.1. Для языка Perl существуют специальные модули, реализующие методы работы с протоколом SNMP. В данном дипломном проекте используется модуль Net::SNMP. Создание соединения по протоколу SNMP, используя данный модуль, выглядит следующим образом:

($session, $error) = Net::SNMP->session(

hostname => shift || '192.168.0.10',

community => shift || 'public',

-port => shift || 161 );

То есть необходимо указать IP-адрес агента, имя сообщества и порт.

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

-     $AmountPort = '.1.3.6.1.2.1.2.1.0' - количество интерфейсов;

-     $AverageCPULoad = '.1.3.6.1.4.1.9.2.1.58.0' - загрузка центрального процессора;

-       $FreeMemory = '.1.3.6.1.4.1.9.2.1.8.0' - объем свободной памяти;

-       $Uptime = '.1.3.6.1.2.1.1.3.0' - время наработки на отказ;

-       $DescrPort = ".1.3.6.1.2.1.2.2.1.2.$i" - описание интерфейса i;

-       $SpeedPort = ".1.3.6.1.2.1.2.2.1.5.$i" - cкорость интерфейса;

-       $OperPort = ".1.3.6.1.2.1.2.2.1.8.$i" - оперативное состояние интерфейса;

-       $AdminPort = ".1.3.6.1.2.1.2.2.1.7.$i" - административное состояние интерфейса;

-       $InOctets = ".1.3.6.1.2.1.2.2.1.10.$i" - количество входящих байт (через интерфейс);

-       $OutOctets = ".1.3.6.1.2.1.2.2.1.16.$i" - количество исходящих байт;

-       $ifInErrors = ".1.3.6.1.2.1.2.2.1.14.$i"- количество входящих байт с ошибками;

-       $ifOutErrors = ".1.3.6.1.2.1.2.2.1.20.$i" - количество исходящих байт с ошибками.

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

$ResultDescr = $session->get_request($DescrPort);

$ResultSpeed = $session->get_request($SpeedPort);

$ResultOper = $session->get_request($OperPort);

$ResultAdmin = $session->get_request($AdminPort);

$ResultInOctets = $session->get_request($InOctets);

$ResultOutOctets = $session->get_request($OutOctets);

$ResultInErrors = $session->get_request($ifInErrors);

$ResultOutErrors = $session->get_request($ifOutErrors);

Для опроса всех интерфейсов одного коммутатора организуется цикл.

Запись информации должна вестись в базы данных. Для работы с СУБД (системой управления базами данных) MySQL и другими для языка программирования Perl также существуют модули. В разрабатываемой программе используется модуль DBI. Все рассмотренные модули поддерживают разные операционные системы, поэтому возможно их использование для встроенного интерпретатора Linux.

Используя средства модуля DBI установить соединение с базой данных можно следующим образом:

$dbi_user = 'root';

$dbi_password = '';

$dbi_database = 'Sw_01';

$dbi_host = 'localhost';

$dbi_host2 = '192.168.0.1';

$dbi_dsn = "DBI:mysql:database=$dbi_database;host=$dbi_host";

$dbi_dsn2 = "DBI:mysql:database=$dbi_database;host=$dbi_host2";

$dbh = DBI->connect($dbi_dsn, $dbi_user, $dbi_password, { AutoCommit => 1, RaiseError => 1, PrintError => 1 });

$dbh2 = DBI->connect($dbi_dsn2, $dbi_user, $dbi_password, { AutoCommit => 1, RaiseError => 1, PrintError => 1 });

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

($month, $year) = (localtime)[4,5];

$table_name = sprintf ("%02d%02d", $month + 1, $year + 1900);

А затем проверяется наличие в базе данных таблицы с таким именем. В случае отсутствия такой таблицы, она создается:

# Выполнение запроса SQL из программы, написанной на Perl

# с возвращением в программу результатов запроса

$sth = $dbh->prepare("show tables from $dbi_database like 'g$table_name';");

$sth->execute() or die $dbh->errstr;

$ex = $sth->fetchrow_array();($ex ne "g$table_name")

# Выполнение запроса SQL из программы, написанной на Perl

# без возвращения в программу результатов

{$dbh->do($sql_create_gtable);

$sth->execute() or die $dbh->errstr;};

Запрос SQL (Structured Query Language - язык структурированных запросов) на создание таблицы для хранения информации о коммутаторах выглядит следующим образом:

($sql_create_gtable) = "CREATE TABLE g$table_name (INT(10) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT,INT(11) UNSIGNED,SMALLINT(3) UNSIGNED,SMALLINT(3) UNSIGNED,INT(11) UNSIGNED,TEXT,KEY (sID));";

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

($sql_create_iftable) = "CREATE TABLE if$table_name (INT(10) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT,INT(11) UNSIGNED,TEXT,INT(10) UNSIGNED,INT(10) UNSIGNED,INT(10) UNSIGNED,TINYINT(1) UNSIGNED,TINYINT(1) UNSIGNED,INT(6) UNSIGNED,INT(6) UNSIGNED,KEY (sID));";

Чтобы определить, изменился или нет статус интерфейса, предыдущие состояния интерфейсов в программе хранятся в файле state.old. При i-ой итерации программного цикла из файла берется соответствующее значение и сравнивается с текущим состоянием. При несовпадении этих значений запускается стандартная программа для отправки электронной почты в Linux Sendmail, и отправляется сообщение администратору.

$state_c = $ResultOper->{$OperPort};

$state_o = substr($previous, $i, 1);

$current .= $state_c;($state_c ne $state_o)

{open (SENDMAIL, "|/usr/sbin/sendmail -oi -t -odq");(SENDMAIL "To: 79022270899@sms.dti.ru Subject: SNMP Alert! Interface $ResultDescr of Sw_01 changed status. EOF");(SENDMAIL);}

Полный текст программы приведен в приложении А. Запуск данной программы будет происходить каждые десять минут. Для этих целей используется планировщик заданий для операционной системы Linux - Cron. Cron это программа, выполняющая задания по расписанию, позволяющая неоднократный запуск заданий. Т.е. задание можно запустить в определенное время или через определенный промежуток времени. Данная программа загружается вместе с операционной системой, и постоянно работает, как процесс, проверяя каждую минуту содержимое конфигурационного файла crontab. Каждая команда в пользовательском файле crontab занимает одну строку и состоит из шести полей. Общий формат команды: минута час день_месяца месяц день_недели команда

Допустимые значения:

- минута - от 0 до 59;

-       час - от 0 до 23;

-       день_месяца - от 1 до 31;

-       месяц - от 1 до 12 (можно три буквы из названия месяца, регистр не имеет значения от jan до dec);

-       день_недели - от 0 до 6 (0 это воскресенье, можно писать от sun до sat).

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

-59/10 * * * * "путь к программе"

4.2 Разработка программы для сбора тарификационной информации с УАТС

УАТС выдают тарификационную информацию на порт RS-232 (com-порт), и в соответствии с выбранным решением построения схемы мониторинга, программа сбора тарификационной информации должна работать на компьютере, непосредственно подключенным к com-порту станции. Для этих целей для интерпретатора языка Perl существуют дополнительные модули, которые предлагают ряд методов для работы с com-портом. В дипломном проекте использовался модуль Device::SerialPort, предназначенный для работы в операционной системе Linux.

Кроме этого, тарификационная информация, собранная через порт, должна быть записана в две базы данных - локальную (ЛБД) и центральную (ЦБД). Организация взаимодействия с СУБД MySQL в данной программе такая же, как в программе мониторинга коммутаторов. То есть используется модуль DBI, запись информации ведется параллельно в две базы данных, в которых для каждого месяца создаются отдельные таблицы.

Схема алгоритма программы сбора информации со станции приведена на рисунке 4.2.

Установление соединения с com-портом в программе организовано следующим образом:

$port = '/dev/ttys0';

$ob = Device::SerialPort->new ($port);}"Can't open serial port $port: $^E\n" unless ($ob);

Настройка параметров com-порта средствами модуля Device::SerialPort осуществляется следующим образом:

$ob->baudrate(38400); # Скорость передачи данных через порт

$ob->parity("none"); # Наличие бита четности

$ob->databits(8); # Биты данных

$ob->stopbits(1); # Количество стоповых бит

$ob->handshake('none'); # Управление потоком

$ob->write_settings; # Применение настроек

Для чтения одного байта информации из порта используется метод read:

($count, $active) = $ob->read(1);

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

-     номер вызывающего абонента;

-       номер вызываемого абонента;

-       время начала разговора;

-       продолжительность разговора.

Формат выдаваемых данных для станции Hicom приведен на рисунке 4.3, а для станции NEAX - на рисунке 4.4.

Рисунок 4.3 - Формат тарификационных данных для Hicom

Рисунок 4.4 - Формат тарификационных данных для NEAX

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

Чтение информации из порта в программе происходит в цикле, в котором проверяется наличие данных. Предусмотрен механизм тайм-аута. Если отсутствует информация на com-порту в течении определенного времени, то выполнении программы прерывается. Следующий запуск программы произойдет согласно конфигурационному файлу планировщика Cron через 10 минут. Если за это время накопились данные о звонках, то они будут храниться во временном буфере станции до тех пор, пока не считаются программой. Буфер предусмотрен для обоих типов станций.

Полный текст программы для сбора тарификационной информации со станции Hicom приведен в приложении Б, а со станции NEAX - в приложении В.

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

Тарификационные данные, собираемые со станции необходимы не только для выставления счетов абонентам, но еще они являются статистическим материалом, на основании которого можно делать выводы о нагрузке на оборудование и каналы связи. В данном дипломном проекте предлагается рассмотреть частную задачу определения нагрузки на направление. УАТС в сети ОАО "Хабаровскэнерго" связаны потоками Е1, которые содержат 30 каналов. Определить, нужно ли увеличение каналов между узлами, позволит только анализ статистических данных о нагрузке между узлами.

Схема алгоритма программы определения нагрузки на направление представлена на рисунке 4.5.

Для наглядности информацию о нагрузке на направление нужно оформить в виде графика. Для рисования различных графиков в Perl существует модуль GD::Graph::lines.

Создание графика:

$mygraph=GD::Graph::lines->new(1000,500); # график размером 1000 на 500 точек

$mygraph->set(_label =>'Time', # Описание оси х_label =>'Count', # Описание оси y=>'800') or warn $mygraph->error;

Непосредственно рисование графика происходит на основании данных, расположенных в двумерном массиве. В данном случае это массив @data.

my $myimage=$mygraph->plot(\@data) or die $mygraph->error;

Массив данных заполняется значениями промежутка времени и количеством вызовов в нужном направлении за заданный промежуток. График сохраняется в файл png.

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

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

Полный текст программы приведен в приложении Г.

Рисунок 4.6

5. Требования к качеству системы мониторинга

Информация, собираемая при работе системы мониторинга, передается по сети передачи данных в центральный узел. Таким образом, организуемую систему мониторинга можно отнести к службе передачи данных (ПД) с коммутацией пакетов по протоколам, относящимся к семейству Internet Protocol (IP).

Согласно Руководящему документу 45.0128-2000 "Сети и службы передачи данных" к услугам служб ПД по протоколам IP предъявляются следующие требования:

-     служба ПД с коммутацией пакетов по протоколам, относящимся к семейству Internet Protocol (IP), является службой без установления виртуальных соединений (службой датаграмм);

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

-       режим работы в точке доступа к службе ПД оператора должен соответствовать документу IETF RFC 791 при использовании версии 4 протокола IP (Ipv4), либо документу RFC 2460 или их последователю при использовании версии 6 протокола IP (Ipv6);

-       возможен как прямой доступ, так и непрямой доступ для ООД. Непрямой доступ возможен через сеть ТфОП и другие коммутируемые сети;

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

Показатели качества обслуживания в службах ПД с коммутацией пакетов по протоколам, относящимся к семейству Internet Protocol (IP).

В современных сетях по протоколу IP не гарантируется качество обслуживания (предоставляются услуги с негарантированным качеством обслуживания). В настоящее время разрабатываются и внедряются способы обеспечения качества обслуживания. Намечаемые показатели качества обслуживания в сетях по протоколу IP согласно Рекомендации МСЭ-Т I.380 приведены в таблице 5.1.

Нормы для этих показателей качества обслуживания в настоящее время изучаются. Предварительно (на основе проекта Рекомендации МСЭ-Т Y.1541) устанавливаются классы обслуживания, приведенные в таблице 5.2. Кроме того, предварительно рекомендуются следующие нормы для всех классов обслуживания, кроме "приемлемого":

-     время доступа: не более 5 с;

-       коэффициент потери IP-пакетов: не более 1х10-3;

-       коэффициент ошибок в IP-пакетах: не более 1х10-4;

-       коэффициент ошибок в IP-пакетах: не более 1х10-4;

-       критерий отказа: отказом считается ситуация, при которой коэффициент потери IP-пакетов превышает 0,75.

Указанные нормы приведены для связи между оконечными точками (от конца до конца) IP-сети, имеющей архитектурную модель, которая определена в Рекомендации МСЭ-Т Y.1231. Нормы приведены для международной связи длиной 27500 км. Качество обслуживания в сетях отдельных операторов должно быть не хуже указанного в таблице 5.2.

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

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

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

Таблица 5.1 - Показатели качества обслуживания

Таблица 5.2 - Предварительно рекомендуемые нормы для классов обслуживания

6. Технико-экономический расчет

Технико-экономический расчет заключается в определении затрат, возникающих в результате ввода в эксплуатацию системы мониторинга. Данная система необходима для внутренних нужд ОАО "Хабаровскэнерго" и не предусматривает наличия доходов. Таким образом, расчет складывается из расчета капитальных затрат на ввод в эксплуатацию системы и расчета годовых эксплуатационных расходов. Общая структура всех затрат приведена на рисунке 6.1.

.1 Капитальные затраты на ввод в эксплуатацию системы мониторинга

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

Таблица 6.1

Рисунок 6.1 - Структура затрат

Затраты, образующие себестоимость программного обеспечения, состоят из:

-       материальных затрат;

-       затрат на электроэнергию;

-       затрат на оплату труда;

-       отчисления на социальные нужды;

-       амортизация основных средств.

В материальных затратах должны отражаться стоимости приобретенного аппаратного и программного обеспечения, необходимого для разработки программного продукта. Так как программное обеспечение разрабатывалось на рабочем месте в ОАО "Хабаровскэнерго", оборудованном персональным компьютером, то материальные затраты на приобретение аппаратного и программного обеспечения отсутствует.

Учитываем только затраты на приобретение электрической энергии.

Стоимость 1 кВт/час для предприятий, использующих низкое напряжение (к таким относятся все учреждения связи) для Хабаровска составляет 2,24 рублей. Потребление компьютером электроэнергии согласно техническому паспорту составляет 340 Вт/час, монитором 210 Вт/час.

Согласно принятых норм время, затрачиваемое на работу с ЭВМ при проведении работ по созданию ПО tЭВМ составляет 72% от общего времени разработки программного обеспечения:

, (6.1)

где Т - продолжительность разработки проекта, месяцев.

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

Т = 2,5 Ì [3,6 Ì (nТ.И.К.)1,2]0,32, мес. (6.2)

где nТ.И.К. - число тысяч исходных команд. В нашем случае число тысяч команд составляет 0,5.

Исходя из выше приведенных формул, рассчитаем длительность разработки проекта и время, затрачиваемое на работу с ЭВМ:

Т = 2,5 Ì [3,6 Ì (nТ.И.К.)1,2]0,32 = 2,5 Ì [3,6 Ì (0,5)1,2]0,32 3, мес.

Среднее количество рабочих часов в месяце - 169 часа.

Таким образом объем затраченного времени на работу с ЭВМ tЭВМ.ч будет составлять:

 часа (6.3)

Рассчитаем стоимость электроэнергии потребляемой компьютером за один час работы:

, (6.4)

где ТЭ - тариф на электроэнергию для не бюджетных организаций;

Мб - мощность, потребляемая системным блоком, составляет 340 Ватт в час;

Мм - мощность, потребляемая монитором, составляет 210 Ватт в час.

Таким образом, стоимость электроэнергии затраченной на разработку программного обеспечения составляет:

 (6.5)

В элементе "Затраты на оплату труда" отражаются затраты на оплату труда разработчика.

Расчет заработной платы произведем по формуле:

, руб. (6.6)

где Зпл/мес - оклад инженера-программиста, составляет 5000 рублей;

Т - продолжительность разработки проекта;

,4 - ежемесячная премия;

,6 - районный коэффициент (в него входит непосредственно сам районный коэффициент, равный 1,2, а также дальневосточный коэффициент, равный 1,3, и стимулирующий коэффициент, равный 1.1).

В элементе "Отчисления на социальные нужды" отражаются обязательные отчисления по установленным законодательством Российской Федерации нормам. Отчисления на социальные нужды составляют:

в пенсионный фонд - 20%;

социальное страхование - 3,2%;

в фонд медицинского страхования - 2,8%;

в фонд страхования от несчастного случая - 0,2%.

Суммарное удержание на социальные нужды (Зсоц) составляет 26,2% от суммы начислений заработной платы. Расходы по данной статье определяются исходя из следующей формулы:

, (6.7)

где Зпл - заработная плата, руб.

В элементе "Амортизация основных средств" отражается сумма амортизационных отчислений на полное восстановление основных производственных средств, исчисленная исходя из восстановительной стоимости и утвержденных в установленном порядке норм [15].

Сумма амортизационных отчислений определяется исходя из первоначальной стоимости объекта и нормы амортизации, исчисленной исходя из срока полезного использования этого объекта. Согласно решения методического совета ОАО "Связьинвест" от 18.04.2002 г. №6 норма амортизации в Дальневосточном регионе для вычислительной техники включая персональный компьютер составляет 2,7 % в месяц. Отсюда, амортизационные отчисления с учетом времени работы за компьютером составят:

, руб., (6.8)

где А - балансовая стоимость ПЭВМ, составляет 26943 руб.;

Т - продолжительность разработки проекта.

Таким образом, себестоимость данного программного продукта - С, определяется по формуле:

 (6.9)

Структура капитальных затрат приведена в таблице 6.2.

Таблица 6.2

Наибольшие статьи расходов на капитальные затраты - это затраты на приобретение оборудования и на заработную плату программиста.

Рассмотренные затраты являются единовременными, то есть такими, которые предприятие несет в связи вводом в эксплуатацию проектируемой системы мониторинга один раз.

.2 Расчет годовых эксплуатационных расходов

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

Годовые эксплуатационные расходы складываются из следующих основных статей затрат:

-                    заработная плата штата основной деятельности;

-             отчисления на социальное страхование;

-             амортизационные отчисления;

-             затраты на электроэнергию;

-             прочие производственные и административно-управленческие расходы.

Расчет годового фонда заработной платы

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

-      начальник сектора ЦКС и ПД;

-             инженер-программист 1 категории;

-             два инженера 2 категории;

-             три электромонтера 6 разряда.

Весь персонал необходим для работы в секторе цифровых коммутационных систем и передачи данных (ЦКС и ПД). Начальник сектора и инженер-программист 1 разряда занимаются сетевым оборудованием, инженеры 2 категории программируют цифровые УАТС, на монтажные и кроссировочными работы потребуется три электромонтера 6 категории.

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

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

Таблица 6.3

Таким образом, общий штат сектора ЦКС и ПД составляет 7 человек.

Тогда годовой фонд заработной платы составит

Фг=Фобщ.Ìn= 66689Ì12=800268 руб., (6.10)

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

Отчисления на социальные нужды разделяются на статьи и рассчитываются в процентном отношении к Фг:

·   отчисления в пенсионный фонд - 20%;

·   отчисления в фонд социального страхования - 3,2%;

·   отчисления в фонд обязательного медицинского страхования - 2,8%;

·   отчисления в фонд производственного травматизма - 0,2%.

Всего отчислений 26,2%.

Общий фонд отчислений на страхование составляет:

Фотч.=ФгÌОтч.=800268Ì0,262 = 209670,2 руб., (6.11)

где Фг - годовой фонд заработной платы, руб.;

Отч. - отчисления на социальные нужды.

Тогда годовой фонд заработной платы вместе с отчислениями составляет:

Фз/пл=Фг+Фотч.=800268 + 209670,2 =1009938,2 руб., (6.12)

где Фг - годовой фонд заработной платы, руб.

Фотч - общий фонд отчислений на страхование, руб.

Расчет годовых амортизационных отчислений

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

Амортизационные отчисления рассчитываются с помощью формулы:

А=, руб. (6.13)

где Ф - первоначальная стоимость оборудования (капитальные затраты на приобретение оборудования), руб.;

,7 - норма амортизации для ЭВМ в процентах в месяц;

- количество месяцев, так как рассматриваются годовые эксплуатационные расходы.

В результате расчетов получают годовые амортизационные отчисления для приобретаемого оборудования. Данная методика характерна для ОАО "Хабаровскэнерго".

Расчет затрат на электроэнергию.

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

эн =, руб. в год,

где Т - тариф на электроэнергию, Т=2,24 руб./кВт-ч для предприятий, использующих низкое напряжение;

Рп - потребляемая мощность, для компьютера Рп=340 Вт, по техническим данным;- КПД сетевого оборудования, по фактическим данным n=0.9;

- среднее количество часов в году.

Прочие затраты

Затраты на прочие производственные, управленческие и эксплуатационно-хозяйственные расходы (например) определяются укрупненно в размере 35% от годового фонда заработной платы производственного персонала и составляют:

З=Фз/плÌk=.1009938,2 Ì0,35=353478,37, руб.,

где Фз/пл - годовой фонд заработной платы, руб.;- норма отчислений расходов на прочие затраты, %.

Результаты расчета годовых эксплуатационных расходов представлены в таблице 6.4

Таблица 6.4

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

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

-     своевременную реакцию на повреждение линии связи;

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

-       получение информации, на основании которой возможен прогноз развития сети связи, своевременное ее расширение.

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

7. Вопросы обеспечения безопасности жизнедеятельности

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

Установка оборудования должна соответствовать требованиям, таким как, действующим ведомственным нормам технологического проектирования ВНТП 112-92, правилам устройства электроустановок ПУЭ, правилам эксплуатации электроустройств, техники безопасности при эксплуатации электроустановок и правил пожарной безопасности, СанПиН 2.2.2.542-96, а также ГОСТам, предусмотренными для организации рабочих мест телефонистов. При проектировании сектора ЦКС и ПД ОАО "Хабаровскэнерго" предъявляются следующие требования.

.1 Требования к микроклимату в коммутаторном цехе

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

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

Таблица 7.1 - Нормы на параметры микроклимата

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

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

.2 Требования к освещенности

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

Утомляемость органов зрения зависит от ряда причин: недостаточность освещенности; чрезмерная освещенность; неправильное направление света.

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

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

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

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

.3 Требования к шуму в коммутаторном цехе

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

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

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

.4 Требования к организации рабочего места с персональным компьютером

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

При правильной организации рабочего места производительность труда возрастает с 8 до 20 процентов.

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

оптимальное размещение оборудования, входящего в состав рабочего места;

достаточное рабочее пространство, позволяющее осуществлять все необходимые движения и перемещения;

 необходимо естественное и искусственное освещение для выполнения поставленных задач;

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

Площадь одного рабочего места с видеомонитором должна составлять не менее 6 м², а объем не менее 20 м3.

Главными элементами рабочего места пользователя ПК являются письменный стол и кресло. Основным рабочим положением является положение сидя. Рабочее место для выполнения работ в положении сидя организуется в соответствии с ГОСТ 12.2.032-78.

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

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

ширина не менее 700 мм;

глубина не менее 400 мм;

высота рабочей поверхности стола над полом 680-800 мм.

Модульными размерами рабочей поверхности стола с видеомонитором, на основании которых должны рассчитываться конструктивные размеры, следует считать: ширину - 800, 1000, 1200 и 1400 мм, глубину - 800 и 1000 мм при высоте 725 мм. Оптимальными размерами стола являются:

- высота 710 мм;

- длина стола 1300 мм;

ширина стола 650 мм.

Под рабочей поверхностью должно быть предусмотрено пространство для ног:

высота не менее 600 мм;

ширина не менее 500 мм;

глубина не менее 400 мм.

Рабочий стул должен быть подъемно - поворотным и регулируемым по высоте и углом наклона сидения и спинки.

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

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

Экран дисплея, документы и клавиатура должны быть расположены так, чтобы перепад яркостей поверхностей, зависящий от их расположения относительно источника света, не превышал 1 : 10, рекомендуемое значение 1 : 3. При номинальных значениях яркостей изображения на экране 50-100 кд/м² освещенность на рабочем месте должна составлять 300-500 лк.

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

.5 Требования к электробезопасности

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

В персональном компьютере источником опасности является электрическая часть, а именно входные цепи блока питания, который может быть подключен к сети переменного напряжения 220 В частотой 50 Гц. Выходные цепи блока питания составляют от минус 12 до плюс 12 В. Таким образом, согласно ПЭУ 1.1.3 устройство относится к установкам с рабочим напряжением до 1000 В. Использующееся помещение коммутаторного цеха в котором установлены ЭВМ относятся к классу помещений с повышенной опасностью, так как имеется большое количество заземленных устройств, имеющих возможность одновременного прикосновения к конструктивно заземленным устройствам.

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

Рассчитаем сопротивление одиночного вертикального заземлителя по формуле:

где К1 - поправочный коэффициент промерзания грунта, при средней многолетней низкой температуре -20°С, К1 = 1,9;

- длина заземляющего устройства, =20 м;

h - расстояние от поверхности земли до верхнего заземлителя, h = 0,7 м;

,95·b= 0,1 м - диаметр трубы,

где b - ширина сторон уголка;

ρ - удельное сопротивление грунта, рассчитывается по формуле

ρ = 2π·R·a = 2·3,14·0,2·6 = 7,536 Ом·м,

где R - замеренное значение сопротивления 05.08.94 года прибором М-416, R = 0,2 Ом;

Заземляемые установки могут быть с электропитанием 660/380 В при ρ ≤ 100 Ом·м должны иметь заземляющие устройства со значением R ≤ 2 Ом.

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

В качестве заземлителя используется металлическая труба диаметром 100 мм, длиной 20 м. Труба устанавливается в предварительно пробуренную скважину. Глубина установки верхнего конца трубы должна составлять 0,7 м от поверхности земли.

Подключение заземляющего устройства к КИП производится кабелем ВРГ - 1х16. Кабель ВРГ - 1х16 приваривается электросваркой к металлической полосе 40х4, которая приваривается к металлической трубе. Места сварки гидроизолируются битумом и бумажной лентой.

.6 Допустимые нормы на излучение

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

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

электромагнитное поле сложного спектрального состава в широком диапазоне частот (от 10 Гц до 1000 МГц);

электростатический заряд на ЭЛТ монитора;

ультрафиолетовое, инфракрасное и рентгеновское излучения;

эргономические параметры экрана (блики, мерцание, контрастность).

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

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

Для защиты от электромагнитного излучения применяется защитное экранирование при помощи отражающих и поглощающих экранов, а также производится нормирование параметров излучения.

Так, напряженность электромагнитного поля по магнитной составляющей на расстоянии 50 см от поверхности видеомонитора должна составлять - 10 В/м; напряженность электромагнитного поля по электрической составляющей на расстоянии 50 см от поверхности видеомонитора должна составлять - 0,3 А/м; напряженность электростатического поля должна быть не более 20 кВ/м.

.7 Требования к пожаробезопасности

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

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

в секторе должны быть размещены углекислотные огнетушители типов ОУ-2, ОУ-5, ОУ-8. Согласно типовым правилам пожарной безопасности на каждые 50 м2 площади помещения с видеомониторами должен приходиться один огнетушитель.

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

Меры пожарной безопасности определены в ГОСТ 12.1.004-91.

Заключение

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

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

Так же было предложено решение аппаратной организации системы мониторинга, проведены экономические расчеты, в которых были определены расходы на внедрение такой системы в производственный процесс ОАО "Хабаровскэнерго".

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

Список использованных источников

1.      Паркер Т., Сиян К. TCP/IP. Для профессионалов. - СПб.: Питер, 2004.

2.      RFC 1157. Simple Network Managenent Protocol (SNMP).

3.      Аткинсон Л. Библиотека профессионала: MySQL. - М.: Вильямс, 2002.

.        Дюбуа П. MySQL. Сборник рецептов. - СПб.:Символ, 2004.

.        Клинтон П. Освой самостоятельно Perl за 24 часа. - М.:Вильямс, 2000.

.        Кристиансен Т., Торкингтон Н. Perl: библиотека программиста. - СПб.: Питер, 2004.

.        Методические указания по дипломному и курсовому проектированию. Хабаровск: ХФ СибГУТИ, 2004.

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

.        Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организация работы. Санитарные нормы и правила 2.2.2.542.-96.

.        Правила устройства электроустановок ПУЭ. М.:НЦ ЭНАС, 1999.- 80с.

.        Технико-экономическое обоснование дипломных проектов: Учеб. Пособие для втузов. - М.: Высш. шк., 1991.- 176 с.

.        ГОСТ 12-1-004-91 (1999) ССБТ - Пожарная безопасность - Общие требования.

.        Приказ Минфина РФ от 30 марта 2001 г. №26н.

.        Руководящий документ отрасли РД 45.128-2000. Сети и службы передачи данных.

Приложение А

#Текст программы мониторинга коммутаторов ЛВС

# Знаком "#" обозначены комментарии

#! /usr/local/bin/perl

# Подключение модулей для работы с протоколом SNMP и для работы с СУБД

use Net::SNMP;DBI;

# Создание соединения по протоколу SNMP

($session, $error) = Net::SNMP->session(

-hostname => shift || '192.168.0.10',

community => shift || 'public',

-port => shift || 161);

# Подключение к локальной и центральной базе данных

$dbi_user = 'root';

$dbi_password = '';

$dbi_database = 'Sw_01';

$dbi_host = 'localhost';

$dbi_host2 = '192.168.0.1';

$dbi_dsn = "DBI:mysql:database=$dbi_database;host=$dbi_host";

$dbi_dsn2 = "DBI:mysql:database=$dbi_database;host=$dbi_host2";

$dbh = DBI->connect($dbi_dsn, $dbi_user, $dbi_password, { AutoCommit => 1, RaiseError => 1, PrintError => 1 });

$dbh2 = DBI->connect($dbi_dsn2, $dbi_user, $dbi_password, { AutoCommit => 1, RaiseError => 1, PrintError => 1 });

# Запрос на создание таблицы для хранения данных о состоянии коммутатора

($month, $year) = (localtime)[4,5];

$table_name = sprintf ("%02d%02d", $month + 1, $year + 1900);

($sql_create_gtable) = "CREATE TABLE g$table_name (INT(10) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT,INT(11) UNSIGNED,SMALLINT(3) UNSIGNED,SMALLINT(3) UNSIGNED,INT(11) UNSIGNED,TEXT,KEY (sID));";

# Запрос на создание таблицы для хранения данных об интерфейсах коммутатора

($sql_create_iftable) = "CREATE TABLE if$table_name (INT(10) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT,INT(11) UNSIGNED,TEXT,INT(10) UNSIGNED,INT(10) UNSIGNED,INT(10) UNSIGNED,TINYINT(1) UNSIGNED,TINYINT(1) UNSIGNED,INT(6) UNSIGNED,INT(6) UNSIGNED,KEY (sID));";

# Если таблиц с таким названием (номер текущего месяца) нет, тогда их создать

$sth = $dbh->prepare("show tables from $dbi_database like 'g$table_name';");

$sth->execute() or die $dbh->errstr;

$ex = $sth->fetchrow_array();($ex ne "g$table_name")

{$dbh->do($sql_create_gtable);

$sth->execute() or die $dbh->errstr;};

$sth = $dbh->prepare("show tables from $dbi_database like 'if$table_name';");

$sth->execute() or die $dbh->errstr;

$ex = $sth->fetchrow_array();($ex ne "if$table_name")

{$dbh->do($sql_create_iftable);

$sth->execute() or die $dbh->errstr;};

$sth = $dbh2->prepare("show tables from $dbi_database like 'g$table_name';");

$sth->execute() or die $dbh2->errstr;

$ex = $sth->fetchrow_array();($ex ne "g$table_name")

{$dbh2->do($sql_create_gtable);

$sth->execute() or die $dbh2->errstr;};

$sth = $dbh2->prepare("show tables from $dbi_database like 'if$table_name';");

$sth->execute() or die $dbh2->errstr;

$ex = $sth->fetchrow_array();($ex ne "if$table_name")

{$dbh2->do($sql_create_iftable);

$sth->execute() or die $dbh2->errstr;};

$datetime = time();

# Получение данных о состоянии коммутатора и запись из в базу данных

$AmountPort = '.1.3.6.1.2.1.2.1.0'; # Количество интерфейсов

$ResultAmount = $session->get_request($AmountPort);

$AverageCPULoad = '.1.3.6.1.4.1.9.2.1.58.0'; # Загрузка центрального процессора

$ResultACL = $session->get_request($AverageCPULoad);

$FreeMemory = '.1.3.6.1.4.1.9.2.1.8.0'; # Объем свободной памяти

$ResultFM = $session->get_request($FreeMemory);

$Uptime = '.1.3.6.1.2.1.1.3.0'; # Время наработки на отказ

$ResultUptime = $session->get_request($Uptime);

$dbh->do("INSERT INTO g$table_name (sDateTime, sAmount, sACPU, sFM, sUptimec) VALUES ('$datetime', '$ResultAmount->{$AmountPort}', '$ResultACL->{$AverageCPULoad}', '$ResultFM->{$FreeMemory}', '$ResultUptime->{$Uptime}')");

$dbh2->do("INSERT INTO g$table_name (sDateTime, sAmount, sACPU, sFM, sUptimec) VALUES ('$datetime', '$ResultAmount->{$AmountPort}', '$ResultACL->{$AverageCPULoad}', '$ResultFM->{$FreeMemory}', '$ResultUptime->{$Uptime}')");

# Считывание из файла данных о предыдущем состоянии статуса интерфейсов коммутатора

open (OLDSTATE, "state.old");

$previous = <OLDSTATE>;

close(OLDSTATE);

# Цикл по количеству интерфейсов

for ($i = 1; $i <=($ResultAmount->{$AmountPort}); $i++)

# Получение данных об интерфейсах

{$DescrPort = ".1.3.6.1.2.1.2.2.1.2.$i"; # Описание интерфейса

$SpeedPort = ".1.3.6.1.2.1.2.2.1.5.$i"; # Скорость интерфейса

$OperPort = ".1.3.6.1.2.1.2.2.1.8.$i"; # Оперативное состояние интерфейса

$AdminPort = ".1.3.6.1.2.1.2.2.1.7.$i"; # Административное состояние интерфейса

$InOctets = ".1.3.6.1.2.1.2.2.1.10.$i"; # Количество входящих байт (через интерфейс)

$OutOctets = ".1.3.6.1.2.1.2.2.1.16.$i"; # Количество исходящих байт

$ifInErrors = ".1.3.6.1.2.1.2.2.1.14.$i"; # Количество входящих байт с ошибками

$ifOutErrors = ".1.3.6.1.2.1.2.2.1.20.$i"; # Количество исходящих байт с ошибками

$ResultDescr = $session->get_request($DescrPort);

$ResultSpeed = $session->get_request($SpeedPort);

$ResultOper = $session->get_request($OperPort);

$ResultAdmin = $session->get_request($AdminPort);

$ResultInOctets = $session->get_request($InOctets);

$ResultOutOctets = $session->get_request($OutOctets);

$ResultInErrors = $session->get_request($ifInErrors);

$ResultOutErrors = $session->get_request($ifOutErrors);

# Сравнение предыдущего оперативного состояния интерфейса с поступившим

# Если состояние изменилось - оправляется сообщение администратору

$state_c = $ResultOper->{$OperPort};

$state_o = substr($previous, $i, 1);

$current .= $state_c;($state_c ne $state_o)

{open (SENDMAIL, "|/usr/sbin/sendmail -oi -t -odq");(SENDMAIL "To: 79022270899@sms.dti.ru Subject: SNMP Alert! Interface $ResultDescr of Sw_01 changed status. EOF");(SENDMAIL);}

# Запись в базу данных информации об интерфейсах

$dbh->do("INSERT INTO if$table_name (sDateTime, sDescr, sSpeedPort, sInOct, sOutOct, sOperPort, sAdminPort, sInErrors, sOutErrors) VALUES ('$datetime', '$ResultDescr->{$DescrPort}', '$ResultSpeed->{$SpeedPort}', '$ResultInOctets->{$InOctets}', '$ResultOutOctets->{$OutOctets}', '$ResultOper->{$OperPort}', '$ResultAdmin->{$AdminPort}', '$ResultInErrors->{$ifInErrors}', '$ResultOutErrors->{$ifOutErrors}')");

$dbh2->do("INSERT INTO if$table_name (sDateTime, sDescr, sSpeedPort, sInOct, sOutOct, sOperPort, sAdminPort, sInErrors, sOutErrors) VALUES ('$datetime', '$ResultDescr->{$DescrPort}', '$ResultSpeed->{$SpeedPort}', '$ResultInOctets->{$InOctets}', '$ResultOutOctets->{$OutOctets}', '$ResultOper->{$OperPort}', '$ResultAdmin->{$AdminPort}', '$ResultInErrors->{$ifInErrors}', '$ResultOutErrors->{$ifOutErrors}')");

};

# Запись информации в файл о последних полученных состояниях интерфейсов

open (OLDSTATE, ">state.old");(OLDSTATE "$current\n");(OLDSTATE);

$session->close;

$dbh->disconnect();

Приложение Б

# Текст программы сбора тарификационной информации с УАТС Hicom

#!/usr/bin/perl -w

# Подключение модуля для работы с СУБДDBI;

# Выбор модуля для работы с com-портом в зависимости от операционной системы

BEGIN {

$OS_win = ($^O eq "MSWin32") ? 1 : 0;($OS_win) {"use Win32::SerialPort";}{"use Device::SerialPort";}}($OS_win) {

$port = 'COM0';

$ob = Win32::SerialPort->new ($port);}{

$port = '/dev/ttys0';

$ob = Device::SerialPort->new ($port);}"Can't open serial port $port: $^E\n" unless ($ob);

# Установление параметров работы с com-портом

$ob->baudrate(38400); # Скорость передачи данных через порт

$ob->parity("none"); # Наличие бита четности

$ob->databits(8); # Биты данных

$ob->stopbits(1); # Количество стоповых бит

$ob->handshake('none'); # Управление потоком

$ob->write_settings; # Применение настроек

# Подлючение к локальной и центральной базам данных

$dbi_user = 'root';

$dbi_password = '';

$dbi_database = 'ATS_01';

$dbi_host = 'localhost';

# Параметры для подлючения к локальной базе данных

$dbi_dsn = "DBI:mysql:database=$dbi_database;host=$dbi_host";

$dbi_host2 = '192.168.0.1';

# Параметры для подлючения к центральной базе данных

$dbi_dsn2 = "DBI:mysql:database=$dbi_database;host=$dbi_host2";

$dbh = DBI->connect($dbi_dsn, $dbi_user, $dbi_password, {AutoCommit => 1, RaiseError => 1, PrintError => 1 });

$dbh2 = DBI->connect($dbi_dsn2, $dbi_user, $dbi_password, {AutoCommit => 1, RaiseError => 1, PrintError => 1 });

# Запрос на создание таблицы

($month, $year) = (localtime)[4,5];

$table_name = sprintf ("s%02d%02d", $month + 1, $year + 1900);

($sql_create_table) = "CREATE TABLE $table_name (INT(10) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT,DATE DEFAULT '0000-00-00' NOT NULL,TIME DEFAULT '00:00:00' NOT NULL,SMALLINT(3) UNSIGNED DEFAULT '0' NOT NULL,VARCHAR(8),TIME DEFAULT '00:00:00' NOT NULL,VARCHAR(16),INT(10) UNSIGNED,

PRIMARY KEY (sID));";

# Если таблица с таким названием (название - текущий месяц) не существует, то ее создать

# в локальной и центральной базах данных

$sth = $dbh->prepare("show tables from $dbi_database like '$table_name';");

$sth->execute() or die $dbh->errstr;

$ex = "";

$ex = $sth->fetchrow_array();($ex ne $table_name) {

$dbh->do($sql_create_table);

$sth->execute() or die $dbh->errstr;};

$sth=$dbh2->prepare("show tables from $dbi_database like '$table_name';");

$sth->execute() or die $dbh2->errstr;

$ex="";

$ex=$sth->fetchrow_array();($ex ne $table_name) {

$dbh2->do($sql_create_table);

$sth->execute() or die $dbh2->errstr;};

$timestart = time();

$timeout = 2;

$result = "";

# Опрос com-порта в цикле (осуществляется до истечения тайм-аута)((time() - $timestart) < $timeout) {

# Чтение одного байта информации из com-порта ($count - признак того, что данные

# из com-порта поступили, $active - данные, считанные из порта)

($count, $active) = $ob->read(1);

# Если данные поступили, то дописать их в переменную-накопитель и сбросить счетчик

# времени для тайм-аута($count)

{ $result .= $active;

$timestart = time();}

# Обработка информации

if ($result =~ m/\r/)

# Отбросить символ "$" из строки

{if ($result =~ m/\$(.*)\+/)

# Разбить строку на составляющие и записать их в переменные

{($datetime, $sline, $sstn, $stimetalk, $sdestno) = split(/\s*\+\s*/, $result);

# Выделить дату и время

($date, $time) = $datetime =~ m/\$(\d{6})(\d{6})/;

# Перевести время разговора в секунды

($hour, $min, $sec) = $stimetalk =~ m/(\d{2})(\d{2})(\d{2})/;

$stimetalksec = ($hour * 3600) + ($min * 60) + $sec;

# Записать полученные данные в локальную и центральную базу данных

$dbh->do("INSERT INTO $table_name (sDateCall, sTimeCall, sLine, sStn, sTimeTalk, sDestno, sTimeTalkSec) VALUES ('$date', '$time', '$sline', '$sstn', '$stimetalk', '$sdestno', '$stimetalksec')");

$dbh2->do("INSERT INTO $table_name (sDateCall, sTimeCall, sLine, sStn, sTimeTalk, sDestno, sTimeTalkSec) VALUES ('$date', '$time', '$sline', '$sstn', '$stimetalk', '$sdestno', '$stimetalksec')");}

$result = "";}}

$dbh->disconnect();

$dbh2->disconnect();

undef $ob;

Приложение В

# Текст программы сбора тарификационной информации с УАТС NEAX

#!/usr/bin/perl -w

# Подключение модуля для работы с СУБД

use DBI;{

$OS_win = ($^O eq "MSWin32") ? 1 : 0;($OS_win) {"use Win32::SerialPort";}{"use Device::SerialPort"}}($OS_win) {

$port = 'COM2';

$ob = Win32::SerialPort->new ($port);

}{

$port = '/dev/ttyS0';

$ob = Device::SerialPort->new ($port);

} die "Can't open serial port $port: $^E\n" unless ($ob);

# Установление параметров работы с com-портом

$ob->baudrate(38400); # Скорость передачи данных через порт

$ob->parity("none"); # Наличие бита четности

$ob->databits(8); # Биты данных

$ob->stopbits(1); # Количество стоповых бит

$ob->handshake('none'); # Управление потоком

$ob->write_settings; # Применение настроек

# Подлючение к локальной и центральной базам данных

$dbi_user = 'root';

$dbi_password = '';

$dbi_database = 'nec';

$dbi_host = 'localhost';

$dbi_dsn = "DBI:mysql:database=$dbi_database;host=$dbi_host";

$dbi_host2 = '192.168.1.1';

$dbi_dsn2 = "DBI:mysql:database=$dbi_database;host=$dbi_host2";

$dbh = DBI->connect($dbi_dsn, $dbi_user, $dbi_password, { AutoCommit => 1, RaiseError => 1, PrintError => 1 });

$dbh2 = DBI->connect($dbi_dsn2, $dbi_user, $dbi_password, { AutoCommit => 1, RaiseError => 1, PrintError => 1 });

($month, $year) = (localtime)[4,5];

$table_name = sprintf ("s%02d%02d", $month + 1, $year + 1900);

# Запрос на создание таблицы

($sql_create_table) = "CREATE TABLE $table_name (sID INT(10) UNSIGNED DEFAULT '0' NOT NULL AUTO_INCREMENT,VARCHAR(6),VARCHAR(24),VARCHAR(10),VARCHAR(10),int(10) UNSIGNED,

# Если таблица с таким названием (название - текущий месяц) не существует, то ее создать

# в локальной и центральной базах данных

$sth = $dbh->prepare("show tables from $dbi_database like '$table_name';");

$sth->execute() or die $dbh->errstr;

$ex = "";

$ex = $sth->fetchrow_array();($ex ne $table_name) {

$dbh->do($sql_create_table);

$sth->execute() or die $dbh->errstr;};

$sth=$dbh2->prepare("show tables from $dbi_database like '$table_name';");

$sth->execute() or die $dbh2->errstr;

$ex="";

$ex=$sth->fetchrow_array();($ex ne $table_name) {

$dbh2->do($sql_create_table);

$sth->execute() or die $dbh2->errstr;};

$timestart = time();

$timeout = 2;

$result = "";

# Опрос com-порта в цикле (осуществляется до истечения тайм-аута)((time() - $timestart) < $timeout)

{

# Чтение одного байта информации из com-порта ($count - признак того, что данные

# из com-порта поступили, $active - данные, считанные из порта)

($count, $active) = $ob->read(1);

# Если данные поступили, то дописать их в переменную-накопитель и сбросить счетчик

# времени для тайм-аута($count)

{

$result .= $active;

$timestart = time();}

# Обработка информации

if ($result =~ m/B0!K.{64}/) # Если набралась полная строка данных

{

$ssrcno = substr($result, 12, 6); # Выделение номера вызывающего абонента

$sdestno = substr($result, 47, 26); # Выделение номера вызываемого абонента

$sstarttime = substr($result, 20, 10); # Выделение времени начала разговора

$sendtime = substr($result, 30, 10); # Выделение времени окончания разговора

# Расчет продолжительности разговора в секундах

$stimetalksec = ((substr($result, 32, 2) * 3600) + (substr($result, 34, 2) * 60) + substr($result, 36, 2)) - ((substr($result, 22, 2) * 3600) + (substr($result, 24, 2) * 60) + substr($result, 26, 2));

# Запись значений в базы данных

$dbh->do("INSERT INTO $table_name (nums, numd, starttime, endtime, timetalksec) VALUES ('$ssrcno', '$sdestno', '$sstarttime', '$sendtime', '$stimetalksec')");

$dbh2->do("INSERT INTO $table_name (nums, numd, starttime, endtime, timetalksec) VALUES ('$ssrcno', '$sdestno', '$sstarttime', '$sendtime', '$stimetalksec')");

$result = "";}}

$dbh->disconnect();

$dbh2->disconnect();

undef $ob;

Приложение Г

# Текст программы для построения графиков нагрузки на направление

#!/usr/bin/perl

# Подключение модулей для работы с СУБД и для построения графиков

use DBI;GD::Graph::lines;

# Инициализация переменных, в переменной $dsn записываются параметры

# подключенения к базе данных: тип СУБД - MySQL, название базы данных - ATS_01,

# адрес подключения к базе данных - localhost

my ($dsn)="DBI:mysql:ATS_01:localhost";($dbh,$sth);@data;

$count="0";

$start=1; # Первый день рассматриваемого периода

$finish=7; # Последний день рассматриваемого периода

$month='2003-03'; # Рассматриваемый месяц

$Title='s0305'; # Название таблицы в базе данных

$Lines='800'; # Номер направления

$interval=30;

$Nagruzka=25; # Пороговое значение нагрузки

# Подключение к базе данных

$dbh=DBI->connect($dsn,"","",{RaiseError=>1});

# Проверка наличия в базе данных временных таблиц end_01 и end_02, если таблицы

# существуют, то они удаляются

$sth=$dbh->prepare("show tables from ATS_01 like 'end_01';");

$sth->execute() or die $dbh->errstr;

$ex="";

$ex=$sth->fetchrow_array();($ex eq "end_01") {

$sth=$dbh->prepare("drop table end_01;");

$sth->execute() or die $dbh->errstr;};

$sth=$dbh->prepare("show tables from ATS_01 like 'end_02';");

$sth->execute() or die $dbh->errstr;

$ex="";

$ex=$sth->fetchrow_array();($ex eq "end_02") {

$sth=$dbh->prepare("drop table end_02;");

$sth->execute() or die $dbh->errstr;};

# Цикл по каждому дню рассматриваемого периода

for($j=$start;$j<=$finish;$j=$j+1){

# Формирование даты($j<10) {$date=($month)"-0".($j)}{$date=($month)"-".($j)};

# Создание временной таблицы для записей о звонках за определенный день

($sql_day)="CREATE TABLE end_01 SELECT * FROM $Title WHEREBETWEEN ' $date ' AND ' $date ' ";

$sth=$dbh->prepare($sql_day);

$sth->execute() or die $dbh->errstr;

# Создание временной таблицы для записей о звонках в определенном направлении

# В этой таблицы значения начала и конца разговора переведены в секунды

# относительно начала суток

($sql_day)="CREATE TABLE end_02 SELECT sLine, (TIME_TO_SEC(sTimeCall))'sTimeCallSec', (TIME_TO_SEC (sTimeCall) + TIME_TO_SEC (sTimeTalk)) AS

'sTimeEndSec' FROM end_01";

$sth=$dbh->prepare($sql_day);

$sth->execute() or die $dbh->errstr;

# Создание нового объекта "График"$mygraph=GD::Graph::lines->new(1000,500);

$mygraph->set(_label =>'Time',_label =>'Count',=>'800') or warn $mygraph->error;

# Цикл, в котором рассматриваются текущие сутки по заданному интервалу в

# секундах

for ($i="0";$i<86400;$i=$i+$interval){

# Запрос на определение количества записей в таблице end_02, которые

# попадают в рассматриваемый на данной итерации цикла интервал

($sql_count800)="SELECT COUNT(*) FROM end_02 WHERE

(($i>=sTimeCallSec) AND ($i<=sTimeEndSec))";

$sth=$dbh->prepare($sql_count300);

$sth->execute() or die $dbh->errstr;

$res=$sth->fetchrow_array();

$count=$res;

# Формирование данных для построения графика

$data[0][$i]="$i";

$data[1][$i]=int $count;        

# Формирование времени в формате "часы-минуты-секунды"

$h=int($i/3600);

$hour=$h;($h<10) {$hour='0'.$h};

$m=int(($i%3600)/60);

$min=$m;($m<10) {$min='0'.$m};

$s=int(($i%3600)%60);

$sec=$s;($s<10) {$sec='0'.$s};

# Если количество вызовов за данный интервал превышает пороговое

# значение, то об этом выводится сообщение

if ($count>=$Nagruzka) {print $Lines,"\t", $hour ,":",$min,":",$sec,"-",$count,"\n"};}

# Формирование графика и сохранение его в файл

my $myimage=$mygraph->plot(\@data) or die $mygraph->error;(PICTURE,">c:\\picture_800_$j.png") or die("Cannot open file for writing");PICTURE;PICTURE $myimage->png;(PICTURE);"\n", "\n";

# Удаление временных таблиц

($sql_drop)="DROP TABLE end_01";

$sth=$dbh->prepare($sql_drop);

$sth->execute() or die $dbh->errstr;

($sql_drop)="DROP TABLE end_02";

$sth=$dbh->prepare($sql_drop);

$sth->execute() or die $dbh->errstr;}

# Отключение от базы данных

$dbh->disconnect(); print "Finish"; exit(0);