Разработка системы контроля параметров линейной батареи на узле коммутации

- обнаруживается ошибка CRC номера посылки в пакете START OF FRAME (SOFI, FNCERR=1);

- пакет STALL (EPINTx, STALLEDI=1);

- ошибка CRC в изохронном режиме в направлении OUT (EPINTx, STALLEDI=1);

- переполнение в изохронном режиме (EPINTx, OVERFI=1);

- незаполнение в изохронном режиме (EPINTx, UNDERFI=1);

- отправлено NAK в направлении IN (EPINTx, NAKINI=1);

- отправлено NAK в направлении OUT (EPINTx, NAKOUTI=1).

4.12 Регистры USB общего назначения и конечных точек (режим Device)

Регистрами USB общего назначения задается режим работы интерфейса. Всего имеется 7 регистры общего назначения [3]. Ниже приведено их подробное описание.

Формат регистра UDCON представлен на рисунке 4.11.

Биты 7-3 - Резерв. При чтении данных бит всегда возвращается 0.

Бит 2 - LSM - выбор низкоскоростного режима (LS). Когда USB-контроллер настроен на работу в режиме Device, с помощью данного бита выбирается скоростной режим: полноскоростной (FS) или низкоскоростной (LS).

Для выбора полноскоростного режима необходимо обнулить данный бит (после этого, установка бита ATTACH приведет к активизации подтяжки к плюсу питания на линии D+) . Для выбора низкоскоростного режима необходимо установить данный бит (после этого, установка бита ATTACH приведет к активизации подтяжки к плюсу питания на линии D-). Данный бит не оказывает никакого влияния, когда интерфейс USB настроен на работу в режиме HOST.

Бит 1- RMWKUP - бит удаленного возобновления. Данный бит устанавливается для отправки Host-стороне потока UPSTREAM-RESUME для удаленного возобновления (бит SUSPI должен быть установлен). Сбрасывается аппаратно по окончании генерации сигналов. Программный сброс не оказывает никакого влияния.

Бит 0 - DETACH - бит отсоединения. Этот бит, при необходимости, устанавливается для физического отсоединения от шины Device-стороны (отключает подтяжку к плюсу питания на линии D+ или D-).

Бит 7 - Резерв. При чтении данного бита всегда возвращается 0.

Бит 6 - UPRSMI - флаг прерывания UPSTREAM RESUME. Устанавливается аппаратно, когда USB-контроллер отправляет сигнал возобновления, называемый UPSTREAM RESUME. Это приводит к запуску USB-прерывания, если установлен бит UPRSME. Должен быть сброшен программно (перед этим должна быть разрешена синхронизация USB-контроллера). Программная установка не оказывает никакого эффекта.

Бит 5 - EORSMI - флаг прерывания END OF RESUME. Устанавливается аппаратно, когда USB-контроллер обнаруживает правильный сигнал END OF RESUME, переданный Host-стороной. Если установлен бит EORSME, это приведет к запуску прерывания USB. Бит необходимо сбросить программно. Программная установка не оказывает никакого эффекта.

Бит 4 - WAKEUPI - флаг прерывания для возобновления ЦПУ. Устанавливается аппаратно, когда USB-контроллер повторно активизируется отфильтрованным отличным от IDLE сигналом на линии USB (кроме UPSTREAM RESUME). Если бит WAKEUPE установлен, это приведет к запуску прерывания. Это прерывание необходимо разрешать только для возобновления активной работы ЦПУ из режима POWER DOWN. Должен быть сброшен программно (перед этим должны быть активизированы входы синхронизации USB-контроллера). Программная установка не оказывает никакого эффекта.

Бит 3 - EORSTI - флаг прерывания END OF RESET. Устанавливается аппаратно при обнаружении USB-контроллером условия END OF RESET. Если установлен бит EORSTE, это приведет к запуску USB-прерывания. Необходимо сбросить программно. Программная установка не оказывает никакого влияния.

Бит 2 - SOFI - флаг прерывания START OF FRAME. Устанавливается аппаратно при обнаружении USB-контроллером идентификатора пакета (PID) START OF FRAME (SOF), что происходит с периодичностью 1 мс. Если бит SOFE установлен, это приведет к запуску USB-прерывания.

Бит 1 - Резерв. При опросе данного бита всегда возвращается 0.

Бит 0 - SUSPI - флаг прерывания SUSPEND. Устанавливается аппаратно при обнаружении приостановки шины USB (шина в состояние IDLE в течение 3 периодов посылок или иначе: шина в состоянии 'J' в течение 3 мс). Если установлен бит SUSPE, это приводит к запуску USB-прерывания. Должен быть сброшен программно. Программная установка не оказывает никакого влияния.

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

Формат регистра UDIE, представлен на рисунке 4.13:

Бит 7 - Резерв. При опросе данного бита всегда возвращается 0.

Бит 6 - UPRSME - бит разрешения прерывания UPSTREAM RESUME. Устанавливается этот бит для разрешения прерывания UPRSMI.

Бит 5 - EORSME - бит разрешения прерывания END OF RESUME. Устанавливается этот бит для разрешения прерывания EORSMI.

Бит 4 - WAKEUPE - бит разрешения прерывания по возобновлению ЦПУ. Устанавливается этот бит для разрешения прерывания по возобновлению активной работы ЦПУ. Для корректной обработки прерывания его работу необходимо разрешать только перед вводом режима POWER-DOWN.

Бит 3 - EORSTE - бит разрешения прерывания END OF RESET. Устанавливается этот бит для разрешения прерывания EORSTI. После сброса данный бит равен 1.

Бит 2 - SOFE - бит разрешения прерывания START OF FRAME. Устанавливается этот бит для разрешения прерывания SOFI.

Бит 1 - Резерв. При опросе данного бита всегда возвращается 0.

Бит 0 - SUSPE - бит разрешения прерывания SUSPEND. Устанавливается этот бит для разрешения прерывания SUSPI.

Формат регистра UDADDR, представлен на рисунке 4.14:

Бит 7 - ADDEN - бит активизации адреса. Устанавливается этот бит для активизации адреса UADD (USB-адрес). Сбрасывается аппаратно. Программный сброс не оказывает никакого эффекта.

Биты 6-0 - UADD6:0 - биты USB-адреса. Программа записывает в эти биты необходимое значение адреса.

Формат регистра UDFNUMH, представлен на рисунке 4.15:

Биты 7-3 - Резерв. При опросе данных бит всегда возвращаются нули.

Биты 2-0 - FNUM10:8 - старшие биты номера посылки. Устанавливаются аппаратно. Данные биты являются тремя старшими битами 11-битного значения номера посылки (Frame Number). Их значение появляется после приема последнего пакета SOF. Обновление FNUM происходит при приеме искаженного пакета SOF.

Формат регистра UDFNUML, представлен на рисунке 4.16:

Младший байт значения номера посылки. Устанавливается аппаратно. Данные биты являются 8 младшими битами 11-битного значения номера посылки.

Формат регистра UDMFN, представлен на рисунке 4.17:

Биты 7-5 - Резерв. При опросе данных бит всегда возвращаются 0.

Бит 4 - FNCERR -флаг ошибки CRC в номере посылки. Устанавливается аппаратно при обнаружении искаженного номера посылки в принятом пакете START OF FRAME (SOF). Данный бит обновляется одновременно с прерыванием SOFI.

Биты 3-0 - Резерв. При опросе данных бит всегда возвращаются 0.

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

Формат регистра UENUM, представлен на рисунке 4.18.

Биты 7-3 - Резерв. При опросе данных бит всегда возвращаются 0.

Биты 2-0 - EPNUM2:0 биты номера конечной точки. Загружается программно для выбора номера конечной точки, доступ к которой желает осуществить ЦПУ.

Формат регистра UERST, представлен на рисунке 4.19:

Бит 7 - Резерв. При опросе данного бита всегда возвращается 0.

Биты 6-0 - EPRST6:0 - биты сброса буфера FIFO конечной точки. Устанавливаются для сброса буфера FIFO выбранных конечных точек. Это необходимо сделать до выполнения каких-либо других операций после аппаратного сброса или приема по шине USB-сброса. Для завершения операции сброса и перехода к использованию конечных точек необходимо сбросить установленные биты.

Формат регистра UECONX, представлен на рисунке 4.20:

Биты 7-6 - Резерв. При опросе данных бит всегда возвращаются 0.

Бит 5 - STALLRQ - бит запроса отправки подтверждения STALL. Устанавливается этот бит при необходимости отправки Host-стороне STALL в качестве следующего подтверждения. Сбрасывается аппаратно после приема нового запроса SETUP. Программный сброс не оказывает никакого влияния.

Бит 4 - STALLRQC - бит отмены подтверждения запросом STALL. Устанавливается данный бит для отключения механизма подтверждения STALL. Сбрасывается аппаратно сразу после установки.

Бит 3 - RSTDT - бит сброса переключателя данных (Data Toggle). Устанавливается бит для автоматической отмены последовательности переключения данных. Для конечной точки OUT это означает, что следующий принятый пакет будет иметь переключатель данных равным 0. В свою очередь для конечной точки IN это означает, что у следующего подлежащего отправке пакета переключатель данных будет равен 0. Сбрасывается мгновенно аппаратными средствами. Программа не должна ожидать сброса этого бита. Программный сброс бита не оказывает никакого влияния.

Биты 2, 1 - Резерв. При опросе данных бит всегда возвращаются 0.

Бит 0 - EPEN - бит разрешения работы конечной точки. Устанавливается этот бит при необходимости разрешения работы конечной в соответствии с выполненной настройкой Device-контроллера. После аппаратного сброса или USB-сброса перед конфигурацией Device-контроллера должна быть разрешена работа конечной точки 0. Сброс этого бита отключит конечную точку.

Биты 7-6 - EPTYPE1:0 - биты типа конечной точки. Устанавливаются значения этих битов в соответствии с требуемой настройкой конечной точки.

Варианты значений битов типа конечной точки представлены в таблице 4.1.

Биты 3-2 - Зарезервировано для целей тестирования. Данными битами всегда возвращается нулевое значение.

Бит 1 - Резерв. При чтении бита всегда возвращается 0.

Бит 0 - EPDIR - бит направления конечной точки. Устанавливается бит для задания направления IN конечной точке типа BULK, INTERRUPT или ISOCHRONOUS. Сбрасывается для задания конфигурации OUT конечной точке типа BULK, INTERRUPT, ISOCHRONOUS или CONTROL.

Формат регистра UECFG1X, представлен на рисунке 4.22:

Бит 7 - Резерв. При чтении данного бита всегда возвращается 0.

Биты 6-4 - EPSIZE2:0 - биты размера конечной точки. Устанавливаются эти биты в соответствии с требуемым размером конечной точки.

Варианты значений битов размера конечной точки представлены в таблице 4.2.

Таблица 4.2 - Биты размера конечной точки

Значение	Размер	Значение	Размер
000b	8 байт	100b	128 байт
001b	16 байт	101b	256 байт
010b	32 байта	110b	Резерв
011b	64 байта	111b	Резерв

Значения 100b и 101b действительны только для конечной точки 1.

Биты 3-2 - EPBK1:0 - биты банка конечной точки. Настраивается данное поле с учетом размера конечной точки.

Варианты значений битов размера банка конечной точки представлены в таблице 4.3.

Таблица 4.3 - Биты размера банка конечной точки

Значение	Размер
00b	Один банк
01b	Два банка
1xb	Резерв

Бит 1 - ALLOC - бит назначения памяти конечной точки. Устанавливается этот бит для назначения памяти конечной точки. Сброс бита приводит к освобождению памяти конечной точки.

Бит 0 - Резерв. При чтении данного бита всегда возвращается 0.

Формат регистра UESTA0X, представлен на рисунке 4.23:

Бит 7 - CFGOK - флага статуса конфигурации. Устанавливается аппаратно, когда параметры размера X (EPSIZE) и банка (EPBK) конечной точки согласованы с максимальным размером буфера FIFO и предельным числом банков. Обновление бита происходит после установки бита ALLOC. Если CFGOK=0, это означает, что пользователю необходимо заново записать регистр UECFG1X с корректными значениями EPSIZE и EPBK.

Бит 6 - OVERFI - флаг прерывания по ошибке переполнения. Устанавливается аппаратно при обнаружении ошибки переполнения в конечной точке типа ISOCHRONOUS. Приводит к запуску прерывания (EPINTx), если таковое было разрешено. Должен быть сброшен программно. Попытка программной установки не дает никакого результата.

Бит 5 - UNDERFI - флаг прерывания по ошибке незаполнения. Устанавливается аппаратно при обнаружении ошибки незаполнения в конечной точке типа ISOCHRONOUS. Приводит к запуску прерывания (EPINTx), если таковое было разрешено. Должен быть сброшен программно. Попытка программной установки не дает никакого результата.

Бит 4 - Резерв. При чтении данного бита всегда возвращается 0.

Биты 3-2 - DTSEQ1:0 - флаг состояния переключателя данных. Устанавливается аппаратно для индикации данных идентификатора пакета (PID) для текущего банка.

Варианты значений биты идентификации данных представлены в таблице 4.4.

Таблица 4.4 - Биты идентификации данных

Значение	Данные
00b	DATA 0
01b	DATA 1
1xb	Резерв

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

Биты 1-0 - NBUSYBK1:0 - флаги занятости банка. Устанавливаются аппаратно для индикации количества занятых банков. Для конечной точки IN они индицируют количество занятых банков, которые заполнены пользователем и готовы для передачи типа IN. Для конечной точки OUT флаги индицируют количество занятых банков, которые заполнены Host-стороной в ходе транзакции типа OUT.

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

Таблица 4.5 - Флаг занятости банка

Значение	Описание
00b	Все банки свободны
01b	Занят один банк
10b	Занято два банка
11b	Резерв

Формат регистра UESTA1X, представлен на рисунке 4.24:

Биты 7-3 - Резерв. При чтении данных бит всегда возвращается значение 0.

Бит 2 - CTRLDIR - управление направлением (флаг, а также бит для отладочных целей). Устанавливается аппаратно после пакета SETUP и задает направление следующего пакета: 1 для конечной точки IN и 0 для конечной точки OUT.

Биты 1-0 - CURRBK1:0 - флаги текущего банка (все конечные точки, кроме конечной точки CONTROL). Устанавливаются аппаратно для индикации номера текущего банка.

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

Таблица 4.6 - Биты индикации номера текущего банка

Значение	Текущий банк
00b	Банк 0
01b	Банк 1
1xb	Резерв

Формат регистра UEINTX, представлен на рисунке 4.25:

Бит 7 - FIFOCON - бит управления буфером FIFO. У конечной точки OUT и SETUP данный бит устанавливается аппаратно после записи нового сообщения OUT в текущий банк (одновременно с RXOUT или RXSTP). Сбрасывается этот бит для освобождения текущего банка и переключения к следующему банку. Попытка программной установки не оказывает никакого эффекта. Применительно к конечной точке IN данный бит устанавливается аппаратно, когда освобождается текущий банк (одновременно с TXIN). Сбросьте FIFOCON для отправки данных FIFO и переключения данных. Программная установка не дает никакого результата.

Бит 6 - NAKINI - флаг прерывания по отправке NAK в передаче типа IN. Устанавливается аппаратно, когда в ответ на запрос IN Host-стороны было отправлено подтверждение NAK. Если установлен бит NAKINE, это приводит к генерации USB-прерывания. Должен быть сброшен программно.

Бит 5 - RWAL - флаг возможности чтения/записи. Устанавливается аппаратно для сигнализации: незаполненности текущего банка (т.е. о возможности помещения новых данных в буфер FIFO) конечной точки IN и наличии данных в текущем банке (т.е. о потребности считывания данных из буфера FIFO) конечной точки OUT. Бит никогда не устанавливается, если установлен бит STALLRQ или обнаружена ошибка. В остальных случаях бит равен нулю. Его нельзя использовать для конечной точки CONTROL.

Бит 4 - NAKOUTI - флаг прерывания по приему NAK в передаче типа OUT. Устанавливается аппаратно, когда в ответ на запрос OUT/PING из Host-стороны было отправлено подтверждение NAK. Если бит NAKOUTE установлен, это приводит к запуску USB-прерывания. Должен быть сброшен программно. Программная установка не оказывает никакого влияния.

Бит 3 - RXSTPI - флаг прерывания по приему SETUP. Устанавливается аппаратно для сигнализации о доступности нового действительного пакета SETUP в текущем банке. Приводит к запуску прерывания (EPINTx), если таковое было разрешено. Должен быть сброшен программно для подтверждения прерывания. Программная установка не оказывает никакого влияния. Данный бит неактивен (равен 0), если конечная точка имеет направление IN.

Бит 2 - RXOUTI / KILLBK - флаг прерывания по приему данных (передача типа OUT). Устанавливается аппаратно для сигнализации о том, что в текущем банке содержится новый пакет. Запускает прерывание (EPINTx), если таковое было разрешено. Должен быть сброшен программно для подтверждения прерывания. Попытка программной установки не оказывает никакого влияния. Бит ликвидации банка IN. Устанавливается данный бит, чтобы ликвидировать последний записанный банк. Сбрасывается аппаратно после ликвидации банка. Программный сброс не оказывает никакого влияния.

Бит 1 - STALLEDI - флаг прерывания STALLEDI. Устанавливается аппаратно для сигнализации об отправке подтверждения STALL или обнаружении ошибки CRC в конечной точке типа ISOCHRONOUS с направлением OUT. Должен быть сброшен программно. Программная установка не оказывает никакого влияния.

Бит 0 - TXINI - флаг прерывания по готовности передатчика. Устанавливается аппаратно для сигнализации о готовности к заполнению текущего банка. Запускает прерывание (EPINTx), если таковое было разрешено. Должен быть сброшен программно для подтверждения прерывания. Программная установка не оказывает никакого влияния. Данный бит является неактивным (равен 0) для конечной точки с направлением OUT.

Формат регистра UEIENX, представлен на рисунке 4.26:

Бит 7 - FLERRE - флаг разрешения прерывания по ошибке потока. Устанавливается для разрешения прерывания конечной точки (EPINTx) по установке флага VERFI или UNDERFI.

Бит 6 - NAKINE - флаг разрешения прерывания по отправке NAK в передаче типа IN. Устанавливается для разрешения прерывания конечной точки (EPINTx) при установке флага NAKINI.

Бит 5 - Резерв. При чтении данного бита всегда возвращается 0.

Бит 4 - NAKOUTE - бит разрешения прерывания по приему NAK в передаче типа OUT. Устанавливается для разрешения прерывания конечной точки (EPINTx) по установке флага NAKOUTI.

Бит 3 - RXSTPE - флаг разрешения прерывания по приему SETUP. Устанавливается для разрешения прерывания конечной точки (EPINTx) по установке флага RXSTPI.

Бит 2 - RXOUTE - флаг разрешения прерывания по приему данных в передаче типа OUT. Устанавливается для разрешения прерывания конечной точки (EPINTx) по установке флага RXOUTI.

Бит 1 - STALLEDE - флаг разрешения прерывания STALLEDI. Устанавливается для разрешения прерывания конечной точки (EPINTx) по установке флага STALLEDI.

Бит 0 - TXINE - флаг разрешения прерывания по готовности передатчика. Устанавливается для разрешения прерывания конечной точки (EPINTx) по установке флага TXINI.

Формат регистра UEDATX, представлен на рисунке 4.27:

Биты 7-0 - DAT7:0 - биты данных. Используются данные биты в программе для чтения (записи) байта из буфера (в буфер) FIFO конечной точки, выбранной битами EPNUM.

Формат регистра UEBCHX, представлен на рисунке 4.28:

Биты 7-3 - Резерв. При чтении данных бит всегда возвращаются нули.

Биты 2-0 - BYCT10:8 - старшие биты счетчика байт. Устанавливаются аппаратно. В них хранятся старшие биты счетчика байт буфера FIF конечной точки. Младший байт хранится в регистре UEBCLX.

Формат регистра UEBCLX, представлен на рисунке 4.29:

Биты 7-0 - BYCT7:0 - младшие биты счетчика байт. Устанавливаются аппаратно. Значение бит BYCT10:0: (для конечной точки IN) инкрементируется после записи в конечную точку и декрементируется после отправки каждого байта и (для конечной точки OUT) инкрементируется после отправки Host-стороной каждого байта и декрементируется после программного чтения каждого байта.

Формат регистра UEINT, представлен на рисунке 4.30:

Бит 7 - Резерв. При чтении данного бита всегда возвращается 0.

Биты 6-0 - EPINT6:0 - биты прерываний конечной точки. Устанавливаются аппаратно, когда запускается прерывание регистром UEINTX и, при этом, установлен бит разрешения прерывания соответствующей конечной точки. Сбрасывается аппаратно по завершении обслуживания источника прерывания.

4.13 Разработка структуры данных для программной реализации USB пакета

Информация по каналу передается в виде пакетов (Packet) [20]. Каждый пакет начинается с поля синхронизации SYNC (SYNChronization), за которым следует идентификатор пакета PID (Packet IDentifier). Поле Check представляет собой побитовую инверсию PID. Общий формат пакета представлен на рисунке 4.31.

Рисунок 4.31 - Формат пакета USB

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

usb_control_msg(handle, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN, CUSTOM_RQ_GET_STATUS, 0, 0, buffer, sizeof(buffer), 5000)

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

- usb_dev_handle *dev. Здесь используется значение переменной handle - передается идентификатор открытого USB HID устройства. Получают валидный handle после однократного вызова функции usbOpenDevice;

- int requesttype, тип запроса. Его значение равно USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_ENDPOINT_IN. Указывается конечная точка USB_ENDPOINT_IN;

- int request, значение запроса. Тут подставляется значение CUSTOM_RQ_GET_STATUS, что означает, что передается запрос на получение данных;

- int value. Передается 0, параметр не используется;

- int index. Передается 0, параметр не используется;

- char *bytes. Указатель на буфер, выделенный в памяти. В случае запроса CUSTOM_RQ_GET_STATUS этот буфер используется для переноса данных от USB устройства к ПО хоста. Передается четыре байта, об этом говорит return 4 на выходе из usbFunctionSetup в случае обработки запроса CUSTOM_RQ_GET_STATUS;

- int size. Тут передается размер буфера. В случае запроса CUSTOM_RQ_GET_STATUS передается значение 4, отражающее реальный размер буфера;

- int timeout. Таймаут, в течение которого должен прийти ответ. Установленное значение 5000, означает 5000 миллисекунд.

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

5.1 Модуль поиска устройства

Программная реализация с комментариями модуля поиска устройства приведена в приложении А. Этот модуль опрашивает все устройства на всех шинах USB и ищет конкретное устройство [12]. Поиск начинается с проверки на совпадение Vendor- и Product-ID (переданных в переменных 'vendorID' и 'productID'). ID равный 0 совпадает с любым цифровым ID (wildcard).

Когда устройство совпало по идентификаторам IDs, проверяется совпадение по имени. Сопадение может быть по текстовому имени вендора ('vendorNamePattern'), имени продукта ('productNamePattern') и серийному номеру ('serialNamePattern'). Устройство совпадает только тогда, когда совпадают все непустые (non-null) маски.

Если не надо проверять определенную строку, передается NULL в качестве маски. Маски работают в стиле Unix shell: '*' означает 0 или другое количество символов, '?' означает любой одиночный символ, любой символ из списка, заданного квадратными скобками (дефис разрешен для указания диапазона символов) и если список символов начинается с символа caret ('^'), то он соответствует любому символу не принадлежащий этому списку.

Другие параметры функции: если 'warningsFp' не NULL, предупреждающие (warning) сообщения будут печататься в файловый дескриптор с помощью функции fprintf(). Если 'printMatchingDevicesFp' не NULL, устройства не будут открыты, но совпавшие устройства будут распечатаны в предоставленный файловый дескриптор 'warningsFp' с помощью функции fprintf(). Если устройство открыто, результирующий USB=хендл сохраняется в '*device'. Здесь должен быть передан указатель на тип переменной "usb_dev_handle *". Возврат: 0 в случае успеха или код ошибки.

Объявление функции поиска устройства имеет следующий вид:

int usbOpenDevice(usb_dev_handle **device, int vendorID, char *vendorNamePattern, int productID, char *productNamePattern, char *serialNamePattern, FILE *printMatchingDevicesFp, FILE *warningsFp);

5.2 Модуль формирования ответного пакета

Программная реализация с комментариями модуля формирования ответного пакета приведена в приложении А. Блок-схема алгоритма представлена на рисунке 5.1. Этот модуль вызывается, когда драйвер принимает транзакцию SETUP от хоста, которому не отвечает драйвер непосредственно (на практике: запросы класса и вендора) [15]. Все управляющие передачи стартуют с транзакции SETUP, где хост сообщает параметры следующих (опционально) передач данных. Данные SETUP доступны в параметре 'data', который должен быть преобразован в 'usbRequest_t для лучшего дружественного для пользователя доступа к параметрам.

Если SETUP показывает передачу control-in, должны быть обеспечены для драйвера запрошенные данные. Есть два пути для передачи этих данных: установить глобальный указатель 'usbMsgPtr' на начало блока данных static RAM и возвратить длину данных в 'usbFunctionSetup()'. В нашем случае, данные необходимые для отправки заполняются в буфер, и указывается размер возвращаемых данных (4 байта). Или возвратить USB_NO_MSG в 'usbFunctionSetup()'. Драйвер будет вызывать 'usbFunctionRead()' [20], когда понадобятся данные.

Объявление функции отправки ответного пакета имеет следующий вид:

USB_PUBLIC usbMsgLen_t usbFunctionSetup(uchar data[8]);

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

Здесь в блоке 1 проверяется присутствие логической единицы на входе ножки порта, куда подключен вывод реле. Если логическая единица обнаружена, то в блоке 2 осуществляется сравнение данных, полученных от АЦП на предыдущем выполнении программы с теми же данными, полученными до этого, и, если, они отличаются (хотя бы одним значением тока или напряжения), то выполняется функция очистки экрана (блок 3). Далее, не зависимо от того, выполнялась ли очистка экрана, в блоке 4 курсор экрана устанавливается в левое крайнее положение на верхней строке (координаты 0,0), и выводится слово «Norma», как показано в блоке 5, означающее, что разряд батареи идет в нормальном режиме. Затем в блоке 6 идет считывание данных с АЦП, а именно, кодовое значение уровня напряжения ножки, куда подключен датчик напряжения. Это кодовое значение, в блоке 7, переводится в числовое значение уровня напряжения на входе АЦП по формуле 3.1. Далее значение умножается на масштабный коэффициент в блоке 8, для получения действительного значения напряжения в электрической цепи, и это значение выводится на экран в блоке 9. В блоке 10 идет считывание данных с АЦП по току, полученное кодовое значение переводится в числовое значение уровня напряжения на входе АЦП, куда подключен датчик тока в блоке 11. Затем в блоке 12, аналогично блоку 8, осуществляется умножение на масштабный коэффициент, и действительное значение тока выводится на экран в блоке 13. Далее в блоке 14 подаем логическую единицу на ножку порта, куда подключен светодиод «Разряд батареи», тем самым зажигая его, и подаем логический ноль на ножку порта, куда подключен светодиод «Батарея отключена», тем самым гася его. Если горит первый светодиод, это показывает, что идет разряд батареи, если горит второй - значит, система отключила батарею от цепи, для предотвращения глубокого разряда. В блоке 15 полученное значение напряжения сравнивается и минимально допустимым, и, если первое меньше либо равно последнему, то на вывод порта, куда подключено реле, подается логический ноль, тем самым размыкая цепь и отключая батарею от нагрузки.

Если же в блоке 1 на входе ножки порта, куда подключен вывод реле, обнаружен логический ноль, то переходим к блоку 17. В блоке 17 проверяется присутствие логического нуля на входе ножки порта, куда подключен вывод реле еще раз, для исключения ситуации, когда после не выполнения блока 16 не перешли к выполнению следующих за 17 блоков. В Блоках 18 - 30 выполняются аналогичные действия, как в блоках 2 - 14, за исключением того, что в блоке 21 выводится слово «Alarm»? сигнализирующее об аварии, и в блоке 30 происходит обратные действия блоку 14, а именно: светодиод «Разряд батарей» потушить, а светодиод «Батарея отключена» зажечь. В блоке 31 значение напряжения, выдаваемое от батареи, сравнивается с минимально допустимым, и, если оно больше, то идет замыкание реле, путем подачи на выход подключения реле логической единицы в блоке 32. Наконец, если в блоке 17 считана логическая единица, то идет переход в конец модуля, пропуская действия, описанные в 18 - 32 блоках. Текст программы представлен в приложении А.

6. Методика и результаты испытаний системы контроля

Система была смоделирована в симуляторе Proteus [9], который имеет набор всех необходимых электрических элементов для сбора модели электропитающей установки АТС и системы контроля.

6.1 Моделирование ЭПУ

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

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

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

Модель, составленная в симуляторе, представлена на рисунке 6.1.



Рисунок 6.1 - Модель ЭПУ АТС

6.2 Моделирование системы контроля

Модель системы контроля включает в себя: микроконтроллер AT90USB1286; подключенный к нему жидкокристаллический дисплей; датчик тока и напряжения, подключенные к входам АЦП; два светодиода («Разряд батарей» и «Батарея отключена»), подключенных к микроконтроллеру для индикации состояния питания нагрузки; реле, для имитации отключения батареи от цепи и дополнительные вольтметр и амперметр, для проверки соответствия выводимых значений тока и напряжения, на жидкокристаллический дисплей, действительным, чем можно удостовериться в правильности работы системы контроля. В качестве опорного напряжения для АЦП, выводы AREF и AVCC соединены последовательно с источником напряжения 5 В.

Модель системы контроля, составленная в симуляторе, представлена на рисунке 6.2.



Рисунок 6.2 - Модель системы контроля

6.3 Методика и результаты испытания

Для проверки работоспособности системы контроля в память микроконтроллера загружается скомпилированный модуль программы контроля параметров, имеющий расширение .hex. Для этого необходимо нажать правой кнопкой мыши по объекту модели микроконтроллера, и в открывшемся списке меню выбрать пункт Edit Properties. В открывшемся окне в поле Program File необходимо указать путь к файлу программы, если этот файл лежит в той же папке, что и проект моделирования, то достаточно указать полное имя файла, как показано на рисунке 6.3.

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

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

Для проверки правильности работы системы контроля можно, меняя внутреннее сопротивление резистора, нажимая кнопки «+» и «-», сравнивать выводимые параметры на жидкокристаллический дисплей с показаниями амперметра и вольтметра. На рисунке 6.4,а видно, что напряжение в сети больше 53,5 В, поэтому на экране выведено «Norma» и горит зеленый светодиод («Разряд батареи»). В этом случае реле замкнуто, и батарея подключена к цепи электропитания. Далее поменяв значение внутреннего сопротивления резистора, из рисунка 6.4,б видно, что напряжение стало меньше 53,5 В, поэтому произошло размыкание реле (сигнал К10), на экране выведено «Alarm» и горит красный светодиод («Батарея отключена»).

7. Экономическая оценка создания и внедрения программного продукта

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

7.1 Маркетинговые исследования проектируемого продукта

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

- выход на новые рынки;

- продвижение нового продукта; - ребрендинг;

- определение цены на продукцию компании;

- каналы и методы продвижения товаров;

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

Потребительская ценность продукта

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

- контроль заряда/разряда батареи;

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

- обработка аварийных ситуаций.

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

- идентификация аварийных ситуаций;

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

- контроль состояния батарей в режиме реального времени.

Портрет потребителя

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

Предполагаемый сегмент рынка сбыта

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

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

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

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

Сегментация рынка по потребительскому признаку:

1. Предприятия, предоставляющие телекоммуникационные услуги - 80%

2. Другие объекты, применяющие электропитающие установки - 20%

Графическое представление сегментации представлено на рисунке 7.1.

Рисунок 7.1 - Сегментация рынка сбыта по потребительскому признаку

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

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

Оценка рыночной направленности приведена в таблице 1 приложения Б. Находим среднеарифметическую величину:



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

Конкурентоспособность программного продукта

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

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

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

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

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

Жизненный цикл программного продукта

Жизненный цикл изделия (ЖЦИ), как определяет его стандарт ISO 9004-1, -- это совокупность процессов, выполняемых от момента выявления потребностей общества в определенной продукции до момента удовлетворения этих потребностей и утилизации продукта.

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

В классическом жизненном цикле товара можно выделить пять стадий или фаз:

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

2. Внедрение или выход на рынок. Фаза появления нового товара на рынке.

3. Фаза роста. Если товар требуется на рынке, то сбыт начнет существенно расти.

4. Фаза зрелости. Характеризуется тем, что большинство покупателей уже приобрело товар.

5. Спад. Спад является периодом резкого снижения продаж и прибыли.

Кривая ЖЦТ изображена на рисунке 2 приложения В, она показывает изменение объема продаж и прибыли на протяжении жизненного цикла товара.

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

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

7.2 Определение затрат на проектирование

Расчет трудоемкости

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

Общий объем разрабатываемого ПП (V0) определяется по формуле:

, (7.1)

где Vi - объем i- ой функции ПП;

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

Трудоемкость: Тр = 44,5 ( затраты труда на разработку ПС ВТ определяется в зависимости от объема V₀ и группы сложности в тысячах условных команд ).

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

Полученную общую трудоемкость (Тобщ) разработки ПС ВТ разбивают на соответствующе стадии разработки. Трудоемкость каждой стадии разработки ПС ВТ (Тi) определяют по формулам 3-7 представленным в приложении В.

Так как данный проект не использует ни новую ОС, ни новую платформу, то согласно справочным данным Кн=0.7, а степень новизны относится к классу В. В зависимости от этого значения удельного веса, для стадий разработки, имеют значения, представленные в таблице 3 приложения Б. Степень охвата реализуемых функций ПС ВТ типовых программ, в зависимости от стадии разработки, представлена в таблице 4 приложения Б. Расчеты трудоемкости каждой стадии разработки (Тi) и уточненная общая трудоемкость ПС ВТ (Т_уточ) в человеко-днях представлены в приложении Б.

Исходя из трудоемкости Т_уточ и численности исполнителей, рассчитывается срок разработки:

 (7.2)

где Fмес - фонд рабочего времени в месяц. Принимается равным 21,8 дней;

Ч - численность разработчиков [чел]. Она планируется исходя из объема работ. Численность разработчиков Ч принимается 1.

Исходя из имеющихся данных, получаем:

[ месяца]

Расчет себестоимости часа машинного времени

Исходные данные для расчета себестоимости часа машинного времени приведены в таблице 5 приложения Б. Расчет годовых эксплуатационных затрат приведен в приложении В, полученные данные вынесены в таблицу 8.1.

Себестоимость часа машинного () времени рассчитывается по формуле:

, (ден.ед.), (7.3)

где - годовые эксплуатационные затраты.

(час). (7.4)

(час),

(грн.)

Таблица 7.1 - Смета годовых эксплуатационных затрат

П/П	Название расходов	грн.
1	Материальные затраты	125
2	Затраты на электроэнергию	134,7
3	Расходы на оплату труда	23600
4	Затраты на ремонт	75
5	Накладные расходы	14160
6	Отчисления от ФОТ	8732
7	Амортизационные отчисления	1788
	Итого	48614,7

Определение фонда оплаты труда проектировщиков

Основная заработная плата разработчиков (ЗП_прямая) определяется по формуле 7.5:

ЗП_{основная} = Ч * С_рр * Оклад, (7.5)

где Ч - количество исполнителей данного проекта, чел;

С_рр - срок разработки без применения ВТ, мес.

ЗП_{основная} = 1 * 0,5 * 2000= 1000 (грн.)

Кроме основной заработной платы, в расчет включаем доплаты в размере 30% от основной зарплаты. Тогда фонд основной зарплаты составит:

ФОТ = ЗП_осн * 1.3 (7.6)

ФОТ = 1000 * 1,3 = 1300 (грн)

Отчисления на социальные нужды определяются в процентах от ФОТ по формуле 7.7.

ОТЧс =37*ФОТ/100 (7.7)

ОТЧс =37*1300/100 = 481 (грн)

Тогда ФОТ с отч. = 1781 (грн)

Накладные расходы

Совокупность расходов на содержание помещений, на управление организацией, относим к накладным расходам и принимаем в размере 30-60% от ФОТ (З_накл). =60%

, (7.8)

(грн).

Затраты на разработку ПП с применением ВТ (З_по) определяются по формуле 7.9:

З_по = С_рм* F_эф.м*C_ч.м.в., (7.9)

где С_рм - срок разработки ПП с использованием ВТ, месяцев;

F_{эф. м} - эффективный фонд рабочего времени за месяц;

С_ч.м.в. - себестоимость часа машинного времени, грн.

З_по = 1·168·25,53 = 4289,04 (грн)

Все расчеты сведены в таблицу 7.2.

Таблица 7.2 - Смета затрат на проектирование

Наименование расходов	Сумма, грн.
1. Фонд оплаты труда проектировщиков (с отчислениями на социальные меры ) за работу, выполненную без применения ВТ	1781
2. Накладные расходы	1068,6
3. Затраты на разработку ПП с применением ВТ	4289,04
Итого: Зпр	7138,64

Полученная сумма служит основанием для определения цены предложения ПП.

Формирование цены предложения разработчика

Цена предложения разработчика устанавливается в соответствии с выбранным методом ценообразования. Одним из методов ценообразования является метод безубыточности.

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

Для реализации данного метода необходимо рассчитать постоянные и полные издержки. Постоянные издержки (И_П) представляют собой затраты на проектирование ПП.

И_п=ФОТ_{без экспл}+ФОТ_экспл. (7.10)

И_п= 1781+4289,04=6070,04 [грн.].

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

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

И_пер=З_накл +25%*З_пр , (7.11)

И_пер=1068,6+0,25*7138,64=2853,26 [грн.].

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

Полные издержки (И_пол) составят:

И_пол=И_п+И_пер (7.12)

И_пол=8923,3 [грн.]

Пр = 8923,3*0,2=1784,66 [грн.]

Выручка от реализации (В) определяется в зависимости от цены продажи одного экземпляра ПП (Ц) и объема продаж:

В=Ц*N (7.13)

Цена: Ц=С+Пр = 8923,3+1784,66=10707,96 [грн.]

Тогда цена за единицу продукции составит:

Ц_ед= Ц/N = 10707,96 /30 = 356,95 [грн.]

К цене также необходимо добавить НДС (20%).

Ц_{с уч. НДС} = 428,35 [грн.]

На основе полученных данных, был построен график безубыточности, изображенный на рисунке 7.2.



Рисунок 7.2 - График безубыточности

Из расчётов и рисунка 7.2 следует, что при минимальном объёме продаж равном 23 экземпляра, затраченные убытки будут оправданы. Максимальный объем продаж составляет 30 штук. Цена одного экземпляра программного продукта составляет 428,35 грн.

Расчет капитальных затрат

Капитальные расходы для разработчика представляют собой расходы на покупку (Ц_тс), доставку (З_тр) и монтаж (З_м) технических средств, а также на приобретение программного обеспечения (Ц_по), необходимого для процесса создания программного продукта представлены в приложении Д и составляют 3905 грн. Оценка эффективности проектирования программного продукта Анализ эффективности проекта производится на основе показателей: интегрального экономического эффекта за весь жизненный цикл продукта; периода возврата капитальных вложений. Задачей экономической оценки является определение динамики чистой текущей стоимости. Исходные данные для расчета интегрального экономического эффекта приведены в таблице 7.3.

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

Года	Кап.вложения, ден.ед.	Объем выпуска, шт	Цена, грн
2010	3905		428,35
2011		30	428,35
2012		30	428,35
2013		25	428,35
2014		23	428,35

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

Эs = ЧТСt (7.14)

где Т - жизненный цикл проекта, 5 лет.

Таблица 7.4 - Оценка эффективности программного продукта

Показатели	2010	2011	2012	2013	2014
Объем реализации, грн.	0	12850,5	12850,5	10708,75	9852,05
Капитальные вложения, грн.	3905	0	0	0	0
Годовые издержки, грн.	0	8923,3	4461,65	2900,07	3190,07
Коэффициент приведения по фактору времени бt	1	0,909	0,826	0,751	0,683
ЧДП, грн.	-3905	3927,2	8388,85	7808,68	6661,98
ЧТС, грн.	-3905	3569,83	6929,2	5864,32	4550,13
ЧТС с нарастающим итогом, грн.	-3905	-335,17	6594,03	12458,35	17008,50
Амортизация, грн (Аt)	0	976,25	976,25	976,25	976,25
Прибыль, грн (Пt)	0	2950,45	7412,1	6832,43	5685,73
Рентабельность, % (Pt)		75,5	189,8	174,95	145,6

Эs =-3950+3569,83+6929,2+5864,32+4550,13=17008,50 [грн.]

А так же рассчитаем внутреннюю норму рентабельности

R_в = Е_i + (Э_i * (Е_i+1 - Е_i)) / (Э_i - Э_i+1), где (7.15)

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

Е_i+1 - повышенная (пониженная на один пункт по сравнению с Е_н) норма дисконтирования, при которой интегральный эффект принимает ближайшее к нулю положительное или отрицательное значение;

Э_i и Э_i+1 - значения интегрального эффекта соответственно при Е_т и Е_т+1.

Э₁=15693,187

Э₂=15264,169

Е₁=0,11

Е₂=0,12

R_в = 0.475*100=47,5%

На основе полученных данных был построен финансовый профиль проекта, представленный на рисунке 7.3.

Рисунок 7.3- Финансовый профиль проекта

Из графика видно, что в данном виде продукт является экономически целесообразным, так как затраты окупаются уже на третий год. Максимальный долг в 2010 году составляет 3905 грн. Суммарный интегральный экономический эффект составляет 17008,50 грн. Внутренняя норма рентабельности составляет 47,5% это означает, что если брать кредит под 47,5% проект не будет убыточным.

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

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

Были получены следующие данные:

Затраты на проектирование исследованного программного продукта составили 7138,64 грн.

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

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

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