Информационно-компьютерная система службы видеонаблюдения

Информационно-компьютерная система службы видеонаблюдения

Министерство образования и науки, молодежи и спорта Украины

Черниговский государственный технологический университет

Кафедра информационных и компьютерных систем

Квалификационная работа

Информационно-компьютерная система службы видеонаблюдения

Компьютерные системы и сети

Чернигов, 2011

Техническое задание

Тема работы: Информационно-компьютерная система службы видеонаблюдения.

Предполагаемые технические и эксплуатационные результаты работы:

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

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

Администратор должен иметь неограниченные права доступа для выполнения всего спектра действий по управлению структурой видеоархива, информацией о наблюдаемых объектах, пользователями. Менеджер архива имеет все права оператора, а также возможность по управлению служебной информацией о наблюдаемых объектах. Оператору система должна предоставлять возможность просмотра видеоархива, «on-line» просмотр с камер видеонаблюдения, поиск событий по личности, поиск событий по дате, поиск видеоархивов по дате, поиск видеоархивов по событиям, а также по перенаправлению видеотрансляции на мобильного клиента. Гостю система должна предоставлять возможность регистрации, также возможность просмотра страницы приветствия.

Проект локальной вычислительной сети (ЛВС) редакции журнала «Мой компьютер», включающий в себя информационный анализ, план прокладки коммуникаций и подбор оборудования. ЛВС содержит 64 компьютера, установленных в 13 отделах.

Локальная вычислительная сеть редакции журналам ой компьютер должна обеспечивать:

–       скорость передачи информации 100 и 1000 Мбит/сек;

–       беспроводной доступ к сетевым ресурсам;

–       сервис ip-телефонии;

–       безопасный доступ к Интернету для сотрудников редакции;

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

–       защиту от несанкционированного доступа на структурном уровне;

–       разделение сети на сегменты, используя VLAN.

Объем текстовой и графической документации

Работа объемом 100-130 с. формата А4, 10 листов формата А1 иллюстраций и чертежей.

Предполагаемая трудоемкость работы - 800 чел-часов.

Плановые сроки по этапам

Предзащита с полным представлением чистовых распечаток текстов и иллюстративного материала 24.05.2011.

Плановый срок защиты работы

Работа планируется к защите на заседании ГЭК 8.06.2011.

Руководитель работы и консультанты по разделам

Руководитель работы - к.т.н., доцент Зайцев С.В., консультант по аппаратной части - ст. преподаватель Хижняк А.В., консультант по охране труда - к.ф-м.н., доцент Никитенко Е.В.

Реферат

Объектом разработки является организация работы службы видеонаблюдения.

Целью квалификационной работы является создание информационно-компьютерной системы службы видеонаблюдения. Система предоставляет просмотр видеозаписей с архива, «on-line» трансляции, информацию о структуре предприятия, возможность редактирования информации о структуре предприятия, управление видеозаписями, одновременный просмотр и запись видео, поиск видеозаписей по различным критериям, возможность сохранения видеозаписей на съемный носитель, подключение пользователей с мобильных устройств. Данная система позволяет работать со следующими категориями пользователей: гость, оператор, менеджер архива, мобильный клиент и администратор.

Основным методом проектирования было нисходящее структурное проектирование с применением языка UML.

В ходе разработки:

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

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

-             разработана архитектура системы;

-             разработан веб-интерфейс для доступа пользователей к ИКС;

-             разработана подсистема захвата видео с камер наблюдения и ведения архива видеонаблюдения;

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

В аппаратной части дипломной работы разработан проект локальной вычислительной сети (ЛВС) редакции журнала «Мой компьютер», осуществлен подбор оборудования, а также проведено моделирование работы сети с помощью программы Packet Tracer.

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

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

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

ИКС, WEB, JAVA, Hibernate, JAX-WS, RICHFACES, JSF.

Реферат

Об'єктом розробки є організація роботи служби відеоспостереження. Метою кваліфікаційної роботи є створення інформаційно-комп'ютерної системи служби відеоспостереження. Система надає можливість перегляду відеозаписів з архіву, «on-line» трансляції, інформацію про структуру підприємства, можливість редагування інформації про структуру підприємства, управління відеозаписами, одночасний перегляд і запис відео, пошук відеозаписів за різними критеріями, можливість збереження відеозаписів на знімний носій, підключення користувачів з мобільних пристроїв. Дана система дозволяє працювати з наступними категоріями користувачів: гість, оператор, менеджер архіву, мобільний клієнт та адміністратор.

Основним методом проектування було низхідне структурне проектування з застосуванням мови UML.

У ході розробки:

−       проведено аналіз існуючих інформаційно-комп'ютерних систем відеоспостереження;

−       сформульовано вимоги до інформаційно-комп'ютерної системи служби відеоспостереження;

−       розроблена структура системи;

−       розроблено веб-інтерфейс для доступу користувачів до ІКС;

−       розроблено підсистему захвату відео з камер спостереження та ведення архіву відеоспостереження;

−       розроблена підсистема управління мобільними клієнтами.

В апаратній частині дипломної роботи розроблено проект локальної обчислювальної мережі (ЛОМ) редакції журналу «Мій комп`ютер», здійснений підбір обладнання, а також проведено моделювання роботи мережі з допомогою програми Packet Tracer.

Розроблену ІКС доцільно застосовувати для підприємств будь-якої потужності спільно з системою відеоспостереження та розпізнавання образів для зберігання та структурування відеоінформації, журналу подій розпізнавання образів, для автоматизації діяльності підприємства.

Подальший розвиток роботи можливий у бік доопрацювання системи контролю доступу на основі журналу подій.

Робота має практичну цінність. Розрахунок економічної ефективності не проводився.

ІКС, WEB, JAVA, Hibernate, JAX-WS, RICHFACES, JSF.

Abstract

The object of development is the organization of the service video.aim of qualifying work is to create an information computer system ofservice. The system provides a view video recordings from the archive, «on-line» events, information about the structure of the enterprise, the ability to edit information about the structure of enterprises, management of video, simultaneous viewing and recording video, search videos by various criteria, the ability to save video to removable media, the connection users with mobile devices. The system allows you to work with such categories of users: visitor, operator, manager of archive, mobile client and administrator.main method of design was downward structural design using language UML.development:

−       an analysis of existing information computer systems of surveillance systems;

−       formulate requirements for information computer system the surveillance service;

−       developed a system structure;

−       developed a web interface for user access to ICS;

−       subsystem designed to capture video from surveillance cameras and archivevideo;

−       developed a subsystem for managing mobile clients.the hardware part of the work developed a project local area network (LAN) of magazine redaction, selection of equipment, and simulated the network using Packet Tracer. ICS advisable to apply for enterprises of any power together with CCTV system and image recording for storing and structuring of video information and the magazine's recognition, for automation of the organization. development work is possible in the direction of refinement and access control based on event log.work has practical value. Calculation of economic efficiency was not calculated., WEB, JAVA, Hibernate, JAX-WS, RICHFACES, JSF.

Введение

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

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

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

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

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

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

1.1  Анализ предметной области

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

1.1.1  Описание основных задач ИКС службы видеонаблюдения

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

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

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

Основные области применения систем видеонаблюдения:

а)       охранное видеонаблюдение;

б)      городская система безопасности;

в)      видеоаналитика;

г)       видеоконтроль на подвижных обьектах;

д)      контроль дорожной обстановки;

е)       системы биометрии и распознавания человека;

ж)      системы распознавания образов;

з)       системы аудиорегистрации;

и)      систе6мы оповещения;

к)      безопасность и автоматизация аэропортов, торговли, банков.

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

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

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

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

а)       хранение видеозаписей;

б)      on-line видеонаблюдение;

в)      одновременный просмотр видео и запись;

г)       управление видеоархивом;

д)      политику ограничения доступа к видеоархиву;

е)       возможность сохранения видеоданных на внешний носитель;

ж)      удобный поиск видеозаписей.

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

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

1.1.2  Построение базовой модели предметной области

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

Рисунок 1.1 - Концептуальная модель предметной области

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

Таблица 1.1 - Описание сущности «Категория»

Название поля	Описание поля
Название	Название категории
Идентификатор	Идентификатор категории
Описание	Подробное описание категории

Сущность «Наблюдательный пункт» используется для хранения информации о наблюдательных пунктах. Сущность содержит поля IP адреса и подробное описание наблюдательного пункта. Описание сущности «Наблюдательный пункт» представлено в таблице 1.2.

Таблица 1.2 - Описание сущности «Наблюдательный пункт»

Название поляОписание поля
Идентификатор	Идентификатор наблюдательного пункта
Описание	Подробное описание наблюдательного пункта
IP адрес	Сетевой адрес наблюдательного пункта

Сущность «Часть записи» используется для хранения информации о части сохраненного видео потока. Сущность содержит поля размера файла, время и дату начала захвата, время и дату окончания захвата видеопотока и путь к файлу. Описание сущности «Часть записи» представлено в таблице 1.3.

Таблица 1.3 - Описание сущности «Часть записи»

Название поляОписание поля
Идентификатор	Идентификатор части записи
Время начала	Дата и время начала захвата видеопотока
Время окончания	Дата и время окончания захвата видеопотока
Размер файла	Размер сохраненного видео файла
Адрес файла	Адрес сохраненного файла

Сущность «Сотрудник» используется для хранения информации о сотрудниках предприятия. Содержит поля имени, отчества, фамилии, даты рождения, должность, адрес проживания. Описание сущности «Сотрудник» представлено в таблице 1.4.

Таблица 1.4 - Описание сущности «Сотрудник»

Название поля	Описание поля
Идентификатор	Идентификатор сотрудника
Имя	Имя сотрудника
Фамилия	Фамилия сотрудника
Отчество	Отчество сотрудника
Адрес проживания	Адрес проживания сотрудника
Дата рождения	Дата рождения сотрудника
Должность	Занимаемая должность
Адрес электронной почты	Адрес электронной почты сотрудника

Сущность «Атрибут» используется для хранения атрибутов описывающих категории и пункты наблюдения. Содержит поля названия атрибута, значения атрибута. Описание сущности «Атрибут» представлено в таблице 1.5.

Таблица 1.5 - Описание сущности «Атрибут»

Название поля	Описание поля
Идентификатор	Идентификатор атрибута
Название	Название атрибута
Значение	Значение атрибута

Сущность «Тип атрибута» используется для хранения информации о типе атрибута. Содержит поля названия типа и сам тип атрибута. Данная информация необходима для правильной интерпретации значения атрибута. Описание сущности «Тип атрибута» представлено в таблице 1.6.

Таблица 1.6 - Описание сущности «Тип атрибута»

Название поляОписание поля
Идентификатор	Идентификатор типа атрибута
Тип данных	Тип интерпретируемых данных
Название	Название типа атрибута

Сущность «Событие распознавания личности» используется для хранения информации о событиях распознавания образов. Содержит поля времени и даты фиксации сотрудника на определенной камере. Описание сущности «Событие распознавания личности» представлено в таблице 1.7.

Таблица 1.7 - Описание сущности «Событие распознавания личности»

Название поляОписание поля
Идентификатор	Идентификатор события
Время	Дата и время распознавания сотрудника на определенной камере

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

Таблица 1.8 - Описание сущности «Параметр настройки кодека»

Название поляОписание поля
Идентификатор	Идентификатор параметра кодека
Название	Название параметра
Значение	Значение параметра

.2 Анализ существующих решений

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

1.2.1 Программное обеспечение видеонаблюдения TRASSIR

Программное обеспечение видеонаблюдения TRASSIR обеспечивает работу с IP видеокамерами и IP видеосерверами Lancam и Lanser, а так же оборудованием сторонних производителей. Разработчиком данного программного обеспечения является компания DSSL. Это программное обеспечение обеспечивает работу с IP-видеоустройствами производства как DSSL, так и других производителей. Список поддерживаемых марок и устройств включает наиболее популярные, такие как Axis, D-Link, ACTi, Vivotek, Hikvision и множество других.

Программное обеспечение TRASSIR владеет набором специализированных интеллектуальных функций. Программа видеонаблюдения TRASSIR может поставляться с дополнительными расширенными возможностями. Распознавание номеров транспортных средств AutoTRASSIR обладает мощным функционалом, не требует настроек и имеет высокую производительность. ActiveDome -функция управления поворотными камерами SpeedDome. Ускоряет работу оператора, позволяет контролировать множество поворотных камер. В сочетании с SIMT - объектным детектором нового поколения, дает возможность автоматического сопровождения целей скоростными поворотными камерами SpeedDome. Видео регистратор, оснащенный детектором SIMT, имеет возможность событийного анализа видеозаписей. Данный функционал может работать на IP видеокамерах и IP видеосерверах Axis.

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

Программное обеспечение TRASSIR имеет возможность записи многоканального видео. В зависимости от мощности используемого видеорегистратора, выполняющего роль видеоархива, с программным обеспечением видеонаблюдения TRASSIR поддерживается запись до 128-ми каналов видео разрешения D1 (полный кадр) и в реальном времени 25 кадров в секунду каждый канал. Видеорегистраторы с программой видеонаблюдения TRASSIR позволяют одновременно с записью осуществлять просмотр «живого» видео, воспроизведение видео из архива, передачу в сеть большому числу потребителей. Так же, все другие операции по настройке не прерывают записи. Для записи большого числа каналов программное обеспечение использует технологию MultiStor, равномерно распределяющую записи по всем подключенным дискам. Также данная технология увеличивает надежность сохранения записей при использовании всего объема дисков, так как при выходе из строя одного из дисков, будет потеряна только часть информации, в отличии, например, от технологии RAID0 или JBOD. Распределение записи по всем доступным дискам снижает нагрузку на каждый диск в отдельности и не позволяет третировать запись при воспроизведении или копировании данных с какого-либо из дисков.

Данная система имеет высокую степень масштабируемости. Легко расширяема. Один видеорегистратор на базе TRASSIR может записывать до 128 каналов видео (25 Fps D1 на канал). Программное обеспечение TRASSIR позволяет объединить несколько видеорегистраторов TRASSIR в единый комплекс, что дает возможность построить систему на большое количество каналов.

Программное обеспечение TRASSIR поддерживает детектирование движения. Помимо детекторов движения, строенных в IP видеокамеры и IP видеосерверы, возможно использование других детекторов поставляемых с программой видеонаблюдения TRASSIR. Например, GenericDetector, который имеет функцию детектирования лиц в поле зрения видеокамер и может детектировать медленное и быстрое движение. Опционально возможно приобретение мощного и многофункционального детектора (детектор видеоаналитики) SIMT <#"598901.files/image002.gif">

Рисунок 1.3 - Схема интеграции систем

Система имеет возможность ретрансляции видео по сети. Помимо того, что программное обеспечение для IP видеонаблюдения TRASSIR получает данные с IP видеокамер и серверов, поддерживается дальнейшая ретрансляция этих потоков. Это позволяет обойти ограничения на количество подключений к IP видеокамерам - клиенты ПО TRASSIR бесплатны и компьютер выдерживает в сотни раз больше подключений, чем само IP устройство. Или, можно использовать программу видеонаблюдения TRASSIR, как шлюз. Чтобы не перегружать канал, по которому передается видео с IP видеокамеры (например, это может быть xDSL, GPRS или что-то иное) несколькими соединениями.

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

-   просмотр живого видео;

-       видеонаблюдение через интернет (онлайн);

-       управление архивными записями;

-       тонкая настройка приложения;

-       подключение к другим видеорегистраторам TRASSIR;

-       просмотр видеоархивов;

-       управление настройками и телеметрией PTZ.

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

Программное обеспечение TRASSIR поддерживает событийную модель поведения. Любое событие, помимо регистрации в журнале, может быть использовано для программирования реакции. Например, ПО TRASSIR может отправить SMS или Email сообщение по срабатыванию детектора движения. Или поворотная видеокамера может быть предустановлена в сохраненную позицию по событию с другой видеокамеры.

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

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

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

1.2.2 Программное обеспечение видеонаблюдения NMS

NMS - NOVUS MANAGEMENT SYSTEM является профессиональным решением для построения системы видеонаблюдения на базе сети TCP/IP в режиме CLIENT-SERVER.

Широкий ряд конфигураций и настроек видеопотоков сервера NMS позволяет создать комплексную систему мониторинга с несколькими локализациями (пунктами) наблюдения и регистрации видео с персональными операторскими рабочими местами. Удобный конфигурируемый интерфейс пользователя и режим работы с несколькими мониторами. Клиентское программное обеспечение позволяет опубликовывать онлайн видео в сети.

Функции программного обеспечения NMS:

-   программное обеспечение для удалённого соединения с сервером NMS в режиме «живого» просмотра

-       одновременный просмотр до 128 видеопотоков в двух отдельных окнах

-       воспроизведение потоков RTSP с сервера NMS или непосредственно с IP камеры на сайте либо при помощи программы-проигрывателя

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

-       использование приложения для работы с несколькими мониторами

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

-   полнофункциональное обслуживание оборудования, управляемого по протоколам Novus-C, Novus-C1, Novus-C2 и Pelco-D при помощи панели PTZ или мыши

-       запись аудио и „real-time” - прослушивание для каждого канала видео

-       новый алгоритм быстрого конвертирования в файлы mpeg4

-       управление доступом пользователей к системе

-       удобная и простая работа с закладками (картами)

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

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

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

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

На рисунке 1.4 показан пользовательский интерфейс предоставляемый программным обеспечением NMS - NOVUS MANAGEMENT SYSTEM.

Рисунок 1.4 - Пользовательский интерфейс

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

.2.3 Программное обеспечение видеонаблюдения VOCORD Phobos Video

Аппаратно-программный комплекс VOCORD Phobos Video предназначен для построения высокопроизводительных многоканальных цифровых систем видеонаблюдения <#"598901.files/image004.gif">

Рисунок 1.5 - Схема масштабируемой системы

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

Система имеет «клиент/серверную» архитектуру, благодаря чему возможно подключение практически неограниченного числа удаленных рабочих мест.

На рисунке 1.6 представлен интерфейс системы видеонаблюдения для пользователя.

Рисунок 1.6 - Интерфейс программы системы видеонаблюдения VOCORD Phobos Video

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

Что касается архива системы VOCORD Phobos, помимо оперативного архива на жестких дисках (постоянных носителях) станции записи, в системе предусмотрена функция репликации записей на внешние (сменные) носители для резервирования и долговременного хранения. Для создания подобного архива используются устройства записи на носители большой емкости (магнитооптический дисковод, CD, DVD и др.). Репликация на сменные носители может производиться как выборочно по команде оператора, так и автоматически по расписанию.

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

1.2.4 Сравнение характеристик существующих ИКС

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

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

Таблица 1.9 - Сравнительная таблица параметров рассмотренных систем видеонаблюдения

Параметры	Название
	Программное обеспечение видеонаблюдения TRASSIR	Программное обеспечение видеонаблюдения NMS	Программное обеспечение видеонаблюдения VOCORD Phobos Video
Тип интерфейса	«Толстый» клиент + «Тонкий» клиент	«Толстый» клиент	«Тонкий» клиент
Управление доступом пользователей к системе	Создание "ролей" доступа для групп пользователей	+	+
Работа с IP видеокамерами	+	+	+
Просмотр «on-line» видео	+	+	+
Детектирование движений	+	-	+
Интеграция с охранно-пожарной сигнализацией	+	-	-
Управление архивными записями	+	+	+
Управление поворотными камерами	+	+	-
Управление структурой архива	-	-	-
Поддержка LDAP	-	-	-
Ведение журнала событий распознавания образов	+	-	-
Отправка SMS или Email по событию	+	-	-

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

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

.3 Постановка задачи на разработку системы

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

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

1.3.1 Определение общих требований к разрабатываемой системе

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

Система должна обеспечивать безопасность данных путем разграничения доступа пользователей к сервисам системы. Для этого ИКС должна работать со следующими категориями пользователей: Администратор, Менеджер видеоархива, оператор, мобильный клиент и Гость.

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

Для администратора система должна предоставлять возможность управления пользователями: просмотр, добавление, удаление администраторов и менеджеров, просмотр и удаление пользователей, управление их правами. Также система должна предоставлять возможность управления структурой видеоархива таким образом, чтобы максимально приблизить её к бизнес-структуре предприятия, а также хранение служебной информации о наблюдаемых объектах. Система должна обеспечивать управление видеозаписями, «on-line» трансляциями, журналом событий, управление набором захватываемых потоков видеоданных.

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

Оператору система должна предоставлять возможность просмотра видеоархива, «on-line» просмотр с камер видеонаблюдения, поиск событий по личности, поиск событий по дате, поиск видеоархивов по дате, поиск видеоархивов по событиям, перенаправление потокового видео с камер на мобильного пользователя.

Мобильному пользователю система должна предоставлять возможность просмотра онлайн трансляции.

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

1.3.2 Определение требований к архитектуре системы

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

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

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

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

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

1.3.3 Определение требований к графическому интерфейсу

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

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

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

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

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

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

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

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

Пользовательский интерфейс должен соответствовать стандарту XHTML 1.0. XHTML - это основанный на XML язык разметки гипертекста, максимально приближенный к текущим стандартам HTML. XHTML отличается от HTML строгостью написания кода. Если HTML позволял писать практически любые конструкции и браузер их корректно распознавал, то теперь, с появлением XHTML, это стало невозможным. Последний требует строгого соблюдения всех правил, предъявляемых W3C. Строгие требования к оформлению XHTML-кода позволяют избежать многих ошибок на стадии написания и отладки.

Также пользовательский интерфейс должен соответствовать стандарту CSS консорциума W3C. На данный момент существует вторая и третья версия, однако они не полностью поддерживается некоторыми браузерами. Наиболее полно стандарт CSS поддерживается многими (даже старыми) пользовательскими агентами только версии 1.0. Следовательно, разрабатываемый интерфейс пользователя должен соответствовать CSS 1.0.

.3.4 Определение требований к безопасности системы

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

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

На данный момент наиболее популярной операционной системой для мобильных устройств является Android OS. Данная платформа предоставляет широкие возможности, как для пользователей системы, так и для разработчиков. Данная ОС хорошо документирована, а также имеется большой набор учебных материалов. Таким образом, ИКС службы видеонаблюдения должна быть ориентированной на данную операционную систему и обеспечить взаимодействие с мобильными устройствами под операционной системой Android.

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

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

2. Разработка ИКС службы видеонаблюдения

2.1 Определение и описание ролей пользователей ИКС службы видеонаблюдения

В результате анализа ИКС службы видеонаблюдения были выделены внешние сущности (актеры), с которыми взаимодействует проектируемая система, и сервисы, которые данная система предоставляет актерам.

В системе были выделены следующие актеры:

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

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

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

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

-       «Мобильный клиент» - авторизованный пользователь системы, которому доступен только просмотр онлайн трансляции, которую на него перенаправил оператор.

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

Рисунок 2.1 - Диаграмма наследования вариантов использования системы

2.1.2 Варианты использования системы для сущности «Гость»

Диаграмма вариантов использования для актера «Гость» системы представлена на рисунке 2.2.

Рисунок 2.2 - Диаграмма вариантов использования для актера «Гость»

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

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

Просмотреть страницу приветствия. Пользователю предоставляется информация о компании, спектре её услуг.

.1.3 Варианты использования системы для сущности «Оператор»

Диаграмма вариантов использования для актера «Оператор» системы представлена на рисунке 2.3.

Рисунок 2.3 - Диаграмма вариантов использования для актера «Оператор»

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

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

Просмотр видеоархива. Данная возможность позволяет выбрать интересующие видео файлы по дате и просмотреть их.

«On-line» просмотр с камер видеонаблюдения. Позволяет получить список активных камер видеонаблюдения и просмотреть видеотрансляцию в режиме «On-line».

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

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

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

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

Поиск видеозаписей по камере наблюдения. Позволяет получить список видеофайлов по определенной камере наблюдения.

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

2.1.4 Варианты использования системы для сущности «Менеджер видеоархива»

Диаграмма вариантов использования для актера «Менеджер» системы представлена на рисунке 2.4.

Рисунок 2.4 - Диаграмма вариантов использования для актера «Менеджер»

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

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

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

Выполнение CRUD операций над сущностями «Part» представляющими файл видеоархива.

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

.1.5 Варианты использования системы для сущности «Администратор»

Диаграмма вариантов использования для актера «Администратор» системы представлена на рисунке 2.5.

Рисунок 2.5 - Диаграмма вариантов использования для актера «Администратор»

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

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

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

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

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

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

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

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

2.1.6 Варианты использования системы для сущности «Мобильный клиент»

Диаграмма вариантов использования для актера «Мобильный клиент» представлена на рисунке 2.6.

Рисунок 2.6 - Диаграмма вариантов использования для актера «Мобильный клиент»

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

.2 Выбор технологий и инструментальных средств разработки

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

.2.1 Выбор языка реализации

Существуют клиентские и серверные языки web-программирования. Клиентские языки используются для написания программ, выполняемых на стороне клиента (браузер), а серверные - для программ, выполняемых на сервере.

Среди клиентских языков программирования стоит выделить JavaScript, которые, также как и HTML, лежит в основе многих веб-технологий.

Другие популярные клиентские языки, а точнее фреймворки - это Adobe Flash (язык Action Script) и Silver Light (любые .NET языки). Adobe Flash применяется веб-мастерами довольно долгое время. Основное применение этой технологии - интерактивные сайты и сервисы, онлайновые игры, мультимедийный контент, реклама. Silver Light - это новая технология, разработанная компанией Microsoft и позиционируемая как замена Adobe Flash. Не смотря на то, что с помощью Adobe Flash и Silver Light можно построить полностью весь сайт, этого делать не следует, потому, что современные поисковые системы не могут индексировать ни Adobe Flash ни Silver Light.

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

Если говорить про ОС Windows, то здесь лучше всего и быстрее всего работает технология ASP .NET, разработанная компанией Microsoft. С помощью ASP .NET можно создавать сайты любого уровня сложности - от самых простых, состоящих из нескольких страниц, до очень сложных, обрабатывающих миллионы запросов в день. Сайты Microsoft, написанные на ASP .NET, являются одними из самых посещаемых в Интернет. Здесь основным языком веб-программирования служит C#. Основной недостаток этой технологии - меньшее, по сравнению с Unix, количество дешевых хостингов и необходимость покупки серверной лицензии, в случае с выделенным хостингом.

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

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

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

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

.2.2 Среды разработки IDE

Для проектирования программных комплексов необходимо наличие интегрированной среды(IDE). На данный момент существует широкий выбор средств для разработки программ. Для решения поставленных целей определенных в техническом задании были выбрана такая среда разработки как Eclipse. является полноценной Java IDE, нацеленной на групповую разработку: среда интегрирована с системами управления версиями -CVS в основной поставке, для других систем (например, Subversion, MS SourceSafe) существуют плагины. В силу бесплатности и высокого качества, Eclipse во многих организациях является корпоративным стандартом для разработки приложений. Также Eclipse включает поддержку технологии JAX-WS и позволяет разрабатывать приложения для медиа флэш сервера Red5.

Основной причиной выбора данной среды разработки является её бесплатность, качество и наличие поддержки флэш серверов Red5, а также поддержка всех основных технологий применяемых при разработке данной системы, а именно: JPA, JSF и JAX-WS.

.2.3 Серверы и контейнер сервлетов

Для выполнения приложений необходимо наличие сервера, выполняющего их. При выборе сервера приложений необходимо, что бы он реализовывал эффективное исполнение процедур (программ, механических операций, скриптов) которые поддерживают построение приложений. Также необходимо, чтобы сервер приложений действовал как набор компонент доступных разработчику программного обеспечения через API (интерфейс прикладного программирования) определенный самой платформой. В качестве сервера приложений был выбран следующий продукт от Apache:- программа-контейнер сервлетов, написанная на языке Java и реализующая спецификацию сервлетов и спецификацию Java Server Pages (JSP), которые являются стандартами для разработки веб-приложений на языке Java. Tomcat позволяет запускать веб-приложения, содержит ряд программ для автоконфигурирования. Tomcat используется в качестве самостоятельного веб-сервера, в качестве сервера контента в сочетании с веб-сервером Apache HTTP Server.

Для публикации видеопотоков необходим флэш медиа сервер. Который будет играть роль контейнера медиа приложений. В качестве контейнера медиа приложений был выбран Red5 Media Server.

Red5 Media Server - это RTMP <#"598901.files/image012.gif">

Рисунок 2.7 - Общая архитектура ИКС службы видеонаблюдения

.4 Разработка структуры системы

В результате разработки архитектуры системы было выделено четыре основных программных подсистемы: подсистема отображения «Video Portal», подсистема «Media Server», подсистема «Media Gateway» и подсистема мобильного клиента «Mobile Client». Каждая подсистема взаимодействует между собой с помощью протокола SOAP, так как данный протокол является де-факто при реализации взаимодействия между основной логикой и подсистемой отображения. Применение данного стандарта позволит минимизировать зависимости между подсистемами и интегрировать данную систему с другими. Общая структура системы представлена на рисунке 2.8. Далее рассматривается внутренняя структура каждой подсистемы.

Рисунок 2.8 - Общая структура системы

.4.1 Подсистема публикации потоков «Media Gateway»

Данная подсистема играет роль централизованной точки доступа к видеопотокам. Так как доступ к видеопотокам должен осуществляться с нескольких точек одновременно, а именно с «Media Server», «Video Portal» и «Mobile Client», появляется необходимость выделения системы, осуществляющую широковещательную публикацию видеопотока.

На рисунке 2.9 показана структура подсистемы «Media Gateway».

Рисунок 2.9 - Структура подсистемы «Media Gateway»

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

Компонент «Хранилище конфигурации» играет роль хранилища конфигурационных данных подсистемы «Media Gateway». Инициализируется при старте приложения.

Компонент «Обработчик подключений» выполняет функцию обработчика событий со стороны клиентов подсистемы. Обрабатывает события подключения клиентов, отключения, запросов на получение потока или публикацию потока.

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

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

Компонент «Поток преобразования видеоданных» является отдельным потоком, выполняющимся параллельно по отношению к основной программе. В системе будет создан набор экземпляров данного компонента, по одному на каждый обрабатываемый поток. Данный компонент и является механизмом, обрабатывающим потоки от IP камер.

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

.4.2 Подсистема записи и хранения видеоархива «Media Server»

Данная подсистема играет роль хранилища видеофайлов и информации о предприятии, осуществляет захват потоков публикуемых подсистемой «Media Gateway». Данная подсистема является централизированным хранилищем информации о предприятии, работниках, структуре предприятия, журнале событий и предоставляет сервисы для работы с информацией. На рисунке 2.10 представлена структура подсистемы «Media Server».

Рисунок 2.10 - Структура подсистемы «Media Server»

Компонент захвата видеопотока выполняет функцию подключения к подсистеме «Media Gateway», захвата видеопотока. Для записи видеоинформации в файл использует компонент декодирования и записи в архив.

Компонент доступа к БД компонент предоставляет доступ к хранилищу информации о инфраструктуре предприятия.

Компонент «Хранилище информации об инфраструктуре предприятия» является хранилищем основных сущностей системы.

Компонент «Хранилище видеоданных» играет роль хранилища видеоархива, записанного с видеокамер предприятия.

Компонент декодирования потока и записи в архив выполняет функцию преобразования видеопотока в формат, который можно сохранить в файл. Взаимодействует с компонентом доступа к БД, так как необходимо вести учет сохраненных видеофайлов, и с компонентом «Хранилище видеоданных» куда и сохраняются видеофайлы.

Компонент «Хранилище видеоданных» обеспечивает хранение видеофайлов, представляющих сохраненный поток.

Компонент «Публикация видеофайлов и потоков» выполняет функцию публикации видеофайлов из архива, данная функция используется подсистемой «Video portal». Также предоставляет данные об активных потоках для внешних подсистем, таких как «Video portal» и «Mobile Client».

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

Компонент регистрации активных мобильных клиентов необходим для оповещения подсистемы «Media Server» обо всех активных на данный момент мобильных клиентах.

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

.4.3 Подсистема отображения «Video portal»

Основной задачей данной подсистемы является взаимодействие с пользователем, отображение видеоинформации с архива и в реальном режиме времени с IP камер. Данная подсистема предоставляет пользователю графический интерфейс, через который пользователь производит взаимодействие с системой. Данная подсистема взаимодействует с подсистемой «Media Server» через веб-сервисы по средствам протокола SOAP. С помощь данного вида взаимодействия минимизируются зависимости между основной логикой системы и отображением. Это позволяет при необходимости использовать различные реализации отображения, а также производить интеграцию с другими системами. На рисунке 2.11 представлена структура подсистемы отображения.

Рисунок 2.11 - Структура подсистемы отображения

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

Компонент приема потокового видео необходим для подключения к подсистеме «Media Gateway» и приема опубликованного видеопотока.

Компонент приема видео с архива необходим для подключения к подсистеме «Media Server» и скачивания видеофайлов с видеоархива.

Компонент взаимодействия с Media Server является связующим звеном с подсистемой «Media Server».

.4.4 Подсистема «Mobile Client»

Основной задачей данной подсистемы является взаимодействие с мобильным клиентом. Подсистема позволяет захватывать видеопоток публикуемый подсистемой «Media Gateway» и показывает его пользователю. На рисунке 2.12 показана структура подсистемы «Mobile Client».

Рисунок 2.12 - Структура подсистемы «Mobile Client»

Компонент приема потокового видео необходим для подключения к подсистеме «Media Gateway» и приема опубликованного видеопотока.

Компонент взаимодействия с Media Server является связующим звеном с подсистемой «Media Server».

.4.5 Разработка взаимодействия подсистем

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

Для передачи потокового видео между подсистемами используется протокол RTMP. Причиной выбора данного протокола является наличие готовой свободной реализации сервера медиа-приложений Red5, который полностью поддерживает и ориентирован на данный протокол. А также, наличие свободно распространяемого фреймворка Xuggler framework, который позволяет обрабатывать взаимодействовать с протоколом RTMP.

.6 Разработка классов сущностей системы

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

Рисунок 2.13 - Диаграмма классов основных сущностей системы

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

id - код категории

name - название категории

topCategory - ссылка на родительскую категорию

subCategories - ссылка на коллекцию подчиненных категорий

listAttributes - ссылка на коллекцию атрибутов

checkpost - ссылка на наблюдательный пункт

description - описание категории

listEmployee - ссылка на список сотрудников

Листинг 2.1- Листинг класса сущности «Категория»

@Entity

@Table(name = "CATEGORIES")

@NamedQueries({

@NamedQuery(name = "Category.getAll", query = "select c from Category c")

})

public class Category implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String description;

private String name;

@ManyToOne(fetch = FetchType.EAGER)

private Category topCategory;

@OneToMany(fetch = FetchType.LAZY)

private List<Category> subCategories;

@OneToMany(fetch = FetchType.EAGER)

private List<Attribute> listAttributes;

@OneToMany(fetch = FetchType.EAGER)

private List<Checkpost> listCheckposts;

@OneToMany(fetch = FetchType.LAZY)

private List<Employee> listEmployee;

…

}

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

id - код атрибута

name - название атрибута

value - значение атрибута

type - ссылка на тип атрибута

category - ссылка на категорию

checkpost - ссылка на наблюдательный пункт

Листинг 2.2 - Листинг класса сущности «Атрибут»

@Entity

@Table(name = "ATTRIBUTES")

@NamedQueries({

@NamedQuery(name = "Attribute.getByCategoryId", query = "select a from Attribute a where a.category.id = :id"),

@NamedQuery(name = "Attribute.getByCheckpostId", query = "select a from Attribute a where a.checkpost.id = :id")

})

public class Attribute implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String name;

private String value;

@ManyToOne(fetch = FetchType.EAGER)

private AttrType type;

@ManyToOne(fetch = FetchType.LAZY)

private Category category;

@ManyToOne(fetch = FetchType.LAZY)

private Checkpost checkpost;

…

}

Класс AttrType используется для хранения информации о типе атрибута. Содержит поля названия типа и сам тип атрибута. Данная информация необходима для правильной интерпретации значения атрибута. Текст класса приведен в листинге 2.3.

id - код типа

title - название типа

dataType - тип данных

listAttributes - ссылка на коллекцию атрибутов

Листинг 2.3 - Листинг класса сущности «Тип атрибута»

@Entity

@Table(name = "ATTR_TYPES")

@NamedQueries({

@NamedQuery(name = "AttrType.getByTitle", query = "select at from AttrType at where at.title = :title")

})

public class AttrType implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String title;

private String dataType;

@OneToMany(fetch = FetchType.LAZY)

private List<Attribute> listAttributes;

…

}

Класс Checkpost используется для хранения информации о наблюдательных пунктах. Класс содержит поля IP адреса, описания, ссылку на категорию, ссылку на коллекцию атрибутов, описывающих более подробно наблюдательный пункт и ссылку на коллекцию SDP атрибутов, которые представляют настройки кодека для захвата и ретрансляции RTP потока. Текст класса представлен в листинге 2.4.

id - код наблюдательного пункта

ip - IP адрес наблюдательного пункта

description - описание наблюдательного пункта

listSDPAttributes - ссылка на коллекцию SDP атрибутов

topCategory - ссылка на категорию

listAttributes - ссылка на коллекцию атрибутов

listFixations - ссылка на коллекцию событий распознавания образов

listParts - ссылка на коллекцию частей сохраненного потока

Листинг 2.4 - Листинг класса сущности «Наблюдательный пункт»

@Entity

@Table(name = "CHECKPOSTS")

@NamedQueries({

@NamedQuery(name = "Checkpost.getByCategoryId", query = "select ch from Checkpost ch where ch.topCategory.id = :id")

})

public class Checkpost implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String ip;

private String description;

@OneToMany(fetch = FetchType.EAGER)

private List<SDPAttribute> listSDPAttributes;

@ManyToOne(fetch = FetchType.EAGER)

private Category topCategory;

@OneToMany(fetch = FetchType.EAGER)

private List<Attribute> listAttributes;

@OneToMany(fetch = FetchType.LAZY)

private List<Fixation> listFixations;

@OneToMany(fetch = FetchType.LAZY)

private List<Part> listParts;

…

}

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

- id - код сотрудника

name - имя сотрудника

surname - фамилия

patronymic - отчество

email - адрес электронной почты

birthday - дата рождения

post - должность

address - адрес проживания

listFixations - ссылка на коллекцию фиксаций данного сотрудника

category - ссылка на категорию

Листинг 2.5 - Листинг класса сущности «Сотрудник»

@Entity

@Table(name= "EMPLOYEE")

@NamedQueries({

@NamedQuery(name = "Employee.getByCategoryId", query = "select e from Employee e where e.category.id = :id"),

@NamedQuery(name = "Employee.getAll", query = "select e from Employee e")

})

public class Employee implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String name;

private String surname;

private String patronymic;

private String email;

@Temporal(TemporalType.DATE)

private Calendar birthday;

private String post;

private String address;

@OneToMany(fetch = FetchType.LAZY)

private List<Fixation> listFixations;

@ManyToOne(fetch = FetchType.EAGER)

private Category category;

…

}

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

id - код записи о фиксировании

time - время и дата фиксации

employee - ссылка на зафиксированного сотрудника

checkpost - ссылка на наблюдательный пункт

Листинг 2.6 - Листинг класса сущности «Фиксация»

@Entity

@Table(name = "FIXATIONS")

@NamedQueries({

@NamedQuery(name = "Fixation.searchByTimeRange", query = "select f from Fixation f where f.time >= :start AND f.time <= :end"),

@NamedQuery(name = "Fixation.getByCheckpostId", query = "select f from Fixation f where f.checkpost.id = :id"),

@NamedQuery(name = "Fixation.getByEmployeeId", query = "select f from Fixation f where f.employee.id = :id")

})

public class Fixation implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

@Temporal(TemporalType.TIMESTAMP)

private Calendar time;

@ManyToOne(fetch = FetchType.EAGER)

private Employee employee;

@ManyToOne(fetch = FetchType.EAGER)

private Checkpost checkpost;

…

}

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

- id - код записи

file - путь к видеофайлу

length - размер файла

dateTo - дата и время окончания записи потока

dateFrom - дата и время начала записи потока

checkpost - ссылка на наблюдательный пункт

Листинг 2.7 - Листинг класса сущности «Часть записи»

@Entity

@Table(name = "PARTS")

@NamedQueries({

@NamedQuery(name = "Part.getByTime", query = "select p from Part p where p.dateFrom <= :time AND p.dateTo >= :time"),

@NamedQuery(name = "Part.getByTimeRange", query = "select p from Part p where :start BETWEEN p.dateFrom AND p.dateTo OR " +

                             ":end BETWEEN p.dateFrom AND p.dateTo OR " +

                             "p.dateFrom BETWEEN :start AND :end OR " +

                             "p.dateTo BETWEEN :start AND :end")

})

public class Part implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String file;

private Long length;

@Temporal(TemporalType.TIMESTAMP)

private Calendar dateTo;

@Temporal(TemporalType.TIMESTAMP)

private Calendar dateFrom;

@ManyToOne(fetch = FetchType.LAZY)

private Checkpost checkpost;

…

}

Класс SDPAttribute используется для хранения информации, которая представляет собой параметры конфигурации для преобразования RTP потоков в RTMP. Данная информация необходима FFMPEG кодеку. Содержит поля названия атрибута и значения. Текст класса приведен в листинге 2.8.

name - название атрибута

value - значение атрибута

checkpost - ссылка на наблюдательный пункт

Листинг 2.8 - Листинг класса сущности «SDP атрибут»

@Entity

@NamedQueries({

@NamedQuery(name = "SDPAttribute.getByCheckpostId", query = "select s from SDPAttribute s where s.checkpost.id = :id")

})

public class SDPAttribute implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@GeneratedValue

private Long id;

private String name;

private String value;

@ManyToOne(fetch = FetchType.LAZY)

private Checkpost checkpost;

…

}

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

Рисунок 2.14 - Реляционная схема базы данных

2.7 Проектирование диаграмм деятельности ИКС службы видеонаблюдения

Диаграммы деятельности для системы архива видеонаблюдения представляют собой схему поведения системы при реакции на различные события. Необходимо рассмотреть диаграмму деятельности при старте приложения и начальной инициализации подсистем «Media Server» и «Media Gateway». Начальное конфигурирование подсистемы «Media Gateway» представляет собой запрос и загрузку конфигурационных данных с центральной подсистемы «Media Server». Конфигурационные данные содержат в себе параметры публикации поток во внутреннюю среду системы. Конфигурация будет сохранена до перезагрузки приложения, после перезагрузки операция начальной инициализации повториться снова. Диаграмма активности, описывающая основные аспекты поведения системы при инициализации показана на рисунке 2.15.

При старте подсистемы «Media Gateway» происходит вычитывание конфигурации подсистемы из конфигурационного файла, далее формируется запрос к подсистеме «Media Server». Производится отправка запроса к удаленной подсистеме и прием ответа. В случае неудачного выполнения запроса процесс останавливается на некоторый промежуток времени и снова повторяется до момента приема корректных данных. Далее производится сохранение конфигурации, после чего начинается проход по всем конфигурационным данным, для каждого сконфигурированного потока отправляется уведомление удаленной подсистеме о публикации нового потока. По окончанию прохода по всем конфигурационным данным процесс завершается.

Рассмотрена диаграмма активности при подключении клиента к видеопотоку, диаграмма описывает процесс, выполняющийся в контексте подсистемы «Media Gateway». Для экономии ресурсов подсистемы «Media Gateway», потоки к которым не подключено ни одного клиента закрываются, а публикация потока инициируется при подключении клиента. Следует отметить, что при подключении клиента производится проверка логина и пароля, а также прав доступа. На рисунке 2.16 показана диаграмма активности при подключении клиента к видеопотоку.

Рассмотрена диаграмма активности при оповещении подсистемы «Media Server» о публикации нового потока. При получении оповещения о публикации нового потока подсистема «Media Server» должна произвести подключение к видеопотоку и начать запись потока в файл. Диаграмма активности при оповещении о публикации нового потока показана на рисунке 2.17.

Рисунок 2.15 - Диаграмма активности для начальной инициализации системы

Рисунок 2.16 - Диаграмма активности при подключении клиент к потоку

Рисунок 2.17 - Диаграмма активности для обработчика оповещения о публикации нового потока

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

Далее будет рассмотрена диаграмма активности при управлении мобильным клиентом. Управление заключается в отправке команды подсистеме «Mobile Client» на подключение к определенному потоку. Диаграмма активности для управления мобильным клиентом показана на рисунке 2.18.

Рисунок 2.18 - Диаграмма активности для управления мобильным клиентом

Управление подсистемой «Mobile Client» производится с подсистемы «Media Server», которая предоставляет для этого сервисы другим клиентам. Управление мобильным клиентом производится следующим образом, сначала выполняется проверка логина и пароля пользователя, далее, в случае легитимности пользователя, выполняется поиск мобильного клиента по идентификационному номеру. В случае отсутствия в списке мобильного клиент с заданным идентификационным номером формируется сообщение об ошибке. Далее формируется управляющая команда, после чего выполняется отправка команды мобильному клиенту.

.8 Проектирование диаграмм последовательности работы ИКС службы видеонаблюдения

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

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

Для описания временных аспектов поведения системы при начальной инициализации системы определим логику процесса. Начальная инициализация системы необходима для конфигурирования подсистемы «Мedia Gateway» и «Media Server». Подсистему «Media Gateway» при старте необходимо сконфигурировать таким образом, чтобы она опубликовала все необходимые потоки с внешней среды во внутреннюю среду системы. Таким образом, данной подсистеме необходимы конфигурационные данные, хранящиеся централизованно в подсистеме «Media Server». После получения конфигурационных данных подсистема «Media Gateway» должна проинформировать подсистему «Media Server» о наборе публикуемых потоков. В свою очередь подсистема «Media Server» начнет захват видеопотока. Для экономии ресурсов используется техника «ленивой загрузки», таким образом, старт и преобразование видео потока начинается только при подключении клиента. Диаграмма последовательности начальной инициализации системы показана на рисунке 2.19.

Для описания временных аспектов поведения системы при выполнении запрос на просмотр видеопотока определим последовательность действий. Запрос на просмотр потокового видео выполняется в два этапа. На первом этапе необходимо получить информацию о доступных на данный момент транслируемых видеопотоках. На втором этапе выполняется подключение к определенному видеопотоку, который публикуется и контролируется подсистемой «Media Gateway». После чего происходит захват видеопотока. Диаграмма последовательности при выполнении запроса на просмотр видеопотока показана на рисунке 2.20.

Рисунок 2.20 - Диаграмма последовательности при выполнении запроса на просмотр видеопотока

Для описания временных аспектов поведения системы при выполнении запроса на просмотр видео из архива, определим последовательность действий. Выполнение данного запроса также выполняется в два этапа относительно подсистемы «Video portal». На первом этапе происходит получение информации о необходимых архивных видеозаписях, которые хранятся и управляются системой «Media Server». После получения информации производится подключение к подсистеме «Media Server» и инициируется загрузка видеозаписей. Диаграмма последовательности представлена на рисунке 2.21.

 

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

2.9 Обеспечение требований к безопасности ИКС службы видеонаблюдения

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

Рисунок 2.22 - Схема дерева LDAP для ИКС службы видеонаблюдения

2.10 Разработка карты сайта подсистемы отображения «Video Portal»

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

 

Рисунок 2.23 - Карта сайта для оператора системы

Рисунок 2.24 - Карта сайта для администратора системы

2.11 Проектирование прототипов интерфейса пользователя ИКС службы видеонаблюдения

Интерфейс клиентского приложения должен обеспечить максимальную функциональность по управлению службой видеонаблюдения.

На рисунке 2.25 приводится прототип интерфейса главного окна подсистемы «Video portal» системы службы видеонаблюдения. В верхней части располагается логотип организации наряду с расширенным меню, которое будет общим для всей системы. Данное меню содержит пять закладок, с помощью которых можно переключаться между представлениями. Закладка «Архив видеонаблюдения» необходима для перехода на страницу просмотра информационной структуры предприятия и соответственно просмотра видеофайлов архива. Закладка «On-line трансляции» необходима для перехода на страницу просмотра «on-line» видео в реальном режиме времени с видеокамер. Закладка «События» нужна для перехода на страницу поиска и просмотра событий распознавания образов. Кнопка «Поиск видеозаписей» будет использоваться для просмотра страницы поиска видеозаписей архива. Ниже расположено меню по управлению просмотром информационной структуры предприятия, которое включает в себя три закладки. Первая закладка отвечает за просмотр детальной информации о выбранном элементе в информационном дереве. Вторая показывает список событий произошедших на выбранном объекте в дереве. Третье меню активируется при выборе в дереве элемента представляющего собой наблюдательный пункт. Слева находится элемент пользовательского интерфейса отвечающего за отображение древовидной информационной структуры предприятия.

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

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

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

Рисунок 2.25 - Прототип интерфейса просмотра информационной структуры предприятия

Рисунок 2.26 - Прототип интерфейса просмотра событий

Рисунок 2.27 - Прототип интерфейса поиска видеозаписей в архиве

Рисунок 2.28 - Прототип интерфейса просмотра онлайн видеотрансляций

3. Реализация ИКС службы видеонаблюдения

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

.1 Таблицы базы данных

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

- таблица «Categories» необходима для хранения абстрактных сущностей «Категория»;

- таблица «Attributes» необходима для хранения атрибутов категорий и наблюдательных пунктов;

- таблица «Attr_types» необходима для хранения типов атрибутов, что необходимо для правильной интерпретации значения атрибута;

-   таблица «Checkposts» необходима для хранения сущностей «Наблюдательный пункт»;

-   таблица «Employee» необходима для хранения записей о сотрудниках;

- таблица «Parts» требуется для хранения информации о видеозаписях;

-   таблица «Fixation» требуется для ведения журнала событий распознавания образов;

-   таблица «SDP_Attributes» требуется для хранения настроек преобразования видеоданных.

Поля, типы, ограничения и описание каждого из полей таблиц приведены в таблицах 3.1-3.8.

Таблица 3.1 - Описание таблицы «Categories»

Название колонки	Тип данных	Ограничения	Описание
id	bigint(20)	not null	Первичный ключ, идентификационный номер категории
name	varchar(255)	not null	Название категории
top_category	bigint(20)	not null	Внешний ключ, указывающий на категорию родителя

Таблица 3.2 - Описание таблицы «Attributes»

Название колонкиТип данныхОграниченияОписание
id	bigint(20)	not null	Первичный ключ, идентификационный номер атрибута
value	text	not null	Значение атрибута
name	varchar(255)	not null	Название атрибута
category_id	bigint(20)	-	Внешний ключ, указывающий на категорию
checkpost_id	bigint(20)	-	Внешний ключ, указывающий на наблюдательный пункт
type_id	bigint(20)	not null	Внешний ключ, указывающий на тип атрибута

Таблица 3.3 - Описание таблицы «Attr_types»

Название колонки	Тип данных	Ограничения	Описание
id	bigint(20)	not null	Первичный ключ, идентификационный номер типа атрибута
title	varchar(255)	not null	Название типа атрибута
datatype	varchar(255)	not null	Тип данных атрибута

Таблица 3.4 - Описание таблицы «Checkposts»

Название колонки	Тип данных	Ограничения	Описание
id	bigint(20)	not null	Первичный ключ, идентификационный номер наблюдательного пункта
ip	text	not null	IP адрес наблюдательного пунтка
description	varchar(255)	not null	Описание наблюдательного пункта
top_category	bigint(20)	not null	Внешний ключ, указывающий на категорию

Таблица 3.5 - Описание таблицы «Employee»

Название колонки	Тип данных	Ограничения	Описание
id	bigint(20)	not null	Первичный ключ, идентификационный номер сотрудника
email	varchar(255)	not null	Адрес электронной почты сотрудника
birthday	date	not null	Дата рождения сотрудника
name	varchar(255)	not null	Имя сотрудника
post	varchar(255)	not null	Должность сотрудника
patronymic	varchar(255)	not null	Отчество сотрудника
address	varchar(255)	not null	Адрес проживания сотрудника
surname	varchar(255)	not null	Фамилия сотрудника
category_id	bigint(20)	not null	Внешний ключ, указывающий на категорию

Таблица 3.6 - Описание таблицы «Parts»

Название колонкиТип данныхОграниченияОписание
id	bigint(20)	not null	Первичный ключ, идентификационный номер части записи
length	bigint(20)	not null	Длинна записи
dateto	timestamp	not null	Время окончания записи
datefrom	timestamp	not null	Время начала записи
file	varchar(255)	not null	Название файла
checkpost_id	bigint(20)	not null	Внешний ключ, указывающий на наблюдательный пункт

Таблица 3.7 - Описание таблицы «Fixation»

Название колонки	Тип данных	Ограничения	Описание
id	bigint(20)	not null	Первичный ключ, идентификационный номер фиксации
time	timestamp	not null	Время фиксации
employee_id	bigint(20)	not null	Внешний ключ, указывающий на сотрудника
checkpost_id	bigint(20)	not null	Внешний ключ, указывающий на наблюдательный пункт

Таблица 3.8 - Описание таблицы «SDP_Attributes»

Название колонкиТип данныхОграниченияОписание
id	bigint(20)	not null	Первичный ключ, идентификационный номер SDP атрибута
value	text	not null	Значение атрибута
name	varchar(255)	not null	Название атрибута
checkpost_id	bigint(20)	not null	Внешний ключ, указывающий на наблюдательный пункт

3.2 Диаграмма классов модуля доступа к данным ИКС службы видеонаблюдения

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

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

Решением данной проблемы есть использование шаблона объектов доступа к данным (DAO), которые будут инкапсулировать весь доступ к источнику данных и управлять соединением с источником данных для получения и хранения данных.

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

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

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

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

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

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

Рисунок 3.1 - Диаграмма классов DAO ИКС службы видеонаблюдения

.3 Диаграмма веб-сервисов подсистемы «Media Server»

Подсистема записи и хранения видеоархива «Media Server» предоставляет набор веб-сервисов. Доступ к данным веб-сервисам осуществляется с помощью протокола SOAP, что позволит в дальнейшем производить интеграцию с другими системами. Диаграмма веб-сервисов представлена на рисунке 3.2.

Рисунок 3.2 - Диаграмма веб-сервисов

Веб-сервис «ArchiveManagement Service» предоставляет набор веб- методов для навигации по всей структуре данных, расширенному поиску категорий архива, наблюдательных пунктов, видеофайлов, сотрудников, событий в журнале. Также, веб-метод getCheckposts используется подсистемой «Media Gateway» для загрузки активных наблюдательных пунктов и их настройки для конвертирования видео потоков.

Веб сервис «RecognizeObserver Service» предоставляет единственный веб-метод recognizedNotify.

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

Веб-сервис «AdminManagement Service» предоставляет набор веб- методов, реализующих CRUD операции над всеми сущностями системы. Данный веб-сервис необходим для администрирования ИКС архива видеонаблюдения. Доступ к данному веб-сервису ограничен, доступ имеют только пользователи с правами администратора.

3.4 Диаграмма пакетов подсистемы «Media Server»

Для упорядочивания и структурирования исходные тексты системы объединяются в пакеты. Объединение производится по функциональной принадлежности класса. На рисунке 3.3 показана диаграмма пакетов подсистемы «Media Server» ИКС службы видеонаблюдения.

Пакет «com.videoarch.mediaserver» содержит классы необходимые для инициализации конфигурации системы, конфигурационный контекст, базовые классы для классов логики.

Пакет «com.videoarch.mediaserver.logic» содержит классы, реализующие логику работы веб-методов, организованы в соответствии с шаблоном «Команда».

Пакет «com.videoarch.mediaserver.security» содержит классы, применяемые для контроля доступа в системе.

Пакет «com.videoarch.mediaserver.dao» содержит интерфейсы, определяющие слой компонент доступа к данным.

Пакет «com.videoarch.mediaserver.dao.impl» содержит реализацию интерфейсов пакета «com.videoarch.mediaserver.dao».

Пакет «com.videoarch.mediaserver.decode.worker» содержит реализацию классов-потоков необходимых для параллельного захвата нескольких потоков.

Пакет «com.videoarch.mediaserver.decode» содержит классы, содержащие наборы методов для декодирования видео.

Пакет «com.videoarch.mediaserver.mobileclient» содержит классы по управлению мобильными клиентами.

Пакет «com.videoarch.mediaserver.ws» содержит классы, реализующие веб-сервисы подсистемы.

Пакет «com.videoarch.mediaserver.ws.inout» содержит классы являющиеся моделью входных и выходных параметров веб-сервисов.

3.5 Диаграмма развертывания ИКС службы видеонаблюдения

Система ИКС службы видеонаблюдения состоит из 4 подсистем. Три их них являются серверными приложениями. Каждое серверное приложение требует отдельной процедуры развертывания на серверах. На рисунке 3.4 представлена диаграмма развертывания для подсистемы «Media Gateway».

Рисунок 3.4 - Диаграмма развертывания подсистемы «Media Gateway»

Данная подсистема является шлюзом, ретранслирующим видеопотоки во внутреннюю среду системы, после чего потоки будут захвачены и записаны подсистемой «Media Server». Диаграмма развертывания подсистемы «Media Server» представлена на рисунке 3.5.

Рисунок 3.5 - Диаграмма развертывания подсистемы «Media Server»

Подсистема отображения «Video Portal» должна быть развернута отдельно, диаграмма развертывания показана на рисунке 3.6.

Рисунок 3.6 - Диаграмма развертывания подсистемы «Video Portal»

3.6 Описание механизмов автоматизации сборки приложения

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

Необходимо было автоматизировать процессы компиляции исходных кодов, развертывание на удаленных серверах, создания клиентов к удаленным подсистемам. Для решения этих задач был выбран инструмент Ant 1.6 и разработан ряд ant целей. Текст ant цели по автоматическому генерированию клиента к веб-сервису приведен в листинге 3.1.

Листинг 3.1- Листинг ant цели по генерированию клиента к веб-сервису

<!-- == macrodef: build-client-from-source == -->

<macrodef name="build-client-from-source">

<attribute name="sei.package" />

<attribute name="sei.class" />

<attribute name="service.name" />

<attribute name="client.package" />

<sequential>

<wsgen sei="@{sei.package}.@{sei.class}" destdir="${build.wsgen.classes}"="${build.wsgen.resource}" keep="false" genwsdl="true">

<classpath>

<path refid="jaxws.classpath" />

<pathelement path="${build.classes.home}" />

</classpath>

</wsgen>

<wsimport debug="true" verbose="true" keep="true" extension="true" destdir="${build.wsimport.src}"="@{client.package}" Xnocompile="true" wsdl="${build.wsgen.resource}/@{service.name}.wsdl"="/META-INF/@{service.name}.wsdl" />

<replace dir="${build.wsimport.src}" includes="**/@{service.name}.java,**/@{service.name}_Service.java"=".class.getResource(&quot;.&quot;);" value=".class.getResource(&quot;&quot;);" />

<javac srcdir="${build.wsimport.src}" destdir="${build.wsimport.classes}" source="${javac.source.version}"="${javac.target.version}" debug="on" debuglevel="lines,source" encoding="UTF-8"="true" classpath="jaxws.classpath" />

<copy todir="${build.wsimport.classes}/META-INF/">

<fileset dir="${build.wsgen.resource}" includes="**/*" />

</copy>

</sequential>

</macrodef>

<target name="build-client-from-source" description="Build client from source" depends="clean,setup,compile">

<build-client-from-source client.package=" com.videoarch.mediaserver.wsclient".class="MediaServerService" sei.package="com.videoarch.mediaserver.ws" service.name="MediaServerService" />

<jar destfile="${build.wsimport.home}/${ant.project.name}-client.jar" basedir="${build.wsimport.classes}">

<manifest>

<attribute name="Built-By" value="${user.name}" />

<attribute name="Implementation-Title" value="${ant.project.name}" />

<attribute name="Implementation-Version" value="${implementation.vresion}" />

<attribute name="Implementation-Time" value="${TODAY}" />

<attribute name="Implementation-Vendor" value="" />

</manifest>

</jar>

</target>

…

3.7 Описание основных сценариев использования системы пользователем

Рисунок 3.7 - Интрефейс навигации по архиву

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

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

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

Рисунок 3.8 - Интерфейс просмотра онлайн трансляций

Рисунок 3.9 - Интерфейс поиска видеозаписей

На рисунке 3.10 представлен интерфейс порсмотра журнала событий. Интерфейс содержит таблицу c информацией о событиях. Для применения фильтрации пользователю достаточно ввести критерий фильтрации в заголовке таблицы и нажать кнопку «Aplly filter».

Рисунок 3.10 - Интерфейс просмотра событий распознавания личностей

4. Разработка локальной вычислительной сети редакции журнала «мой компьютер»

Исходя из требований, поставленных в техническом задании, необходимо разработать проект локальной вычислительной сети (ЛВС) редакции журнала «Мой компьютер».

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

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

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

ЛВС - это совместное подключение нескольких отдельных компьютерных рабочих мест к единому каналу передачи данных. ЛВС в наши дни встречаются почти повсеместно. Этим обусловлена актуальность данной работы.

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

единой передающей среды;

единого метода управления;

единых протоколов;

гибкой модульной организации;

- информационной и программной совместимости.

.1 Определение требований к локальной вычислительной сети

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

4.1.1 Полное описание целей и сферы деятельности редакции журнала

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

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

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

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

 

Рисунок 4.1 - План здания редакции журнала «Мой компьютер»

4.1.2 Описание основных подразделений редакции

Редакция журнала занимает одноэтажное здание и состоит из следующих отделов:

–   Отдел техподдержки;

–       Отдел программирования;

–       Отдел тестирования;

–       Отдел аппаратного обеспечения;

–       Отдел программного обеспечения;

–       Отдел новостей;

–       Игровой отдел;

–       Бухгалтерия;

–       Редакционный совет;

–       Редакционная коллегия;

–       Главный редактор;

Отдел технической поддержки представляет собой отдел, в котором находятся: сервер баз данных представляющая собой обычную СУБД, которая принимает запросы по сети и возвращает результат, сервера Proxy, Mail, DNS, FS, DHCP, VoIp. Сервера Proxy, Mail, DNS и Web расположены в публичной зоне по отношению к остальной части ЛВС, т.е. они видны из Интернета.

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

Главный редактор, редакционная коллегия и редакционный совет.

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

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

Отделы журналистов.

Отдел новостей.

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

Отдел тестирования.

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

Отдел программного обеспечения.

Отдел занимается подготовкой статей о программном обеспечении, его особенностях и характеристиках.

Отдел аппаратного обеспечения.

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

Отдел программирования.

Отдел занимается подготовкой статей о методиках и технологиях программирования, публикацией конкретных программных решений.

Игровой отдел.

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

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

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

-   Основная приватная сеть - для всех отделов журналистов, техподдержки;

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

.1.3 Описание аппаратных и программных ресурсов

Отдел техподдержки - оснащен тремя серверами и персональным компьютером. Один сервер оснащен Windows Server 2003SP2. На нем хранится база 1С бухгалтерии и запущен сервис Windows Terminal, сервис WINS, Genie Backup Pro (для ежедневного резервирования базы 1C по расписанию), Kerio Winroute Firewall, Microsoft Project 2007 Pro, MS SQL-сервер. Остальные два сервера оснащены ОС FreeBSD 7. На них находятся общие ресурсы сети: Samba-сервер, а также утилиты для анализа сетевого трафика и учета. Установлен сетевой принтер и телефон.

Для работы отдела достаточно пропускной способности сети в 100 Mb/sec.

Главный редактор и редакционная коллегия и редакционный совет - компьютер (11), оснащены операционной системой Windows 7. Также в программный набор входит MS Office 2010, Open Office, TotalCommander, антивирус Avira. Также в данных отделах установлены сетевые принтеры (6) и телефоны (6).

Для работы отдела достаточно пропускной способности сети в 100 Mb/sec.

Главбух, заместитель главбуха и отдел бухгалтерии - компьютер (5), оснащены операционной системой Windows 7. Также в программный набор входит MS Office 2010, Open Office, Клиент-Банк, тонкий клиент терминала (для 1С) для хранения информации о финансовых оборотах редакции, TotalCommander, антивирус Avira. Также выделяются сетевые принтер (2) и телефоны (2).

Для работы отдела достаточно пропускной способности сети в 100 Mb/sec.

Журналисты - компьютер (5), оснащены операционной системой Windows 7. Также в программный набор входит MS Office 2010, Open Office, средства для обработки и публикации новостей, TotalCommander, антивирус Avira. Также выделяются сетевой принтер и телефон.

Для работы отдела достаточно пропускной способности сети в 100 Mb/sec.

Тестеры - компьютер (10), оснащены операционной системой Windows 7. Также в программный набор входит MS Office 2010, Open Office, а также средства для тестирования программного и аппаратного обеспечения, TotalCommander, антивирус Avira, для проверки работоспособности новых технологий Visual Studio, Eclipse, OllyDBG. Выделяются сетевой принтер и телефон.

Для работы отдела достаточно пропускной способности сети в 100 Mb/sec.

Редакторы ПО - компьютер (7), оснащены операционной системой Windows 7. Также в программный набор входит MS Office, Open Office, TotalCommander, антивирус Avira, программы для вёрстки журналов Adobe PageMaker, Quark XPress, Adobe Illustrator, CorelDRAW <#"598901.files/image045.gif">

Рисунок 4.2 - Логическая схема ЛВС редакции журнала «Мой компьютер»

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

4.2 Выбор сетевого оборудования для ЛВС

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

.2.1 Выбор коммутаторов

Для построения ЛВС использовались неуправляемые и управляемые коммутаторы. Управляемый коммутатор выполняет разделение сети на подсети. Неуправляемые коммутаторы применяются для создания звездообразной топологии подсетей.

В таблицах 4.1, 4.2 и 4.3 представлены сравнительные характеристики коммутаторов.

Таблица 4.1 - Коммутаторы для групп серверов (8 -портовые)

Фирма производитель	D-Link	3Com
Модель	DES-1008D	3C16791B
Поддерживаемые стандарты	10/100Base-TX	10/100 BASE-TX
Количество портов	8	8
Размер буфера данных	64 Кб	1 Мб
Размер таблицы MAC-адресов	1024	1024
Тип корпуса	Настольный	Настольный
Автосогласование скорости	+	+
Полный дуплекс	+	+
Цена, грн.	140.70	355,80

Среди 8-ми портовых коммутаторов DES-1008D и 3C16791B имеют примерно одинаковые возможности, для установки в отделах с малой потребностью к скоростному обмену информации, был выбран неуправляемый коммутатор фирмы D-Link модель DES-1008D, поскольку его стоимость значительно меньше.

Рисунок 4.3 - Коммутатор D-Link DES-1008D

Link DES-1008D является неуправляемым коммутатором 10/100 Мбит/с, предназначенным для повышения производительности работы малой группы пользователей, позволяет подключить к порту сетевое оборудование, работающее на скоростях 10 или 100 Мбит/с. Коммутатор снабжен 8 портами 10/100 Мбит/с с автоопределением скорости, функция управления потоком предотвращает пакеты от передачи, которая может привести к их потере. Все порты поддерживают автоматическое определение полярности MDI/MDIX. Это исключает необходимость в использовании кроссированных кабелей или портов uplink. Любой порт можно подключить к серверу, маршрутизатору или коммутатору, используя прямой кабель на основе витой пары.

Таблица 4.2 - Коммутаторы рабочих групп (16-портовые)

Фирма производитель	D-Link	3Com
Модель	DGS1016D/GE	3C1671600
Поддерживаемые стандарты	10/100/1000Base-T	10/100/1000Base-T
Количество портов	16	16
Размер буфера данных	340 Кб	512 Кб
Коммутационная фабрика	32 Гбит/с	32 Гбит/с
Размер таблицы MAC-адресов	8192	2048
Проверка времени жизни пакета	+	+
Автоопределение скорости	+	+
Полный дуплекс	+	+
Фильтрация пакетов	+	+
Скорость передачи данных, полу/полный дуплекс, Мбит/с	Ethernet: 10/20 Мбит/с Fast Ethernet: 100/200 Мбит/с; Gigabit Ethernet: 2000 Мбит/с	Ethernet: 10/20 Мбит/с Fast Ethernet: 100/200 Мбит/с Gigabit Ethernet: 2000 Мбит/с
Автоопределение полярности MDI/MDIX на всех портах	+	+
Цена, грн.	1237.08	1528,00

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

Рисунок 4.4 - Коммутатор D-Link DGS-1016D/GE

Коммутатор D-Link DGS-1016D/GE обеспечивает быстрый доступ к серверам при большой загрузке сети, все порты поддерживают автоопределение скорости 10/100/1000Mбит/с и автосогласование полу/полнодуплексного режима работы. Порты Gigabit Ethernet предоставляют выделенную полосу пропускания в 2000Мбит/с в режиме полного дуплекса для подключения серверов. Таблица МАС-адресов размером 8 000 адресов обеспечивает хорошую масштабируемость даже для крупных сетей.

Управление потоком IEEE 802.3x позволяет подключать серверы напрямую к коммутатору с целью получения высокоскоростного канала связи. Все порты поддерживают автоматическое определение полярности MDI/MDIX. Устройство поддерживает IEEE 802.1p QoS (4 очереди приоритетов) и Jumbo-фреймов (9,600 байт).

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

Таблица 4.3 - Коммутаторы 2-го уровня

Фирма производитель	D-Link	3Com
Модель	DES-3528	Baseline 2916-SFP Plus
Порты 10BASE-T/ 100BASE-TX/1000BASE-T	24	16
Порты SFP Gigabit	2	4
Консольный порт RS-232	+	+
Дополнительные функции уровня 3	+	-
Таблица МАС адресов	16 К	8 К
Loopback Detection (LBD)	+
Скорость коммутации	12,8Gb/s	10,2Gb/s
Объединение в стек	+	-
Виртуальные сети (VLAN)	256	256
Поддержка Jumbo-фреймов	9216 байт	-
Цена, грн	2350	2100

Данный коммутатор должен взять на себя обязанности по коммутации пакетов между различными виртуальными подсетями. При выборе коммутатора необходимо руководствоваться условием наличия портов позволяющих подключать оптоволокно на скорости 1Gb/s и поддержкой виртуальных подсетей.

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

При разработке ЛВС будет использоваться DES-3528 - данные коммутаторы сочетают в себе высокую производительность, по сравнению с Baseline 2916-SFP Plus, комплексную функциональность и отличаются доступной ценой.

Рисунок 4.5 - Коммутатор D-Link DES-3528

Коммутатор DES-3528 оснащен 24 портами 10/100/1000Base-T Gigabit Ethernet, 2 комбо-порта 10/100/1000 BASE/SFP. Коммутатор поддерживает работу с расписаниями. Шаблоны расписания задаются на отдельной странице основного раздела и обзываются подходящими именами, после чего их можно применять при дальнейшем конфигурировании некоторых функций, например списков доступа. DES-3528 имеет большой набор инструментов для работы по протоколу SNMP (Simple Network Management Protocol - простой протокол управления сетью). Для него отведен целый подраздел меню. Поддерживается работа всех трех версий протокола. Заводскими настройками предусмотрено несколько групп для пользователей с разными правами. Каждый из них сможет увидеть только тот набор (SNMP View) ветвей (OID-ов) дерева настроек коммутатора, к которому разрешен доступ правами соответствующей группы.

Из редких преимуществ стоит отметить поддержку протокола Q-in-Q, благодаря которой коммутатор будет правильно распознавать и обрабатывать пакеты с двумя вложенными тегами виртуальной сети 802.1q. Протокол Q-in-Q традиционно используется в больших и сложных сетях для того, чтобы без какого-либо вмешательства в структуру и содержимое пакетов прозрачно транслировать по собственным VLAN-ам клиентский трафик, который в свою очередь приходит на вход сети уже "упакованным" в один или несколько клиентских VLAN-ов.

4.2.2 Выбор маршрутизаторов

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

В таблице 4.4 находятся основные характеристики маршрутизаторов. Маршрутизаторы используемые в данной ЛВС имеют разное назначение, следовательно, к ним будут предъявляться разные требования. Один из маршрутизаторов используется внутри сети для ограничения доступа сотрудников фирмы к «внутреннему» участку сети. К данному участку принадлежат бухгалтерия, редакционный совет и редколлегия. Была выбрана линейка маршрутизаторов Cisco 2800 Series с возможностью подключения дополнительных модулей.

Таблица 4.4 - Маршрутизаторы Cisco 2800 Series

Устройство	Cisco 2801	Cisco 2811	Cisco 2821	Cisco 2851
Порты Ethernet	2 порта 10/100BaseT		2 порта 10/100/1000BaseT
Память	128 MB	256 MB	256 MB
Консольный порт	1 порт (115.2 кб/с)
Наличие сетевых слотов	-	1слот (NM/NME типы)	1 слот (NM, NME и NME-X типы)	1 слот (NM, NME, NME-X, NMD и NME-XD типы)
Аппаратная поддержка шифрования	DES, 3DES, AES 128, AES 192 и AES 256
Голосовые слоты расширения	0		1
Поддержка модулей	-	NM-16ESW 16-port 10/100 Cisco EtherSwitch; Network Module VWIC-1MFT-E1 1-port RJ-48 multiflex trunk-E1
Compact Flash	Default: 64 MB Max: 128MB		Default: 64 MB Max: 256 MB

Маршрутизатор Cisco 2811, как и вся серия модульных маршрутизаторов 2800 отличается гибкой модульной конструкцией. Доступны слоты NME, для установки сетевых модулей, слоты HWIC для установки интерфейсных модулей, Слоты EVM для поддержки дополнительных голосовых интерфейсов, а также слоты PVDM и гнезда AIM на системной плате маршрутизатора для установки модулей обработки голоса и сервисных модулей соответственно. Слоты NME и HWIC имеют обратную совместимость с модулями NM и WIC соответственно.

Модуль Cisco NME-16ES-1G для маршрутизаторов Cisco 2800, 3800 серий c 16 Ethernet-интерфейсами. Имеет 16 портов тип разъемов RJ-45, поддерживает интерфейсы Ethernet 10Base-T, Ethernet 100Base-TX, поддерживает протоколы SNMP 1, Telnet, SNMP 3, SNMP 2c, HTTP. Скорость передачи данных - 100 Mб/с.

Рисунок 4.6 - Модуль Cisco NME-16ES-1G

Сетевой модуль Cisco NM-HDV-1E1-30 с одним 30ти канальным цифровым голосовым портом. Данный voice/fax сетевой модуль предоставляет одно E1 соединение и поддерживает 30 каналов со средней плотностью компрессии голоса, используя любой из представленных VoCoders: G.711, G.729a/b, G.726, и факс. Этот модуль также может быть использован для предоставления 18 каналов высокой и/или средней степени компрессии голоса используя любой из представленных VoCoders: G.711, G.729, G.729a/b, G.726, G.728, G.723.1, и факс. Голосовые модули высокой плотности предназначены для внедрения VOIP технологии на базе маршрутизаторов Cisco 2600, 3600, 3700 серии. Модули NM-HDV при установке в них модулей VWIC (Voice Wan Interface Card) и модулей цифровых процессоров (DSP) позволяют организовать до 60 одновременных голосовых соединений при использовании алгоритмов сжатия средней сложности (mid-complexity voice compression codec).

Модуль NM-HDV (рисунок 4.7) содержит на своем шасси слот для установки интерфейсных модулей VWIC и пять разъемов для установки модулей DSP (PVDM-12). Положительным свойством данного модуля является его масштабируемость.

Рисунок 4.7 - Модуль Cisco NM-HDV-1E1-30

Далее необходимо рассмотреть варианты роутеров для маршрутизации пакетов между подсетями.

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

Таблица 4.5 - Маршрутизаторы

Фирма производитель	MOXA	TP-Link
Модель	EDR-G903	TL-R4299G
Порты	1 порт 100/1000Base SFP, 1 порт 10/100/1000BaseT(X), 1 DMZ порт 10/100/1000BaseT(X)	8 портов 10/100/1000M,  1 независимый SFP-порт 1000M
WAN 1	1 RJ45/fiber combo port	2 порта 10/100M, автоматическое согласование скорости, разъем RJ45 (Auto MDI/MDIX)
WAN 2	1 RJ45/fiber combo port
Порты SFP Gigabit	1	1
Консольный порт RS-232	+	+
VLAN по портам	-	+
Фильтрация по MAC-адресам	+	+
Поддержка VPN	+	+
Балансировка нагрузки	-	+
Защита от DoS-атак	+	+
Цена, грн	15997	2064

В результате проведенного сравнения, был выбран маршрутизатор фирмы TP-Link модели TL-R4299G. Основной причиной выбора данного маршрутизатора является цена. Цена на данный маршрутизатор значительно ниже при более обширном функционале. Более того, маршрутизатор фирмы MOXA не поддерживает виртуальные подсети.

Помимо стандартных настроек широкополосного маршрутизатора в устройстве имеется ряд дополнительных функций таких, как управление полосой пропускания, зеркало портов, поддержка VLAN на портах, идентификация по протоколу IEEE 802.1x, UPnP, DDNS, VPN-проход, брандмауэр и системный журнал. Также имеется функция комплексного управления коммутатором, поддержка VLAN и зеркалирования портов.

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

.2.3 Сервера демилитаризированной зоны и рабочих групп

Для реализации ЛВС необходимо 5 сервера - VoIP сервер, сервер для сервисов DNS, DHCP,почтовый сервер, файловый сервер.

Таблица 4.6 - Конфигурации серверов

Устройство	Dell PowerEdge SC1430	Dell PowerEdge 840	PowerEdgeR300
Процессоры	2- процессора Dual Core Xeon 5100 (1.6 GHz)	1 x Intel Xeon 3040	Один 4-ядерный процессор Intel Xeon 5400 (3,16 ГГц)
Память	2GB Full Buffered DIMMs (FBD) 533MHz или 677 MHz; 4 слотов памяти до 8GB	2GB ECC DDR2 533MHz или 677 MHz; 4 слота памяти до 8 GB	Шесть разъемов для модулей памяти DIMM ECC DDR-2 SDRAM (667 МГц) емкостью до 24 Гбайт
Видеосистема	Интегрированный ATI ES1000 16MB	Интегрированный ATI ES1000 16MB	Встроенный контроллер ATI ES1000 VGA 32 MB
Жесткие диски	До 4-ех жестких дисков 3.5” SAS (10K rpm) 73GB, 146GB, 300GB (без горячей замены)	До 4-ех жестких дисков 3.5” SAS (10K rpm) 73GB, 146GB, 300GB	Жесткие диски SATA емкостью 160 Гбайт, 250 Гбайт, 500 Гбайт, 750 Гбайт и 1000 Гбайт (7200 об./мин.)
Удаленное управление	Dell Server Assistant для серверов PowerEdge SC и мониторинг при помощи ОС	В поставке baseboard management controller (IPMI 1.5) опциональный DRAC 4/p для расширенных возможностей	Программное обеспечение Dell OpenManage Server Administrator
Операционные системы	Microsoft Windows Server 2003 R2 Standard, SBS Standard and Premium Edition; x64 R2 Standard Editions;  Red Hat Linux Enterprise v4, ES EMT64;  SUSE Linux Enterprise Server 10 EMT64	Microsoft Windows Server 2003 R2 Standard, SBS Standard and Premium Edition; x64 R2 Standard Editions;  Red Hat Linux Enterprise v4, ES EMT64;  SUSE Linux Enterprise Server 10 EMT64	Microsoft Windows Server 2008, Standard  Windows Server 2003, Web Edition Red Hat Linux Enterprise v5, ES x64 SUSE Linux Enterprise Server 9, x86-64 SUSE Linux Enterprise Server 10, x86-64
Сетевой контроллер	Встроенный сетевой контроллер Broadcom Gigabit Ethernet	Встроенный сетевой контроллер Broadcom Gigabit Ethernet	Две встроенные сетевые платы Gigabit1

В результате сравнения приведенных характеристик был выбран Dell PowerEdge 840 так как он имеет 1 процессор Pentium D 915 (2.8GHz), что вполне достаточно для реализации всех серверов (включая сервер ip-телефонии) данной ЛВС.PowerEdge 840 - сервер общего назначения с одним процессорным разъемом и корпусом Tower. подходит для организаций, где требуется установить простой сервер, который легко настраивается, прост в эксплуатации и обслуживании, а также легко может быть модернизирован с минимальным привлечением специалистов IT-поддержки или вообще без их участи. Сервер поддерживает выполнение различных приложений для рабочих групп: систем электронной почты, служб совместного использования файлов и принтеров, систем управления базами данных, систем общего доступа в Интернет.

4.2.4 Выбор Ip-телефонов

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

Таблица 4.7 - Характеристики ip-телефонов

Устройство	Cisco CP-7912G	DPH-70S / DPH-70H	DPH-100H
Протоколы	SIP	SIP	Н.323v2	IEEE 802.1Q (VLAN) IEEE 802.3 (Ethernet) IEEE 802.3af (power over ethernet) IEEE 802.3u (Fast Ethernet)	IP, TCP, UDP, ARP protocols  HTTP 1.0  Клиент DHCP  DNS	TCP/IP, UDP  DHCP клиент Ethernet 10/100 Мбит/с
Определитель номера	есть	есть	нет
Интерфейсы	2 x Ethernet 10/100BaseT (RJ-45)	2 x Ethernet 10/100BaseT (RJ-45)	Порт LAN: RJ-45для Ethernet (MDI-II)  Порт PC : RJ-45 для Ethernet (MDI-X)
Спикерфон	есть	Нет	нет
Аудиокодеки	G.723.1  G.729A/AB	G.711u-law/A-law  G.723.1  G.729A/AB	G.711 m-law, G.711 A-law, G.723 и G.729
Поддержка QoS	есть	нет	нет

На основании сравнения был выбран Cisco CP-7912G, так как он поддерживает протокол SIP, стандарт - IEEE 802.1Q (VLAN), также поддерживает сжатие голоса аудиокодеками G.723.1 и G.729A/AB и обеспечивает поддержку QoS.

Рисунок 4.8 - Телефон Cisco CP-7912GCP-7912G представляет собой модель IP-телефона, который предназначен для обеспечения голосовой связи сотрудников, располагающихся в отделах с малыми или средними объемами телефонного трафика. Пиксельный дисплей и динамические контекстно-зависимые клавиши обеспечивают быстрый доступ к базовому набору функций. Поддерживает одновременно не более двух вызовов и один абонентский номер; поддерживает питание по витой паре и содержит интегрированный коммутатор 10/100 Ethernet для подключения ПК. К специальным функциям относится определитель номера, поддержка QoS, спикерфон и голосовая почта.

.2.5 Сетевые принтеры

В качестве сетевого принтера был выбран принтер HP LaserJet 1022N так как он имеет хорошие эксплуатационные характеристики и не высокую цену.

С помощью сетевого принтера HP LaserJet 1022N можно создавать документы высокого качества, с разрешением 1200 т/д. Наличие драйвера печати HP PCL 5e и ОЗУ 8 Мб обеспечивает надёжность и высокую производительность устройства. Благодаря использованию технологии мгновенного закрепления тонера печать документов данным принтером происходит довольно быстро. Выбранный принтер относится к малогабаритным лазерным принтерам, что позволяет использовать его в условиях небольшой площади рабочего места. Кроме того, он готов к работе в сети.

.2.6 Расчёт стоимости сети

В таблице 4.8 приведен расчет суммарной стоимости выбранного сетевого оборудования.

Таблица 4.8 - Расчет суммарной стоимости выбранного сетевого оборудования

Наименование оборудования	Количество, шт./м	Цена, грн. 1 шт./м	Сумма, грн.
D-link DES-3016	2	136	272
D-Link DGS-1016D/GE	10	1103	11030
Витая пара UTP 4 кат. 5е	944	3,50	3304
Розетка RJ45	86	10	860
D-Link DES- 3528	1	1720	1720
TL-R4299G	1	1861	1861
D-link DIR-130	1	12 816	12816
Dell PowerEdge 840	2	10728	21456
Cisco CP-7912G	13	720	9360
HP LaserJet 1022N	10	2495	24950
			87629

.3 Моделирование ЛВС

Согласно разработанной логической схеме ЛВС было проведено моделирование с помощью программы Cisco Packet Tracer.

На рисунке 4.9 представлен результат моделирования сети в программе Cisco Packet Tracer.

Рисунок 4.9 -Модель сети редакции журнала «Мой компьютер»

В листинге 4.1 показана проверка функционирования ЛВС.

Листинг 4.1 - Список проверок ЛВС

From 192.168.91.2

PC>tracert 192.168.91.99route to 192.168.91.99 over a maximum of 30 hops:

94 ms 64 ms 48 ms 192.168.91.1

* 156 ms 124 ms 192.168.91.99complete.192.168.91.2>tracert 10.10.11.2route to 10.10.11.2 over a maximum of 30 hops:

19 ms 47 ms 78 ms 192.168.91.1

109 ms 109 ms 80 ms 192.168.165.1

* 112 ms 158 ms 10.10.11.2complete.192.168.91.194>tracert 192.168.91.34route to 192.168.91.34 over a maximum of 30 hops:

94 ms 78 ms 86 ms 192.168.91.193

93 ms 125 ms 143 ms 192.168.91.161

187 ms 203 ms 203 ms 192.168.91.34complete.192.168.91.194>tracert 193.154.21.2route to 193.154.21.2 over a maximum of 30 hops:

51 ms 78 ms 78 ms 192.168.91.193

127 ms 63 ms 95 ms 192.168.91.161

160 ms 171 ms 128 ms 193.154.21.2complete.192.168.91.194>tracert 10.10.11.2route to 10.10.11.2 over a maximum of 30 hops:

78 ms 58 ms 67 ms 192.168.91.193

125 ms 94 ms 141 ms 192.168.91.161

127 ms 171 ms 171 ms 192.168.165.1

190 ms 156 ms 172 ms 10.10.11.2complete.192.168.91.194>ping 192.168.91.35192.168.91.35 with 32 bytes of data:from 192.168.91.35: bytes=32 time=202ms TTL=126from 192.168.91.35: bytes=32 time=172ms TTL=126from 192.168.91.35: bytes=32 time=199ms TTL=126from 192.168.91.35: bytes=32 time=187ms TTL=126statistics for 192.168.91.35:: Sent = 4, Received = 4, Lost = 0 (0% loss),round trip times in milli-seconds:= 172ms, Maximum = 202ms, Average = 190ms192.168.91.194>ping 10.10.11.210.10.11.2 with 32 bytes of data:from 10.10.11.2: bytes=32 time=129ms TTL=125from 10.10.11.2: bytes=32 time=203ms TTL=125from 10.10.11.2: bytes=32 time=218ms TTL=125from 10.10.11.2: bytes=32 time=156ms TTL=125statistics for 10.10.11.2:: Sent = 4, Received = 4, Lost = 0 (0% loss),round trip times in milli-seconds:= 129ms, Maximum = 218ms, Average = 176ms192.168.91.3>ping 192.168.91.99192.168.91.99 with 32 bytes of data:from 192.168.91.99: bytes=32 time=140ms TTL=127from 192.168.91.99: bytes=32 time=158ms TTL=127from 192.168.91.99: bytes=32 time=156ms TTL=127from 192.168.91.99: bytes=32 time=125ms TTL=127statistics for 192.168.91.99:: Sent = 4, Received = 4, Lost = 0 (0% loss),round trip times in milli-seconds:= 125ms, Maximum = 158ms, Average = 144ms192.168.91.3>ping 193.154.21.2193.154.21.2 with 32 bytes of data:from 193.154.21.2: bytes=32 time=96ms TTL=254from 193.154.21.2: bytes=32 time=109ms TTL=254from 193.154.21.2: bytes=32 time=109ms TTL=254from 193.154.21.2: bytes=32 time=94ms TTL=254statistics for 193.154.21.2:: Sent = 4, Received = 4, Lost = 0 (0% loss),round trip times in milli-seconds:= 94ms, Maximum = 109ms, Average = 102ms

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

Листинг 4.2 -Листинг файла конфигурации локального маршрутизатора

!12.4service timestamps log datetime msecservice timestamps debug datetime msecservice password-encryptionRoutername-server 0.0.0.0

!FastEthernet0/0address 192.168.165.2 255.255.255.0autoautoFastEthernet0/1ip addressautoautoFastEthernet0/1.1dot1Q 10address 192.168.91.1 255.255.255.224FastEthernet0/1.2dot1Q 11address 192.168.91.33 255.255.255.224FastEthernet0/1.3dot1Q 12address 192.168.91.65 255.255.255.224FastEthernet0/1.4dot1Q 13address 192.168.91.97 255.255.255.224FastEthernet0/1.5dot1Q 14address 192.168.91.129 255.255.255.224FastEthernet0/1.6dot1Q 15address 192.168.91.161 255.255.255.224Vlan1ip addressclasslessroute 192.168.91.192 255.255.255.224 192.168.91.180 route 192.168.91.224 255.255.255.224 192.168.91.180 route 192.168.92.0 255.255.255.224 192.168.91.180 route 0.0.0.0 0.0.0.0 192.168.165.1 con 0vty 0 4

В листинге 4.3 представлен текст файла конфигурации внешнего маршрутизатора.

Листинг 4.3 - Листинг файла конфигурации внешнего маршрутизатора

version 12.4service timestamps log datetime msecservice timestamps debug datetime msecservice password-encryptionRouterFastEthernet0/0address 193.154.21.2 255.255.0.0autoautoFastEthernet0/1address 192.168.165.1 255.255.255.0autoautoFastEthernet1/0address 10.10.11.1 255.0.0.0autoautoVlan1ip addressclasslessroute 192.168.91.0 255.255.255.224 192.168.165.2 route 192.168.91.32 255.255.255.224 192.168.165.2 route 192.168.91.64 255.255.255.224 192.168.165.2 route 192.168.91.96 255.255.255.224 192.168.165.2 route 192.168.91.128 255.255.255.224 192.168.165.2 route 192.168.91.160 255.255.255.224 192.168.165.2 route 192.168.91.192 255.255.255.224 192.168.165.2 route 192.168.91.224 255.255.255.224 192.168.165.2 route 192.168.92.0 255.255.255.224 192.168.165.2 con 0vty 0 4

Для доступа к файловым серверам, серверам баз данных, а также к серверам DMZ-зоны по их именам, а не по ip-адресам, необходимо настроить службу доменных имен DNS. Для настройки DNS сервера named в конфигурационном файле named.conf необходимо описать конфигурацию службы DNS.

В листинге 4.4 представлен текст конфигурационного файла named.conf:

Листинг 4.4 - Содержимое файла named.conf

options {

directory     "/var/lib/chroot/var/named";yes;first;  {

         };

};

//домен ".""." IN {hint;"named.ca";

};"/etc/named.rfc1912.zones";"general" IN {master; "masters/db.general";

//ограничение ответа на запросы для данной зоны

allow- query{

.168.91.0/27;

.168.91.32/27;

.168.91.64/27;

.168.91.96/27;

.168.91.128/27;

.168.92.32/27;

.168.91.160/27;

.168.91.192/27;

.168.91.224/27;

.168.92.0/27;

};

};"inserv" IN {master;"masters/db.inserv";

};"dmz" IN {

type master;"masters/db.dmz";query           {

192.168.91.0/27;

.168.91.32/27;

.168.91.64/27;

.168.91.96/27;

.168.91.128/27;

.168.92.32/27;

.168.91.160/27;

.168.91.192/27;

.168.91.224/27;

.168.92.0/27;

};

};

//обратная зона "91.168.192.in-addr.arpa"{master;"masters/db.1.168.192";query{

.168.91.0/27;

.168.91.32/27;

.168.91.64/27;

.168.91.96/27;

.168.91.128/27;

.168.92.32/27;

.168.91.160/27;

.168.91.192/27;

.168.91.224/27;

.168.92.0/27;

};

};"91.168.192.in-addr.arpa"{master;"masters/db.91.168.192";

};

zone "91.69.169.in-addr.arpa"{master;"masters/db. 91.69.169.in-addr.arpa";

};

В конфигурационном файле службы имен описаны зоны для всех подсетей редакции журнала. В этом файле заданы имена файлов, в которых приведены соответствия доменных имен ip-адресам. В листинге 4.5 представлен текст файла db.general.

Листинг 4.5 - Содержимое файла db.general

$TTL 28800         ;TTL по умолчанию

$ORIGIN .  ;суффикс

;основной сервер имен для данной зоны

General       SOA          ns.webmaker dnsmaster.general. (

2011112701; серийный номер файла

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

                                      7200 ; время, через которое ;вторичные сервера должны совершать повторную попытку

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

                                      86400) ; Time to Live

;авторитетные сервера

IN      NS     ns.webmaker.        ;первичный сервер

;адреса авторитетных серверов

ns.general    IN      A       192.168.0.1

;адреса хостов зоны

$ORIGIN general.//суффикс                 

fs                         IN      A       192.168.0.2                    IN      A       192.168.0.3                    IN      A       192.168.0.4                    IN      A       192.168.0.5

В листинге 4.6 представлен текст файла db.inserv.

Листинг 4.6 - Содержимое файла db.inserv

$TTL 28800         ;TTL по умолчанию

$ORIGIN .  ;суффикс

;основной сервер имен для данной зоны

admin_inserv IN    SOA          ns.admin_inserv dnsmaster.admin_inserv. (

; серийный номер файла

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

                                      7200 ; время, через которое ;вторичные сервера должны совершать повторную попытку

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

                                      86400) ; Time to Live

;авторитетные сервера

IN      NS     ns.admin_inserv.   ;первичный сервер

;адреса хостов зоны

$ORIGIN admin_inserv.//суффикс                      IN      A       192.168.92.34                          IN      A       169.69.91.4                    IN      A       169.69.91.2                    IN      A         169.69.91.8

В листинге 4.7 представлен текст файла db.dmz.

Листинг 4.7 - Содержимое файла db.dmz

$TTL 28800         ;TTL по умолчанию

$ORIGIN .  ;суффикс

;основной сервер имен для данной зоны

dmz IN        SOA          ns.admin_inserv dnsmaster.dmz. (

2011112701; серийный номер файла

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

                                      7200 ; время, через которое ;вторичные сервера должны совершать повторную попытку

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

                                      86400) ; Time to Live

;авторитетные сервера

IN      NS     ns.dmz.       ;первичный сервер

;адреса авторитетных серверов

ns.dmz IN   A       192.168.0.1

;адреса хостов зоны

$ORIGIN dmz.//суффикс

mail             IN     A       169.69.91.4

В листинге 4.8 представлен текст файла db.91.168.192.in-addr.arpa.

Листинг 4.8 - Содержимое файла db.91.168.192.in-addr.arpa

$TTL 28800

$ORIGIN .

.168.192.in-addr.arpa IN SOA ns.general. dnsmaster. general. (

         2011092601

          86400

          14400

          3600000

          345600 )    NS     ns.general.

$ORIGIN 91.168.192.IN-ADDR.ARPA.

         IN      PTR  fs.general.

В листинге 4.9 представлен текст файла db.91.168.192.in-addr.arpa.

Листинг 4.9 - Содержимое файла db.91.168.192.in-addr.arpa

$TTL 28800

$ORIGIN .

.168.192.in-addr.arpa IN SOA ns.admin_inserv. dnsmaster.admin_inserv. (

         2011092601

          86400

          14400

          3600000

          345600 )    NS     ns.admin_inserv.

$ORIGIN 91.168.192.IN-ADDR.ARPA.

         IN      PTR  dns.general.

         IN      PTR  db.general.

         IN      PTR  voip.general.

В листинге 4.10 представлен текст файла db.91.69.169.in-addr.arpa

Листинг 4.10 - Содержимое файла db.91.69.169.in-addr.arpa

$TTL 28800

$ORIGIN .

.91.69.169.in-addr.arpa IN SOA ns.dmz. dnsmaster.dmz. (

         2011092601

          86400

          14400

          3600000

          345600 )    NS     ns.dmz.

$ORIGIN 91.69.169.IN-ADDR.ARPA.

         IN      PTR  mail.dmz.

         IN      PTR  dns.general.

         IN      PTR  db.general.

         IN      PTR  voip.general.

5. Охрана труда

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

5.1 Гигиенические требования к производственным помещениям для эксплуатации ВДТ ПК