- Сервер использует name_attach() для регистрации сервиса в GNS и name_deattach для обратного процесса.

- Клиент использует name_open() для открытия зарегистрированного сервиса и name_close() соответственно для его закрытия.

Так как такой функционал полезен в построении кластера рассмотрим этот процесс подробнее:

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

Типичный вызов name_attach() выглядит так:

if ((attach = name_attach(NULL, "printer", NAME_FLAG_ATTACH_GLOBAL) == NULL){

returnEXIT_FAILURE;

}

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

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

Клиент для присоединения к сервису вызывает функцию name_open().

if ((fd = name_open("printer", NAME_FLAG_ATTACH_GLOBAL)) == -1)

{

returnEXIT_FAILURE;

}

Если флаг не указывать GNS будет искать ресурс только локально.

Все зарегистрированные сервисы хранятся в каталоге /dev/name/global или /dev/name/local в зависимости от того, как они зарегистрированы.

Для всех узлов в локальной сети каталог /dev/name/global одинаковый. А каталог /dev/name/local хранит информацию о локально зарегистрированных сервисах.

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

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

В случае с избыточным GNS каждый клиент регистрирует сервис в каждом GNS сервере. Между собой GNS сервера общаться не могут.

Вот так выглядит избыточная конфигурация GNS сервера.

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

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

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

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

Помимо всего прочего QNET поддерживает QoS. В зависимости от заданной политики qnet распределяет трафик между сетевыми интерфейсами.

Существует три политики выбора интерфейса:

- loadbalancing ( политика по умолчанию ) - равномерно распределяет трафик между интерфейсами

- preffered - использует один интерфейс, игнорируя все другие, до тех пор пока интерфейс не откажет

- exclusive - использует только один интерфейс, даже если он откажет

Рассмотрим подробнее каждую из них:

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

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

- exclusive - Здесь используется только один интерфейс, не зависимо от того сколько интерфейсов еще доступно. Если такой интерфейс откажет Qnet не будет использовать доступные интерфейсы.

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

/net/node1~exclusive:en0/dev/ser1

Помимо всего вышеописанного QNX поддерживает очень важный и ключевой механизм для моей работы: менеджер высокой доступности (HAM - High Avaliability Manager).

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

QNX сама по себе является системой высокой доступности и поэтому отлично подходит для таких ситуаций. Помимо уже описанной микроядерности QNX предоставляет компоненты высокой доступности: HAM - high avaliability manager (менеджер высокой доступности) и high availability client-side library (клиентская библиотека высокой доступности).

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

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

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <errno.h>

#include <ha/cover.h>

#define TESTFILE "/net/machine99/home/test/testfile"

typedef struct handle {

int nr;

int curr_offset;

} Handle ;

int recover_conn(int oldfd, void *hdl)

{

int newfd;

Handle *thdl;

thdl = (Handle *)hdl;

newfd = ha_reopen(oldfd, TESTFILE, O_RDONLY);

if (newfd >= 0) {

// устанавливаем смещение в последнюю известнуюточку

lseek(newfd, thdl->curr_offset, SEEK_SET);

// счетчик успешных восстановлений

(thdl->nr)++;

}

return(newfd);

}

int main(int argc, char *argv[])

{

int status;

int fd;

int fd2;

Handle hdl;

char buf[80];

hdl.nr = 0;

hdl.curr_offset = 0;

// открываем сессию

// функцией восстановления будет recover_conn

// hdl будет передан ей в качестве параметра

fd = ha_open(TESTFILE, O_RDONLY, recover_conn, (void *)&hdl, 0);

if (fd < 0) {

printf("could not open file\n");

exit(-1);

}

status = read(fd,buf,15);

if (status < 0) {

printf("error: %s\n",strerror(errno));

exit(-1);

}

else {

hdl.curr_offset += status;

}

fd2 = ha_dup(fd);

// fs-nfs2 отказывает,в этот момент

// начинается процесс восстановления

// Старый дескриптор fd уже не актуален

sleep(18);

// Пытаемся читать что - то из файла с дескриптором fd

// получаем ошибку, восстанавливаемся с помощью recover_conn

status = read(fd,buf,15);

if (status < 0) {

printf("error: %s\n",strerror(errno));

exit(-1);

}

else {

hdl.curr_offset += status;

}

printf("total recoveries, %d\n",hdl.nr);

ha_close(fd);

ha_close(fd2);

exit(0);

}

Так как библиотека взаимодействует с низкоуровневым вызовом MsgSend(), то стандартные библиотечные функции (open(), read(), write(), printf() и т.д.) также можно сделать высокодоступными.

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

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

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

Рассмотрим подробнее как устроен HAM.

HAM состоит из трех основных частей :

- Сущности

- Условия

- Действия

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

Существует три фундаментальных типа сущностей:

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

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

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

- Условия - представляют состояние сущностей.

Условие	Описание
CONDDEATH	Сущность умерла.
CONDABNORMALDEATH	Сущность ненормально завершила свою работу. Когда сущность умирает таким способом, генерируется файл дампа ядра.
CONDDETACH	Сущность больше не является объектом мониторинга HAMа.
CONDATTACH	HAM мониторит сущность.
CONDBEATMISSEDHIGH	The entity missed sending a "heartbeat" message specified for a condition of "high" severity.
CONDBEATMISSEDLOW	The entity missed sending a "heartbeat" message specified for a condition of "low"
CONDRESTART	Сущность была успешно перезапущена.
CONDRAISE	Произошло какое то внешнее событие. Подписчики на это события могут указывать что делать при его возникновении.
CONDSTATE	Состояние сущности изменилось. Подписчики на изменения могут также указывать что при этом делать.
CONDANY	Любое условие. Можно также ассоциировать какое то действие с этим условием

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

- Действия

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

Действие	Описание
ham_action_restart()	Перезапустить сущность.
ham_action_execute()	Запустить какую - либо команду.
ham_action_notify_pulse()	Уведомить процессы о возникновении условия. Уведомление посылается со специальной переменной pulse, значение которой задает процесс, желающий получить уведомление.
ham_action_notify_signal()	Уведомить процессы о возникновении условия. Уведомление посылается с использованием специального сигнала, значение которого задает процесс, желающий получить уведомление.
ham_action_notify_pulse_node()	То же самое что и ham_action_notify_pulse() только с указанием конкретного узла
ham_action_notify_signal_node()	То же самое что и ham_action_notify_signal() только с указанием конкретного узла
ham_action_waitfor()	Позволяет организовывать паузы между действиями, если их несколько
ham_action_heartbeat_healthy()	Если сущность перестает посылать сигналы heartbeat функция перезапускает механизм и запускает условие CONDBEATMISSEDHIGH или CONDBEATMISSEDLOW.
ham_action_log()	Посылает условие в лог.

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



· ham_action_fail_execute()

· ham_action_fail_notify_pulse()

· ham_action_fail_notify_signal()

· ham_action_fail_notify_pulse_node()

· ham_action_fail_notify_signal_node()

· ham_action_fail_waitfor()

· ham_action_fail_log()

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

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

Существует два пути уведомления HAM о событиях:

- Уведомление об изменении состояния.

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

Для уведомления об изменении состояния необходимо вызвать функцию ham_entity_condition_state(). Для подписки на такие уведомления необходимо вызвать функцию ham_condition_state().

- Другие уведомления.

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

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

Заключение исследовательской части

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

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

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

QNX также предоставляет механизм балансировки нагрузки, так же из "коробки". Благодаря Qnet взаимодействие между процессами в распараллеленной программе становится прозрачным.

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

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

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

Специальная часть

Итак, необходимо используя все преимущества системы QNX построить на ней кластер высокой доступности. Для тестирования кластера я буду использовать образы виртуальных машин с QNX в VmwarePlayer.

Практическая часть включает систему управления ресурсами кластера (программную) а также общую схему работы системы.

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

Архитектура кластера, в общем, выглядит следующим образом:

Узлы кластера объединяются в доверенную сеть Qnet.

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

2) На каждом узле запускается менеджер ресурсов кластера

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

Алгоритм работы менеджера кластера следующий:

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

Рассмотрим подробнее каждый тип кластера.

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

Сначала на выбранном активном узле (мастере) запускаем менеджер.



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

Менеджер выдает список процессов и доступных узлов.

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

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

Активный узел начинает отслеживать состояние критических сервисов. Пассивные узлы синхронизируются с активным с помощью rsync

Далее программа работает по следующему алгоритму:



Кластер типа активный/активный

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

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

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

Кластер типа N+1

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

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

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

Расчет надежности. Надежность программного обеспечения

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

- Завершенность

- Восстанавливаемость

- Устойчивость

- Доступность

Завершенность

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

Рассчитаем среднее время наработки на ошибку.

Средняя наработка на ошибку рассчитывается следующим образом:



где лПО - интенсивность ошибок программного обеспечения.

Интенсивность ошибок разрабатываемого программного обеспечения рассчитывается по формулам:

где ф -время отладки;

б - коэффициент крутизны линии, характеризующий скорость роста надежности;

N0 - число обнаруженных ошибок во время отладки;

N -число строк кода;

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

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

КЯЗi - коэффициент, учитывающий использование i-го языка программирования;

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

В данном программном обеспечении использована процедурная технология программирования (КТПi = 0,1), язык программирования Си (КЯЗi = 2), операционная система QNX (КПЛi = 1.5)



КТП = 0,1*2*1,5 = 0,3

Количество строк кода N = 2037.

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

Число ошибок	Время отладки	Интенсивность ошибок
13	1	0,001914584
10	2	0,000736377
7	3	0,000343642
5	4	0,000184094
3	5	0,000088365
2	6	0,000049091
1	7	0,000021039
1	8	0,000018409
1	9	0,000016363
0	10	0

На основе полученных данных построим кривую зависимости интенсивности ошибок от времени отладки

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

Таким образом, интенсивность ошибок разрабатываемого ПО составляет:

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

Степень покрытия тестами функции и структуры программы.

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

- Покрытие утверждения

- Покрытие ветвей

- Покрытие условий

Покрытие утверждений. Здесь нужно следить за тем, выполнялась ли каждая строка кода, по крайней мере, один раз. Чтобы достичь 100%-го покрытия утверждений, понадобится выполнить утверждение IF, причем оно должно принять значение TRUE для выполнения соответствующего требования THEN.

Покрытие ветвей. В данном случае нужно следить затем, была ли взята каждая ветвь или точка принятия решения при всех возможных исходах. Чтобы покрытие было 100%-м, требуется два прохода через условие IF, когда при одном проходе оно принимает значение TRUE, а при другом - FALSE. Каждый цикл DO-WHILE так же должен быть выполнен при условиях TRUE и FALSE. Для утверждений CASE или SWITCH требуются тестовые примеры, которые будут брать все возможные ветки, включая заданные по умолчанию пути.

Покрытие условий. Оно известно так же как покрытие предикатов и следит затем, принимает ли каждый операнд в комплексных логических выражениях значения FALSE/TRUE. Комплексные логические выражения содержат операторы AND, OR и XOR.

Каждый из этих типов покрытия содержит в себе более низкие уровни. Достижение 100%- го покрытия ветвей означает 100%- ное покрытие утверждений. Аналогично достижение 100%- го покрытия условий автоматически приводит к удовлетворению 100%- го покрытия ветвей.

На основе тестирования были получены следующие коэффициенты:

Коэффициент полноты:

,

Где Р - степень покрытия тестами в процентах.

Коэффициент достоверности:

Где Nпр - число прогонов;

Nош - число ошибок, обнаруженных во время данных прогонов.

Kдост = 600-43/600 = 0,928

Устойчивость

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

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

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

Восстанавливаемость

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

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

Доступность

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

Коэффициент готовности рассчитывается по формуле:



,

где То - средняя наработка на ошибку (2682 часов),

Тв - время восстановления программы (0,1 минуты=0,0016 часа).

Таким образом, коэффициент готовности разрабатываемой системы:

.

Раздел по безопасности жизнедеятельности

Защитное зануление системы.

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

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

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

Нулевой защитный проводник(в системе TN - S - PE - проводник) - проводник, соединяющий открытые проводящие части с глухозаземленной нейтральной точкой источника питания трехфазного тока или с заземленным выводом источника питания однофазного тока.

Нулевой защитный проводник отличают от PEN - проводника и рабочего нулевого проводника.

Нулевым рабочим проводником (в системе TN - S - N - проводник) называют проводник, предназначенный для питания электроприемников, соединенный с глухозаземленной нейтральной точкой генератора или трансформатора в сетях трехфазного тока, с глухозаземленным выводом источника однофазного тока, с глухозаземленной точкой источника в сетях постоянного тока, в установках с напряжением до 1 кВ.

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

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

Зануление применяется в следующих случаях:

- В установках с напряжением до 1 кВ в трехфазных сетях переменного тока с заземленной нейтралью;

- В установках с напряжением до 1 кВ в однофазных сетях переменного тока с заземленным выводом;

- В установках с напряжением до 1 кВ в сетях постоянного тока с заземленной средней точкой источника.

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

Принципиальная схема зануления:

1 - корпус электроустановки

R0 - сопротивление заземления нейтрали;

RП - сопротивление повторного заземления нулевого защитного проводника;

Iк - ток короткого замыкания;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Расчет защитного зануления системы

Напряжение Uф=220В

Мощность S=120кВА

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

Расстояние до потребителя L=110м.

- Ток нагрузки приемника

- Ток плавкой вставки.

Кi=5-кратность пускового тока, б=1,5-для электродвигателя с тяжелыми условиями пуска

Выбираем предохранитель типа ПН-2 , его параметры:

Номинальный ток - 400А

Номинальный ток плавкой вставки-315А

Наибольший отключаемый ток - 40000А

- Сопротивление фазных проводников, сечение 50мм2

с-удельное сопротивление алюминия

S-сечение проводника

L-длина проводника

- Сопротивление зануляющего проводника, сечение 100мм2:

- Величина внешнего индуктивного сопротивления:

- Полное сопротивление петли фаза-нуль

Где, ZT=0,779Ом-сопротивление трансформатора

Хф=Хн=0-индуктивные сопротивления Al проводов

- Значение тока короткого замыкания

- Корпусный потенциал

- Ток проходящий через тело человека



Экономическая часть

Расчет затрат на разработку дипломного проекта.

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

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

(цена компьютера * время работы)/36.

Цена компьютера 25 000 рублей. Время работы 4месяца.

Стоимость аренды = 25000 * 4 / 36 = 2700рублей.

Рассчитаем теперь стоимость необходимого программного обеспечения:

- Среда разработки программ QNX Momentics IDE- учебная лицензия бесплатно;

- Образ операционной системы QNX Neutrino-учебная лицензия бесплатно;

- Программа для запуска виртуальных машин - Vmware Player-бесплатно;

- Microsoft Office для дома и учебы - 3500 рублей

- Windows 8 Pro - 3500 рублей

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

- Бумага для печати (200 листов) - 150 рублей

- Диски (2 штуки) - 30 рублей

- Флеш-накопитель - 450 рублей

Во время дипломного проекта использовался интернет и мобильная связь.

- Расход на интернет - 550 рублей/месяц;

- Расходы на мобильную связь - 150 рублей/месяц.

Общая стоимость за все время разработки:

- Интернет - 2200 рублей;

- Мобильная связь - 600 рублей.

Заработная плата исполнителя дипломного проекта:

Заработная плата за месяц, руб/мес.	Время выполнения ДП, дни	Сумма, руб.
50000	120	200000

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

Наименование	Сумма, руб.
Аренда оборудования	2700
Программное обеспечение	7000
Расходные материалы	630
Интернет и мобильная связь	2800
Заработная плата	200000
Итого	213130

Расчет прибыли, налогов и рентабельности.

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

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

Прибыль = рентабельность * цена без налога

Цена без налога = Затраты + Прибыль

Прибыль = (рентабельность * затраты) / (1 - рентабельность) = (0,45 * 213130) / (1 - 0,45) = 174272 рублей.

Расчет налогов.

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

Налог Пенсионного фонда Российской Федерации (ПФР). Данный налог составляет 26% от минимального размера оплаты труда (МРОТ). Минимальный размер оплаты труда в России составляет 5205 рублей.

Нпфр = 5205 · 0,26 · 2 · 4 = 10846,2 рублей.

Налог Федерального фонда обязательного медицинского страхования (ФФОМС). Данный налог составляет 5,1% от минимального размера оплаты труда (МРОТ). Минимальный размер оплаты труда в России составляет 5205 рублей.

Нффомс = 5205 · 0,051 · 4 = 1061,91 рублей.

Налог на доход в рамках Упрощенной системы налогообложения (УСНО). Данный налог составляет 6% от дохода. Доходом в данном случае является цена изделия. Цена изделия складывается из общих затрат и прибыли.

Цена изделия = затраты + прибыль

Нусно = (затраты + прибыль) · 0,06 = 11329,49 рублей.

Итого:

Налоги = Нпфр + Нффомс + Нусно = 22236 рублей.

Расчет общей стоимости разработки

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



Цена проекта = Затраты + Налоги + Прибыль

Цена проекта = 213130 + 22236 + 174272 = 409638 рублей.

Размещено на Allbest.ur

...