Прототип СКРС/VCS на базе OMAP 3530

VCS Prototype

Прототип VCS

Особенность таких систем как VCS/СКРС в том, что они используют сумму программно-аппаратных технологий, что предъявляет несколько противоречивые требования к софту и оборудованию. Можно выделить три основные подсистемы, или блока, которые сильно разнятся между собой: это подсистема графического терминала (GT), подсистема SIP/SDP и собственно VoIP в виде связки RTP + Кодеки.

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

Графический терминал GT:

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

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

SIP/SDP:

  • присутствует значительная часть компонентов, задающих бизнес-логику работы, соответственно очевидно желание использовать высокоуровневые фреймворки STL/Qt для удобства работы;
  • сложная объектная модель, диктующая использование классов C++, плюс возможности SQL для конфигурирования системы в базах данных, как локальных так и распределенных;
  • асинхронный режим работы, нет требований к реалтайму.

VoIP (RTP + Кодеки + Эхоподавление и другие полезные вещи):

  • компоненты содержат инструменты для работы с низкоуровневым железом, бизнес-логика и влияние алгоритмов системы на работу компонентов отсутствует;
  • простая объектная модель, конфигурирование с помощью традиционных файлов конфигурации;
  • синхронный режим работы, связанный с синхронной природой обмена с аудиоустройствами, использование низкоуровневых шин I2C/McBSP.

Итак, все три подсистемы различны как по использованию технологий софта, так и по железу, о чем будет сказано далее. А пока сделаем небольшое отступление. Это отступление относится к продуктам VCS/СКРС отечественных компаний, которые представлены на рынке оборудования для авиадиспетчеров.

Как были разработаны эти продукты? Запускается группа программистов и они начинают писать код. Поскольку нанять профессиональную команду дорого, и управлять профессионалами – себе дороже, придется переделать всю оргструктуру предприятия (кому это нужно, если заказчик и так все возьмет?) выбирается самый простой путь. Простой путь – это использование платформы MS Windows и нечто вроде MS Visial Studio. Не имея опыта разработки клиент-серверных и сетевых приложений, а также боязнь использования богатого инструментария Linux приводит к тому, что все подсистемы реализуются на обычной PC платформе со всеми вытекающими отсюда последствиями: нестабильная работа приложений, отсутствие возможности адаптировать код проприетарных приложений и драйверов под свои нужды, дорогая аппаратная реализация и высокое энергопотребление.

Такой подход я называю подходом программиста.

Инженерный подход – это другое. Инженер аполитичен по отношению к программным технологиям и холиварам Windows vs Linux. Для него это просто инструменты для решения конечной задачи. Инженер, в отличие от программиста, не боится железа. Для программиста взаимодействие с железом начинается и заканчивается вставкой флешки в компьютер. Инженер же видит систему на уровне различных аппаратных реализаций: Intel, ARM, DSP, FPGA; он может перемещать проблемы туда где они проще решаются – из домена программной реализации в аппаратную или наоборот; из аналоговой части в цифровую или также наоборот, что позволяет точно выбрать инструменты для совместной работы всех трех упомянутых подсистем.

Лет десять назад, когда мы делали АРП “Платан”, стояла задача обработки потока оцифрованных данных с выхода радиоканала пеленгатора. Программисты настаивали на том, что для обеспечения низкой латентности необходимо ставить ОС РВ QNX. Задача была решена просто: между выходом радиотракта и комьютером разработали и поставили DDC с аналогово-программной реализацией, благодаря чему скорость потока данных была сокращена в 32 раза без потери информации, и вместо QNX была использована FreeBSD.

Это пример инженерного подхода.

Заканчиваем наше отступление и возвращаемся к прототипу VCS/СКРС, который показан на фото. На фотографии осталась за кадром левая часть, которая представляет точно такой же комплект, для имитации двусторонней связи. Оба комплекта работают друг с другом через локальную сеть. Как видно из фото, в комплект входит ноут, собственно плата SBC (Single Board Computer) и аудиопериферия, представленная микрофоном и динамиками.

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

На ноуте: графическая подсистема GT под Ubuntu Linux, с использованием фреймворка Qt для отображения графики;

SBC: содержит процессор OMAP 3530 с поддержкой сети и аудиопериферии. Процессор включает ARM ядро и DSP ядро. На ARM располагается SIP/SDP подсистема под управлением Arago Linux. На DSP располагаются система эхоподавления и еще некоторые приложения. Вызов функций DSP осуществляется из ARM Linux с использованием библиотеки межядерного взаимодействия Syslink.

VCS ARM+DSP Prototype Board

SBC на базе OMAP 3530

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

Самый интересный вопрос: на каком ядре должна размещаться RTP подсистема и кодеки? С одной стороны, RTP смотрит в сторону асинхронного сетевого интерфейса, тогда ее место на ARM ядре. С другой – в жестко тактируемую синхронную линию передачи/приема аудиоданных, соответственно тогда она должна располагаться на DSP, который работает с шинами кодеков в реальном времени.

На этот вопрос ответа пока не будет. Это маленький секрет )

Прототип работал следующим образом. На одном из рабочих мест через визуальный интерфейс GT инициировалось соединение с sip адресом другого рабочего места. Выполнялась SIP процедура соединения INVITE/RINGING, на отвечающем рабочем месте возникал сигнал вызова, нажатием кнопки возвращался ответ и оставшаяся часть процедуры SIP 200OK/ACK выполняла SDP согласование кодеков и медиаданных обоих рабочих мест. После согласования, инициировалось RTP соединение в каждую из сторон.

Оценивались задержки в тракте обработки и передачи, степень джиттера, а также эхоподавление. Эхо имитировалось акустической связью между динамиком и микрофоном – просто приставляли их друг другу. Интересно было наблюдать за адаптацией системы эхоподавления в течении 10 – 20 секунд: вначале слышно сильное эхо, затем оно плавно сходит на нет, а голос остается.

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

Что осталось непроверенным и в чем состоят риски? Как и в любой низкоуровневой архитектуре железа ARM/DSP, смотреть узлы надо только с родной аппаратной периферией. Поскольку OMAP 3530 использует специализированный чип аудио-подсистемы, не факт что все будет работать в другом аппаратном окружении. Кроме того, замена платы прототипа на другую плату влечет за собой полную замену BSP (Board Support Package) и все что с этим связано: драйверы, патчи ядра Linux, библиотеки предназначенные для работы специально с этой платой. Поэтому работу с BSP также надо тестировать только на финальной конфигурации.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">