SCA: особенности и принципы работы с фреймворком

23 июня 2017

Аннотация
Архитектурный фреймворк SCA (англ. Software Communication Architecture) — открытая архитектура, разработанная Министерством обороны США для стандартизации разработки программно-определяемых радиосистем (англ. Software-Defined Radio, SDR), улучшения совместимости разнородных систем связи, уменьшения стоимости их разработки и внедрения.

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

Многие методы и принципы, используемые в SCA, могут быть не знакомы разработчикам радиоаппаратуры, это влечет за собой потерю времени на возможные ошибки и длительное обучение. Понимание этих принципов играет важную роль для разработчиков вне зависимости от их личного мнения о самой SCA. Эта статья направлена на обучение разработчиков радиоаппаратуры принципам программного подхода и описание того, как SCA использует их для достижения своих целей. Мы описываем различные интерфейсы SCA, которые предоставляют средства разработки для реализации SDR, а также базовые принципы использования SCA по материалам OSSIE (Open-Source SCA Implementation-Embedded, SCA для встраиваемых устройств с открытым исходным кодом), разработанной исследовательской группой «Wireless» в Политехническом университете Виргинии.

Введение
SDR — новая парадигма реализации беспроводных систем связи. Она повышает гибкость, уменьшает стоимость разработки и производства и может быть использована в большом количестве случаев. Однако SDR — сложная технология, требующая различных знаний, большая часть которых обычно не включена в формальное обучение инженера-конструктора радиоаппаратуры. Необходимость дополнительных навыков, особенно с точки зрения разработки программного обеспечения, а также отсутствие понимания существующих стандартов, оказывают значительное влияние на медленное развитие SDR, снижая темпы инноваций в коммуникационных технологиях. Данная статья объясняет основы SCA понятным и доступным языком для уменьшения влияния этих факторов. Главной целью статьи является объяснение ключевых идей SCA и логики каждой из них, особенно с точки зрения разработки ПО.

В идеальном случае SDR-системы должны быть реконфигурируемыми, гибкими и простыми в обслуживании без привлечения существенных ресурсов. Для достижения этой цели требуется использовать правильные методы и подходы к разработке, позволяющие эффективно справляться со сложностью создаваемых систем. Рекомендуемые методы разработки ПО и популярные паттерны проектирования подразумевают применение компонентно-ориентированного подхода [1], который облегчает разработку и сопровождение и позволяет повторно использовать существующие наработки. К сожалению, большинство разработчиков радиосистем не знакомы с этими подходами или не используют их, так как зачастую считают нецелесообразными. SCA представляет из себя открытую архитектуру, принятую на мировом уровне, разработанную в рамках программы объединенной системы тактической радиосвязи (англ. Joint Tactical Radio System, JTRS) Министерства обороны США [2]. JTRS нацелена на решение проблемы совместимости систем связи при помощи предоставления семейства модульных цифровых радиостанций с возможностью перепрограммирования и многополосной работы с различными видами модуляции. SCA определяет, как трансиверы, разрабатываемые JTRS, должны проектироваться, внедряться и обслуживаться. Реализация SCA для встраиваемых систем с открытым исходным кодом (OSSIE) была создана политехническим университетом Виргинии, в образовательных и исследовательских целях. Она может быть хорошим стартом при разработке и обучения в сфере SCA. Данная статья написана на основе опыта команды, полученного при разработке OSSIE.

Несмотря на свое военное происхождение, SCA определяет многие принципы и подходы, которые могут быть использованы в коммерческих и исследовательских проектах. Существуют опасения по поводу производительности целевого решения и объему используемой памяти, которые могут ограничить применение SCA в таких проектах. Важно упомянуть, что несмотря на то, что некоторые опасения небезосновательны, многие из них связаны с недостатком знания архитектуры [3] и используемых технологий в целом.

В этой статье мы предоставляем введение в SCA. Целью является создание руководства для разработчиков радиосистем, заинтересованных в SCA и SDR. Для более подробной информации, см. [4].

Определение требований к архитектуре SDR
Перед детальным исследованием SCA определим требования, необходимые для поддержки компонентного программного радиоприложения, которое может быть запущено на модульной реконфигурируемой платформе. Это поможет понять некоторые проектные решения, используемые в SCA. В контексте SCA любое конечное приложение по обработке радиосигнала называется радиоприложением «waveform», будь то простой AM приемник, одноканальная радиосистема для сухопутных и воздушных войск или реализация коммерческого стандарт LTE. SCA определяет радиоприложение как набор преобразований, примененный к информации для передачи по воздуху и соответствующий набор преобразований для приведений принятого сигнала обратно к его информационному виду [2]. Определение требований начнем с рассмотрения двух базовых радиоприложений W₁ и W₂, показанных на Рисунке 1. Их реальный функционал не имеет значения. Каждый компонент C_i,j является обособленным объектом, который выполняет какую-либо обработку сигнала или функцию контроля над каким либо радиоприложением. Компонентный подход помогает сопровождению и повторному использованию, позволяя получать большую прибыль от интеллектуальных вложений. Компоненты могут иметь несколько реализаций, каждая из которых сохраняет свой функционал и интерфейс, а также направлена на определенное устройство обработки D. На Рисунке 1, C_2,1 имеет три разных реализации. Причины использования отдельных компонентов со множеством реализаций станут понятны позже.

Оба радиоприложения должны работать на двух платформах, P₁ и P₂, также показанных на Рисунке 1. Эти платформы имеют разные перепрограммируемые обрабатывающие устройства D_m,n, и хотя их природа не имеет значения, предположим, что хотя бы одно из них является цифровым процессором (тип процессора не определен, но можно предположить, что это процессор общего назначения). Будем считать P₁ одноплатной платформой, на которую не может быть добавлен ни один элемент. P₂, в свою очередь, является модульной платформой, а значит, на нее могут быть добавлены дополнительные обрабатывающие устройства. Примером такой платформы является блейд-сервер с поддержкой горячей замены оборудования.

Рисунок 1. Блок схема примера.

Обычно SDR-платформы содержат комбинацию различных вычислительных устройств: процессоров общего назначения (англ. general purpose processor, GPP), цифровых сигнальных процессоров (англ. digital signal processor, DSP), программируемых логических матриц (англ. field-programmable gate array, FPGA), интегральных схем специального назначения (англ. application-specific integrated circuit, ASIC). Например, SDR-платформа малого форм-фактора от компании Lyrtech включает в себя процессор ARM9, цифровой сигнальный процессор Texas Instruments C64+ и FPGA Xilinx Virtex-4. Гетерогенная природа SDR-платформ требует интерфейсов, механизмов коммуникаций и четкого разграничения функциональности между модулями, что делает компонентный подход логичным выбором. Таким образом, необходима компонентная модель, которая определит семантику компонентов, их интерфейсы и протоколы обмена информацией с другими компонентами.

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

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

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

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

Более того, разные платформы будут иметь разные физические возможности, которые могут быть переконфигурированы в процессе работы или неизвестны на момент разработки. Например, такая модульная платформа, как P₂, может изменять свои возможности обработки и хранения данных. Схожим образом, разные радиоприложения будут иметь разные требования к ресурсам. Необходимо проверять, способна ли платформа обрабатывать конкретное радиоприложение. Как следствие, необходима модель емкости устройства (англ. capacity model) для описания доступных ресурсов и требований.

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

SCA
SCA регулирует структуру и работу SDR, а также следит за тем, чтобы аппаратные и программные элементы слаженно работали в рамках JTRS [2]. SCA имеет открытую архитектуру для достижения следующих целей:

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

SCA базируется на компонентах готовых коммерческих решений (англ. Commercial Off-The-Shelf, COTS), стандартных интерфейсах и популярных паттернах проектирования с целью предоставления рабочего окружения управления и функционирования приложений SDR, а также обеспечения независимости от аппаратной платформы и возможности к повторному использованию существующих наработок. Эти подходы позволяют просто и быстро разрабатывать гибкие приложения с возможностями удаленного обслуживания и обновления. SCA определяет стандартную модель компонентов, позволяя третьим лицам создавать компоненты радиосистем, что упрощает разработку и уменьшает стоимость поддержки. Важная особенность SCA заключается в том, что она описывает только ожидаемое поведение компонентов, радиоприложений и окружения, но не детали реализации. Это дает определенную свободу разработчикам, но может привести к различным интерпретациям спецификаций, из-за чего могут возникнуть проблемы совместимости.

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

Существуют некоторые распространенные заблуждения, касающиеся SCA, которые должны быть пояснены. Одно из самых распространенных заключается в том, что якобы использование SCA приводит к созданию портируемых приложений (вероятно из-за того, что повторное использование радиоприложений имеет такое большое значение в SCA). Это не верно. Несмотря на то, что следование модульной архитектуры является необходимым требованием при разработке портируемого кода, оно не является достаточным. Чтобы достичь портируемости и возможности повторного использования, необходимо следовать соответствующим практикам разработки программного обеспечения и намеренно проектировать компоненты с учетом этих целей. SCA лишь помогает разработчикам достичь этих задач. Другим распространенным заблуждением является суждение о том, что SCA — это SDR. Хоть SCA и является на данный момент самой полной и надежной архитектурой SDR с открытой архитектурой, ее использование для реализации SDR необязательно. SDR может быть разработана и без использования SCA, а SCA может быть использована для реализации других платформ, помимо SDR. Последнее заблуждение о SCA заключается в том, что она очень ресурсоемка и практически нереализуема. Чаще всего это не так. Хоть разработка многократно используемых радиоприложений для модульных платформ является более сложной и требует больших ресурсов, чем разработка специализированных приложений для конкретных платформ, во многих случаях расходы, связанные с SCA, целесообразны и оправданы повышением гибкости и совместимости [5]. Актуальность данного подхода может быть продемонстрирована успешным внедрением портативных радиоустройств, разработанных с использованием SCA, например, Falcon III от Harris Corporation.

Спецификации SCA

Структура программного обеспечения SCA, показанная на Рисунке 2, базируется на рабочем окружении (англ. Operating Environment, ОЕ) для абстрактных устройств и платформ. ОЕ предоставляет обобщенные механизмы установки приложений на аппаратные устройства с разными компонентами, драйверами или транспортными механизмами. ОЕ также содержит интерфейсы для управления и контроля приложений и их компонентов, вне зависимости от конкретной реализации. ОЕ состоит из 4 слоев, которые предоставляют следующие уровни абстракции:

• Операционная система Реального Времени, ОСРВ (англ. Real-Time Operating System),
• Промежуточное программное обеспечение (англ. Middleware),
• Основной фреймворк (англ. core framework, CF),
• Службы.

SCA необходима POSIX-совместимая ОСРВ. SCA также определяет подгруппу POSIX интерфейсов, которая называется профилями прикладной среды (англ. Application Environment Profiles, AEP), включающую в себя службы операционной системы. Компоненты CF имеют полный доступ к операционной системе. Кроме того, SCA точно определяет использование служб журналирования событий и именования, согласно рекомендациям рабочей группы, занимающейся разработкой и продвижением объектно-ориентированных технологий и стандартов (англ. Object Management Group, OMG).

Рисунок 2. Структура программного обеспечения SCA

Брокер объектных запросов (Middleware)
Общая архитектура брокера объектных запросов (англ. Common Object Request Broker Architecture, CORBA) является фундаментом архитектуры программного продукта. В SCA используется минимальная конфигурация CORBA, стандартизованная рабочей группой OMG [6], для обеспечения прозрачного обмена информацией между компонентами. Она была выбрана из-за своей простоты, открытости и независимости от платформы. CORBA дает SCA возможность эффективно распределять приложения. Она создает гибкое программное обеспечение для поддержки модульных переконфигурируемых платформ, изолируя приложения от аппаратно-зависимых элементов, таких как ОСРВ и транспортный уровень. В каждом устройстве компоненты могут располагаться на разных процессорах, платах, компьютерах или в разных сетях, но при этом выглядеть единым целым. CORBA имеет связанные с задержкой проблемы, вызванные динамическим расположением дочерних компонентов и маршрутизацией сообщений. Несмотря на то, что CORBA повышает сложность системы, а при неэффективном использовании нарушает работу SDR, возможность последовательной распределенной разработки устройств перевешивает эти недостатки. Более того, существует множество высокооптимизированных реализаций CORBA (например, e*ORB компании PrismTech или ORBexpress от компании Objective Interface). Важно упомянуть, что задержки в CORBA в основном вызваны транспортными механизмами. Это связано с тем, что стандартный транспортный протокол, используемый CORBA, протокол IIOP (англ. Internet Inter-ORB Protocol) основан на TCP/IP, что приводит к долгим и недетерминированным задержкам. Чтобы избежать зависимости от IIOP, разработчики ORB предоставляют возможность устанавливать оптимизированные пользовательские транспортные механизмы. При правильном использовании (реализации минимального функционала, использовании оптимизированных транспортных протоколов вместо TCP/IP и установке постоянных связей), задержки CORBA составляют лишь малую часть от общих вычислительных задержек [7] и не выходят за допустимые пределы [3,8], позволяя использовать CORBA во множестве реализаций SDR.

Основной фреймворк SCA
Фреймворк — набор взаимодействующих классов, которые образуют конфигурацию с поддержкой повторного использования для конкретных классов программного обеспечения [1]. SCA определяет набор интерфейсов, которые регулируют установку и управление радиоприложениями и их компонентами в основном фреймворке. Эти интерфейсы определяют архитектуру и другие детали системы, позволяя разработчикам концентрироваться на конкретном приложении. Основной фреймворк SCA включает в себя:

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

Интерфейсы основного фреймворка SCA определены в языке описания интерфейсов (англ. Interface Definition Language, IDL) CORBA. Упрощенная диаграмма их отношений показана на Рисунке 3.

Рисунок 3. Упрощенные отношения основного фреймворка SCA

Базовые интерфейсы приложений – в SCA каждый компонент радиоприложения должен иметь реализацию базовых интерфейсов. На верхнем уровне этих интерфейсов находится интерфейс ресурсов (англ. resource interface), который предоставляет общий интерфейс для управления и конфигурации программных компонентов (например, определение поведения при запуске и остановке приложения) и наследует от следующих интерфейсов:

• LifeCycle используется для инициализации или уничтожения ресурса,
• TestableObject предоставляет ресурсы со встроенными тестовыми возможностями,
• PropertySet предоставляет операции по конфигурации и запросу свойств ресурсов,
• PortSupplier возвращает ссылку на объект порта.

Базовые интерфейсы приложений также включают интерфейсы Port и ResourceFactory. Первый используется для соединения компонент типа Resource. Второй является необязательным интерфейсом, разработанным по архитектурному паттерну фабрики [1] и используется для создания и уничтожения ресурсов.

Порт — логический элемент, который позволяет компонентам обмениваться данными. Порты делятся на порты типа «Uses» (клиенты) и порты типа «Provides» (серверы). Интерфейс порта также реализует функции подключения и отключения, необходимые радиоприложениям.

Базовые интерфейсы устройств – ориентированные на устройства интерфейсы, позволяющие взаимодействовать с аппаратурой, выполняющие роль посредника для остальной части фреймворка. Эта абстракция позволяет не поддерживающим CORBA элементам взаимодействовать с другими компонентами фреймворка. Эти интерфейсы представляют особый интерес для разработчиков аппаратного обеспечения и разработчиков драйверов.

К интерфейсам устройств относятся:

• Device предоставляет логическое представление аппаратных устройств. Он наследуется от интерфейса Resource, расширяя его и предоставляя управление статусом и пропускной способностью (выделение и освобождение ресурсов). ASIC или выделенный элемент устройства является типичным примером физического устройства, представленного этим интерфейсом.
• LoadableDevice расширяет функционал Device. Он добавляет функционал загрузки и выгрузки, которые изменяют ход работы программы физического устройства. Примерами таких компонентов являются FPGA и DSP.
• ExecutableDevice расширяет интерфейс LoadableDevice, позволяя ему создавать и уничтожать ресурсы. Примером такого устройства является GPP, однако, в этом интерфейсе может быть представлен любой процессор с поддержкой многопоточности.
• AggreagteDevice используется для представления устройств, состоящих из нескольких логических устройств, предоставляемых по единому интерфейсу.

Интерфейсы управления фреймворка. Эти интерфейсы предоставляют основному фреймворку возможность управления и контроля над всем радиодоменом. Эти интерфейсы позволяют выполнять размещение, конфигурацию и управление радиоприложениями и платформами. В этой категории присутствуют 4 интерфейса: ApplicationFactory, Application, DeviceManager и DomainManager.

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

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

Интерфейс DeviceManager используется для управления набором логических устройств и служб. Обычно этот интерфейс используется для представления CORBA совместимого устройства. При создании, DeviceManager создает файловую систему для устройства, которое он представляет, и запускает все логические устройства, находящиеся под своим контролем. DeviceManager также определяет взаимосвязи с DomainManager и регистрирует себя как часть радиодомена.

Интерфейс DomainManager управляет общим состоянием радиоустройства. Он создает FileManager, который содержит файловую систему каждого DeviceManager, зарегистрированного под своим доменом. При создании. DomainManager также устанавливает контекст именования для радиоустройства в системе идентификации имен CORBA. DomainManager предоставляет интерфейсы регистрации для устройств, менеджеров и служб, управляет доступом к зарегистрированным устройствам и приложениям и предоставляет пользовательский интерфейс.

Рисунок 4. Поведение фабрики приложений

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

• File предоставляет доступ к отдельным файлам и их базовым операциям (например, чтение, запись, закрытие) внутри радио домена.
• FileSystem позволяет осуществлять удаленный доступ к физическим файловым системам, а также к созданию, удалению, копированию файлов и так далее. Обычно объект FileSystem ограничен одной аппаратной единицей или единственной операционной системой.
• FileManager предоставляет возможность управления несколькими распределенными файловыми системами. Его можно рассматривать как корень файловой системы, который монтирует и демонтирует другие файловые системы

Доменный профиль. Вся информация о приложениях и платформах внутри SCA включена в набор файлов, который называется доменный профиль. Эти файлы описывают интерфейсы, модель ресурсоемкости устройства, свойства, внутренние зависимости, внутренние связи и логическое расположение каждого компонента внутри домена. Эти описания представлены в формате XML. Визуальное описание отношений внутри доменного профиля показано на Рисунке 5.

Дескриптор программного пакета (англ. Software Package Description, SPD) описывает программные компоненты и их реализации. Используемые каждым компонентом интерфейсы описаны в дескрипторе программных компонентов (англ. Software Component Descriptor, SCD), а ссылка на этот файл включена в SPD. Конкретные свойства каждого компонента описаны в дескрипторе свойств (PRF). Свойство — представление любой физической или логической характеристики.

Радиоприложения описываются в файле дескриптора программной сборки (англ. Software Assembly Descriptor, SAD), который включает в себя список компонентов, требования к развертыванию, конфигурации и связям между ними. Файл SAD ссылается на SPD при описании каждого компонента радиоприложения.

Характеристики платформы описаны в дескрипторе аппаратного комплекса (англ. Device Package Descriptor, DPD) и дескрипторе конфигурации устройства (англ. Device Configuration Descriptor, DCD), также известных как профиль устройства. Аппаратные и логические представления каждого компонента описаны в DPD и SPD, соответственно. DPD также ссылается на PRF, который описывает свойства введенного в эксплуатацию устройства (серийный номер, тип процессора и т. д.). DCD содержит список устройств, установленных при запуске менеджера устройств, и необходимую информацию для поиска менеджера домена.

Рисунок 5. XML отношений доменного профиля

Радиоприложения SCA

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

Правильная разработка радиоприложений SCA включает построение модели анализа сигналов (модели UML и симуляции), определение интерфейсов приложения (интерфейсы IDL, заглушки и их структура), реализацию интерфейсов компонентов (сами компоненты обработки сигналов) и сборку компонентов приложения (доменный профиль XML). Необязательно строго следовать этим шагам, однако, они способствуют разработке, интеграции, тестированию и составлению документации.

Разработка приложений SCA может быть сложной задачей: она требует времени и абсолютного понимания основного фреймворка SCA. К счастью, существуют инструменты, позволяющие заметно ускорять разработку радиоприложений SCA и компонентов (например, OEF от OSSIE, Spectra компании PrismTech, Component Enabler от компании Zeligsoft и SCA от Communication Research Center Canada). Среди этих инструментов есть как платные, так и бесплатные.

Проект OSSIE

Разобраться с SCA может быть сложно, особенно для разработчика радиосистем без опыта работы со сложными программными архитектурами. Проект OSSIE [9] создан по инициативе исследовательской группы Wireless в Политехническом университете Виргинии с целью создания SCA с открытой архитектурой, которая бы позволила осуществлять интерактивное обучение без привлечения существенных ресурсов. OSSIE был разработан для поддержки образования и исследований в сфере SDR, когнитивного радио, распределенных беспроводных вычислений и безопасности. Он также позволяет производить быстрое прототипирование экспериментальных коммуникационных систем. OSSIE написан на C++ , использует omniORB и парсер Xerces XML, имеющие открытый исходный код. OSSIE разработан для Linux, а в частности, поддерживает сборки Fedora и Ubuntu. Для запуска OSSIE на других платформах могут быть использованы Cygwin или VMWare. Первая версия OSSIE была выпущена в июле 2004 и с тех пор находится в постоянной разработке.

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

OSSIE реализует большинство интерфейсов, описанных в основном фреймворке. Интерфейсы управления фреймворком (например, DomainManager и ApplicationFactory) не зависят от приложения. OSSIE также предоставляет примеры базовых применений и реализаций интерфейса устройства, которые могут быть использованы в качестве шаблона. Например, OSSIE включает реализацию ExecutableDevice, разработанную для персонального компьютера на Linux.

Для быстрого прототипирования компонентов и сигналов в OSSIE были разработаны инструменты разработки и отладки. Полный набор инструментов называется «OSSIE Waveform Workshop». Он включает инструмент «OSSIE Eclipse Feature» для разработки компонентов и радиоприложений, визуализацию ALF приложений, среду отладки и визуализации данных, а также панель инструментов для конфигурации радиоприложений во время работы.

OSSIE также предлагает библиотеку основных компонентов обработки сигналов для разработки радиоприложений. Библиотека содержит функции модуляции и демодуляции, интерполяции и прореживании, автоматической регулировки усиления, восстановления несущей частоты и символьной синхронизации. Более того, она включает компоненты для интерфейсного взаимодействия с универсальным периферийным устройством программно-определяемой радиосистемы (англ. universal software radio peripheral, USRP) [10].

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

Важно упомянуть, что существуют другие реализации SCA, включая SCARI от CRC и dmTK от Harris Corporation. Однако их использование требует покупки лицензии.

Коммерциализация

Рынок, однако, не торопится принимать SCA. Частично это связано с различием в общих требованиях и приоритетах. SCA была разработана для решения конкретных задач армии США, с упором на гибкость, совместимость и упрощенную адаптацию радиоприложений к новым аппаратным средствам. Несмотря на то, что множество первоначальных принципов проектирования SCA могут представлять интерес для бизнеса, они не являются приоритетом. Например, возможность устанавливать радиоприложение на разных аппаратных платформах не является такой же важной, как уменьшение стоимости системы и снижение потребляемой мощности. На данный момент коммерческие компании не желают менять производительность, стоимость и время работы батареи на повышенную гибкость и упрощенную адаптацию приложения к новым аппаратным средствам, которой позволяет достичь SCA. Это не значит, что коммерческие организации не могут получать прибыль от использования SCA. Существует множество особенностей SCA, которые коммерческие организации могут использовать или уже используют. Эти особенности приносят ощутимую прибыль в рамках используемых бизнес моделей. Модульный дизайн, использование локального фреймворка, размещение приложений, основанное на внешней информации и широкое использование связующего ПО являются распространенными методами в коммерческих проектах. Эти методы уменьшают стоимость разработки и способствуют портируемости инструментов тестирования, а также валидации и верификации. По мере того, как SCA и ее вспомогательные технологии эволюционируют, существует высокая вероятность того, что эта архитектура (или близкая к ней) окажет большое влияние на коммерческий мир. На самом деле, SCA положила начало спецификации программного радио (англ. software radio specification, SRS), чья изначальная цель заключалась в приведении SCA к коммерческому стандарту. Несмотря на то, что SRS значительно отличается от SCA, она все еще содержит те же самые базовые принципы.

Заключение

Учитывая выгоду от реализации коммуникационных устройств в виде программного обеспечения, современные разработчики радиосистем должны изучать соответствующие методы разработки, улучшающие качество при разработке SDR, повышающие возможность повторного использования программного обеспечения и упрощающие адаптацию устройства к новым аппаратным средствам. SCA использует такие методы при определении полной и надежной архитектуры реализации SDR. Однако SCA может быть трудной для понимания. Она была разработана для решения конкретных задач армии США. Чтобы стать эффективной, SCA должна быть принята всем радио сообществом. SCA-сообщество усердно работает над улучшением всех аспектов этой архитектуры, включая её производительность, энергоэффективность и распространенность.

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

1. E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.
2. JTRS; http://jpeojtrs.mil
3. D. Dohse, “Successfully Introducing CORBA into the Signal Processing Chain of a Software Defined Radio,” COTS J., Jan. 2003, pp. 32–37.
4. J. Bard and V. J. J. Kovarik, Software Defined Radio: The Software Communications Architecture, Wiley, 2007.
5. T. Quinn and T. Kacpura, “Strategic Adaptation of SCA for STRS,” Proc. SDR Forum Tech. Conf., Orlando, FL, Nov. 2006.
6. Common Object Request Broker Architecture (CORBA/IIOP) Specification; http://www.omg.org
7. P. Balister, M. Robert, and J. H. Reed, “Impact of the Use of CORBA for Inter-Component Communication in SCA Based Radio,” Proc. SDR Forum Tech. Conf., Orlando, FL, Nov. 2006.
8. J. Bertrand et al., “CORBA Delays in a Software-Defined Radio,” IEEE Commun. Mag., vol. 40, no. 2, Feb. 2002, pp. 152–55.
9. Open Source SCA Implementation::Embedded; http://ossie.wireless.vt.edu
10. Universal Software Radio Peripheral; http://www.ettus.com
11. OMG, “PIM and PSM for Software Radio Components Specification Version 1.0,” formal OMG doc. no.:formal/07-03-01, 2007.

Источник:
IEEE Communications Magazine
Volume 47 Issue 9, September 2009
Pages 50-57

Теги: sca, sdr, software defined radio, jtrs, arm, программно-определяемые радиосистемы, архитектурный фреймворк sca