Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО 'КИЭП 'Энергомера'

Вид работы:

Дипломная (ВКР)
Предмет:

Информационное обеспечение, программирование
Язык:

Русский
,
Формат файла:
MS Word

3,30 Mb
Опубликовано:

2011-06-30

Все дипломные работы по информационному обеспечению

Скачать дипломную работу Читать текст online Заказать дипломную
*Помощь в написании! Посмотреть все дипломные работы

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

Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО 'КИЭП 'Энергомера'

Введение

. Предпроектное обследование ЗАО "КИЭП "Энергомера", г. Ставрополь. Формулировка задач проектирования

.1 Постановка задачи предпроектного обследования

.1.1 Объект и методы проведения предпроектного обследования

.1.2 Программа проведения обследования

.1.3 План-график выполнения работ обследования

.2 Характеристика предприятия ЗАО "КИЭП "Энергомера"

.2.1 Общая характеристика предприятия

.2.2 Организационная структура предприятия

.2.3 Организационно-управленческая модель

.3 Технические и программные средства ЭИВТ предприятия

.3.1 Задачи, решаемые с использованием средств ЭИВТ

.3.2 Технические средства

.3.3 Программные средства

.3.4 Локальная сеть предприятия

.3.5 Организация доступа к мировым информационным сетям

.3.6 Обеспечение информационной безопасности, защита информации

.3.7 Информационные базы и информационные потоки

.3.8 Проблемные ситуации и способы их решения

.3.9 Выбор проблемной ситуации для решения

.4 Формулировка задач проектирования

.4.1 Общие сведения о проекте

.4.2 Назначение, цели создания информационной подсистемы

.4.3 Характеристика объекта автоматизации

.4.4 Требования к подсистеме

.4.5 Состав и содержание работ по созданию подсистемы

.4.6 Порядок контроля приемки подсистемы

.4.7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу подсистемы в действие

.4.8 Требования к документированию

.4.9 Источники разработки

Выводы

. Разработка информационной подсистемы PLC-Tester

.1 Обоснование выбора программного обеспечения

2.2 Проектирование и разработка БД

.2.1 Определение сущностей

2.2.2 Определение зависимостей между сущностями

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

.2.4 Создание физической модели данных

.2.5 Разработка хранимых процедур

.2.6 Создание пользователей и распределение привилегий

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

.3.1 Проектирование модуля

.3.2 Разработка модуля TNNCL.dll

.3.3 Разработка модуля TAT.dll

.3.4 Разработка модуля PLCTester.exe

.4 Разработка web-приложения

Выводы

. Информационная подсистема PLC-Tester

.1 Общие сведения о программном продукте

.2 Функциональное назначение программного продукта

.3 Описание логической структуры программного продукта

.4 Требования к техническому обеспечению

.4.1 Общие требования

.4.2 Требования к центральному процессору

.4.3 Требования к оперативному запоминающему устройству

.4.4 Требования к наличию свободного места на жестком диске

.4.5 Требования к монитору

.4.6 Прочие требования

.5 Вызов программы

.5.1 Установка ПО

.5.2 Запуск программы

.6 Входные данные

.7 Выходные данные

.8 Описание тестовых прогонов

.8.1 Общие сведения

.8.2 Тестирование модуля PLCTester

.8.3 Тестирование web-приложения

Выводы

. Технико-экономическое обоснование проекта

.1 Краткая характеристика проекта

.2 Трудоемкость выполняемых работ

4.3 Расчет себестоимости информационной подсистемы

.4 Оценка экономической эффективности внедрения программного продукта

.5 Основные технико-экономические показатели проекта

Выводы

. Безопасность и экологичность проекта

.1 Общая характеристика опасных, вредных факторов на рабочем месте оператора информационной подсистемы

.2 Обеспечение безопасности на рабочем месте оператора информационной подсистемы

.3 Расчет защитного зануления на отключающую способность

Выводы

Заключение

Библиографический список

Приложение

ВВЕДЕНИЕ

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

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

Одной из основных задач АСКУЭ является автоматизированный процесс сбора данных со счетчиков электроэнергии, который может осуществляться по различным каналам связи и технологиям (RS-232, RS-485, Ethernet, GSM, GPRS, PLC и др.), схема АСКУЭ представлена в приложении А. Технология PLC (средой передачи являются линии электропередачи) обладает рядом преимуществ: нет необходимости прокладывать и обслуживать дополнительную кабельную систему (например, как при использовании технологии Ethernet); нет необходимости платить за передачу данных сторонним организациям (например, как при использовании технологий GPRS и GSM).

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

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

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

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

В третьем разделе описана уже разработанная информационная подсистема.

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

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

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

В приложениях приведены дополнительные материалы, которые предназначенные для более полного раскрытия темы дипломного проекта. (блок-схемы, UML-модели, программный код).

1. Предпроектное обследование ЗАО "КИЭП "Энергомера", г. Ставрополь. Формулировка задач проектирования

.1 Постановка задачи предпроектного обследования

.1.1 Объект и методы проведения предпроектного обследования

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

- характеристика предприятия;

- структура предприятия;

- информационные системы, функционирующие на предприятии;

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

- корпоративная сеть предприятия, и её особенности;

- обеспечение информационной безопасности;

- информационные потоки и базы предприятия;

- проблемные ситуации, имеющиеся на предприятии;

- возможные способы решения проблемных ситуаций.

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

- функции, выполняемые системой;

- структура системы;

- пользователи системы;

- место системы в структуре предприятия;

- производственные процессы, связанные системой;

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

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

- личные наблюдения;

- анкетирование и опросы;

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

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

.1.2 Программа проведения обследования

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

Таблица 1.1 - Программа проведения обследования предприятия

Наименование вопроса	Источник информации	Получатель инфор
Общая характеристика	Начальник отдела развития	Студент Саркисов С.А.
Организационная структура	Директор предприятия	Студент Саркисов С.А.
Организационно-управленческая модель	Директор предприятия	Студент Саркисов С.А.
Задачи, решаемые с использованием средств ЭИВТ	Начальник ОКПО	Студент Саркисов С.А.
Технические средства	Начальник отдела IT	Студент Саркисов С.А.
Программные средства	Начальник отдела IT	Студент Саркисов С.А.
Локальная сеть	Начальник отдела IT	Студент Саркисов С.А.
Организация доступа к мировым информационным сетям	Начальник отдела IT	Студент Саркисов С.А.
Обеспечение информационной безопасности, защита информации	Начальник отдела IT	Студент Саркисов С.А.
Информационные базы и информационные потоки	Начальники отделов, сотрудники	Студент Саркисов С.А.
Информационные системы	Начальники отделов, сотрудники	Студент Саркисов С.А.
Проблемные ситуации и способы их решения	Начальники отделов, сотрудники	Студент Саркисов С.А.

.1.3 План-график выполнения работ обследования

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

Таблица 1.2 - План-график выполнения работ обследования

Наименование работы	Код работы	Исполнитель	Дата начала	Дни	Дата окончания
Обследование общей характеристики предприятия	001	Студент Саркисов С.А.	06.12.10	2	07.12.10
Обследование организационной структуры предприятия	002	Студент Саркисов С.А.	08.12.10	2	09.12.10
Обследование организационно-управленческой модели предприятия	003	Студент Саркисов С.А.	10.12.10	1	10.12.10
Выявление задач, решаемых средствами ЭИВТ	004	Студент Саркисов С.А.	13.12.10	3	15.12.10
Обследование технических средств предприятия	005	Студент Саркисов С.А.	16.12.10	2	17.12.10
Обследование программных средств предприятия	006	Студент Саркисов С.А.	20.12.10	5	24.12.10
Обследование локальной сети предприятия	007	Студент Саркисов С.А.	27.12.10	5	31.12.10
Обследование информационных баз и информационных потоков предприятия	008	Студент Саркисов С.А.	11.01.11	9	21.01.11
Обследование информационных систем предприятия	009	Студент Саркисов С.А.	24.01.11	20	18.02.11
Выявление проблемных ситуации и определение способов их решения	010	Студент Саркисов С.А.	21.02.11	13	11.03.11
Всего затрачено дней				62

.2 Характеристика предприятия ЗАО "КИЭП "Энергомера"

.2.1 Общая характеристика предприятия

Открытое акционерное общество Концерн "Энергомера" образовано 25 января 1994 г. на юге России и располагается по адресу г. Ставрополь ул. Ленина 415-А. В первые месяцы работы, его численность составляла 24 человека. Сегодня на его предприятиях работает более 6000 сотрудников. Сегодня концерн входит в число ведущих компаний РФ по производству средств и систем учета электроэнергии. За время деятельности компанией достигнуты значительные результаты: продукция торговой марки "Энергомера" получила широкое признание не только на территории России, но и за рубежом.

Номенклатурный ряд электротехнической продукции Концерна включает:

- электронные приборы и системы учета электроэнергии, а также соответствующее сервисное и метрологическое оборудование;

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

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

В настоящее время основными задачами и целями являются: повышение надежности приборов, расширение функциональности приборов, повышение энергосберегаемости и автоматизация процессов сбора и обработки данных измерений, расширение рынка. Одним из филиалов концерна является ЗАО Корпоративный институт электротехнического приборостроения "Энергомера" (далее по тексту ЗАО "КИЭП "Энергомера"). Предприятие образовано в 2005 году на базе шести конструкторских бюро. За пять лет после образования, значительно увеличилось количество конструкторских бюро, специализирующихся на разработке новых продуктов, выпускаемых на заводах Концерна.

Основные задачи, которые ставятся перед предприятием - это:

- разработка современных, качественных приборов учета электроэнергии;

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

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

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

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

1.2.2 Организационная структура предприятия

Организационная структура предприятия в целом представлена в виде схемы (рисунок 1.1).

Рисунок 1.1 - Организационная структура ЗАО "КИЭП "Энергомера"

Условные обозначения, применяемые на схеме и в дальнейшем:

- Гл. инженер - главный инженер предприятия;

- ГКСУ - главный конструктор систем учета;

- ГКС - главный конструктор счетчиков;

- ГКУ - главный конструктор по упаковке;

- ГКМ - главный конструктор по метрологии;

- КБСУ - конструкторское бюро систем учета;

- КБТМО - конструкторское бюро телекоммуникационного оборудования;

- ОКПП - отдел конструктивов печатных плат;

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

- КБС - конструкторское бюро счетчиков;

- КБЭХЗ - конструкторское бюро электрохимической защиты;

- БПС - бюро патентования и сертификации;

- ОТП - отдел технической поддержки;

- ЛР - лаборатория;

- ОР - отдел развития;

- - административно-техническое руководство;

- - техническое руководство.

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

Организационная структура КБСУ представлена на рисунке 1.2 в виде схемы.

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

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

Рисунок 1.2 - Организационная структура КБСУ

Условные обозначения, примененные на схеме:

- ПО ЦОИ - программное обеспечение централизованной обработки информации;

- КТС - комплекс технических средств.

Организационная структура КБС представлена на рисунке 1.3 в виде схемы.

Рисунок 1.3 - Организационная структура КБС

Организационная структура ОКПО представлена на рисунке 1.4 в виде схемы.

Рисунок 1.4 - Организационная структура ОКПО

.2.3 Организационно-управленческая модель

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

Группы функциональных задач представлены в таблице 1.3.

Таблица 1.3 - Группы функциональных задач и подзадач

Номер и название функциональной задачи	Номер и содержание функциональной подзадачи
1. Управление планированием	1.1 Разработка новых проектов
	1.2 Составление смет на поставку комплектующих
	1.3 Внесение изменений в текущие и перспективные планы производства
2. Управление производством	2.1 Получение заказов от клиентов и оформление договоров на их выполнение
	2.2 Оформление проектов и подготовка их к внедрению
	2.3 Выполнение заказов клиентов
3. Информационное обеспечение	3.1 Обеспечение руководства оперативной информацией
	3.2 Обеспечение информацией персонал
4. Автоматизация производства	4.1 Разработка автоматизированной системы управления технологическими процессами
	4.2 Использование локальных сетей в управлении
5. Обеспечение импорта	5.1 Поиск поставщиков комплектующих
	5.2 Заключение договоров
6. Обеспечение качества продукции	6.1 Тестирование программного обеспечения
	6.2 Оценка надежности продукции
	6.3 Контроль качества продукции
7. Обеспечение безопасности продукции	7.1Обеспечение безопасности продукции
	7.2 Контроль обеспечения безопасности
8. Патентование и сертификация продукции	8.1 Патентование продукции
	8.2 Сертификация продукции
9. Обеспечение поддержки клиентов	9.1 Предоставление техпомощи клиентам
	9.2 Документирование продукции
10. Разработка продукции	10.1 Разработка продукции

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

- × - основной участник процесса;

/ - частичное участие в процессе;

\ - основная ответственность за выполнение процесса.

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

Таблица 1.4 - Организационно-управленческая модель предприятия

1.3 Технические и программные средства ЭИВТ предприятия

.3.1 Задачи, решаемые с использованием средств ЭИВТ

Функциональные задачи, решаемые, с использованием средств ЭИВТ представлены в таблице 1.5.

Таблица 1.5 - Функциональные задачи решаемые, с использованием средств ЭИВТ

Номер и название функциональной задачи	Номер и содержание функциональной подзадачи	Наименование подсистемы
1. Информирование	1.1 Обеспечение руководства оперативной информацией	АС "Портал"
	1.2 Обеспечение информацией персонал	АС "Портал"
2. Автоматизация	2.1 Автоматизация офиса	MS Office
	2.2 Разработка автоматизированной системы управления технологическими процессами	MS Visual Studio, NetBeans IDE
3. Обеспечение качества	3.1 Тестирование программного обеспечения	MantisBT	MantisBT
	3.3 Контроль качества продукции	MantisBT
4. Обеспечение поддержки клиентов	4.1 Предоставление техпомощи клиентам	АС "Портал самообслуживания"
	4.2 Документирование продукции	MS Office
5. Разработка продукции	5.1 Разработка ПО	MS Visual Studio, NetBeans IDE, AVR Studio
	5.2 Разработка схем	P-CAD
	5.3 Контроль версий	SVN

1.3.2 Технические средства

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

Таблица 1.6 - Основные технические средства

Группа средств	Средства	Кол-во
Компьютеры	Главный сервер	1
	Сервер печати	1
	Сервер почты	1
	Прокси-сервер	1
	Рабочие станции администрации	10
	Рабочие станции КБСУ	16
	Рабочие станции КБС	7
	Рабочие станции ОКПП	15
	Рабочие станции ОКПО	6
	Рабочие станции КБТМО	10
	Рабочие станции КБЭХЗ	6
	Рабочие станции БПС	6
	Рабочие станции ОТП	7
	Рабочие станции ЛР	7
	Рабочие станции ОР	8
Телекоммуникационное оборудование	Сетевые хабы (32 порта)	2
	Cетевые хабы (16 портов)	3
	Оборудование кабельных систем	-
Оборудование печати	Лазерный принтер	14
	Плоттер	1
Другое оборудование	Сканер	8

1.3.3 Программные средства

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

MS VS 2005 (Microsoft Visual Studio) - продукт компании Майкрософт, включающий интегрированную среду разработки программного обеспечения и ряд других инструментальных средств.

AVR Studio - интегрированная среда разработки (IDE) для разработки 8-битных AVR приложений от компании Atmel.IDE - свободная интегрированная среда разработки приложений на языках программирования Java, JavaFX, Python, PHP, JavaScript, C++, Ада и ряде других.(также известная как "SVN") - свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc (хранит исходные коды программы, следит за их изменениями, одно из основных достоинств - централизованное хранение данных).

P-CAD - система автоматизированного проектирования электроники (EDA) производства компании Altium. Предназначена для проектирования многослойных печатных плат вычислительных и радиоэлектронных устройств.

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

"Портал" - web-приложение, предназначенное для информирования персонала предприятия (предоставляет разграниченный, по привилегиям, доступ к базе данных, в которой хранятся все электронные документы, такие как технические требования, технические задания, акты внедрения, акты соответствия и др.).

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

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

- × - основное использование в процессе, решение основных задач;

\ - частичное использование, вспомогательное использование,

/ - обеспечение работы других средств.

Таблица 1.7 - Использование программных средств

Программные средства

Категория

Номера задач

1.1

1.2

2.1

2.2

3.1

3.2

3.3

4.1

4.2

5.1

5.2

5.3

ОС Linux

Системное

ОС Windows ХР

Системное

MS VS 2005

Разработка ПО

AVR Studio

Разработка ПО

Netbeans IDE

Разработка ПО

SVN

Разработка ПО

MantisBT

Разработка ПО

P-CAD

Разработка схем

Apache

Системное

IIS

Системное

"Портал"

Общее

MS OFFICE

Общее

1.3.4 Локальная сеть предприятия

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

Основные характеристики локальной сети:

· на канальном уровне используется технология Ethernet;

· используются коммутаторы фирмы D-Link;

· основной кабельной системой является витая пара (как экранированная, так и неэкранированная).

Схема локальной сети предприятия представлена не рисунках 1.5 и 1.6 (на рисунке 1.5 представлена часть сети, которая расположена на первом этаже здания, а на рисунке 1.6 - на втором этаже).

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

Локальная сеть построена по топологии "дерево".

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

Условные обозначения, используемые на схеме:

· группа серверов - ГС;

· рабочее место сотрудника с ПК, подключенным к сети - ;

· сетевой хаб (32 порта) - ;

· сетевой хаб (16 портов) - ;

· сетевой принтер - ;

· кабельная система - ;

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

Рисунок 1.5 - Схема локальной сети предприятия (первый этаж)

Рисунок 1.6 - Схема локальной сети предприятия (второй этаж)

1.3.5 Организация доступа к мировым информационным сетям

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

.3.6 Обеспечение информационной безопасности, защита информации

На предприятии используется доменная политика безопасности, для каждого сотрудника создается учетная запись. Учётная запись - запись, содержащая сведения, которые пользователь сообщает о себе некоторой компьютерной системе. Перед каждой загрузкой операционной системы на своем компьютере, пользователь должен пройти процедуру авторизации. Учетные записи не "привязаны" к конкретным машинам пользователей (т.е. пользователи могут поменяться ЭВМ, но работать, используя свои учетными записями), а управление учетными записями производится централизовано.

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

.3.7 Информационные базы и информационные потоки

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

Рисунок 1.7 - Схема утверждения технического задания

.3.8 Проблемные ситуации и способы их решения

Основные проблемные ситуации (и способы их решения), имеющиеся на предприятии представлены в таблице 1.8.

Таблица 1.8 - Проблемные ситуации и способы их решения

Проблемная ситуация	Способ решения
Недостаточная автоматизация	Разработка и внедрение ИС
Устаревшее оборудование	Замена оборудования
Нехватка квалифицированных кадров	Набор и обучение кадров
Нехватка специализированного ПО	Приобретение необходимого ПО
Нехватка рабочего пространства	Приобретение зданий под офисы

.3.9 Выбор проблемной ситуации для решения

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

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

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

1) информационная подсистема тестирования PLC-модемов для отдела качества ЗАО "КИЭП "Энергомера" предназначена для автоматизации процессов тестирования PLC-модемов и процессов сбора, обработки и хранения информации о проведенных тестах, а также предоставления этой информации пользователям;

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

) в системе должны быть поддержаны два типа тестирований:

· тестирование AT-команд;

· тестирование команд протокола NNCL.

4) для всех тестов должна указываться следующая информация:

· время начала проведения тестирования;

· время завершения проведения тестирования;

· режим тестирования;

· пользователь, проводивший тестирование.

5) для тестирований команд протокола NNCL должна предоставляться следующая информация:

· количество ошибок обнаруженных при тестировании;

· количество запросов, на которые не получены ответы;

· входные данные к тестированию (адреса модемов).

6) должен контролироваться доступ к системе.

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

.4 Формулировка задач проектирования

.4.1 Общие сведения о проекте

Проект называется "Информационная подсистема PLC-Tester". Разработчиком является отдел качества программного обеспечения ЗАО "КИЭП "Энергомера". Исполнителем проекта является студент группы ИС-061 Саркисов Сергей Артурович, техник отдела качества программного обеспечения ЗАО "КИЭП "Энергомера".

.4.2 Назначение, цели создания информационной подсистемы

Основные цели создания информационной подсистемы:

· повышения качества тестирования встроенного программного обеспечения PLC-модемов;

· повышение производительности труда;

· снижение нагрузки на персонал;

· повышение прибыли.

1.4.3 Характеристика объекта автоматизации

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

· обмен данными между ПК и PLC-модемом;

· обработка полученных данных.

В силу особенностей модемов, в системе выделены два типа тестов:

· тестирование AT-команд;

· тестирование команд протокола NNCL.

Тестирование проводится в двух основных режимах:

· режим тестирования функциональности;

· нагрузочный режим.

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

· MAC-адреса модемов, задействованных в тестировании;

· режим теста (нагрузочный тест, функциональное тестирование);

· тип адресации (указывает используемый тип адресации);

· дополнительные данные (последовательный порт и его настройки).

Входными данными для процесса тестирования AT-команд являются:

· режим теста (нагрузочный тест, функциональное тестирование);

· дополнительные данные (последовательный порт и его настройки).

Выходными данными для тестов являются:

· результат завершения теста;

· количество ошибок (только тесты команд протокола NNCL);

· количество неполученных ответов (тесты команд NNCL);

· журналы тестов.

Управляющими воздействиями являются:

· запуск теста;

· остановка теста;

· сохранение результатов тестирований в базу данных.

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

1.4.4 Требования к подсистеме

Требования к проектируемой информационной подсистеме удобно проиллюстрировать диаграммой вариантов ее использования в нотации UML (рисунок 1.8). На диаграмме представлены шесть актеров (представляют основные модули подсистемы и её пользователей), и самые основные функции, которые они должны выполнять. Система должна быть разработана по технологии "клиент/сервер" и состоять из трех основных модулей:

· модуль автоматизации процесса тестирования (и сбора данных);

· база данных (для долгосрочного хранения данных, полученных в результате тестирований);

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

база данный тестирование программный

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

В системе три основных типа пользователей:

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

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

· администраторы системы (имеют доступ к базе данных, без каких-либо ограничений).

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

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

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

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

Информационная подсистема тестирования PLC-модемов не должна зависеть от других ИС.

.4.5 Состав и содержание работ по созданию подсистемы

Состав и содержание работ по созданию системы должны удовлетворять требованиям ГОСТ 34.601-90.

ГОСТ <#"525240.files/image010.gif">

Рисунок 2.1 - ER-диаграмма базы данных в нотации "Crow's Foot"

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

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

Сущность NNCLTest имеет следующие атрибуты:

· nncl_test_id - первичный ключ;

· begin - дата и время начала тестирования;

· end - дата и время завершения тестирования;

· input_data - входные данные для теста (внешний ключ);

· nncl_test_mode - режим теста (внешний ключ);

· command_count - количество отправленных команд;

· error_count - количество ошибок;

· no_answer_count - количество запросов, оставшихся без ответа;

· end_code - код завершения (внешний ключ);

· user_login - логин пользователя (внешний ключ).

Сущность ATTest имеет следующие атрибуты:

· at_test_id - первичный ключ;

· begin - дата и время начала тестирования;

· end - дата и время завершения тестирования;

· at_test_mode - режим теста (внешний ключ);

· end_code - код завершения (внешний ключ);

· user_login - логин пользователя (внешний ключ).

Сущность TestMode имеет следующие атрибуты:

· test_mode_id - первичный ключ;

· test_mode_name - наименование типа тестирования;

· description - описание;

· nncl_only - принадлежность режима теста к типу теста.

Сущность EndCode имеет следующие атрибуты:

· end_code_id - первичный ключ;

· end_code_name - наименование кода завершение;

· description - описание.

Сущность NNCLLog имеет следующие атрибуты:

· nncl_log_id - первичный ключ;

· nncl_test - тест, к которому относится лог (внешний ключ);

· nncl_log_file - прикрепляемый файл;

· nncl_log_type - тип прикрепляемого файла (внешний ключ);

· description - описание.

Сущность ATLog имеет следующие атрибуты:

· at_log_id - первичный ключ;

· at_test - тест, к которому относится лог (внешний ключ);

· at_log_file - прикрепляемый файл;

· at_log_type - тип прикрепляемого файла (внешний ключ);

· description - описание.

Сущность LogType имеет следующие атрибуты:

· log_type_id - первичный ключ;

· log_type_name - наименование;

Сущность NNCLInputData имеет следующие атрибуты:

· nncl_input_id - первичный ключ;

· first_mac - MAC-адрес первого модема в списке тестировании;

· last_mac - MAC-адрес последнего модема в списке тестировании;

· host_mac - MAC-адрес host-модема, участвующего в тестировании;

Сущность User имеет следующие атрибуты:

· login - логин пользователя (первичный ключ);

· password - пароль пользователя;

· email - адрес электронной почты пользователя;

· user_type - тип пользователя (внешний ключ);

· first_name - имя пользователя;

· second_name - фамилия пользователя;

· third_name - отчество пользователя.

Сущность UserType имеет следующие атрибуты:

· user_type_id - первичный ключ;

· user_type_name - имя типа пользователя;

· description - описание;

· can_add - возможность добавлять информацию;

· can_delete - возможность удалять информацию.

Функциональные зависимости представлены на рисунках 2.2 - 2.10.

Рисунок 2.2 - Функциональные зависимости между атрибутами сущности NNCLTest

Рисунок 2.3 - Функциональные зависимости между атрибутами сущности TestMode

Рисунок 2.4 - Функциональные зависимости между атрибутами сущности ATTest

Рисунок 2.5 - Функциональные зависимости между атрибутами сущности EndCode

Рисунок 2.6 - Функциональные зависимости между атрибутами сущности NNCLLog

Рисунок 2.7 - Функциональные зависимости между атрибутами сущности LogType

Рисунок 2.8 - Функциональные зависимости между атрибутами сущности ATLog

Рисунок 2.9 - Функциональные зависимости между атрибутами сущности NNCLInputData

Рисунок 2.10 - Функциональные зависимости между атрибутами сущностей UserType и User

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

2.2.4 Создание физической модели данных

В таблицах 2.1 - 2.9 представлены составы таблиц базы данных. Для каждого поля таблицы указан тип данных (столбец "Тип поля"). Для некоторых полей введен запрет на использование неопределенных значений (столбец "NULL"). Примечание - Если в столбце "NULL" указано значение "Нет", это означает, что данное поле, при заполнении таблицы в базе данных, не может иметь неопределенные значения, в противном случае поле может иметь неопределенные значения.

Таблица 2.1 - Состав таблицы NNCLTest

Наименование атрибута	Тип поля	NULL
nncl_test_id nncl_test_mode begin end command_count error_count no_answer_count user_login end_code input_data	INT(11) INT(11) DATETIME DATETIME INT(11) INT(11) INT(11) VARCHAR(30) INT(11) INT(11)	Нет Нет Нет Нет Нет Нет Нет Нет Нет Нет

Ключи таблицы:

· nncl_test_id (первичный ключ), по полю nncl_test_id;

· FK_nncltest_endcode_end_code_id, по полю end_code;

· FK_nncltest_user_login, по полю user_login;

· FK_nncltest_nnclinputdata_nncl_input_id, по полю input_data;

· FK_nncltest_testmode_test_mode_id, по полю nncl_test_mode.

Таблица 2.2 - Состав таблицы ATTest

Наименование атрибутаТип поляNULL
at_test_id at_test_mode begin end end_code user_login	INT(11) INT(11) DATETIME DATETIME INT(11) VARCHAR(30)	Нет Нет Нет Нет Нет Нет

Ключи таблицы:

· at_test_id (первичный ключ), по полю at_test_id;

· FK_attest_endcode_end_code_id, по полю end_code;

· FK_attest_user_login, по полю user_login;

· FK_attest_testmode_test_mode_id, по полю at_test_mode.

Таблица 2.3 - Состав таблицы TestMode

Наименование атрибута	Тип поля	NULL
test_mode_id test_mode_name description nncl_only	INT(11) INT(11) VARCHAR(255) BOOL	Нет Нет Да Нет

Ключи таблицы:

· test_mode_id (первичный ключ), по полю test_mode_id.

Таблица 2.4 - Состав таблицы EndCode

Наименование атрибутаТип поляNULL
end_code_id end_code_name description	INT(11) VARCHAR(50) VARCHAR(255)	Нет Нет Да

Ключи таблицы:

· end_code_id (первичный ключ), по полю end_code_id.

Таблица 2.5 - Состав таблицы NNCLLog

Наименование атрибутаТип поляNULL
nncl_log_id nncl_test nncl_log_file nncl_log_type description	INT(11) INT(11) VARCHAR(255) INT(11) VARCHAR(255)	Нет Нет Нет Нет Да

Ключи таблицы:

· end_code_id (первичный ключ), по полю end_code_id;

· FK_nncllog_logtype_log_type_id, по полю nncl_log_type;

· FK_nncllog_nncltest_nncl_test_id, по полю nncl_test.

Таблица 2.6 - Состав таблицы LogType

Наименование атрибутаТип поляNULL
log_type_id log_type_name description	INT(11) VARCHAR(50) VARCHAR(255)	Нет Нет Да

Ключи таблицы:

· log_type_id (первичный ключ), по полю log_type_id.

Таблица 2.7 - Состав таблицы ATLog

Наименование атрибутаТип поляNULL
at_log_id at_test at_log_type at_log_file description	INT(11) INT(11) INT(11) VARCHAR(255) VARCHAR(255)	Нет Нет Нет Нет Да

Ключи таблицы:

· at_log_id (первичный ключ), по полю at_log_id;

· FK_atlog_attest_at_test_id, по полю at_test;

· FK_atlog_logtype_log_type_id, по полю at_log_type.

Таблица 2.8 - состав таблицы NNCLInputData

Наименование атрибута	Тип поля	NULL
nncl_input_id first_mac last_mac host_mac	INT(11) INT(11) INT(11) INT(11)	Нет Нет Нет Нет

Ключи таблицы:

· nncl_input_id (первичный ключ), по полю nncl_input_id.

В таблицах 2.9 и 2.10 представлены описания таблиц User и UserType, представляющие одноименные сущности.

Таблица 2.9 - состав таблицы User

Наименование атрибута	Тип полей	NULL
login password email user_type first_name second_name third_name	VARCHAR(30) VARCHAR(50) VARCHAR(100) INT(11) VARCHAR(255) VARCHAR(255) VARCHAR(255)	Нет Нет Нет Нет Нет Нет Нет

Ключи таблицы:

· login (первичный ключ), по полю login;

· FK_user_usertype_user_type_id, по полю user_type.

Таблица 2.10 - состав таблицы UserType

Наименование атрибутов	Тип поля	NULL
user_type_id user_type_name description can_add can_delete	INT(11) VARCHAR(30) VARCHAR(255) BOOL BOOL	Нет Нет Да Нет Нет

Единственный ключ таблицы - login (первичный ключ), по полю login.

.2.5 Разработка хранимых процедур

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

Так же хранимые процедуры обладают рядом преимуществ:

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

· сокращение сетевого трафика;

· безопасность;

· простота доступа.

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

Таблица 2.11 - Описание хранимых процедур

Название процедуры	Описание процедуры
get_at_logs_list	Возвращает список журналов, "прикрепленных" к тестам AT-команд
get_at_test_info	Возвращает информацию о выбранном тесте AT-команд
get_at_tests_list	Возвращает список тестирований AT-команд
get_end_codes_list	Возвращает список кодов завершения
get_log_types_list	Возвращает список типов журналов
get_nncl_logs_list	Возвращает список журналов, "прикрепленных" к тестам команд протокола NNCL
get_nncl_test_info	Возвращает информацию о выбранном тесте команд протокола NNCL
get_nncl_tests_list	Возвращает список тестов команд протокола NNCL
get_test_modes_list	Возвращает список режимов тестирования команд протокола
get_user_info	Возвращает информацию о выбранном пользователе
get_users_list	Возвращает список пользователей
attach_file	Добавляет файл в базу данных

Код описанных хранимых процедур представлен в приложении Г.

2.2.6 Создание пользователей и распределение привилегий

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

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

Таблица 2.12 - Описание пользователей базы данных

Пользователь	Привилегии	Описание
plc_tester	INSERT, SELECT	Используется для доступа к базе данных модулем тестирования
php_user	SELECT, EXECUTE	Используется для доступа к базе данных web-приложением

Следует отметить, что учетная запись является составной и принимает форму username@host, где username - имя пользователя, а host - наименование/адрес узла, с которого пользователю username разрешено обращаться к базе данных. Соответственно, администратор сервера, на котором установлена база, данных должен указать фактические адреса машин (можно использовать символ %, который выполняет туже функцию, как и в операторе LIKE).

Для создания пользователя используется оператор CREATE USER, который имеет следующий синтаксис: CREATE USER user [IDENTIFIED BY [PASSORD] password], оператор создает учетную запись user с необязательным паролем password.

Привилегии задаются оператором GRANT. Привилегии INSERT, SELECT и EXECUTE позволяют выполнять добавление данных, выборку данных и выполнять хранимые процедуры, соответственно. Лишить привилегий пользователя можно командой REVOKE.

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

2.3.1 Проектирование модуля

Модуль тестирования и сбора данных должен производить тестирования PLC-модемов, обрабатывать результаты тестов и сохранять их в базу данных. В информационной подсистеме тестирования PLC-модемов рассматриваются два вида тестов: команд протокола NNCL и AT-команд, поэтому принято решение модуль тестирования и сбора сделать составным.

Модуль TNNCL.dll выполняет тестирование команд протокола NNCL, а TAT.dll - AT-команд. Модули TNNCL.dll и TAT.dll между собой никак не взаимодействуют, и связаны только с модулем PLCTester.exe, это представлено на диаграмме компонентов (рисунке 2.11), в нотации UML.

Рисунок 2.11 - Диаграмма компонентов модуля тестирования/сбора данных в нотации UML

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

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

К именованному каналу можно обращаться в значительной степени как к файлу. Можно использовать функции Windows API CreateFile, CloseHandle, ReadFile, WriteFile, чтобы открывать и закрывать канал, выполнять чтение и запись. Функции стандартной библиотеки C такие как fopen, fread, fwrite и fclose, тоже можно использовать, в отличие от сокетов Windows, которые не реализуют использование стандартных файловых операций в сети.

PLCTester.exe создает экземпляр именованного канала, к которому подключается один из подмодулей TNNCL.dll или TAT.dll.

При завершении тестирования PLCTester.exe обрабатывает результаты сохраняет их в базу данных.

2.3.2 Разработка модуля TNNCL.dll

Модуль TNNCL.dll реализован как библиотека динамической компоновки - понятие операционных систем Microsoft Windows и IBM OS/2; динамическая библиотека, позволяющая многократное применение различными программными приложениями.

Инициализация тестирования производится функцией модуля TNNCL.dll TNNCLConstructor, которая в параметрах получает входные данные для теста и служебную информацию (настройки последовательного порта, имя именованного канала, дескриптор главного окна приложения). Принудительное завершение тестирование производится вызовом функции TNNCLDestructor (того же модуля). Сам процесс тестирования выполняется в отдельном потоке операционной системы, выполняясь после завершения TNNCLConstructor.

Функции TNNCLConstructor и TNNCLDestructor вызываются модулем PLCTester.exe.

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

Границей SLIP-кадра является уникальный флаг END (0xC0). Уникальность этого флага поддерживается байт-стаффингом (byte stuffing) внутри кадра с ESC-последовательностью 0xDB, причём байт END (0xС0) заменяется последовательностью (0xDB, 0xDC), а байт ESC (0xDB) - последовательностью (0xDB, 0xDD).

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

Обмен данными с модемом производятся через последовательный порт. Для открытия порта используется функция Windows API CreateFile, после чего порт настраивается функцией SetCommState. Запись и чтение производятся функциями ReadFile, WriteFile. Закрывается порт функцией CloseHandle. Весь кадр, отправляется сразу целиком. Получение ответа производится по более сложному алгоритму, чтение данных из порта будет продолжаться, до тех по пока не будет получен второй байт "0xC0" либо пока не выйдет время таймаута (таймаут задается при вызове функции, отвечающей за получение данных).

Модуль реализован на языке программирования C++, в среде программирования NetBeans IDE с компилятором "MinGW".

2.3.3 Разработка модуля TAT.dll

Модуль TAT.dll работает аналогично модулю TNNCL.dll. Основным отличием является то, что данные передаются модулю PLCTester.exe в более простой форме и отправляются не SLIP-кадры а AT-команды.

AT-команды (набор команд Hayes) - набор команд, разработанных в 1977 году компанией Hayes для собственной разработки, модема "Smartmodem 300 baud". Набор команд состоит из серий коротких текстовых строк, которые объединяют вместе, чтобы сформировать полные команды операций, таких как набор номера, начала соединения или изменения параметров подключения.

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

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

Стандартизация набора команд Hayes (и AT-команд) выразилась в документе под названием Data Transmission Systems and Equipment - Serial Asynchronous Automatic Dialing and Control, известном как TIA/EIA-602.

Данные модулю PLCTester.exe передаются в виде строки, первый символ которой является "управляющим", возможные значения:

· "S" (данные переданы модему);

· "R" (данные получены от модема).

Модуль реализован на языке программирования C++, в среде программирования NetBeans IDE с компилятором MinGW.

2.3.4 Разработка модуля PLCTester.exe

Данный модуль связан с базой данных, его основными задачами являются:

· обработка данных, полученных от модулей TNNCL.dll и TAT.dll;

· сохранение данных в базу данных на сервере.

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

Для работы с базой данных используются классы из пространства имен MySql.Data.MySqlClient:

· MySqlConnection (для соединения с базой данных);

· MySqlCommand (команда для выполнения SQL-запроса);

· MySqlDataReader (для чтения результатов SQL-запросов);

· MySqlException (для обработки исключений).

Для работы с именованными каналами используются класс NamedPipeServerStream из пространства имен System.IO.Pipes.

Для работы с последовательным портом используется класс SerialPort из пространства имен System.IO.Ports.

Для записи настроек и экспорта результатов тестирований на диск (в энергонезависимую память) используются классы пространств имен System.IO и System.Runtime.Serialization.Formatters.Binary: FileStream, BinaryFormatter.

Основными экранными формами приложения (модуля PLCTester.exe) являются:

· форма входа в систему (соединения с базой данных и авторизации пользователя);

· главная форма (на ней располагаются все основные инструменты);

· формы сохранения результатов в базу данных.

Так же используются вспомогательные формы:

· форма настройки последовательного порта;

· форма просмотра информации о задачах, поставленных в очередь на выполнение;

· форма менеджера файлов входных данных;

· форма настроек запуска внешних приложений.

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

· "Тестирование команд протокола" - тестирование команд протокола NNCL;

· "Тестирование AT-команд" - тестирование AT-команд;

· "Планирование задач и настройки" - настройки приложения и планирование задач;

· "Конфигурирование модема" - базовая конфигурация модема;

· "Произвольные команды" - терминал.

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

Чтение данных из именованного канала аналогично чтению из файла.

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

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

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

При конфигурировании модемов реализованы функции чтения и записи конфигурации, а так же записи настроек по умолчанию. Настраиваются модемы AT-командами.

Для работы с потоками в .NET используется класс Thread пространства имен System.Threading.

Для корректной работы и полной функциональности модуль PLCTester.exe использует конфигурационные файлы на жестком диске, это показано на диаграмме компонентов в нотации UML (рисунок 2.12).

Рисунок 2.12 - Диаграмма компонентов модуля тестирования/сбора данных в нотации UML

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

Таблица 2.13 - Описание основных файлов настроек

Имя файла	Описание
Actions.ats	Хранит информацию о задачах, поставленных в очередь на выполнение
ATInputData.atc	Хранит входные данные для тестирования AT-команд
DBConnectionSettings.dbst	Хранит данные для соединения с базой данных
ProtocolInputData.tc	Хранит входные данные для тестирования команд протокола NNCL
RunSettings.rst	Хранит настройки для запуска внешних приложений
Default.mc	Хранит основные настройки приложения
PPortSettings.ps	Хранит настройки последовательного порта для тестирования команд протокола NNCL
ATPortSettings.ps	Хранит настройки последовательного порта для тестирования AT-команд
CPortSettings.ps	Хранит настройки последовательного порта для конфигурирования модемов

Модуль PLCTester.exe реализован в виде Windows-приложения, написан на языке программирования C# в интегрированной среде разработки SharpDevelop.

2.4 Разработка web-приложения

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

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

· mysql_connect(string $hostname, string $user, string $password), для соединения с базой данных и авторизации пользователя (все параметры - необязательные);

· mysql_close(int $connect_id), для закрытия соединения (параметр connect_id необязательный);

· mysql_select_db(string $db, int $id), для выбора базы данных, с которой нужно работать (параметр id необязательный);

· mysql_query(string $query), для выполнения запросов к базе данных;

· mysql_errno(int $id), для получения кода ошибки;

· mysql_error(int $id), для получения описания ошибки.

Для обработки результатов запросов используются следующие функции:

· mysql_result - полчить нужный элемент из набора записей;

· mysql_fetch_array - занести запись в ассоциативный массив или числовой массив;

· mysql_fetch_row - занести запись в массив;

· mysql_fetch_assoc - занести запись в ассоциативный массив;

· mysql_fetch_object - занести запись в объект;

· mysql_num_row - узнать, сколько записей содержит результат выполнения запроса.

PHP предоставляет ещё несколько полезных функций, которые позволяют узнать дополнительную информацию о результате выполнения запросов:

· mysql_field_name(int $result, int $offset) - возвращает имя поля, находящегося в результате $result по индексу $offset;

· mysql_filed_type(int $result, int $offset) - возвращает тип поля с индексом $offset в результате $result.

Для передачи данных из формы в сценарий используется методы POST и GET.

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

Выводы

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

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

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

3. ИНФОРМАЦИОННАЯ ПОДСИСТЕМА "PLC-TESTER"

.1 Общие сведения о программном продукте

Программный продукт называется "Информационная подсистема PLC-Tester", состоит из следующих модулей:

· база данных (используется СУБД MySQL);

· модуль тестирования и сбора данных (PLCTester);

· web-приложение, для предоставления данных пользователям.

Программное обеспечение, на котором разработано приложение:

· dbForge Studio for MySQL/MySQL Administrator (база данных);

· SharpDevelop (модуль тестирования и сбора данных);

· NetBeand IDE (модуль тестирования и сбора данных, web-приложение).

Модуль тестирования и сбора данных состоит из трёх модулей, один из которых написан на языке программирования C#, а два других - на C++.

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

· PLCtools - программа для настройки PLC-модемов, а так же для мониторинга их состояния;

· Free Serial Port Monitor - программа для перехвата данных в последовательных портах компьютера.

3.2 Функциональное назначение программного продукта

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

Модуль PLCTester выполняет два вида тестирований:

· тестирование команд протокола;

· тестирование AT-команд.

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

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

· начать тестирование команд протокола NNCL;

· начать тестирование AT-команд;

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

· сохранить журналы тестирования AT-команд;

· закрыть приложение;

· выключить ПК.

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

Модуль PLCTester позволяет производить базовое конфигурирование PLC-модемов. Основные параметры конфигурирования:

· MAC-адрес модема;

· скорость обмена по последовательному интерфейсу;

· формат байта при обмене;

· время удержания CTS;

· режим работы модема;

· время ожидания ответа от устройства;

· время между байтами в потоке данных;

· подсеть, к которой относится модем.

Данная версия программы работает с модемами фирмы "NERO electronics".

Web-приложение предназначено для передачи информации о проведенных тестированиях пользователям. Основная информация о тестах команд протокола NNCL, предоставляемая пользователям: тип теста, режим теста, время начала тестирования, время завершения тестирования, результат завершения тестирования, информация о пользователе (проводившем тестирование), количество запросов, количество ошибок, процент ошибок, количество неполученных ответов, процент неполученных ответов.

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

· дате проведения тестирования;

· типу теста;

· пользователю, проводившему тест;

· режиму теста;

· результату завершения.

Основная информация о тестах AT-команд: тип теста, режим теста, время начала тестирования, время завершения тестирования, результат завершения тестирования, информация о пользователе (проводившем тестирование), дополнительная информация в прикрепленных файлах.

Так же можно просматривать справочную информацию:

· о пользователях;

· о режимах тестирований;

· о типах журналов.

3.3 Описание логической структуры программного продукта

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

Модуль PLCTester состоит из трех основных компонентов (модулей):

· PLCTester.exe - отвечает за интерфейс пользователя, конфигурирование модемов, планирование задач, анализ и сохранение результатов;

· TNNCL.dll - отвечает за тестирование команд протокола;

· TAT.dll - отвечает за тестирование AT-команд.

При разработке модуля PLCTester.exe использовался объектно-ориентированный подход, а при разработке модулей TNNCL.dll и TAT.dll - процедурный подход. Структура модуля PLCTester показана на диаграмме рисунке 2.11 в виде диаграммы компонентов. Классы модуля можно условно разделить на две группы:

· так называемые, граничные классы (графический интерфейс пользователя);

· сущности (классы, не связанные непосредственно с управляющими воздействиями пользователей).

Описание граничных классов представлено в таблице 3.1, а классов-сущностей - в таблице 3.2.

Таблица 3.1 - Основные граничные классы модуля PLCTester.exe

Название	Назначение
MainForm	Класс главной формы приложения PLCTester.exe
ConnectForm	Класс формы, предназначенной для соединения с базой данных и авторизации пользователя
SaveToDBForm	Класс формы, предназначенной для сохранения результатов тестирования в базу данных (NNCL)
ATSaveToDBForm	Класс формы, предназначенной для сохранения результатов тестирования в базу данных (AT)
HexForm	Класс формы, предназначенной для ввода числовых значений в шестнадцатеричной форме
RunSettingsForm	Класс формы, предназначенной для ввода настроек запускаемых приложений
PortSettingsForm	Класс формы, предназначенной для ввода настроек последовательного порта
AboutBox	Класс формы, предоставляющей информацию о программе

Таблица 3.2 - Классы-сущности модуля PLCTester.exe

Название	Назначение
PortSettings	Класс инкапсулирует в себе настройки последовательного порта
ProtocolInputData	Класс инкапсулирует в себе входные данные для теста команд протокола NNCL
ATInputData	Класс инкапсулирует в себе входные данные для теста AT-команд
MainConfiguration	Класс инкапсулирует в себе основные настройки модуля PLCTester.exe
RunSettings	Класс инкапсулирует в себе настройки для запуска приложений
ActionData	Класс инкапсулирует в себе данные для задач, поставленных в очередь на выполн

Модуль TAT.dll является составным, его структура представлена на диаграмме компонентов в нотации UML на рисунке 3.1, а описание приводится в таблице 3.3.

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

Рисунок 3.1 - Структура модуля TAT.dll

Таблица 3.3 - Описание структуры модуля TAT.dll

Название модуля	Описание модуля
TAT.h	Содержит прототипы основных функций
TAT.cpp	Содержит реализации основных функций
ATTest.h	Содержит прототипы функций, непосредственно связанных с тестирование PLC-модемов
ATTest.cpp	Содержит реализации функций, непосредственно связанных с тестирование PLC-модемов

Структура модуля TNNCL.dll представлена на диаграмме компонентов в нотации UML на рисунок 3.2, а описание - в таблице 3.4.

Рисунок 3.2 - Структура модуля TNNCL.dll

Таблица 3.4 - Описание структуры модуля TNNCL.dll

Название модуля	Описание модуля
TNNCL.h	Содержит прототипы основных функций
TNNCL.cpp	Содержит реализации основных функций
Ping.h	Содержит прототипы функций, предназначенных для тестирования команды ping, протокола NNCL
Ping.cpp	Содержит реализации функций, предназначенных для тестирования команды ping, протокола NNCL
Route.h	Содержит прототипы функций, предназначенных для тестирования команды route, протокола NNCL
Route.cpp	Содержит реализации функций, предназначенных для тестирования команды route, протокола NNCL
Quality.cpp	Содержит прототипы функций, предназначенных для тестирования команды quality, протокола NNCL
Quality.h	Содержит реализации функций, предназначенных для тестирования команды quality, протокола NNCL

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

Таблица 3.5 - Описание модулей web-приложения

Имя модуля	Описание
index.php	Страница входа в систему
main_page.php	Главная страница
about_page.php	Отображает информацию о приложении
tests_list_page.php	Отображает список тестов (краткая информация о тестированиях)
nncl_test_page.php	Отображает подробную информацию о выбранном тестировании команд протокола NNCL
at_test_page.php	Отображает подробную информацию о выбранном тестировании AT-команд
logs_list_page.php	Отображает информацию о журналах к выбранному тестированию
user_page.php	Отображает информацию о выбранном пользователе
users_page.php	Отображает список пользователей системы
end_code_page.php	Отображает список кодов завершения тестирования
test_mode_page.php	Отображает список режимов тестов
log_type_page.php	Отображает список типов журналов
support.php	Страница поддержки пользователей системы
login.php	Отвечает за авторизацию пользователей
upload.php	Отвечает за загрузку файлов на сервер
default.css	Стили оформления

Модули можно разделить на два типа: так называемые визуальные (или граничные) модули, которые предоставляют интерфейс пользователя и модули, отвечающие только за обработку данных или иные служебные действия (login.php, upload.php и default.css).

Модуль default.css используется всеми остальными, за исключением login.php и upload.php, для описания внешнего вида документов. На рисунке 3.3, в виде диаграммы компонентов в нотации UML, показаны основные зависимости между модулями web-приложения.

Рисунок 3.3 - Основные зависимости между модулями web-приложения

При обращении к серверу, пользователю предоставляется форма авторизации (модуль index.php), данные из которой передаются для обработки модулю login.php. Если авторизация проходит успешно, выполняется модуль main_page.php, этот модуль является основным, служит для поиска необходимой информации, из него можно перейти к модулям: nncl_tests_list_page.php, at_tests_list_page.php, about_page.php, в противном случае снова открывается страница авторизации.

Со страниц, представляемыми модулями nncl_tests_list_page.php и at_tests_list_page.php можно перейти к модулям nncl_test_page.php и at_test_page.php соответственно, и к модулю user_page.php. От модуля nncl_test_page.php и at_test_page.php можно перейти к модулям user_page.php и log_list_page.php.

Из любого модуля, кроме index.php, можно перейти к модулям: users_page.php, test_mode_page.php, end_code_page.php и log_type_page.php. Из любого модуля (кроме main_page.php), можно перейти к модулю main_page.php. Со всех страниц можно перейти на страницу about_page.php.

В модулях nncl_test_page.php и at_test_page.php имеются формы для загрузки файлов на сервер, а данные из этих форм предаются модулю upload.php. После удачного завершения работы модуля upload.php выполняется переход к модулю log_list_page.php. Из любого модуля можно перейти к модулю support.php.

.4 Требования к техническому обеспечению

.4.1 Общие требования

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

· web-сервер Apache2;

· интерпретатор PHP;

· СУБД MySQL.

Данные программные продукты могут работать на разных операционных системах, но предпочтительнее UNIX-системы (планируется использовать дистрибутив Linux Debian 6).

На ЭВМ оператора системы должны быть установлены следующие программные продукты:

· ОС Windows XP SP3 и выше;

· .NET Framework 4.0;

· MySQL Connector Net 6.х.х;

· PLCTester.

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

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

Таблица 3.6 - Минимальные системные требования основных используемых программных продуктов

Название ПО	Минимальные системные требования
	Частота ЦП	ОЗУ	Жесткий диск
Windows XP	233 МГц	128 Мб	1,5 Гб
Debian 6	133 МГц	128 Мб	1 Гб
.NET Framework 4	1 ГГц	512 Мб	850 Мб

Объем используемой памяти программными продуктами MySQL, Apache 2, интерпретатором PHP представлено в таблице 3.7.

Таблица 3.7 - Объем используемой памяти MySQL, Apache 2 и PHP

Название ПО	Объем используемой памяти
	ОЗУ	Жесткий диск
MySQL	16 Мб	109 Мб
Apache 2	16 Мб	7 Мб
Интерпретатор PHP	8 Мб	13 Мб

3.4.2 Требования к центральному процессору

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

Для работы сервера необходим процессор с тактовой частотой не мене 2 ГГц, а рекомендуемое значение тактовой частоты - 3 ГГЦ и выше.

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

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

Рекомендуется использовать процессор с тактовой частотой - 2 ГГц и выше.

3.4.3 Требования к оперативному запоминающему устройству

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

, (3.1)

где V - общий объем необходимой памяти;

V_i - объем используемой памяти i-тым программным продуктом;

V_доп - объем памяти, необходимой для обработки запросов клиентов.

Для сервера с установленными Debian 6, MySQL, Apache2 и интерпретатора PHP, расчетные данные для которых приведены в таблицах 3.6 и 3.7 и значением V_доправным 856 Мб (получено эмпирическим путем), минимальные требования к ОЗУ сервера рассчитываются по (3.1):

+ 16 + 16 + 8 + 856 = 1024 (Мб) (3.2)

Рекомендуется использовать ОЗУ объемом 2 Гб и больше.

Требования к ОЗУ персонального компьютера оператора информационной подсистемы рассчитываются по формуле (3.1), при условии что значение V_доп равно нулю. Для ЭВМ с установленными Windows XP, .NET Framework 4 (расчетные данные приведены в таблице 3.6) и модуля PLCTester. Минимальные требования к ОЗУ персонального компьютера оператора информационной подсистемы:

+ 512 + 30 = 670 Мб (3.3)

Примечание - Объем используемой памяти модулем PLCTester определен эмпирическим путем.

.4.4 Требования к наличию свободного места на жестком диске

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

, (3.4)

где H - общий объем необходимой памяти на жестком диске;

H_i - объем используемой памяти i-тым программным продуктом;

H_бд - объем памяти, занимаемый базой данных.

Для сервера с установленными Debian 6, MySQL, Apache2 и интерпретатора PHP, расчетные данные для которых приведены в таблицах 3.6 и 3.7 и значением H_бдравным 4 Гб (получено эмпирическим путем), минимальные требования к наличию свободного места на жестком диске сервера рассчитываются по (3.4):

Мб + 109 Мб + 7 Мб + 13 Мб + 4096 Мб = 5249 Мб. (3.5)

Рекомендуется использовать жесткий диск объемом свободной памяти 51 ГБ и более, так как база данных состоит из 10 таблиц, максимальный размер каждой из которых равен 4 Гб.

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

Для ЭВМ с установленными Windows XP, .NET Framework 4 (расчетные данные приведены в таблице 3.6) и модуля PLCTester (получены эмпирическим путем), минимальные к наличию свободного места на жестком диске компьютера оператора информационной подсистемы:

+ 850 + 30 = 2416 (Мб) (3.6)

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

.4.5 Требования к монитору

Как для сервера, так и для персонального компьютера оператора информационной подсистемы подойдет любой современный монитор, рекомендуется использовать монитор с диагональю 17 дюймов и более, и разрешением 900 × 600 (размер самого большого окна программы 860 × 532).

.4.6 Прочие требования

На всех ЭВМ должны быть сетевые адаптеры Ethernet. На ЭВМ оператора подсистемы должен иметься минимум один COM-порт.

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

.5 Вызов программы

.5.1 Установка ПО

Установка ПО сервера рассматривается на примере операционной системы Debian/Ubuntu. Необходимо установить следующие компоненты:

· http-сервер Apache;

· СУБД MySQL;

· интерпретатор языка PHP.

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

Для установки http-сервера Apache нужно вы полнить команду: sudo apt-get install apache2 (в командном терминале системы).

Для установки PHP нужно выполнить команду: sudo apt-get install php5 libapache2-mod-php5.

Для установки СУБД MySQL нужно выполнить команду: sudo apt-get install mysql-server libapache2-mod-auth-mysql php5-mysql.

После этих действий необходимо перезагрузить http-сервер Apache командой: sudo /etc/init.d/Apache2 reastart.

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

Для установки модуля PLCTester нужно выполнить следующие действия:

· запустить исполняемый файл setup.exe;

· в окне выбора языка установки выбрать язык установки из выпадающего списка и нажать на кнопку "OK";

· в окне "Установка - PLC-Tester" (окно приветствия мастера установки) нажать на кнопку "Далее";

· в окне "Установка - PLC-Tester" (выбор папки установки) указать папку для установки программы и нажать на кнопку "Далее";

· в окне "Установка - PLC-Tester" (выбор папки в меню Пуск) указать папку в меню "Пуск", в которой будут созданы ярлыки для программы, и нажать на кнопку "Далее";

· в окне "Установка - PLC-Tester" (выбор дополнительных задач) нужно указать, создавать ли ярлык для программы на рабочем столе, и нажать на кнопку "Далее";

· в следующем окне нужно нажать на кнопку "Установить", запустив тем самым процесс установки;

· после установки появится окно "Установка - PLC-Tester" (завершение мастера установки) в котором можно выбрать опцию "Запустить PLC-Tester" и нажать на кнопку "Завершить".

3.5.2 Запуск программы

Запуск сервера http-сервера Apache в ОС Debian/Ubuntu осуществляется командой: sudo /etc/init.d/apache2 start.

Запуск сревера MySQL в ОС Debian/Ubuntu осуществляется командой: sudo /etc/init.d/mysql start.

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

3.6 Входные данные

Входные данные программы делятся следующие группы:

· входные данные для заполнения базы данных;

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

· входные данные к тестированию AT-команд;

· входные данные для постановки новой задачи в очередь на исполнение;

· входные данные для настройки работы приложения;

· входные данные для настройки COM-портов;

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

· входные данные для настройки модема;

· служебные данные.

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

Таблица 3.7 - Входные данные к тестированию команд протокола

Название	Тип	Возможные значения
Режим теста	Список	Нормальный режим; Нагрузочный режим 1; Нагрузочный режим 2
Проверка команды (если режим теста -"Нагрузочный режим 1")	Список	Все команды; PING, PING с ошибками; ROUT; ROUT с ошибками
Тип маршрутизации (если режим теста -"Нагрузочный режим 2")	Список	ADDR_M, ADDR_NR, ADDR_NRO, ADDR_NROM, ADDR_BR, ADDR_NBR
Последовательный порт	Список	COM 1 - COM 255 или в зависимости от системы
MAC-адрес первого модема	Целый	От 1 до 4294967295
MAC-адрес последнего модема	Целый	От 1 до 4294967295
MAC-адрес хоста	Целый	От 1 до 4294967295
Автоматически прокручивать списки	Логический	Истина/Ложь

Входные данные к тестированию AT-команд представлены в таблице 3.8.

Таблица 3.8 - Входные данные к тестированию AT-команд

Название	Тип	Возможные значения
Режим теста	Список	Нормальный режим; Нагрузочный
Последовательный порт	Список	COM 1 - COM 255 или в зависимости от системы
Нельзя принудительно останавливать тест	Логический	Истина/Ложь
Нельзя принудительно закрывать приложение	Логический	Истина/Ложь
Нельзя принудительно закрывать приложение планировщику	Логический	Истина/Ложь
Автоматически прокручивать список	Логический	Истина/Ложь

К служебным данным относятся:

· настройки программы;

· информация о настройке COM-портов;

· информация о поставленных в очередь задачах.

3.7 Выходные данные

Выходные данные делятся на следующие группы:

· данные из базы данных (совпадают с входными данными);

· журнал тестирования команд протокола;

· журнал тестирования AT-команд;

· информация о задачах, поставленных в очередь (совпадают с входными данными);

· выходные данные настройки модемов (совпадают с входными данными);

· журнал монитора обмена конфигурирования модемов;

· отчеты (сохраненные журналы тестирований);

· служебная информация (совпадают с входными данными).

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

Журнал тестирования AT-команд представлен в виде одного списка, в котором отправленные данные отображаются шрифтом красного цвета, а принятые данные - шрифтом синего цвета.

Журнал монитора обмена конфигурирования модемов в виде одного списка, в котором отправленные данные отображаются шрифтом красного цвета, а принятые данные - шрифтом синего цвета.

3.8 Описание тестовых прогонов

3.8.1 Общие сведения

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

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

На рисунке 3.4 представлена схема, по которой проводилось тестирование информационной подсистемы тестирования PLC-модемов.

Рисунок 3.4 - Схема проведения тестирований информационной подсистемы

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

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

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

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

3.8.2 Тестирование модуля PLCTester

Тестирование модуля PLCTester осуществлялось по следующим направлениям:

· проверка авторизации пользователей;

· проверка работы тестирования команд протокола NNCL;

· проверка остановки тестирования команд протокола NNCL;

· проверка работы тестирования AT-команд;

· проверка остановки тестирования AT-команд;

· проверка сохранения результатов тестирования в базу данных;

· проверка сохранения журналов тестирования;

· проверка сохранения входных данных;

· проверка восстановления входных данных;

· проверка работы планировщика задач;

· проверка корректности конфигурирования модемов;

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

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

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

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

Во время тестирований, были обнаружены и исправлены некритические ошибки.

3.8.3 Тестирование web-приложения

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

· авторизация пользователей;

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

· корректное предоставление информации (основная функция web-приложения);

· загрузка файлов на сервер.

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

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

· работоспособности всех ссылок;

· загрузка на сервер файлов различных размеров;

· отображение дополнительной информации для привилегированных пользователей;

· достоверность отображаемых данных.

Во время тестирований, ошибок не обнаружено.

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

Выводы

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

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

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

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

4. технико-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРОЕКТА

.1 Краткая характеристика проекта

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

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

К основным программным средствам относятся:

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

- СУБД (поддерживающая технологию клиент-сервер).

Можно рассмотреть несколько вариантов проектирования подсистемы:

- использовать коммерческое программное обеспечение;

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

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

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

- стоимость реализации подсистемы на дешёвом платном программном обеспечении может составить около 500 000 тысяч рублей, а некоторые СУБД стоят больше 1 000 000 миллиона рублей.

С точки зрения конкретной технологии можно выделить два варианта:

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

- использовать технологию толстого клиента (обработка информации осуществляется на машине клиента).

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

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

.2 Трудоемкость выполняемых работ

Языки программирования, используемые при разработке проекта: C, C++, C#, SQL.

Число операторов системы - 2000.

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

, (4.1)

где Т_о - затраты труда на описание задачи, чел.- ч.;

Т_и- затраты на исследование предметной области, чел.- ч.;

Т_а- затраты на разработку блок схемы, чел.- ч.;

Т_п- затраты на программирование, чел.- ч.;

Т_отл- затраты на отладку программы, чел.- ч.;

Т_д- затраты на подготовку документации, чел.- ч..

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

, (4.2)

Где - число операторов, ед. (в данном случае 2000);

c - коэффициент сложности задачи (в данном случае 1,4);

p - коэффициент коррекции программы, учитывающий новизну проекта (в данном случае 0,1).

В результате из (4.2) следует

. (4.3)

Затраты труда на описание задачи Т_о точно определить заранее невозможно, поэтому ориентировочно принимается Т_о= 40 чел.-ч.

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

, (4.4)

где D - общее число операторов, ед.;

b - коэффициент увеличения затрат труда, вследствие недостаточного описания задачи (в данном случае 1,4);

s_и - количество операторов, приходящееся на один чел.-ч. (в данном случае 80);

- коэффициент квалификации программиста (в данном случае 0,8);

С учетом (4.4) следует

(чел.-ч). (4.5)

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

, (4.6)

где s_а- количество операторов, приходящееся на один чел.-ч. (в данном случае 25). Из (4.6) следует

(чел.-ч). (4.7)

Затраты труда на составление программы на ПК по готовой блок-схеме, Т_п чел.-ч., вычисляют по формуле

, (4.8)

где s_п - количество операторов, приходящихся на один чел.-ч.(в данном случае 25).

Из (4.8) следует

( чел.-ч). (4.9)

Затраты труда на отладку программы на ПК Т_отл, чел.-ч., вычисляют по формуле

(4.10)

где s_отл- количество операторов, приходящееся на один чел.-ч. (в данном случае 4).

Из (4.10) следует

( чел.-ч). (4.11)

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

(4.12)

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

, (4.13)

где s_др- количество операторов, приходящееся на один чел.-ч. (в данном случае 20).

Т_до - затраты труда на редактирование, печать и оформление документов, чел.-ч.

(4.14)

Из (4.13) следует

(чел.-ч). (4.15)

Из (4.14) следует

(чел.-ч). (4.16)

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

(чел.-ч) (4.17)

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

, (4.18)

где = 0,8 - коэффициент, учитывающий уровень языка программирования.

Из (4.18) следует

( чел.-ч). (4.19)

.3 Расчет себестоимости информационной системы подсистемы

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

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

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

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

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

д) затраты на амортизацию и ремонт вычислительной техники;

е) расходы на материалы и запасные части.

Основная заработная плата обслуживающего персонала З_о, руб., определяется по формуле

, (4.20)

где - часовая тарифная ставка программиста, руб./ч (в данном случае 60);

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

Из (4.20) следует

(руб.). (4.21)

Дополнительная заработная плата обслуживающего персонала З_д, руб., определяется по формуле

, (4.22)

где - коэффициент дополнительной заработной платы (в данном случае 0,1).

Из (4.22) следует

(руб.). (4.23)

Отчисления в социальные фонды З_с, руб., определяется по формуле

, (4.24)

где - норматив социальных отчислений (= 34%).

(руб.). (4.25)

Затраты на потребляемую электроэнергию З_э, руб., определяется по формуле

, (4.26)

где - мощность ЭВМ, кВт (в данном случае 0,45);

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

- стоимость 1 кВт-ч электроэнергии, руб./кВт-ч.

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

, (4.27)

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

(руб.). (4.28)

(руб.). (4.29)

Расходы на материалы и запасные части З_м, руб., определяется по формуле

, (4.30)

где - перечень видов материалов;

- количество i-гo вида материалов, ед., шт.;

- цена одной единицы i-гo вида материалов, руб.

Из 4.30 следует

(руб.). (4.31)

Затраты на амортизацию

, (4.32)

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

- годовой фонд времени работы вычислительной техники (2112 ч);

- норма отчислений на ремонт.

Из (4.32) следует

(руб.). (4.33)

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

, (4.34)

Из (4.34) следует

(руб.). (4.35)

.4 Оценка экономической эффективности внедрения программного продукта

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

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

, (4.36)

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

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

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

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

,(4.37)

где З_ручн - затраты на ручную обработку информации, руб.;

З_автв- затраты на автоматизированную обработку информации, руб.;

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

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

, (4.38)

где = 960 время, затрачиваемое на обработку информации вручную, ч;

= 60 - цена одного часа работы оператора, руб.;

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

Из (4.38) следует

(руб.). (4.39)

Затраты на автоматическую обработку информации рассчитываются по формуле

, (4.40)

где = 120 - затраты времени на автоматизированную обработку той же самой информации, ч;

= 60 - цена одного часа работы оператора, руб.;

= 1.2 - коэффициент, учитывающий дополнительные затраты

времени на логические операции.

Из (4.40) следует

(руб.). (4.41)

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

Из (4.37), (4.39) и (4.41) следует

(руб.). (4.42)

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

, (4.43)

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

(руб.). (4.44)

Затраты на обслуживание вычислительной техники рассчитываются по формуле (4.32) и складываются из затрат на обслуживания сервера и ПЭВМ оператора подсистемы

(руб.). (4.45)

Из (4.43), (4.44) и (4.45) следует

(руб.). (4.46)

Из (4.36), (4.42) и (4.46) рассчитывается прибыль за год

(руб.). (4.47)

Далее необходимо определить основные экономические показатели проекта:

- чистый дисконтированный доход (ЧДД) от использования программного продукта;

- срок окупаемости (Т_ок) проекта.

Срок окупаемости проекта рассчитывается по формуле

, (4.48)

Где K - капиталовложения при внедрении программного продукта, руб.;

П - прибыль от использования программного продукта за первый год его эксплуатации, руб., полученная в (4.47) при подстановке нормы дисконта E = 20%.

Срок окупаемости проекта составит

(лет). (4.49)

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

, (4.50)

где n - расчетный период, год;

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

эксплуатации, руб.;

Е = 20 % - норма дисконта;

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

Чистый дисконтированный доход за год использования программного продукта (так как продукт окупается в течении одного года) при норме дисконта составит:

(руб.) (4.51)

.5 Основные технико-экономические показатели проекта

Основные технико-экономические показатели проекта приведены в таблице 4.1.

Таблица 4.1 - Основные технико-экономические показатели проекта

Основные характеристики	Единицы измерения	Проект
Итоговая трудоемкость разработки	чел.-ч.	1372
Полные затраты на создание программного продукта	руб.	119515,16
Годовой эффект от внедрения программного продукта	руб.	156592,64
Чистый дисконтированный доход за 3 года использования программного продукта	руб.	276316,22
Срок окупаемости проекта	год	0,79

Выводы

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

Примечание - основные технико-экономические показатели проекта представлены в таблице 4.1.

5. БЕЗОПАСНОСТЬ И ЭКОЛОГИЧНОСТЬ ПРОЕКТА

.1 Общая характеристика опасных, вредных факторов на рабочем месте оператора информационной подсистемы

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

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

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

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

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

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

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

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

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

.2 Обеспечение безопасности на рабочем месте оператора информационной подсистемы

Помещение, в котором находится рабочее место оператора системы, находится на втором этаже здания, а само здание находится на закрытой территории предприятия. В помещении расположено 4 рабочих места оснащенных ПЭВМ, одно из которых занимает оператор разработанной информационной подсистемы.

Размеры помещения представлены в таблице 5.1.

Таблица 5.1 - Размеры помещения оператора подсистемы

Величина	Размерность	Значение
Длина помещения	м	6
Ширина помещения	м	4
Высота помещения	м	3,5
Площадь	м²	24
Объем	м³	84

Из данных, представленных в таблицы 5.1 и количества человек, работающих в данном помещении видно, что на каждого сотрудника приходится по 6 м² площади и по 21 м³ объема помещения, что удовлетворяет нормам (минимум 6 м² площади и минимум 20 м³ объема).

Схема помещения представлена на рисунке 5.1, на ней показаны места работников. Каждое рабочее место оборудовано, предназначенным для использования ПЭВМ, столом. Для комфортной работы каждый стол удовлетворяет следующим условиям:

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

- конструкция стола предусматривает наличие выдвижных ящиков (не менее трех для хранения документации, листингов, канцелярских принадлежностей).

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

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

Рисунок 5.1 - Схема рабочего помещения оператора информационной подсистемы

В помещении используется смешанное освещение:

- окно, площадью 6,8 м² (восточная сторона здания);

- 4 светильника, по 4 люминесцентных лампы (по 20 Вт каждая).

Примечание - На схеме светильники не обозначены.

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

Для снижения шума в помещении компьютеры, принтеры установлены на амортизирующие прокладки. Уровень шума не превышает 30 дБ.

Температура в помещении составляет 22-24 °С в холодный период года и 23-25 °С - в теплый.

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

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

Поражение электрическим током возникает при соприкосновении с электрической цепью, в которой присутствуют источники напряжения и/или источники тока, способные вызвать протекание тока по попавшей под напряжение части тела. Обычно чувствительным для человека является пропускание тока силой более 1 мА.

Основными поражающими воздействиями электрического тока на организм человека являются:

- термическое;

- элетролитический;

- биологическое;

- механическое.

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

- применение малых напряжений (где это возможно);

- электрическая изоляция;

- контроль и профилактика повреждения изоляции;

- защитное зануление;

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

В помещении имеется пожарная сигнализация, так же имеется огнетушитель.

.3 Расчет защитного зануления на отключающую способность

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

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

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

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

При замыкании фазы на зануленный корпус (стенд, с PLC-модемом), система автоматически отключится, если значение однофазного тока короткого замыкания I_к удовлетворяет условию

, (5.1)

где I_к- ток короткого замыкания;

k - коэффициент кратности тока, для автоматического выключателя, для А3161 равен 1,25;_ном - номинальный ток срабатывания автоматического выключателя, в данном случае 15 А.

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

, (5.2)

где U - фазовое напряжение сети (используется сеть напряжением 220 В);

z_T- сопротивление трансформатора (в данном случае - 0,312 Ом);

z_п - сопротивление петли фаза-нуль (контура фазный проводник и нулевой защитный проводник).

Сопротивление петли нуль-фаза рассчитывается по формуле

, (5.3)

где R_ф , R_н - активные сопротивления фазного и нулевого защитного проводников соответственно;_ф , X_н - внутренние индуктивные сопротивления фазного проводника и нулевого защитного проводника соответственно;_п - внешнее индуктивное сопротивление петли фаза-нуль.

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

. (5.4)

Активное сопротивление рассчитывается по формуле

, (5.5)

где ρ - удельное сопротивление проводника (для меди 0,018·10^-6 Ом·м);

l - длина проводника;

s - площадь поперечного сечения проводника.

Длина фазного проводника - 350 м, а защитного нулевого - 15 м.

Площадь поперечного сечения фазного проводника 3,14·10^-6 м², а нулевого проводника - 1,76·10^-6 м².

Соответственно, из (5.5) активное сопротивление фазного проводника:

(Ом). (5.6)

Активное сопротивление нулевого проводника:

(Ом). (5.7)

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

Тогда сила тока короткого замыкания равна

(А). (5.8)

Из (5.1) следует, что для автоматического выключения выключателя модели А3161 сила тока цепи должна составить

(А). (5.9)

Сила тока короткого замыкания, полученная в (5.8) примерно в 5 раз больше чем сила тока, полученная в (5.9), этот факт и формула (5.1) позволяют сделать вывод о том, что отключающая способность системы зануления обеспечена на должном уровне.

Выводы

Условия трудовой деятельности на рабочем месте оператора подсистемы удовлетворяют общим требованиям к организации и оборудованию рабочих мест обозначенных в СанПиН 2.2.2/2.4.1340-03.

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

- микроклимата;

- освещенности;

- уровня шума;

- электробезопасности.

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

ЗАКЛЮЧЕНИЕ

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

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

Подсистема способна функционировать практически полностью на свободном программном обеспечении (исключение - операционная система Windows).

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

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

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

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

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Петров, А. И. Информационные системы [Текст] / А. И. Петров. - М.: Горячая линия-Телеком, 2000. - 300 с., ил..

2. Федорченко, А.А., Синдеев, Ю.Г. Электротехника с основами электроники [Текст] / А.А. Федорченко, Ю.Г. Синдеев - М.: Издательско-торговая корпорация "Дашков и К", 2009. - 416 с..

. Информационная система,

ru.wikipedia.org/wiki/Информационная_система.

4. Автоматизированная система коммерческого учета электроэнергии,

www.energomera.ru/products/askue <#"525240.files/image112.gif">

Рисунок А.1 - Схема АСКУЭ

Приложение Б

Диаграмма размещения информационной подсистемы

Рисунок Б.1 - Диаграмма размещения информационной подсистемы

Логическая схема базы данных

Рисунок В.1 - Логическая схема базы данных

Приложение Г

Код базы данных на языке SQL

Отключение внешних ключей

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

Установка кодировки, с использованием которой клиент будет посылать запросы на серверNAMES 'utf8';

Установка базы данных по умолчанию

USE plctesterdb;

DROP TABLE IF EXISTS endcode;TABLE endcode (_code_id INT(11) UNSIGNED NOT NULL,_code_name VARCHAR(30) NOT NULL,VARCHAR(255) DEFAULT NULL,KEY (end_code_id)

)= INNODB_ROW_LENGTH = 5461SET utf8utf8_general_ci;TABLE IF EXISTS logtype;TABLE logtype (_type_id INT(11) UNSIGNED NOT NULL,_type_name VARCHAR(31) NOT NULL,VARCHAR(255) DEFAULT NULL,KEY (log_type_id)

)= INNODB_ROW_LENGTH = 4096SET utf8utf8_general_ci;TABLE IF EXISTS nncldata;TABLE nncldata (_data_id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,_mac INT(11) UNSIGNED NOT NULL,_mac INT(11) UNSIGNED NOT NULL,_mac INT(11) UNSIGNED DEFAULT NULL,KEY (nncl_data_id)

)= INNODB_INCREMENT = 4_ROW_LENGTH = 5461SET utf8utf8_general_ci;TABLE IF EXISTS testmode;TABLE testmode (_mode_id INT(11) UNSIGNED NOT NULL,_mode_name VARCHAR(30) NOT NULL,VARCHAR(255) DEFAULT NULL,_only TINYINT(1) NOT NULL,KEY (test_mode_id)

)= INNODB_ROW_LENGTH = 5461SET utf8utf8_general_ci;TABLE IF EXISTS usertype;TABLE usertype (_type_id INT(11) UNSIGNED NOT NULL,_type_name VARCHAR(50) NOT NULL,VARCHAR(255) DEFAULT NULL,_add TINYINT(1) NOT NULL,_delete TINYINT(1) NOT NULL,KEY (user_type_id)

)= INNODB_ROW_LENGTH = 5461SET utf8utf8_general_ci;TABLE IF EXISTS user;TABLE user (VARCHAR(30) NOT NULL DEFAULT '',

`password` VARCHAR(50) NOT NULL,VARCHAR(100) NOT NULL,_type INT(11) UNSIGNED NOT NULL,_name VARCHAR(255) NOT NULL,_name VARCHAR(255) NOT NULL,_name VARCHAR(255) NOT NULL,KEY (login),FK_user_usertype_user_type_id (user_type),FK_user_usertype_user_type_id FOREIGN KEY (user_type)usertype(user_type_id) ON DELETE CASCADE ON UPDATE RESTRICT

)= INNODB_ROW_LENGTH = 5461SET utf8utf8_general_ci;TABLE IF EXISTS attest;TABLE attest (_test_id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,_test_mode INT(11) UNSIGNED NOT NULL,

`begin` DATETIME NOT NULL,DATETIME NOT NULL,_code INT(11) UNSIGNED NOT NULL,_login VARCHAR(255) NOT NULL,KEY (at_test_id),FK_attest_endcode_end_code_id (end_code),FK_attest_testmode_test_mode_id (at_test_mode),FK_attest_user_login (user_login),FK_attest_endcode_end_code_id FOREIGN KEY (end_code)endcode(end_code_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_attest_testmode_test_mode_id FOREIGN KEY (at_test_mode)testmode(test_mode_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_attest_user_login FOREIGN KEY (user_login)user(login) ON DELETE CASCADE ON UPDATE CASCADE

)= INNODB_INCREMENT = 12_ROW_LENGTH = 1489SET utf8utf8_general_ci;TABLE IF EXISTS nncltest;TABLE nncltest (_test_id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,_test_mode INT(11) UNSIGNED NOT NULL,

`begin` DATETIME NOT NULL,DATETIME NOT NULL,_count INT(11) UNSIGNED NOT NULL,_answer_count INT(11) UNSIGNED NOT NULL,_login VARCHAR(30) NOT NULL,_code INT(11) UNSIGNED NOT NULL,_count INT(11) UNSIGNED NOT NULL,_data INT(11) UNSIGNED NOT NULL,KEY (nncl_test_id),FK_nncltest_endcode_end_code_id (end_code),FK_nncltest_nncl_data_nncl_data_id (input_data),FK_nncltest_testmode_test_mode_id (nncl_test_mode),FK_nncltest_user_login (user_login),FK_nncltest_endcode_end_code_id FOREIGN KEY (end_code)endcode(end_code_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_nncltest_nncl_data_nncl_data_id FOREIGN KEY (input_data)nncldata(nncl_data_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_nncltest_testmode_test_mode_id FOREIGN KEY (nncl_test_mode)testmode(test_mode_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_nncltest_user_login FOREIGN KEY (user_login)user(login) ON DELETE CASCADE ON UPDATE CASCADE

)= INNODB_INCREMENT = 7_ROW_LENGTH = 4096SET utf8utf8_general_ci;TABLE IF EXISTS atlog;TABLE atlog (_log_id INT(11) UNSIGNED NOT NULL,_test INT(11) UNSIGNED NOT NULL,_log_type INT(11) UNSIGNED NOT NULL,_log_file VARCHAR(255) NOT NULL,VARCHAR(255) DEFAULT NULL,KEY (at_log_id),FK_atlog_attest_at_test_id (at_test),FK_atlog_logtype_log_type_id (at_log_type),FK_atlog_attest_at_test_id FOREIGN KEY (at_test)attest(at_test_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_atlog_logtype_log_type_id FOREIGN KEY (at_log_type)logtype(log_type_id) ON DELETE CASCADE ON UPDATE CASCADE

)= INNODBSET utf8utf8_general_ci;TABLE IF EXISTS nncllog;TABLE nncllog (_log_id INT(11) UNSIGNED NOT NULL,_test INT(11) UNSIGNED NOT NULL,_log_file MEDIUMBLOB NOT NULL,_log_type INT(11) UNSIGNED NOT NULL,VARCHAR(255) DEFAULT NULL,KEY (nncl_log_id),FK_nncllog_logtype_log_type_id (nncl_log_type),FK_nncllog_nncltest_nncl_test_id (nncl_test),FK_nncllog_logtype_log_type_id FOREIGN KEY (nncl_log_type)logtype(log_type_id) ON DELETE CASCADE ON UPDATE CASCADE,FK_nncllog_nncltest_nncl_test_id FOREIGN KEY (nncl_test)nncltest(nncl_test_id) ON DELETE CASCADE ON UPDATE CASCADE)= INNODB_ROW_LENGTH = 147456SET utf8utf8_general_ci;$$PROCEDURE IF EXISTS get_at_logs_list$$DEFINER = 'root'@'localhost'get_at_logs_list(test_id INT(11))LOG.at_log_file, LT.log_type_name, LOG.descriptionplctesterdb.atlog AS LOG, plctesterdb.logtype AS LTLOG.at_test = test_id AND LOG.at_log_type = LT.log_type_id;

DROP PROCEDURE IF EXISTS get_at_tests_list$$

CREATE DEFINER = 'root'@'localhost'get_at_tests_list(begin_date DATE, end_date DATE, login VARCHAR(30), end_code INT(11), test_mode INT(11))

/*Все данные*/login <> '' AND end_code <> -1 AND test_mode <> -1 THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login AND TS.end_code = end_code AND TS.at_test_mode = test_mode;

/*Только логин и завершение*/login <> '' AND end_code <> -1 THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login AND TS.end_code = end_code;login <> '' AND test_mode <> -1 THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login AND TS.at_test_mode = test_mode;

/*Только режим и завершение*/end_code <> -1 AND test_mode <> -1 THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.end_code = end_code AND TS.at_test_mode = test_mode;

/*Только логин*/login <> '' THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login;

/*Только завершение*/end_code <> -1 THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.end_code = end_code;

/*Только режим*/test_mode <> -1 THENTS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.at_test_mode = test_mode;TS.at_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date;CASE;

Описание для процедуры get_at_test_info

DROP PROCEDURE IF EXISTS get_at_test_info$$DEFINER = 'root'@'localhost'get_at_test_info(test_id INT)TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.attest AS TSJOIN plctesterdb.testmode AS TM ON (TS.at_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.at_test_id = test_id; $$

Описание для процедуры get_end_codes_list

DROP PROCEDURE IF EXISTS get_end_codes_list$$DEFINER = 'root'@'localhost'get_end_codes_list()end_code_name, description FROM endcode; END

Описание для процедуры get_log_types_list

DROP PROCEDURE IF EXISTS get_log_types_list$$DEFINER = 'root'@'localhost'get_log_types_list()log_type_name, description FROM logtype;

END

Описание для процедуры get_nncl_logs_list

DROP PROCEDURE IF EXISTS get_nncl_logs_list$$DEFINER = 'root'@'localhost'get_nncl_logs_list(test_id INT(11))LOG.nncl_log_file, LT.log_type_name, LOG.descriptionplctesterdb.nncllog AS LOG INNER JOIN plctesterdb.logtype AS LT ON(LOG.nncl_log_type = LT.log_type_id)LOG.nncl_test = test_id;

$$PROCEDURE IF EXISTS get_nncl_tests_list$$DEFINER = 'root'@'localhost'get_nncl_tests_list(begin_date DATE, end_date DATE, login VARCHAR(30), end_code INT(11), test_mode INT(11))

/*Все данные*/login <> '' AND end_code <> -1 AND test_mode <> -1 THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login AND TS.end_code = end_code AND TS.nncl_test_mode = test_mode;

/*Только логин и завершение*/login <> '' AND end_code <> -1 THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login AND TS.end_code = end_code;

/*Только логин и режим*/login <> '' AND test_mode <> -1 THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login AND TS.nncl_test_mode = test_mode;

/*Только режим и завершение*/end_code <> -1 AND test_mode <> -1 THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.end_code = end_code AND TS.nncl_test_mode = test_mode;

/*Только логин*/login <> '' THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.user_login = login;end_code <> -1 THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.end_code = end_code;

/*Только режим*/test_mode <> -1 THENTS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date AND TS.nncl_test_mode = test_mode;TS.nncl_test_id, TS.begin, TS.end, TM.test_mode_name, EC.end_code_name, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)TS.begin BETWEEN begin_date AND end_date;CASE;

$$PROCEDURE IF EXISTS get_nncl_test_info$$DEFINER = 'root'@'localhost'get_nncl_test_info(test_id INT)TS.begin, TS.end, TM.test_mode_name, DA.first_mac, DA.last_mac, DA.host_mac, EC.end_code_name, TS.command_count, TS.error_count, TS.no_answer_count, TS.user_loginplctesterdb.nncltest AS TSJOIN plctesterdb.testmode AS TM ON (TS.nncl_test_mode = TM.test_mode_id)JOIN plctesterdb.endcode AS EC ON (TS.end_code = EC.end_code_id)JOIN plctesterdb.nncldata AS DA ON (TS.input_data = DA.nncl_data_id)TS.nncl_test_id = test_id;

$$PROCEDURE IF EXISTS get_test_modes_list$$DEFINER = 'root'@'localhost'get_test_modes_list()test_mode_name, description FROM testmode;

$$PROCEDURE IF EXISTS get_users_list$$DEFINER = 'root'@'localhost'get_users_list()login, first_name, second_name, third_name, email FROM user;

$$PROCEDURE IF EXISTS get_user_info$$DEFINER = 'root'@'localhost'get_user_info(user_login VARCHAR(30))US.first_name, US.second_name, US.third_name, US.email, UST.user_type_name FROM plctesterdb.user AS US INNER JOIN plctesterdb.usertype AS UST ON (US.user_type = UST.user_type_id) WHERE US.login = user_login;

END

$$;

Включение внешних ключей

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

Приложение Д

Графический интерфейс модуля PLCTester и web-приложения

Рисунок Д.1 - Главная форма модуля PLCTester (тест AT-команд)

Рисунок Д.2 - Главная форма модуля PLCTester (конфигурирование)

Рисунок Д.3 - Главная форма модуля PLCTester (настройки и запланированные задачи)

Рисунок Д.4 - Форма авторизации web-приложения

Рисунок Д.5 - Основная часть главной страницы web-приложения

Рисунок Д.6 - Основная часть страницы информации о тестировании

Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО 'КИЭП 'Энергомера'

Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО 'КИЭП 'Энергомера'

Похожие работы на - Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО 'КИЭП 'Энергомера'