Количество считывателей до 510

Количество картдо 12000

Расширенное количество карт до 32000

Количество наборов карт до 32

Количество пространственных зон контроля до 128

Количество временных зон контроля до 256

Количество недельных графиков до 128

Количество сменных графиков. до 32

Максимальный размер буфера событий на один драйвер/контроллер:

- для драйверов серий 12301 и 12310, шт. до 16384

- для замкового контроллера PERCo-CL-12200, шт. до 3000

Основные технические характеристики контроллера и концентратора

Напряжение питания 12±1.2 В

Ток потребления (без учета тока заряда аккумулятора) е более 0.15 А

Ток потребления (c учетом тока заряда аккумулятора) не более 0.5 А

Потребляемая мощность не более 6 Вт

Максимальное количество драйверов серии 12201, 12301 и 12310

(драйверов серий 12301 и 12310. только для контроллера-концентратора), шт. 2

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

Время опроса всех замковых контроллеров подсистемы не более 1 сек

Масса (без аккумулятора и блока питания) не более 5,5 кг

Габаритные размеры 384х360х108 мм

Условия эксплуатации:

Температура окружающего воздуха от +1 до +40°С

Относительная влажность не более 80% при t = 25°C

Основные технические характеристики замкового контроллера

Номинальное значение напряжения питания

постоянного тока 12±1.2 В

Ток потребления не более 0,25 А

Потребляемая мощность.не более 3 Вт

Масса контроллера не более 1,5 кг

Габаритные размеры контроллера 205x185x45 мм

Количество контролируемых дверей 2

Количество считывающих устройств 2

Тип карт бесконтактные, магнитные, Wiegand, PIN-код

Количество входов дистанционного управления 2

Количество аналоговых тестовых входов 2

Количество цифровых тестовых входов 2

Количество релейных выходов 2

Количество выходов с открытым коллектором 2

Количество служебных выходов 4

Стандарт интерфейса связи RS-485

Максимальная дальность связи без повторителя, м 1200

Характеристики контроллера в аварийном режиме:

Максимальное количество пользователей 1000

Максимальное количество событий журнала регистраций 1000

Условия эксплуатации:

Температура окружающего воздуха от +1 до +40°С

Относительная влажность не более 80% при t = 25°C



Рисунок 2 - Структурная схема СКУД Perco-12000

2.3.1 Устройство концентратора и контроллера-концентратора

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

В состав унифицированного системного контроллера входят:

- контроллер управления доступом (Плата Main-12002K);

- менеджер питания (Плата PWR-12002).

- кронштейн с индикаторами;

Блок-схема представлена на рисунке 3. Контроллер размещён в металлическом корпусе. Для защиты от несанкционированного доступа к его узлам передняя крышка закрывается с помощью механического замка.

2.3.2 Контроллер управления доступом

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

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

Рисунок 3 - Блок-схема унифицированного системного контроллера

2.4 Программное обеспечение системы

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

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

- Консоль администратора;

- Консоль управления со следующими разделами:

· Конфигуратор

· Справочники доступа

· Персонал (с модулем «Оформление пропусков»)

· Отчеты

· Доступ на объекты

· Мониторинг

- Сервер системы;

- Сервер управления данными;

- Сервер БД;

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

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

Они включают в себя следующие модули:

- «Учет рабочего времени»;

- «Видеоидентификация»;

- «Мониторинг с мнемосхемами»;

- «Интеграция с системой видеонаблюдения»;

- «Интеграция с охранно-пожарной сигнализацией»;

- «Планировщик задач»;

- «Мастер отчетов»;

ПО поддерживает следующие функции:

- Управление подсистемами контроллеров 600 серии (до 64 на один сервер аппаратуры) и 12000 серии (до 128 на один сервер аппаратуры), а также сбор информации с них. Количество подключаемых серверов аппаратуры не ограничено в пределах сети. Количество подключаемых серверов аппаратуры на одном компьютере равно количеству уникальных серий оборудования (на одном компьютере не может быть двух серверов аппаратуры одинаковой серии);

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

- Задание различных прав доступа пользователям ПО системы с помощью паролей;

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

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

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

- Задание индивидуальных графиков доступа сотрудников в помещения;

- Подключение системы видеонаблюдения;

- Подключение системы охранно-пожарной сигнализации;

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

- Мониторинг (слежение за тревожными событиями в системе) и управление аппаратурой с рабочего места оператора (блокировка и разблокировка турникетов, замков, перевод помещений в режим «Охрана», поднятие сигнала тревоги, оперативное запрещение доступа по пропуску в критических ситуациях);

- Защита от передачи карт при проходе через турникет;

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

Работать с программным обеспечением рекомендуется под управлением операционных систем MS Windows 2000 (SP4 или выше) / NT (SP6 или выше), Windows XP, Windows Server 2003, хотя возможен вариант работы и под управлением операционной системы Windows 98SE.

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

Работа ПО в локальных компьютерных сетях предоставляет возможность создания автоматизированных распределенных рабочих мест (АРМов) для различных служб.

АРМ «Администратор»

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

АРМ «Служба безопасности»

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

АРМ «Отдел кадров»

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

АРМ «Бюро пропусков»

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

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

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

3.1 Целесообразность разрабатываемого ПО

До недавнего времени комплекс существующего программного обеспечения полностью удовлетворял заказчика своим функционалом. Однако стоит указать, что система КУД Perco-SYS 12000 была установлена в 2000 году, т.е. срок ее непрерывной эксплуатации составил около 13 лет. За это время на рынке появилось достаточное количество новых систем, а установленная система подверглась не только моральному старению, а так же и физическому износу различных элементов системы.

В любой системе с большим количеством элементов и их высокой дальностью разнесения практически всегда существует понятие отказа. Система Perco-SYS 12000 является сертифицированной и в ней предусмотрены практически все варианты отказов. Но существует два отказа бесконтактного считывателя, которые были обнаружены и включены в техническую документацию только в 2012 году, в новой системе PERCo-S-20, вырезка из документации представлена на рисунке 4.

Рисунок 4- Фрагмент документации бесконтактного считывателя

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

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

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

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

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

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

3.2 Описание ПО и алгоритмы работы

Основные положения принятые при разработке программы:

- Автономность работы;

- Гибкая настройка функций проверки каждого контроллера;

- Возможность выполнения всех операций вручную;

- Обязательное ведение журнала событий;

- Интуитивно понятный интерфейс;

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

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

- Возможность остановки программы во время проверки;

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

На рисунке 6 показан алгоритм проверки контроллера на состояние.

Рисунок 5 - Алгоритм загрузки программы и начала проверки



Рисунок 6 - Алгоритм проверки контроллера на состояние

3.3 Интерфейс и работа ПО

Программа разрабатывалась в среде программирования Borland C++ Builder 6, таблицы БД - Paradox 7. C++ Builder 6 - программный продукт, инструмент быстрой разработки приложений (RAD), интегрированная среда программирования (IDE), система, используемая программистами для разработки программного обеспечения на языке программирования C++. Данный выбор обусловлен наличием опыта работы в данной программе, знанием языка С++, наличием в нем полного количества функций необходимых для работы.

Рисунок 7 - Главное меню программы

На данном меню (рисунок 7) расположены индикаторы общего состояния систем в трех городах. Присутствует активная строка состояния проверки. При нажатии на индикатор открывается форма, на которой представлен функционал и мнемосхема с расположением объектов и контроллеров.

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



Рисунок 8 - Внешний вид интерфейса программы, г.Гомель

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



Рисунок 9 - Внешний вид интерфейса программы, г. Речица

Рисунок 10 - Внешний вид интерфейса программы, г. Светлогорск

Запустить программу можно тремя различными способами: 1. автоматический запуск. Он производится по встроенному таймеру, в настройках можно указать время начала авто-проверки, указать интервал проверок, т.е. сколько раз в сутки будет включаться авто-проверка. 2. ручной запуск полной проверки. например, если нужно было срочно остановить сканирование, либо произошел сбой программы и настройки не сохранились можно вручную запустить полную проверку. 3. также можно по отдельности проверить каждый ТКД.

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

Рисунок 11 - Интерфейс программы, после завершения проверки

Рисунок 12- Запись в логе событий

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

Рисунок 13 - Диаграмма распределения и кол-ва проходов на этаже

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

Статистическое исследование представлено в главе 4.5.

Рисунок 14 - Окно настроек программы

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

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

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

4. Статистический анализ

4.1 Статистический анализ проходов

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

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

- По количеству проходов (c малым, средним и большим количеством проходов);

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

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

- По уровню ограниченности доступа (с ограничением и без ограничения доступа);

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

Без ограничения доступа - все остальные.

4.4.1 Статистика количества проходов

На предоставленных ниже рисунках изображены рассчитанные программой графики проходов через ТКД "Турникет 3", "Лифт и лестница 10 этаж", "Кабинет начальства", "Серверная" за месяц январь 2013 года.



Рисунок 15 - Количество проходов через ТКД "Турникет 3" за январь 2013

Рисунок 16 - Количество проходов через ТКД "Лифт и лестница 10 этаж" за январь 2013

Рисунок 17 - Количество проходов в кабинете начальства за январь 2013



Рисунок 18 - Количество проходов в серверной за январь 2013

На приведенных на рисунках 15, 16, 17, 18 примерах можно наглядно увидеть большое различие в количестве проходов и их распределении.

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

4.4.2 Определение критериев для минимального количества проходов через ТКД

Для статистического анализа данных были использованы программы Stat Plus+ и Statistica 10. Для удостоверения в том, что количество проходов через определенный ТКД в течении года и месяца, является стабильной величиной - принимаем гипотезу о нормальности распределения проходов. Ниже приведены графики и результаты анализа.



Рисунок 19 - Гистограмма за месячного распределения, график отклонения от ожидаемого нормального значения величины, график одномерного распределения вероятностей количества проходов через ТКД "Турникет 3" за январь месяц 2013 года

Рисунок 20 - График распределения с величинами квартилей

Таблица 2 - Проверка нормальности распределения проходов через ТКД "Турникет 3" за январь месяц 2013 года

Размер выборки	19	Среднее	895
Стандартное отклонение	44,913315	Медиана	897,5
Асимметрия	0,076	Эксцесс	2,472009
Альтернативная асимметрия (Фишера)	0,08382	Альтернативный эксцесс (Фишера)	-0,285587
Критерии оценки	Значение статистики	Уровень значимости	Вывод: (5%)
Критерий Колмогорова-Смирнова/Лиллифорcа	0,1592	0,2643	Никаких подтверждений против нормальности
Критерий Шапиро-Уилка	0,9711	0,8193	Нормальность принята
Д'Агостино Асимметрия	0,1658	0,8682	Нормальность принята
Д'Агостино Эксцесс	-0,0898	0,9284	Нормальность принята
Д'Агостино общее	0,0355	0,9823	Нормальность принята

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

Рассмотрим годичное распределение нагрузки на ТКД "Турникет 3".

Рисунок 21 - Гистограмма за годичное распределения, график отклонения от ожидаемого нормального значения величины, график одномерного распределения вероятностей количества проходов через ТКД "Турникет 3" за 2013 год



Рисунок 22 - График распределения с величинами квартилей

Таблица 2 - Проверка нормальности распределения проходов через ТКД "Турникет 3" за 2013 год

Размер выборки	12	Среднее	856
Стандартное отклонение	35,62991593	Медиана	851
Асимметрия	0,133853278	Эксцесс	2,261688361
Альтернативная асимметрия (Фишера)	0,155985002	Альтернативный эксцесс (Фишера)	-0,397186065
Критерии	Значение статистики	Уровень значимости	Вывод: (5%)
Критерий Колмогорова-Смирнова/Лиллифорcа	0,124329254	0,905587091	Никаких подтверждений против нормальности
Критерий Шапиро-Уилка	0,989219079	0,99655086	Нормальность принята
Д'Агостино Асимметрия	0,24617551	0,805546373	Нормальность принята
Д'Агостино Эксцесс	-0,148278449	0,882123023	Нормальность принята
Д'Агостино общее	0,08258888	0,959546559	Нормальность принята

В итоге расчета был получен доверительный интервал для 95% площади выборки, а также получен прогноз наблюдений на его основе. Спрогнозированный нижний предел проходов равен 773, если количество проходов опустится ниже данного предела чуть более, чем на 5%,что полностью выйдет за пределы площади графика распределения, то выборка уже не будет подчиняться нормальному распределению. Соответственно выберем критерием минимального числа проходов в сутки (773/100)*5.5% = 730 проходов /сутки.

Предоставление статистического расчета для ТКД "Турникет и лестница 10 Этаж" не является значимым, т.к. при в 3 раза меньшем количестве проходов, полностью соответствует закономерностям проходов через ТКД "Турникет 3".

На примере месячной нагрузки рассмотрим статистику проходов через ТКД "Кабинет начальника".

Рисунок 23 - Гистограмма за годичное распределения, график отклонения от ожидаемого нормального значения величины, график одномерного распределения вероятностей количества проходов через ТКД "Кабинет начальника" за январь месяц 2013 г.



Рисунок 24 - График распределения с величинами квартилей

Таблица 3 - Проверка нормальности распределения проходов через ТКД "Кабинет начальника"за январь месяц 2013 года

Размер выборки	20	Среднее	5,3
Стандартное отклонение	1,809332532	Медиана	5
Асимметрия	-0,02297	Эксцесс	2,033033157
Альтернативная асимметрия (Фишера)	-0,024879	Альтернативный эксцесс (Фишера)	-0,8882999
Критерии	Значение статистики	Уровень значимости	Вывод: (5%)
Критерий Колмогорова-Смирнова/Лиллифорcа	0	1	Никаких подтверждений против нормальности
Критерий Шапиро-Уилка	0,938385746	0,223474043	Нормальность принята
Д'Агостино Асимметрия	0,051640221	0,95881537	Нормальность принята
Д'Агостино Эксцесс	-1,0371445	0,299668487	Нормальность принята
Д'Агостино общее	1,07833556	0,583233426	Нормальность принята



Рисунок 25 - Гистограмма за годичное распределения, график отклонения от ожидаемого нормального значения величины, график одномерного распределения вероятностей количества проходов через ТКД "Кабинет начальника" за 2013 год

Рисунок 26 - График распределения с величинами квартилей

Таблица 4 - Проверка нормальности распределения проходов через ТКД "Кабинет начальника" за 2013 год

Размер выборки	12	Среднее	5
Стандартное отклонение	0,953462589	Медиана	5
Асимметрия	-0,65726769	Эксцесс	2,64
Альтернативная асимметрия (Фишера)	-0,75514231	Альтернативный эксцесс (Фишера)	0,161333333
Критерии	Значение статистики	Уровень значимости	Вывод: (5%)
Критерий Колмогорова-Смирнова/Лиллифорcа	0	1	Никаких подтверждений против нормальности
Критерий Шапиро-Уилка	0,861657216	0,05128248	Нормальность принята
Д'Агостино Асимметрия	1,214425255	0,224585376	Нормальность принята
Д'Агостино Эксцесс	0,351106046	0,725508792	Нормальность принята
Д'Агостино общее	1,598104156	0,449755095	Нормальность принята

В итоге расчета был получен доверительный интервал для 95% площади выборки, а также получен прогноз наблюдений на его основе. Спрогнозированный нижний предел проходов равен 1,42, если количество проходов опустится ниже данного предела чуть более, чем на 5%,что полностью выйдет за пределы площади графика распределения, то выборка уже не будет подчиняться нормальному распределению. Однако, стоит учитывать, что начальник может уехать в командировку, находится на совещании или в отпуске и т.д.

Это делает количество посещений ненормированным, т.е. несмотря на полученные статистические данные устанавливаем критерием для минимального количества проходов через ТКД "Кабинет начальника" 0 проходов в сутки.

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

4.4.3 Определение критериев допустимого бездействия контроллера в сутки

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

Рисунок 22 - распределение нагрузки в сутки на ТКД "Турникет 3"

Рисунок 23 - распределение нагрузки в сутки на ТКД "Лифт+Лестница 10"

Рисунок 24- распределение нагрузки в сутки на ТКД "Кабинет начальника"

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

Для ТКД "Турникет 3" - активность происходит весь рабочий день без перерывов и с особенной нагрузкой в часы посещения и ухода с работы, что видно из рисунка 25. Соответственно можно сделать вывод, о том, что если в рабочие часы ТКД будет более 1 часа не иметь проходов, то вероятнее всего возникла ситуация отказа. ТКД "Турникет 3 " относится к классу многопроходных.

Для ТКД "Лифт+Лестница 10" - активность происходит чуть позже официального начала рабочего дня,что видно из рисунка 26. Т.к данный ТКДотносится к классу среднепроходных можно сделать вывод, о том, что если в рабочие часы ТКД будет более 2х часов бездействовать, то вероятнее всего возникла ситуация отказа.

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

5. Экономическое обоснование внедрения программного продукта. Расчет экономического эффекта

5.1 Основные положения расчёта стоимости программного обеспечения

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

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

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

· научно-техническая продукция;

· продукция производственно-технического назначения.

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

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

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

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

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

· сокращения расходов на оплату машинного времени и других ресурсов на отладку задач;

· снижения расходов на материалы (магнитные, лазерные диски и прочие материалы);

· ускорения ввода в эксплуатацию новых систем;

· улучшения показателей основной деятельности предприятий в результате использования ПО.

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

· затраты на материалы;

· спецоборудование;

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

· отчисления в фонд социальной защиты населения;

· налоги, входящие в себестоимость ПО;

· машинное время;

· расходы на научные командировки;

· прочие расходы;

· накладные расходы.

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

5.2 Исходные данные

Расчет основной заработной платы исполнителей, занятых разработкой ПО, производится на основе исходных данных, представленных в таблице 5.1.

· В выполнение работ задействованы следующие разработчики ПО:

· начальник отдела (руководитель дипломного проекта):

· тарифный разряд - 13;

· тарифный коэффициент - 3,98;

· продолжительность участия в разработке - 20 дней;

· инженер программист (студент дипломник):

· тарифный разряд - 9;

· тарифный коэффициент - 2,48;

· продолжительность участия в разработке - 40 дней.

Таблица 5.1 - Исходные данные

Наименование показателей	Буквенные обозначения	Единицы измерения	Количество
Коэффициент новизны	kн	единиц	1,0
Группа сложности		единиц	3
Дополнительный коэффициент сложности	kсл	единиц	1,12
Поправочный коэффициент, учитывающий использование типовых программ	Kт	единиц	0,9
Установленная плановая продолжительность разработки	Tр	лет	0,15
Годовой эффективный фонд времени	Ф+	дней	255
Продолжительность рабочего дня	Tч	ч	8
Тарифная ставка 1-го разряда	Tм1	руб.	250000
Коэффициент премирования	kп	единиц	1,4
Норматив дополнительной заработной платы	Hзд	%	10
Ставка отчислений в фонд социальной защиты населения	Hзсз	%	34,6
Норматив на сопровождение и адаптацию ПО	Hрса	%	10
Ставка налога на добавленную стоимость	Hдс	%	20
Норматив амортизации ВТ	На	%	12,5

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

Объем ПО определяется путем подбора аналогов на основании классификации типов ПО [11, приложение 1], каталога функций ПО и каталога аналогов ПО в разрезе функций [11, приложение 2 и 3], которые постоянно обновляются и утверждаются в установленном порядке. На основании информации о функциях разрабатываемого ПО, по каталогу функций определяется объем функций [11, приложение 2]. Затем по каталогу аналогов в разрезе функций уточняется объем функций [11, приложение 3]. На основании этих данных составлена таблица 5.2.

Общий объем ПО рассчитывается по формуле 5.1:

(5.1)

где - общий объем ПО, условных машинных команд;

- объем функций ПО, условных машинных команд;

n- общее число функций.

По формуле (5.1) определим общий объем ПО:

условных машинных команд.

Таблица 5.2 - Объем программного обеспечения

Номер функции	Содержание функций	Объем (условных машинных команд)
101	Организация ввода информации	170
104	Преобразование операторов входного языка в команды другого языка	286
111	Управление вводом/выводом	100
304	Обслуживание файлов	120
309	Формирование файла	139
503	Управление внешним ПО	300
505	Управление внешней памятью	207
506	Обработка ошибочных и сбойных ситуаций	150
507	Обеспечение интерфейса между компонентами	2347
702	Расчётные задачи (расчёт режимов обработки)	988

5.4 Расчёт трудоёмкости ПО

На основании общего объема ПО определяется нормативная трудоемкость Tн по таблицам. Нормативная трудоемкость устанавливается с учетом сложности ПО. Выделяется три группы сложности [11, приложение 5, таблица 5.1], в которых учтены следующие составляющие ПО: языковой интерфейс, ввод-вывод, организация данных, режимы работы, операционная система и техническая среда. Кроме того, устанавливаются дополнительные коэффициенты сложности ПО [11, приложение 5, таблица 5.2].

С учетом дополнительного коэффициента сложности kсл (таблица 5.1) рассчитывается общая трудоемкость ПО (формула 5.2)

(5.2)

где Т_о - общая трудоемкость ПО, человеко-дней;

Т_н - нормативная трудоемкость ПО, человеко-дней;

k_сл - дополнительный коэффициент сложности ПО.

По данным [12, таблица 3.1] объему в 4807 условных машинных команд (3-я группа сложности ПО) соответствует нормативная трудоемкость 105 человеко-дней. По формуле (5.2) определим общую трудоемкость ПО:

При решении сложных задач с длительным периодом разработки ПО трудоемкость определяется по стадиям разработки (техническое задание - ТЗ, эскизный проект - ЭП, технический проект - ТП, рабочий проект - РП и внедрение - ВН) с учетом новизны, степени использования типовых программ и удельного веса трудоемкости стадий разработки ПО в общей трудоемкости разработки ПО. При этом на основании общей трудоемкости рассчитывается уточненная трудоемкость с учетом распределения по стадиям (формула 5.3)

где Т_у - уточненная трудоемкость ПО, человеко-дней;

Т_i - трудоемкость разработки ПО на i-й стадии, человеко-дней;

m - количество стадий разработки.

Трудоемкость ПО по стадиям определяется с учетом новизны [11, приложение 5, таблица 5.3, 5.4] и степени использования в разработке типовых программ и ПО [11, приложение 5, таблица 5.5] (формула 5.4)

(5.4)

где T_стi - трудоемкость разработки ПО на i-й стадии (технического задания, эскизного проекта, технического проекта, рабочего проекта и внедрения), человеко-дней;

k_н - поправочный коэффициент, учитывающий степень новизны ПО;

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

d_стi - удельный вес трудоемкости i-й стадии разработки ПО в общей трудоемкости ПО.

На основании уточненной трудоемкости разработки ПО и установленного периода разработки рассчитывается общая плановая численность разработчиков ПО (формула 5.5)

где Ч_р - плановая численность разработчиков, чел.;

Ф_эф - годовой эффективный фонд времени работы одного работника в течение года, дней в год;

T_рд - плановая продолжительность разработки ПО, лет.

Результаты расчетов уточненной трудоемкости и общей плановой численности разработчиков на разных стадиях разработки по формулам (5.4) и (5.5) представлены в таблице 5.3.

Таблица 5.3 - Результаты расчетов трудоемкости

	Стадии разработки	Итого
	ТЗ	ЭП	ТП	РП	ВН
Коэффициенты удельных весов трудоемкости стадий, dстi	0,11	0,09	0,11	0,55	0,14	1,0
Коэффициенты, учитывающие использование типовых программ, kт	-	-	-	0,9	-	-
Коэффициенты новизны, kн	1,0	1,0	1,0	1,0	1,0	-
Уточняющая трудоемкость Tу стадий, человеко-дней	13	11	13	58	17	112
Численность Чр исполнителей, чел.	0,34	0,29	0,34	1,75	0,51	3,23
Срок Tр разработки, лет	0,026	0,026	0,026	0,03	0,03	0,14

Например, по формуле (5.4) определим уточненную трудоемкость на стадии рабочего проекта

Например, по формуле (5.5) определим общую плановую численность разработчиков на стадии рабочего проекта

.

5.5 Расчёт заработной платы разработчиков ПО

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

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

Месячная тарифная ставка каждого исполнителя Т_м определяется путем умножения действующей месячной тарифной ставки 1-го разряда Т_м1 на тарифный коэффициент Тk, соответствующий установленному разряду (формула 5.6)

. (5.6)

Часовая тарифная ставка рассчитывается путем деления месячной тарифной ставки на установленный при семичасовом рабочем дне фонд рабочего времени - 169,8 часов (формула 5.7)

где Т ч - часовая тарифная ставка, ден. ед.;

Т м - месячная тарифная ставка, ден. ед.

По формулам (5.6) и (5.7) определим месячные и тарифные ставки начальника отдела (Tмо, Tчо) и инженера программиста 1-й категории (T_мп, T_чп)

Основная заработная плата исполнителей ПО рассчитывается по формуле 5.8

где n - количество исполнителей, занятых разработкой ПО;

Т_чi - часовая тарифная ставка i-го исполнителя, ден. ед.;

Ф_эi - эффективный фонд рабочего времени i-го исполнителя, дней;

Т_ч - количество часов работы в день, ч;

k_п - коэффициент премирования.

По формуле (5.8) определим основную заработную плату исполнителей ПО

рублей.

Дополнительная заработная плата на ПО Здi включает выплаты, предусмотренные законодательством о труде (оплата, отпусков, льготных часов, времени выполнения государственных обязанностей и других выплат, не связанных с основной деятельностью исполнителей), и определяется по нормативу в процентах к основной заработной плате (формула 5.9)

где З_дi - дополнительная заработная плата исполнителей ПО, ден. ед.;

Н_д - норматив дополнительной заработной платы в целом по научной организации.

По формуле (5.9) определим дополнительную заработную плату на ПО

5.6 Расчёт отчислений, налогов и затрат

Отчисления в фонд социальной защиты населения Зсзi определяются в соответствии с действующими законодательными актами по нормативу в процентном отношении к фонду основной и дополнительной заработной платы исполнителей (формула 5.10).

где Н_зсз - норматив отчислений в фонд социальной защиты населения, %. По формуле (5.10) определим отчисления в фонд социальной защиты населения:

Расходы по статье “спецоборудование” P_ci включают затраты средств на приобретение вспомогательных специального назначения технических и программных средств, необходимых для разработки ПО, включая расходы на их проектирование, изготовление, отладку, установку и эксплуатацию. Затраты по этой статье определяются в соответствии со сметой расходов, которая составляется перед разработкой ПО. Данная статья включается в смету расходов на разработку ПО в том случае, когда приобретаются специальное оборудование или специальные программы, предназначенные для разработки и создания только данного ПО.

В крупной корпорации, амортизационные отчисления на ПО А_oi можно определить прямым счетом по формуле 5.11:



где Аoi - амортизационные отчисления по конкретному средству ВТ в расчете на год, ден. ед.;

Тф - фактический срок использования основной ВТ (здесь равен 110 дней или 0,3 года);

Псi - первоначальная стоимость ВТ.

По формуле (5.12) определим сумму амортизационных отчислений

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

Расходы по статье “прочие затраты” П_зi на ПО включают затраты на приобретение и подготовку специальной научно-технической информации и специальной литературы. Определяются по нормативу, разрабатываемому в целом по научной организации, в процентах к основной заработной плате (формула 5.12)

где H_пз - норматив прочих затрат в целом по научной организации, %.

По формуле (5.12) определим прочие затраты

Общая сумма расходов по всем статьям сметы С_рi на ПО рассчитывается по формуле 5.13

(5.13)

где M_i = 5000 - затраты на бумагу;

По формуле (5.13) определим общую сумму расходов

Кроме того, организация-разработчик осуществляет затраты на сопровождение и адаптацию ПО P_саi (формула 5.14), которые определяются по нормативу H_рса

где H_рса - норматив расходов на сопровождение и адаптацию, %.

По формуле (5.14) определим расходы на сопровождение и адаптацию

Далее произведем расчёт себестоимости, отпускной цены и прибыли.

Общая сумма расходов на разработку (с затратами на сопровождение и адаптацию) как полная себестоимость ПО Спi определяется по формуле 5.15

(5.15)

По формуле (5.15) определим полную себестоимость ПО

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



где П_рi - прибыль от реализации ПО заказчика, ден. ед.;

У_рпi - уровень рентабельности ПО, принимаем 25 %;

С_пi - себестоимость ПО, ден. ед.

По формуле (5.16) определим прибыль от реализации создаваемого ПО

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

где Н_дсi - налог на добавленную стоимость, ден. ед.;

Д_сi - добавленная стоимость, ден. ед.;

Н_ндс - норматив налога на добавленную стоимость, %.

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

Добавленная стоимость на ПО рассчитывается по формуле 5.18

(5.18)

На реализацию создаваемого ПО льготы по налогу на добавленную стоимость Ндсi не распространяются. В связи с этим добавленная стоимость на ПО определяется по формуле (5.18)

.

По формуле (5.18) определим налог на добавленную стоимость

Прогнозируемая отпускная цена ПО представляет собой сумму себестоимости, прибыли и налога на добавленную стоимость (формула 5.19)

(5.19)

По формуле (5.19) определим прогнозируемую отпускную цену ПО

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

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

6. Классификация воздушных и воздушно-тепловых завес

6.1 Классификация завес

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

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

Воздушные завесы имеют следующие основные элементы:

- калорифер;

- вентиляционный агрегат;

- система воздуховодов и каналов;

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

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

6.2 Схемы воздушно-тепловых завес

Двухсторонняя завеса с боковой раздачей воздуха с подводом снизу к вентколонкам от двух вентиляционных центров и воздухозабором из рабочей зоны или района завесы (рисунок 27).



Рис. 27- Двухсторонняя завеса с боковой раздачей воздуха с подводом снизу к вентколонкам от двух вентиляционных центров: 1 - калорифер; 2 - вентиляционный агрегат; 3 -система воздуховодов; 4 - вентиляционная колонка или воздуховод равномерной раздачи

Двухсторонняя завеса с подводом сверху с боковой раздачей от одного вентиляционного центра и забором воздуха из рабочей зоны или района завесы (рисунок 28).

Рис. 28 - Двухсторонняя завеса с подводом сверху с боковой раздачей от одного вентиляционного центра

Двухсторонняя завеса с подводом сверху с боковой раздачей от одного вентиляционного центра и забором воздуха из верхней зоны (рисунок 29).



Рис. 29 - Двухсторонняя завеса с подводом сверху с боковой раздачей от одного вентиляционного центра

Унифицированная воздушно-тепловая завеса СТД-300М (монтируется в блоке) (рисунок 30).

Рис. 30 - Унифицированная воздушно-тепловая завеса СТД-300М

Двухсторонняя воздушно-тепловая завеса с боковой раздачей воздуха с подводом воздуха сверху от двух вентиляционных центров и воздухозабором и воздухозабором снаружи здания (рисунок 31).

Рис. 31 - Двухсторонняя воздушно-тепловая завеса с боковой раздачей воздуха с подводом воздуха сверху от двух вентиляционных центров

Унифицированная воздушно-тепловая завеса А6,3х3000 (вентиляционная колонка) (рисунок 32).

Рис. 32 - Унифицированная воздушно-тепловая завеса А6,3х3000

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

6.3 Классификация воздушно-тепловых завес

Воздушно-тепловые завесы имеют следующую классификацию.

По режиму работы:

- постоянного действия;

- периодического действия.

Режим работы завесы определяется следующими факторами:

- требованиями к параметрам микроклимата в помещении;

- наличием постоянных рабочих мест в районе завесы;

- режимом работы общеобменных приточных систем вентиляции.

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

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

По направлению действия струи (рисунок 33):

- струя, выпущенная снизу вверх

- струя, выпущенная сбоку

- струя выпущенная сверху вниз

Рис. 33 - Направления воздушных струй, выпущенных из ВТЗ

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

В промышленных зданиях наибольшее распространение получала схема 2.2. Двухстороннюю боковую раздачу проектируют при ширине проема более 2,5 м; при ширине проема менее 2,5 м проектируют одностороннюю боковую раздачу.

В общественных зданиях и административно-бытовых комплексах в основном конструируют воздушно-тепловые завесы по схеме 2.3 (это связано с планировкой помещений).

По температуре подаваемого воздуха и месту воздухозабора на завесу:

- воздушно-тепловые завесы с подогревом воздуха и воздухозабором из помещения:

- воздушная завеса без подогрева и воздухозабором из помещения:

- воздушно-тепловая завеса с подогревом и забором воздуха снаружи здания:

- воздушная завеса без подогрева и воздухозабором снаружи здания:

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

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

Схема 3.3 используется, если завеса является приточной системой вентиляции.

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

Воздушные и воздушно-тепловые завесы следует предусматривать в следующих случаях:

- у постоянно открытых проемов в наружных стенах помещений, а также у ворот и проемов в наружных стенах, не имеющих тамбуров и открывающихся более пяти раз или не менее чем на 40 мин в смену, в районах с расчетной температурой наружного воздуха минус 15 °С и ниже (параметры Б);

- у наружных дверей вестибюлей общественных и административно бытовых зданий - в зависимости от расчетной температуры (°С) наружного воздуха (параметры Б) и числа людей, проходящих через двери в течение 1 ч:

от минус 15 до минус 25 - 400 чел. и более;

от минус 26 до минус 40 - 250 чел. и более;

ниже минус 40 - 100 чел. и более;

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

- у наружных дверей, ворот и проемов помещений с мокрым режимом;

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

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

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

Воздушные и воздушно-тепловые завесы у наружных проемов, ворот и дверей следует рассчитывать с учетом ветрового давления. Расход воздуха следует определять, принимая температуру наружного воздуха и скорость ветра при параметрах Б, но не более 5 м/с. Если скорость ветра при параметрах Б меньше, чем при параметрах А, то воздухонагреватели следует проверять на параметры А. Скорость (м/с) выпуска воздуха из щелей или отверстий воздушно-тепловых завес следует принимать не более:

8 - у наружных дверей;

25 - у ворот и технологических проемов.

Расчетную температуру tсм (°С) смеси воздуха, поступающего в помещение через наружные двери, ворота и проемы, следует принимать не менее:

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

5 - для производственных помещений при тяжелой работе и отсутствии постоянных рабочих мест на расстоянии 6 м и менее от дверей, ворот и проемов.

На практике часто пользуются данными из СНиП 2.04.05-91* [17].

Температуру воздуха, подаваемого воздушно-тепловыми завесами, следует принимать не выше 50°С у наружных дверей и не выше 70°С у наружных ворот и проемов.