• Nenhum resultado encontrado

О ПИСАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ A. Клиентское приложение

ТАБЛИЦА I К ОНФИГУРАЦИЯ ККАР

IV. О ПИСАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ A. Клиентское приложение

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

С

102

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

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

Как сказано выше, клиентское приложение должно иметь возможность связываться с другими клиентами. Это возможно благодаря тому, что современные браузеры поддерживают WebRTC. Данная технология позволяет передавать данные между браузерами по технологии точка- точка[1].

Структура клиентского приложения представлена на рис.

2. Клиентское приложение состоит из следующих частей:

 библиотека, реализующая протокол общения с сигнальным сервером;

 библиотека, реализующая протокол общения клиентов друг с другом;

 библиотека, для соединения между клиентами;

 библиотека, реализующая поддержку субтитров;

 библиотека для поддержки 3D-видео;

 библиотека для поддержки очков виртуальной реальности и панорамного видео;

 библиотека декодирования видео и формирования сегментов;

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

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

 интерфейс управления всеми компонентами приложения.

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

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

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

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

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

Для отображения субтитров используется собственная библиотека, которая отображает текст поверх видео в заданные моменты времени. Библиотека поддерживает, как встроенные в видео субтитры, так и в виде внешних подгружаемых файлов. Реализована поддержка форматов WebVTT[5], в виде внешних файлов и встроенных в WEBM формат, и tx3g[6], встроенных в MP4 формат.

Рис. 2. Структура клиентского приложения.

Приложение поддерживает воспроизведение панорамного видео для очков виртуальной реальности и 3D-видео, для этого используется библиотека WebGL, позволяющая создавать интерактивную 3D-графику в браузере[7], которая в дальнейшем отображается в элементе <canvas>. Включена поддержка вертикальной и горизонтальной стереопары, а также формирования изображения для анаглифных очков.

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

равноугольная проекция, кубическая карта и равноугольная кубическая карта.

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

103

B. Сигнальный сервер

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

C. Сервер хранения контента

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

V.

В

ЫВОДЫ И ЗАКЛЮЧЕНИЕ

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

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

С

ПИСОК ЛИТЕРАТУРЫ

[1] Global IP Solutions. WebRTC // Google. URL: https://webrtc.org.

(Accessed: 09.04.2016).

[2] Matthew Wolenetz; Jerry Smith; Aaron Colwell. Media Source Extensions //

W3C. URL: https://www.w3.org/TR/media-source/. (Accessed: 09.04.2016).

[3] Matroska. Specifications // Matroska. URL:

https://matroska.org/technical/specs/index.html. (Accessed: 09.04.2016).

[4] Information technology — Coding of audio-visual objects — Part 12: ISO base media file format // ISO/IEC 14496-12:2005(E)

[5] MDN Web Docs. Web Video Text Tracks Format (WebVTT) - Web APIs //

MDN. URL: https://developer.mozilla.org/en- US/docs/Web/API/WebVTT_API. (Accessed: 09.04.2016).

[6] Adobe Systems Incorporated. Video File Format Specification Version 10.1

// Adobe Systems Incorporated. URL:

https://wwwimages2.adobe.com/content/dam/acom/en/devnet/flv/video_file_

format_spec_v10_1.pdf. (Accessed: 09.04.2016).

[7] MDN Web Docs. WebGL - Web APIs // MDN. URL:

https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API.

(Accessed: 09.04.2016).

[8] Matthew Wolenetz; Jerry Smith; Aaron Colwell. Media Source Extensions Byte Stream Format Registry. // W3C. URL: https://www.w3.org/TR/mse- byte-stream-format-registry/.

(Accessed: 09.04.2016).

Лузгин Антон Михайлович - студент НГТУ, каф. РПиРПУ.

Область научных интересов: разработка ПО, Web-программирование.

email: tonyfulls@gmail.com

Цвык Маргарита Сергеевна - студент НГТУ, каф. РПиРПУ.

Область научных интересов: разработка ПО, Web-программирование.

email: dear.margo@yandex.ru

104 978-1-5386-7054-5/18/$31.00 ©2018 IEEE

Стенд автоматизированного тестирования устройств Wi-Fi

Валерий В. Максимов, Максим А. Степанов

Новосибирский государственный технический университет, Новосибирск, Россия

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

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

Определены критерии оценки параметров передаваемого и приемного сигналов. Приведены результаты экспериментальной апробации разработанного стенда автоматизированного тестирования. Определены направления модернизации стенда автоматизированного тестирования устройств Wi-Fi.

Ключевые слова – Wi-Fi, тестирование, алгоритм, программное обеспечение

I.

В

ВЕДЕНИЕ

АССОВОЕ производство устройств поддерживающих технологию Wi-Fi требует тщательного контроля качества. В частности имеют место периодические и производственные испытания. Производственное тестирование производится на антеннах и является обязательным для каждого устройства серии и направлено на обнаружение брака монтажа SMD-компонентов. Помимо производственного тестирования требуется проводить периодические испытания перед каждым запуском новой партии устройств и 1 раз на 10000 устройств.

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

Проводятся периодические испытания с целью обнаружения брака партии Wi-Fi чипов или критических изменений при переходе от одной ревизии платы к другой, что выливается в ухудшение TX/RX параметров. В случае неудачной пайки компонентов печатной платы устройство отправляется на устранение неисправности и повторно проходит производственный тест. В случае, когда устройство не проходит периодические испытания, то речь чаще всего речь идет о необходимости переработки устройства с целью соблюдения требований ЭМС.

II.

П

ОСТАНОВКА ЗАДАЧИ

Зачастую тестирование одного устройства 2.4 ГГц требует анализа на трех каналах (1,6,13) и минимум двух антенных разъемах. Если устройство также поддерживает диапазон 5 ГГц, то добавляются измерения еще на 5 каналах (36,60,100,132,161).

Типовая схема тестового стенда включает в себя:

 Wi-Fi тестер

 Тестируемое устройство

 Ethernet-switch

 Экранированный бокс

 ПК

 Набор кабельных сборок

К сетевой карте ПК с помощью Ethernet-switch подключаются Wi-Fi тестер и тестируемое устройство.

Радиочастотные порты Wi-Fi тестера соединяются с разъемами бокса и далее с антенными выходами тестируемого устройства с использованием кабельных сборок. Структура стенда изображена на рис.1.

Рис. 1. Структура стенда автоматического тестирования.

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

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

М

105

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

III.

Т

ЕОРИЯ

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

При тестировании Wi-Fi устройств требуется убедиться в исправной работе передающего (TX) и приемного (RX) тракта. Задача контроля качества сводится к измерению и оценке следующих параметров [1]:

TX

 Выходная мощность (~ 15 dBm)

 EVM (< –27dBm)

 Спектр сигнала (Соответствие маске)

 Частотная ошибка (<10 ppm) RX

 Порог чувствительности (-90 dBm) Раскроем понятия оцениваемых параметров:

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

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

(dB) 10log

10

;

(%) 100%.

error reference

error reference