Разработка кроссплатформенного порта D-Series

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Введение

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

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

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

Однако система функционирует только на компьютерах под управлением Unix-подобной системы внутренней разработки. Таким образом, задача добавления кроссплатформенности данной системе, для её работы на операционных системах семейства Unixи Windows, является актуальной в рамках проекта D-Series компании “Теком”. Задача кроссплатформенности выбрана как основа для написания данной выпускной работы.

Глава 1. Теоретическая часть

1.1 Постановка задач

D-Series - система автоматизации телевещательного процесса используемая рядом современных телестудий. Главной целью данной разработки является обеспечение своевременного выхода видеоматериала в эфир в порядке, соответствующем расписанию и контроль за процессом трансляции. Необходимость в добавлении системе кроссплатформенности возникла в связи с тем, что изначально компоненты системы разрабатывались для функционирования на операционной системе Linux. Однако операционные системы семейства Windows занимают лидирующие позиции на IT-рынке.

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

Целью дипломной работы является разработка кроссплатформенного порта D-Series и проведение тестирования на реальных устройствах.

Задачи, решаемые в ходе работы:

Исследование предметной области;

Анализ существующих решений;

Выбор средств реализации;

Разработка кроссплатформенных компонент;

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

Обзор предметной области

Кроссплатформенная разработка. Портирование

В программировании под термином «кроссплатформенное программное обеспечение» принимают продукт, работающий более чем на одной аппаратной платформе (архитектуре системы) или операционной системе. В рамках данного проекта конечный продукт должен функционировать на Windows и Unix операционных системах. Так как в основе работы лежит уже написанное программное обеспечение, работающее на Unix-системах, то добавление кроссплатформенного аспекта будет производиться за счёт процесса портирования. Портирование или портинг - это адаптация всей или части программы, с целью получения продукта, который будет функционировать в среде, отличной от той, для которой производилась разработка изначально. У любой разработки можно обозначить такое свойство как портируемость. Портируемость определяет насколько легко данный программный продукт может быть подвергнут процессу портинга.

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

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

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

Продукт становится более устойчивым.

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

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

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

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

Инструменты для сборки (компилятор, линковщик);

Инструменты для отладки;

Целевой тип процессора;

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

Библиотеки и интерфейсы.

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

Операционные системы Windows и Linux. Особенности разработки

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

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

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

Windows7 - операционная система семейства WindowsNT. Windows системы, в частности Windows 7, ориентированы на управление посредством графического интерфейса. Как следствие, основным преимуществом системы является пользовательский, интуитивно понятный интерфейс и многозадачность - одновременная работа нескольких приложений, что делает её максимально привлекательной для обычных пользователей. К недостаткам можно отнести проблемы с безопасностью и обязательное использование средств программного интерфейса WindowsAPI для разработчиков.

Linux - это многозадачная, многопользовательская операционная система, принадлежащая семейству UNIX. Рассматриваемая система поддерживает x86 архитектуру и позволяет собирать бинарные пакеты i386 и i686. Linuxпозиционируется как стабильная и мощная операционная система с модульным ядром. Слабой стороной системы является сложность в установке и настройке. Однако открытый код даёт возможность подстраивать систему под конкретные нужды разработчиков, а систематизация файлов делает систему понятной для продвинутых пользователей. Именно по этим причинам Unix-системы стабильно набирают популярность как среди разработчиков, так и среди обычных пользователей.

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

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

Процессы и потоки.

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

К примеру, серверное приложение должно порождать поток для каждого пользователя, который хочет совершить подключение. На Unix-подобных системах будет достаточно системного вызова fork(), который создаст процесс-потомок являющийся копией родителя, за исключением уникального идентификатора процесса (PID). Windows же не имеет аналога fork(), и пользователь должен вручную создавать процесс используя специальную функцию WinAPICreateProcess() с указанием ряда параметров.

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

Доступ к файлам.

Файловые системы рассматриваемых операционных систем коренным образом отличаются. В основе файловой системы ОС Linux лежит дерево файлов, от корня которого монтируются все диски. Корневой каталог обозначается символом «/» и как следствие, пути к любым файлам прописываются от корня дерева. Файловая система Windows иерархическая и основывается на разделении памяти на диски, таким образом, при указании абсолютного пути до файлов необходимо использовать путь от диска. Важным различием так же является чувствительность к регистру, которая присуща Unix-системам и не имеет влияния в семействе Windows.

Пример указания пути в Linuxи Windows:

Linux: /opt/src/…

Windows: C:\Documents\...

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

Средства для кроссплатформенной разработки на языке С++

В настоящее время существует обширное количество инструментов, ряд библиотек и языков программирования (Java, Python и т.д.), которые помогают разработчикам создавать кроссплатформенные приложения. Кроссплатформенность бывает нескольких типов: кроссплатформенность операционных систем, браузерная кроссплатформенность, кроссплатформенность версий ОС и т.д. В рамках данного проекта реализуется кроссплатформенность операционных систем, а используемый язык программирования - C++. Данный пункт работы будет рассматривать ориентированные на данные факты средства для кроссплатформенной разработки.

Можно выделить следующие средства:

Стандарты языка программирования;

Кроссплатформенные библиотеки;

Директивы препроцессора.

Кроссплатформенные библиотеки

BOOST

Boost - собрание библиотек, расширяющих C++. Boost имеет направленость на исследования и расширяемость.

Библиотеки Boost охватывают следующее:

Алгоритмы

Обход ошибок в компиляторах не соответствующих стандарту

Многопоточное программирование

Контейнеры

Юнит-тестирование

Структуры данных

Функциональные объекты

Обобщённое программирование

Графы

Ввод/вывод

Межязыковая поддержка

Итераторы

Математические и числовые алгоритмы

Работа с памятью

Синтаксический и лексический разбор

Метапрограммирование на основе препроцессора

«Умные указатели»

Обработка строк и текста

Метапрограммирование на основе шаблонов

POCO

POCO (или C++ PortableComponents) - это коллекция библиотек классов с открытым исходным кодом которая упрощает и ускоряет разработку сетевых мультиплатформенных приложений на C++. Модульная структура и эффективная реализация делает POCO идеальным кандидатом для использования при разработке для embedded устройств (прошивки и прочее), область, в которой C++ становится все более и более популярным, так как подходит как для низкоуровневой (устройства ввода/вывода, обработчики прерываний и прочее) так и для высокоуровневой объектно-ориентированной разработки.

Особенности:

threads, thread synchronization and advanced abstractions for multithreaded programming

streams and filesystem access

shared libraries and class loading

powerful logging and error reporting

security

network programming (TCP/IP sockets, HTTP, FTP, SMTP, etc.)

XML parsing (SAX2 and DOM) and generation

configuration file and options handling

database access

Платформы и совместимость:

Windows

Mac OS X

(embedded) Linux

HP-UX

Tru64

Solaris

Обзор компиляторов

Компилятор - это программа или техническое для выполнения процесса компиляции.

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

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

В рамках дипломного проекта будут рассмотрены компилятор GCC и его наследник для операционной системы Windows - MinGW.

GCC.

GNUCompilerCollector или GCC - это набор компиляторов распространяемый в рамках проекта GNU и поддерживающий несколько языков программирования (С, С++, Java, Fortran и др.) и различные типы процессоров, в том числе и микроконтроллеры и 64-разрядные процессоры. GCC позиционируется как бесплатный традиционный компилятор для операционной системы Linux.

Начало этому компилятору положил Ричард Столлман в 1985 году, а настоящее время GCC поддерживается и разрабатывается группой программистов со всего мира.

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

GCC также предоставляет пользователям возможность отладки приложений при помощи GNUDebugger (gdb).

Пример использования:

gccmain.cpp -omain

На выходе получим исполняемый файл main.

MinGW.

MinGW или MinimalistGNUforWindows - представляет собой комбинацию компилятора GCC и набора библиотек импорта и заголовочных файлов для WinAPI. В рамках дипломного проекта интересно отметить, что MinGW является портом компилятора GNU под операционную систему Windows. Однако, несмотря на этот факт, в первую очередь он предназначен для работы на Windows операционных системах, и не предназначен для обеспечения среды выполнения POSIX-приложений, то есть не может выполнить ряд функциональности (fork() и др.). Все утилиты управляются из командной строки, что немного непривычно для пользователей Windows.

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

Пример использования:

g++ main.cpp -omain.exe

На выходе получим исполняемый файл main.exe

Краткий обзор существующей системы

Рассматриваемая система обеспечивает полный рабочий цикл вещательных студий. Её основная задача - запуск воспроизведения и записи видеоклипов в эфир. Если рассматривать систему как чёрный ящик, то в качестве входа рассматривается документация с расписанием, предоставляемая «traffic department» отделом в телевещательных компаниях, а выходом - процесс передачи роликов в соответствующей расписанию последовательности. Сложность данной задачи заключается в том, что система должна поддерживать множество каналов и много различных видов оборудования, каждый из которых поставляется разными поставщиками и поддерживает разные стандарты. Существует несколько разновидностей системы, две из которых, в настоящее время, разрабатываются компанией Imagine Communications и отданы на аутсорсинг в Россию: ADC и D-Series. Если произвести сравнение, то D-Series позиционируется как более надёжная система для более крупных телевещательных студий с поддержкой до 1000 каналов.

Основные понятия системы

Один из основных терминов в системе - Bus (Шина). Bus - это канал, по которому в нужное время события выходят в эфир. Основное отличие шины от вещательного канала в том, что она может использоваться не только для трансляции, но и для подготовки материала перед прансляцией. Существуют нескольких типов шин. Основным типом является Presentation bus - шина, непосредственно связанная с транслирующим оборудованием для выпуска материал. Preparation bus - шина, используемая для непосредственной подготовки расписания и отправления на Presentation bus. Кроме основных, система содержит дополнительные шины для реализации различного функционала (Record bus - шина для записи и т.д.)

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

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

Компоненты системы

В рассматриваемой системе можно выделить три ключевых компонента:

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

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

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

Архитектура системы

Архитектура системы представлена на Рисунке 1.

Рисунок 1. Архитектура системы D-Series

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

Если рассматривать компоненты отдельно,то:

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

Вещательное оборудование или видеодиски (BroadcastingEquipment) - представляет собой компьютер под управление Windows или Linux операционной системы, к которому по оптическому интерфейсу подключен D-AIS. Вещательное оборудование производит запись клипов на цифровой носитель, и при получении управляющих команд от девайс контроллера (загрузить клип, подготовить клип к проигрыванию, начать проигрывание, закончить проигрывание), воспроизводит их;

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

Communication hardware - оборудование, обеспечивающее общение девайс контроллеров и вещательного оборудования. Осуществляет автоматическое переключение между видеодисками. Как правило использует последовательный канал передач RS-422, который является промышленным стандартом для последовательной передачи данных. Однако в последнее время предпринимаются попытки перейти на протокол TCP/IP;

DALstations- рабочие места операторов, представляющие собой персональные компьютеры, работающие на WindowsОС. Управление эфиром происходит посредством запуска приложения с одноимённым названием DALStation;

Системный менеджер (Systemmanager) - персональный компьютер, который обеспечивает безопасность системы, отслеживает сбои и ошибки, контролирует трафик и производит сканирование системы на вирусы;

Panels- представляют собой устройства для ручного усправления эфиром.

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

Все компоненты соединяются Ethernet-сетями: AutomationLAN (неуправляемая из вне сеть; пример применения см. выше), InformationLAN (сети для прохода трафика, являются бэк-апами WorkstationLAN), WorkstationLAN («сеть реального времени» используется для общения «операторов» с девайс контроллером) (на Рисунке 1 InformationLAN = WorkstationLAN) иMediaLAN (сеть для общения вещательного оборудования с контент сервером).

Представленные сети организуются посредством использования TCPи UDP протоколов из стека протоколов TCP/IP.

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

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

Обзор системы D-Series даёт общее представление о предназначении системы, её работе и взаимодействии её компонентов.



Глава 2. Практическая часть

2.1 Разработка и анализ технического задания

Назначение и цели создания системы

Целью разработки является добавление кроссплатформенного аспекта системе автоматизации телевещанияD-Series.

Общее описание

Функционал продукта

Основной функционал продукта:

Поддержка ряда телевещательного оборудования;

Создание расписаний для воспроизведения;

Подача материала в эфир в соответствующее время;

Контроль за воспроизведением;

Наложение эффектов на медиа-контент - логотипы, звук и т.д.;

Запись материала на видео сервера;

Обработка сбоев вещания;

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

Операционная среда

Разработка данного проекта требует наличие ПК с установленными операционными системами: Windows 7 и DALinux.

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

Для реализации проекта необходимо наличие 2-х аппаратных устройств: видеосервер NexioDCALи свитчер DCALLRC.

NexioDCAL

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

Рисунок2. ВидеосерверNexioAMP

VisualStudio 2015

Для разработки программного продукта под WindowsОС была выбрана интегрированная среда разработки Microsoft Visual Studio 2015 Community. Данная среда позволяет разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех большого платформ.

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

Реализация проекта

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

Рисунок 3. Структура системы

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

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

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

Портинг будет производиться на языке программирования C++ с использованием кроссплатформенной библиотеки BOOST, стандартов языка С++11 и С++14 и использованием условной компиляции посредством директив препроцессора #ifdefс макросом __linux__, #elseи #endif.

Проект состоит в портинге 2 компонентов системы: libdseriesи ряд драйверов устройств -NexioDCALи DCALLRC.

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

Для операционной системы Windows статические библиотеки имеют расширение .lib, а динамические .dll.

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

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

Такие различия привели к созданию отдельных проектов в среде разработки VisualStudio 2015, после сборки которых были получены файлы с соответствующими расширениями для ОС Windows.

Портинг в данном проекте можно разделить на 4 логических части: портинг NET-части, портинг многопоточности, портинг обработки ошибок и тайм-портинг.

Портинг NET-части

NET-часть или Сетевая часть - фрагменты программы, обеспечивающие взаимодействие устройств через протоколы TCPи UDP. Стандарты C++11 и C++14 на настоящий момент не поддерживают реализацию асинхронного сетевого программирования, поэтому для портинга сетевых фрагментов использовалась библиотека Boost.Asio.

Boost.Asio - кроссплатформенная С++ библиотека для программирования сетей.

Пространство имён Boost.Asio:

boost::asio: - пространство имён основных классов и функций. К главным классам Boost.Asio относят классыio_service и streambuf;

boost::asio::ip: отвечает за сетевую часть библиотеки. Основные классы: tcp, udp, address, endpoint;

boost::asio::error: содержит коды ошибок, которые возможно получить при вызове подпрограммы ввода/вывода;

boost::asio::local: и boost::asio::windows: - пространства имен содержащиеPOSIX и Windowsспецифичные классы соответственно.

В рамках проекта Boost.Asio помогает реализовать работу с ip-адресами, конечными точками и сокетами (ip::tcpи ip::udp).

Конечная точка или endpoint - это адрес подключения вместе с портом.

Примеры кода (libdseries):

ipv4_tcp.h

class IPV4_TCP_HOST : public IPV4_HOST {

public:

IPV4_TCP_HOST(const IPV4_ADDRESS & address, TCP_PORT port); …

private:

asio::ip::tcp::endpoint endpoint;

asio::ip::tcp::socket asio_socket; …}

ipv4_udp.h

class IPV4_UDP_HOST : public IPV4_HOST {

public:

IPV4_UDP_HOST(const IPV4_ADDRESS & ipv4_address, UDP_PORT port); …

private:

asio::ip::udp::endpoint endpoint;

asio::ip::udp::socket asio_socket; …};

ipv4_tcp.cpp

IPV4_TCP_HOST::IPV4_TCP_HOST(const IPV4_ADDRESS & address, TCP_PORT port)

:IPV4_HOST(address, port)

,endpoint(asio::ip::address_v4::from_string(address.c_str()), port)

,asio_socket(io_service)

{

}

void IPV4_TCP_HOST::connect()

{

asio_socket.connect(endpoint);

}

int IPV4_TCP_HOST::get_socket_descriptor()

{

return asio_socket.native_handle();

}

Для реализации других аспектов портинга использовались стандарты языка С++11 и С++14.

Портинг многопоточности

Примеры кода (libdseries):

namespace DSERIES {

namespace THREAD {

typedef std::mutex MUTEX;

typedef std::unique_lock<std::mutex> LOCKER;

typedef std::timed_mutex TIMED_MUTEX;

typedef std::unique_lock<std::timed_mutex> TIMED_LOCKER;

};// namespace DSERIES::THREAD

};// namespace DSERIES

Портинг обработки ошибок

Примеры кода (libdseries):

basic_transport.cpp

BASIC_TRANSPORT::COMPONENT&BASIC_TRANSPORT::component_reference_by_type(unsigned int instance, COMPONENT::TYPE type)

{

if (type == CHANNEL_COMPONENT::component_type()) {

if (unlikely(!data__->channel_is_valid(instance)))

throw std::out_of_range("Invalid transport component interface");

CHANNEL_COMPONENT * const result = data__->channels[instance].interface;

if (unlikely(result == NULL))

throw std::logic_error("Internal Error: derived class did not provide transport components!");

return *result;

} else if (type == CLIPMANAGER_COMPONENT::component_type()) {

if (unlikely(!data__->clipmanagement_is_supported()) || instance > 0)

throw std::out_of_range("Invalid clip management component interface");

return *data__->clipmanager;

}

throw std::invalid_argument("Unknown device component type");

}

communication.cpp

switch (type__) {

case DSERIES::DEVICE::DEVICE_UTIL::TCP:

comm_stream__ = std::make_unique<DSERIES::NET::IPV4_TCP_HOST>(communication_config.tcp.ipv4_address, communication_config.tcp.port);

break;

default:

throw std::runtime_error("Unknown communication type failed to create communication stream.");}

Тайм-портинг

Примеры кода (libdseries):

condition.cpp

bool CONDITION::timed_wait(DSERIES::THREAD::MUTEX & mutex, DSERIES::TIME::INTERVAL const & timeout)

{

unsigned int const timeout_seconds = ((timeout.hours() * 60) + timeout.minutes() * 60) + timeout.seconds();

unsigned int const timeout_nanos = timeout.nanoseconds();

if (!timeout.is_positive()) {

return false;

}

auto future = std::chrono::system_clock::now() + std::chrono::seconds(timeout_seconds) + std::chrono::nanoseconds(timeout_nanos);

DSERIES::THREAD::LOCKER lock(mutex, std::adopt_lock);

if (data__.wait_until(lock, future) == std::cv_status::timeout)

return false;

return true;

}

2.2 Тестирование программы

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

Система должна:

Успешно запускаться с изменёнными компонентам;

Подключать и взаимодействовать с NexioDCALплагином;

Подключать и взаимодействовать с плагином DCALLRC;

Создавать расписание с различными конфигурациями полей;

Обеспечивать одновременную работу с несколькими каналами;

Воспроизводить расписание;

Обеспечивать ручное управление воспроизведением;

Производить переключение на запасной сервер при аварийной ситуации;

Корректно завершать свою работу.

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

Тест 1. Проверка корректного запуска

Начальные условия:

Все компоненты системы собраны в rpmпакеты и установлены. Система сконфигурирована.

Описание процесса:

Запускаем серверный компонент системы.

Результат работы:

Система успешно запущена.

Рисунок 4. Запуск D-MAS

Тест 2. Проверка корректного подключения плагинов

Начальные условия:

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

Описание процесса:

Запускаем D-MAS, проверяем статусы устройства.

Результат работы:

Статус плагина «Good»

Рисунок 5. Статус подключенных устройств



Тест 3. Создание события

Начальные условия:

Система запущена. Плагин Nexio сконфигурирован.

Описание процесса:

Запускаем DALStation. Проверяем наличие соединения. Создаём событие и конфигурируем его.

Результат работы:

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

Рисунок 6. Редактирование события

Тест 4. Воспроизведение расписания

Начальные условия:

Система запущена. Плагин Nexioс конфигурирован.

Описание процесса:

Запускаем DALStation. Создаём расписание и воспроизводим его.

Результат работы:

Система работает корректно. Медиа контент воспроизводится в соотвествии расписанию.

Рисунок 7. DALStation. Работа с расписанием

автоматизация телевещательный кроссплатформенный series

Тест 5. Проверка ручного режима воспроизведения

Начальные условия:

Система запущена. Плагин Nexioсконфигурирован. Интерфейс Nexio запущен.

Описание процесса:

Создаём расписание и воспроизводим его. На интерфейсе производим ручное управление (смена материалы, остановка, наложение эффектов).

Результат работы:

Система реагирует на ручное управление эфиром.

Рисунок 8. Интерфейс Nexio. Ручное управление

2.3 Результаты тестирования

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



Заключение

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

В ходе работы были решены следующие задачи:

1) проведено исследование предметной области;

2) проведен анализ существующих решений;

3) проведён выбор средств реализации проекта;

4) разработаны кроссплатформенные порты;

5) проведено тестирования продукта в рамках лаборатории.

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

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



Список литературы

Зиборов В.В. C++ 2012 на примерах / В.В. Зиборов - СПб.: БХВ - Петербург, 2013. - 480 с.

Мейерс С. Наиболее эффективное использование C++.35 новых рекомендаций по улучшению ваших программ и проектов - «ДМК», 2000. - 304 с.

Мюссер Д., Дердж Ж. и Сейни А. C++ и STL. Справочное руководство, 2-е изд. - 2010. - 432 с.

Харт Д. Системное программирование в среде Windows,3-е изд. - 2005. -608 c.

Таненбаум, Э. Современные операционные системы, 2-е изд. - СПб. : Питер, 2007. - 1038 с.

Прата С. Язык программирования C++ (C++11). Лекции и упражнения, 6-е изд. -- М.: «Вильямс», 2012. -- 1248 с.

Polukhin A. Boost C++ Application Development Cookbook - Packt Publishing, 2013. - 348 pp.

Hook B. Write Portable Code: An Introduction to Developing Software for Multiple Platforms - San Francisco: No Starch Press, 2005. - 273 pp.

Syd L. Cross-Platform Development in C++: Building Mac OS X, Linux, and Windows Applications - 2008. - 550 pp.

Джосаттис Н. Стандартная библиотека С++: справочное руководство, 2-е изд. - 2016. - 1136 с.



Приложение А

Пример тест-кейсов для плагина NexioDCAL

TEST01

Test Description

1. In DALstation or DALterm create an event.

2. Insert single spot material on the event from cache list. Check that material metadata is returned. Define Source_ID and start time.

3. Check that the item can be cued/played. Check transport status in DALstation. Check the appearance of the first material frame on preview monitor.

Expected Results

1-2. Metadata is returned correctly.

3. Event can be cued\played. At the cue time material is loaded to the server channel. The First frame of a material appears on monitor. Transport status in DALstation is changed to “requested item cued”

TEST02

Prerequisites

1. DMAS is up and running

2. Video servers are connected to DMAS

Test Description

1. Create a schedule with back to back (i.e. same item after each) identical short clips from the same source. Take it on air by true time.

2. Check that schedule runs without errors.

3. Create a schedule with back to back (i.e. same item after each) identical short clips from the different sources. Take it on air by true time.

4. Check that the schedule runs without errors.

Expected Results

1-2,3-4. Schedule is on air. There are no playout errors.

TEST03

Prerequisites

1. DMAS is up and running

2. Video servers are connected to DMAS

Test Description

1. Create a schedule with back to back (i.e. the same item after each) identical long clips from the same source. Take it on air by true time.

2. Check that schedule runs without errors.

3. Create a schedule with back to back (i.e. the same item after each) identical long clips from the different sources. Take it on air by true time.

4. Check that the schedule runs without errors.

5. Verify timecode on the following events when they are going on-air.

Expected Results

1-2,3-4. Schedule is on air. There are no playout errors.

5. Timecode is displayed for all an-air events.

TEST04

Prerequisites

1. DMAS is up and running

2. Video server is connected to DMAS

Test Description

1. Create a schedule with several events from one source.

2. Manually put the first event to air by pressing CTRL+ALT+F1.

3. Check that item is going to air.

4. Before the first event ends, take the next event to air by pressing CTRL+ALT+F3.

5. Check that item is going to air.

6. Repeat the switching to a next event (by pressing CTRL+ALT+F1 and CTRL+ALT+F3) several times.

7. Check that after switching all events are cued\played without errors.

Expected Results

1-3. Event is going on-air.

4-5. Next event goes on air after pretake time is counted down.

6-7. After switching all events are cued\played without errors.

TEST05

Prerequisites

1. DMAS is up and running

2. Video servers are connected to DMAS

Test Description

1. Create a schedule with several events from several sources.

2. Manually put the first event to air by pressing CTRL+ALT+F1.

3. Check that item is going to air.

4. Before the first event ends, take the next event to air by pressing CTRL+ALT+F3.

5. Check that item is going to air.

6. Repeat the switching to a next event (by pressing CTRL+ALT+F1 and CTRL+ALT+F3) several times.

7. Check that after switching all events are cued\played without errors.

8. Verify timecode on the following events when they are going on-air.

Expected Results

1-3. Event is going on-air.

4-5. Next event goes on air after pretake time is counted down.

6-7. After switching all events are cued\played without errors.

8. Timecode is displayed



ПриложениеB

Листинг фрагментов кода

Основной C++ файл плагина NexioDCAL

codec.cpp

/// \file

/// \brief Implementation of the DSERIES::DRIVER::NEXIO::CODEC__ class.

#include <dseries/common.h>

#include "codec.h"

#include "sleep.h"

using namespace std;

using namespace DSERIES::DRIVER;

using namespace DSERIES::TIME;

using DSERIES::TIME::TIMECODE;

using DSERIES::TIME::NULL_TIMECODE;

using namespace DSERIES::DCAL;

using namespace DSERIES::DRIVER::NEXIO_UTIL;

static const INTERVAL WAIT_FOR_CUE_COMPLETE(0, 0, 0, 100*1000*1000);

static const size_t MAX_CUE_WAITS = 10;

static const INTERVAL WAIT_FOR_PLAY_COMPLETE(0, 0, 0, 100*1000*1000);

static const size_t MAX_PLAY_WAITS = 10;

static const INTERVAL WAIT_FOR_STOP_COMPLETE(0, 0, 0, 50*1000*1000);

static const size_t MAX_STOP_WAITS = 5;

// Time to wait between requests for transaction status

static const INTERVAL GET_TSTATUS_WAIT(0, 0, 0, 100*1000*1000);

static const size_t MAX_STATUS_WAITS = 10;

/// \brief Construct a Nexio codec object

NEXIO::CODEC__::CODEC__(NEXIO & server, CHANNEL_CAPABILITIES const & capabilities, NAME name, DESCRIPTION description, NAME logger_name, PROTOCOL_CONFIGURATION const & protocol_configuration, bool auto_activate, DSERIES::NET::IPV4_ADDRESS ipv4_address, CHANNEL_IDX channel)

:CHANNEL_IF(server, name, description, capabilities, REQUEST_CALLBACK(dynamic_cast<COMM_THREAD__ *>(this), &COMM_THREAD__::kick_thread))

,COMM_THREAD__(server, name, description, logger_name, auto_activate)

,protocol_configuration__(protocol_configuration)

,udp_dgram__(std::make_unique<NEXIO_UDP_DGRAM>(ipv4_address))

,framer__(std::make_unique<NEXIO_UDP_FRAMER>(*udp_dgram__.get(), logger,

ODETICS_FRAMER::ASSERT_COMM_STATE(dynamic_cast<COMM_THREAD__*>(this), &COMM_THREAD__::assert_comm_bad),

ODETICS_FRAMER::ASSERT_COMM_STATE(dynamic_cast<COMM_THREAD__*>(this), &COMM_THREAD__::assert_comm_good),static_cast<uint8_t>(channel)))

, protocol__(std::make_unique<NEXIO_PROTOCOL>(*framer__.get (), logger))

, preset_is_onair__(false)

, preroll_requested__(false)

, reset_preset__(false)

, last_sequence_number__()

{

}

NEXIO::CODEC__::~CODEC__() throw ()

{

stop_thread ();

}

void NEXIO::CODEC__::establish_connection__() const

{

udp_dgram__->connect();

}

/// \brief Handle all pending channel requests.

///

void NEXIO::CODEC__::handle_pending_requests__()

{

logger.printf(LOGGER::filter_debug_verbose, "start handling channel %s", sense_name().c_str());

REQUEST_WRITE_LOCKER requests(*this);

SEQUENCE_NUMBER new_sequence_number;

if (!communication_state__.communication_is_enabled()) {

logger.printf(LOGGER::filter_debug, "ignoring request on channel %s: communication is disabled", sense_name().c_str());

} else {

while(unlikely((new_sequence_number = timeline_sequence_number()) != last_sequence_number__)) {

last_sequence_number__ = new_sequence_number;

logger.printf(LOGGER::filter_verbose, "handling request on channel %s", sense_name().c_str());

if (!timeline_is_active()) {

bool f_preset_cleared = false;

bool f_stopped = false;

size_t n_to_deactivate = timeline_deactivated_length();

if (n_to_deactivate) {

logger.printf(LOGGER::filter_verbose, "(Inactive timeline) There are %d clips to deactivate", n_to_deactivate);

for (unsigned int i_pos = 0; i_pos < n_to_deactivate; ++i_pos) {

logger.printf(LOGGER::filter_verbose, "Deactivate clip %d, state %d", i_pos, timeline_deactivated_event_state(i_pos));

if (timeline_deactivated_event_state(i_pos) == TSTATE::PENDING) {

if (!f_stopped)

{

SEQUENCE_NUMBER seqnum = timeline_deactivated_event(i_pos).sequence_number();

f_stopped = true;

logger.printf(LOGGER::filter_verbose, "Issueing stop to deactivate clip %d", i_pos);

timeline_update_event_state_by_seqnum(seqnum, TSTATE::PROGRESSING, requests);

requests.unlock();

issue_stop__();

protocol__->reset_in_preset();

protocol__->reset_out_preset();

requests.lock();

f_preset_cleared = true;

timeline_update_event_state_by_seqnum(seqnum, TSTATE::COMPLETE, requests);

} else {

timeline_update_event_state(i_pos, TSTATE::COMPLETE, requests);

}

}

}

}

bool unexpectedly_onair = false;

if (!f_stopped) {

// If the current known codec state is DECODING or ENCODING we need to check codec state again

// to make sure that our data is up-to-date.

// This is necessary if Cue request is initiated right after Eject.

STATE codec_state = sense_state();

if (((codec_state.action() == STATE::DECODING) || (sense_state().action() == STATE::ENCODING))

&& !check_codec_is_active__ ()) {

// codec state appears to be out-of-date, need to initiate poll.

poll__ ();

}

// Ensure we don't inadvertently cancel recording or playout in progress via cue requests even if there is no timeline active

// This can occur when the plug-in activated (e.g. on startup or after a TOC for DMAS)

if (sense_state().action() == STATE::DECODING) {

logger.printf(LOGGER::filter_verbose, "Timeline not active, but decoder playing out - setting preview clip to %s", sense_name().c_str());

preset_is_onair__ = true;

unexpectedly_onair = true;

} else if (sense_state().action() == STATE::ENCODING) {

logger.printf(LOGGER::filter_verbose, "Timeline not active, but encoder recording - ignoring request to cue to record %s", sense_name().c_str());

preset_is_onair__ = true;

unexpectedly_onair = true;

}

}

if (!unexpectedly_onair) {

if (timeline_length() > 0) {

bool f_recue_preset_required = timeline_event_state(0) == TSTATE::COMPLETE && f_preset_cleared;

if (((timeline_event_stage(0) == TSTATE::PREPARATION) && (timeline_event_state(0) == TSTATE::PENDING)) || f_recue_preset_required)

{

const TEVENT t = timeline_event(0);

logger.printf(LOGGER::filter_verbose, "(Inactive timeline) Cueing timeline event 0 to preset (%s)", t.clip().ascii_id().c_str());

timeline_update_event_state_by_seqnum(t.sequence_number(), TSTATE::PROGRESSING, requests);

STATE new_state;

TSTATE::STATUS status;

requests.unlock();

if (t.type() == TEVENT::PLAYOUT) {

protocol__->reset_in_preset();

protocol__->reset_out_preset();

status = set_preset__(&t);

new_state.action(STATE::PREPARED_FOR_DECODING);

} else {

status = prepare_recording__(&t);

new_state.action(STATE::PREPARED_FOR_ENCODING);

}

requests.lock();

timeline_update_event_state_by_seqnum(t.sequence_number(), status, requests);

new_state.clip(t.clip());

new_state.timecode_position(t.clip().som());

new_state.speed(0);

update_state(new_state);

}

} else if (!f_preset_cleared) {

requests.unlock();

protocol__->reset_in_preset();

protocol__->reset_out_preset();

requests.lock();

f_preset_cleared = true;

}

}

size_t const pvw_index = unexpectedly_onair ? 0 : 1;

if (timeline_length() > pvw_index) {

bool f_recue_preview_required = timeline_event_state(pvw_index) == TSTATE::COMPLETE && f_preset_cleared;

if (((timeline_event_stage(pvw_index) == TSTATE::PREPARATION) && (timeline_event_state(pvw_index) == TSTATE::PENDING))

|| f_recue_preview_required) {

const TEVENT t = timeline_event(pvw_index);

logger.printf(LOGGER::filter_verbose, "(Inactive timeline) Cueing timeline event %d to preview (%s)", pvw_index, t.clip().ascii_id().c_str());

if (t.type() == TEVENT::PLAYOUT) {

timeline_update_event_state_by_seqnum(t.sequence_number(), TSTATE::PROGRESSING, requests);

requests.unlock();

TSTATE::STATUS status = set_preview__(&t);

requests.lock();

timeline_update_event_state_by_seqnum(t.sequence_number(), status, requests);

} else {

// back-to-back recording not supported by Nexio - only one item can be "loaded" for recording.

}

}

} else {

requests.unlock();

protocol__->reset_in_preview();

protocol__->reset_out_preview();

requests.lock();

}

} else {

TEVENT active = timeline_active_event();

if (timeline_active_event_state() == TSTATE::PENDING) {

logger.printf(LOGGER::filter_verbose, "(Active timeline) Starting active");

timeline_update_active_event_state(TSTATE::PROGRESSING, requests);

STATE new_state;

TSTATE::STATUS status = TSTATE::FAILURE;

requests.unlock();

if (active.type() == TEVENT::RECORD) {

if (record__()) {

new_state.action(STATE::ENCODING);

status = TSTATE::COMPLETE;

}

} else {

if (play__()) {

new_state.action(STATE::DECODING);

status = TSTATE::COMPLETE;

}

}

requests.lock();

timeline_update_active_event_state(status, requests);

new_state.clip(active.clip());

new_state.timecode_position(active.clip().som());

new_state.speed(STATE::SPEED_FACTOR_DIVISOR);

update_state(new_state);

}

if (timeline_length() > 0

&& timeline_event_stage(0) == TSTATE::PREPARATION

&& timeline_event_state(0) == TSTATE::PENDING)

{

const TEVENT t = timeline_event(0);

if (t.type() == TEVENT::PLAYOUT) {

if (active.clip().id() == t.clip().id() && active.clip().som() == t.clip().som() && active.clip().duration() != t.clip().duration()) {

SONYVTR_TIMECODE new_eom (t.clip().som() + t.clip().duration());

if (!protocol__->set_out_preset (new_eom))

logger.printf (LOGGER::filter_error, "Onair duration edit: unable to set preset out point");

else {

logger.printf (LOGGER::filter_verbose, "Onair duration edit: set preset out point to %08x", new_eom.hhmmssff());

active.clip (t.clip());

timeline_update_event_state_by_seqnum (t.sequence_number(), TSTATE::COMPLETE, requests);

}

} else {

logger.printf(LOGGER::filter_verbose, "(Active timeline) Cueing timeline event 0 to preview (%s)", t.clip().ascii_id().c_str());