Эволюция SCA 2.2

Аннотация
Тремя главными задачами Исполнительного органа по разработке совместных программ (англ. Joint Program Executive Office, JPEO) в сфере Объединенных систем тактической радиосвязи (англ. Joint Tactical Radio System, JTRS) являются ускорение боевого развертывания, улучшение взаимодействия подразделений и снижение стоимости производства средств связи. SCA (англ. Software Communications Architecture) представляет из себя архитектурный фреймворк для JTRS-приложений, который был создан для повышения адаптивности радиоприложений к новым аппаратным средствам, масштабируемости и обеспечения возможности повторного использования программного обеспечения. Одновременно с этим SCA является гибкой архитектурой, способной соответствовать специализированным требованиям.

SCA 1.0 была опубликована в 2000 году, а версия 2.2.2 была выпущена в 2006 году. После выпуска версии 2.2.2 в спецификацию были внесены изменения, направленные на решение проблем, возникших при разработке JTRS первого поколения. Большой вклад в развитие фреймворка внес боевой опыт эксплуатации наземных мобильных радиостанций (англ. Ground Mobile Radio, GMR). SCA продолжает развиваться, для того чтобы продукты JTRS соответствовали текущим и будущим запросам военных.

Для удовлетворения требований ключевых партнеров JTRS JPEO начал разработку новой версии SCA. Главной задачей разработки являлась трансформация SCA в спецификацию, которая будет, с одной стороны, исчерпывающей, а с другой – достаточно гибкой, чтобы стать фундаментом для следующих поколений JTRS. Для достижения такой гибкости, был предложен ряд нововведений, которые привели к технологической независимости, например, отказ от Общей архитектуры брокера объектных запросов (англ. Common Object Request Broker Architecture, CORBA) и привязки к файлам XML DTD. Дополнительно было введено понятие «опциональных элементов» спецификации, которые предоставляют базу для создания совместимого ПО, оптимизированного для определенного аппаратного обеспечения и круга задач.

Происхождение SCA
Бизнес модель JTRS базируется на конкуренции производителей устройств для Объединенных тактических радиостанций (англ. Joint Tactical Radio, JTR) и их совместимости. Эти принципы привели к принятию решения о необходимости обеспечения портируемости радиоприложений на различные аппаратные средства. С этой целью Управление по разработке совместных программ JTRS (англ. Joint Program Office, JPO) создало SCA.

SCA разрабатывалась поэтапно [1]. На первом этапе три рабочие группы провели исследования архитектур. Результаты оказались схожи, и на следующем этапе группа технических специалистов выделила из этих результатов ключевые идеи для проектирования стандарта, его реализации и обоснования концепции. В ходе заключительного этапа были проведены работы по окончательной проверке и подтверждению концепции SCA. Первостепенными участками разработки архитектуры являлись: распределение функций модулей; четкое определение функциональных сущностей; наборы правил для функциональных сущностей и руководства по их реализации; открытость и предметная независимость; управление системой; разработка и распространение программного обеспечения, а также описание интерфейсов. Руководствуясь вышесказанным, рабочая группа начала разработку SCA и выпустила версию 0.1 в декабре 1999 года. Первые версии SCA содержали общий фреймворк SCA, прототипы интерфейсов прикладного программирования (англ. Application Program Interface, API), ставших прародителями единого API для различных устройств JTRS, и прототипы средств безопасности, на базе которых разрабатывались средства радиосвязи для министерства обороны США.

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

Рисунок 1. Схема оригинальной SCA.

SCA 2.2.2 отказалась от описания API и перепоручила его стандартизацию другой группе внутри JPEO. Эта версия SCA не включала описание компонента Specialized Hardware Supplement, отвечавшего за взаимодействие с аппаратным обеспечением. Его описание и стандартизация перешли в ведение рабочей группы по созданию интерфейсов управления (англ. Interface Control Working Group, ICWG JTRS) [4]. Компонент безопасности также был исключен из спецификации. Все эти изменения были направлены на позиционирование SCA в качестве спецификации и для государственного аппарата, и для промышленности. Когда элементы SCA были изъяты из JTRS, то пришлось потратить значительные силы на то, чтобы продукты JTRS продолжили развивать основополагающие принципы архитектуры и предоставлять ту же функциональность.

В декабре 2006 года было добавлено расширение для поддержки новых возможностей радиоприложений. Расширение SCA 2.2.2 предоставило механизм для оптимизации развертывания приложений в многоканальных средах. Оно также поддерживало определение и развертывание служб, не относящихся к SCA (т. е. служб, не относящихся к журналированию, файловой системе, событиям и именованию). Расширение ввело новые требования для общего фреймворка SCA 2.2.2, но только для тех платформ, которые хотели использовать этот дополнительный функционал.

В декабре 2007 года были внесены поправки в Профили прикладной среды (англ. Application Environment Profiles, AEP), которые обновили Переносимый интерфейс операционных систем для Unix (англ. Portable Operating System Interface for Unix, POSIX) в соответствии с опытом, полученным при разработке радиоприложений и актуальными вычислительными стандартами.

SCA 2.2
Несмотря на то, что в названии присутствует слово архитектура, SCA не является архитектурой в привычном смысле этого слова – её принято считать архитектурным уровнем или фреймворком для программно-определяемых радиосистем (англ. Software-Defined Radio, SDR). SCA состоит из специализированных базовых интерфейсов, рабочего окружения, спецификаций, проектных моделей и утилит, как изображено на рисунке 2.

Рисунок 2. Состав SCA.

SCA 2.2 являлась одним из компонентов SDR, а программа JTRS выступила поставщиком наборов API, которые использовались для расширения фреймворка. Сочетание SCA и JTRS API предоставляло улучшенное описание хост-среды для выполнения портируемых радио-приложений Тот факт, что SCA не являлась полноценной архитектурой, было ее ключевым атрибутом, а не недостатком. Это позволяло внедрять SCA в архитектуры различных радиосистем от маленького приемника, работающего от аккумулятора, до многоканальной реконфигурируемой бортовой радиостанции, как показано на рисунке 3.

Рисунок 3. JTRS радиосистемы, построенные на SCA.

Рабочее окружение
SCA нацелена на применение во множестве различных устройств связи, удовлетворяя широкому диапазону требований военных, гражданских и коммерческих платформ. Программа JTRS требует, чтобы радиоприложения могли портироваться на все радиосистемы, показанных на рисунке 3. Для достижения такого результата разработчик радиоприложения должен быть ограничен определенным набором особенностей операционной системы и языка программирования. Также, сама радиостанция должна поддерживать необходимый аппаратный функционал на уровне процессора и источника питания.

AEP SCA 2.2.2 определил более 500 функций операционных систем реального времени (англ. Real-Time Operating System, RTOS), которые SCA-совместимое приложение должно поддерживать (Рисунок 4). AEP является гибридом профилей реального времени POSIX PS 52 и 53, поддерживаемым множеством производителей RTOS. Спецификация SCA задает требования RTOS к рабочему окружению таким образом, чтобы разработчик продукта JTRS имел возможность соответствовать им, используя собственные разработки или готовые решения, доступные на рынке. Требования AEP применяются только к процессорам общего назначения (англ. General Purpose Processor, GPP), так как POSIX-совместимые решения не распространены в области цифровых сигнальных процессоров (англ. Digital Signal Processor, DSP). JTRS были опубликованы лишь общие руководства для процессоров специального назначения, однако среда исполнения в них описана не была.

Рисунок 4. Часть спецификации функционала POSIX.

CORBA стала частью SCA с ее первых версий. Она предоставляла поддержку двух важных атрибутов SCA: распределенных вычислений и компонентной модели. Язык описания интерфейсов (англ. Interface Definition Language, IDL) от рабочей группы, занимающейся разработкой и продвижением объектно-ориентированных технологий и стандартов (англ. Object Management Group, OMG), использовался для базовых интерфейсов SCA и для стоящих особняком API JTRS. Были созданы программные инструменты для создания скелетов кода из IDL-определений, которые могут быть дополнены поведенческой логикой.

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

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

CORBA предоставляет три дополнительных службы: службу именования, службу событий и службу журналирования. Это снимает с SCA необходимость описания этих компонентов. Служба именования OMG выполняет функцию справочника для программных и аппаратных адаптеров внутри радиосистемы. Каждый программный компонент регистрируется в службе именования, а затем другие компоненты могут обращаться к службе именования для получения указателя на зарегистрированный компонент. Служба журналирования OMG стандартизирует запись логов внутри радиосистемы. Компоненты регистрируют события и сообщения в формате с открытым стандартом, а инфраструктура радиосистемы отвечает за жизненный цикл компонентов. Служба событий OMG предоставляет несвязный коммуникационный механизм программных компонентов для подачи сигналов самой радиосистеме или другим программным компонентам, используя интерфейс открытой архитектуры типа «публикация и подписка».

Компонентная модель и динамическое инстанцирование
В дополнении к компонентной модели, предоставленной спецификацией CORBA, SCA предоставляет динамическое инстанцирование программных компонентов радиосистемы (Рисунок 5). SCA не предполагает статической конфигурации компонентов. При включении радиосистемы программные компоненты, показанные на рисунке 5, запускаются начальным загрузчиком, но между этими компонентами не существует никакой связи, и они не имеют информации о том, как взаимодействовать друг с другом.

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

Рисунок 5. Динамическое инстанцирование и связи.

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

Рисунок 6. Базовые интерфейсы, устанавливаемые SCA.

Успех SCA 2.2
JTRS стала очень успешной в адаптации новых радиоприложений, например, в военной сфере (англ. Soldier Radio Waveform, SRW) и в широкополосных сетях (англ. Wideband Networking Waveform, WNW) на новые устройства. Начался выпуск объединенных радиосистем для ВВС и ВМФ США, не требовавших разработки радиоприложений. Производителю необходимо было только скачать программное обеспечение JTRS из репозитория и немного доработать код под конкретные конфигурации и задачи, а не разрабатывать радиоприложение с нуля.

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

Рисунок 7. Требования SCA в зависимости от форм-фактора

Обзор процесса эволюции SCA 2.2
Хотя ICWG сыграла ключевую роль в формировании списка улучшений SCA, но значительное влияние оказал и опыт, полученный при разработке SCA-совместимых продуктов в рамках программ JTRS. На всем протяжении существования JTRS JPO установило своей основной целью поддержание близких отношений не только с разработчиками, но и с промышленностью, и образованием, используя для этого OMG и Форум SDR. Кроме поддержания контактов, в приоритете был сбор информации, касающейся тех частей SCA, которые могли бы быть улучшены или дополнены.

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

Команда программы SCA выделила набор из приблизительно, 60 первостепенно необходимых улучшений. Предложения были ранжированы в зависимости от привносимой выгоды для пользователей SCA. Ранжирование не базировалось на объеме работ, так что изменения с высоким рейтингом могли требовать лишь небольших правок кода или других изменений, но при этом оказывали значительное влияние на систему в целом.

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

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

Для удовлетворения противоречивых требований, указанных на рисунке 7, обновленная SCA должна была иметь больше настроек, чтобы обеспечить совместимость с большим количеством продуктов. Было создано больше точек контроля соответствия требованиям, что позволило разносторонне оценивать практические реализации. Например, устройство SCA представлено как CF::Resource, полностью поддерживающее модель состояний и имеющее возможность управлять распределением ресурсов. Потенциальная системная архитектура может допускать устройство, которому не требуется управлять ресурсами. Устройство может использоваться в качестве коммуникационного реле для передачи данных между конечными точками. В таком случае проектировщик системы может указать, что способ, с помощью которого целевая система собирает данные и отправляет их через релейный канал связи имеет последовательную природу, а значит, не может возникнуть ситуации, когда устройство не сможет отработать запрос. Устройства, основанные на SCA 2.2.2, могут предоставлять полную реализацию операций по управлению ресурсами общего фреймворка “allocateCapacity()” и “deallocateCapacity()”,имеющими некоторые семантические требования к ожидаемому поведению и исключениям. Обновленная спецификация должна была сделать управление ресурсами настраиваемой опцией. Если устройству нужно выступать в качестве менеджера ресурсов, оно может реализовать эту способность и стать субъектом существующих требований общего фреймворка. В случаях, описанных выше, фреймворк предоставит механизм для исключения управления ресурсами, и устройство не подпадет под требования. Следуя этому принципу, существующие реализации смогли сохранить свою совместимость, внеся минимальные изменения. Реализация же дополнительной гибкости позволила фреймворку быть более подходящим к требованиям целевой системы.

Анализ и установка требований
SCA 2.2.2 совместил в себе требования для производителей радиосистем (например, к рабочему окружению) и разработчикам радиоприложений. Спецификация пыталась разделить требования на категории с помощью терминов Base Application и Base Device interfaces, однако, различия были заметны лишь самым сообразительным разработчикам JTRS. Новая спецификация строилась таким образом, чтобы можно было точно определить владельца любых требований. Установка требований была объединена с декларациями о соответствии, чтобы рядовой читатель мог легко определить, какие части спецификации необходимо использовать в его продукте. В последствии это упростило сертификационное тестирование и улучшило производительность разработчиков, так как владельцы требований были четко определены.

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

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

На момент написания этой статьи (2009 год) готовой замены не существовало. Некоторые технологии, например, удаленный вызов процедур (англ. Remote Procedure Call, RPC), поддерживали распределенные вычисления, но не имели компонентной модели. Существовали и более выразительные технологии, например, простой протокол доступа к объектам (англ. Simple Object Access Protocol, SOAP), но они несовместимы с системами реального времени и в некоторых случаях могут требовать дополнительной разработки служб, которые уже существуют в большинстве реализаций CORBA.

Значительная ценность SCA заключается в абстракциях, встроенных в фреймворк и позволяющих применять коммерческие открытые технологии для разработки портируемых SDR-систем. Таким образом, одним из главных достижений SCA является создание спецификации общей модели. Как только такая модель создана, спецификация может быть доработана для ее различных уровней, чтобы усилить важные для внедряющей организации моменты. SCA могла предоставить разработчикам возможность использовать любые технологии, наиболее подходящие их продукту, задать четкий набор технологий для создания продукта или предоставить решение среднее между этими двумя крайностями. Такой подход дал возможность существовавшим реализациям SCA мигрировать на CORBA/e, наследника минимальной версии CORBA.

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

Создание руководств
Многие API в SCA описывают обработку исключений. Однако SCA не обеспечивает нативную обработку исключений C++. Несмотря на удобство, в силу того, что это является особенностью языка, многие программисты встроенных систем избегают обработки исключений из-за высоких затрат памяти и ресурсов центрального процессора. Точно также динамическая информация о типах (англ. Run-Time Type Information, RTTI) и динамическое приведение объектов являются особенностями С++, имеющими высокие требования к ресурсам во встроенных системах.

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

Как и специализированные наборы отображений, которые будут неразрывно связаны с SCA, эти руководства будут связаны с конкретным представлением технологии. Программа JTRS разработала такие руководства, однако они выходят за рамки описания SCA.

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

Эволюция доменного профиля
Доменный профиль SCA 2.2 был описан в наборе XML DTD. Было проведено исследование для выяснения необходимости перехода от DTD к XML Schema (XSD) для большей гибкости. XSD предоставляют альтернативный, но эквивалентный механизм идентификации, функционала, свойств и внутренних зависимостей компонентов домена. Кроме того, XML Schema предоставляет дополнительные функции, которые могли быть полезными при развитии SCA. Изменения, которые было необходимо внести для валидации существующих компонентов файлов при помощи XSD, минимальны.

Заключение
SCA 2.2 за период своего существования прошла через несколько различных стадий. Она зарекомендовала себя как гибкий архитектурный фреймворк, который использовался при разработке и внедрении различных продуктов SDR. Программа JTRS сделала значительный вклад в расширение жизненного цикла SCA до уровня следующего поколения настраиваемых программируемых средств связи на базе SDR. В дополнение к темам, которые мы рассматривали в этой статье, такие темы, как роль служб в реализациях SCA и улучшение процесса внедрения приложений, также рассматривались в процессе эволюции. Улучшенная конфигурируемость и независимость от CORBA стали ключевыми для повышения гибкости спецификации, чтобы она могла удовлетворять функциональным и нефункциональным требованиям, предъявляемым к будущим устройствам радиосвязи.

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

1. J. Place, D. Kerr and D. SchaeferJoint tactical radio system, MILCOM 2000 - IEEE Military Communications Conference, no. 1, October 2000, pp. 209- 213
2. Donald R. Stephens,Brian Salisbury,Kevin Richardson, "JTRS infrastructure architecture and standards", MILCOM 2006 - IEEE Military Communications Conference, no. 1,October 2006 pp.3481-3485.
3. Donald R. Stephens, Cinly Magsombol, Chalena Jimenez, "Designpatterns ofthe JTRS infrastructure", MILCOM 2007 - IEEE Military Communications Conference, no. 1,October2007 pp. 835-839.
4. Cinly Magsombol, ChalenaJimenez, Donald R. Stephens, "Joint tactical radio system-Application programming interfaces", MILCOM 2007 - IEEE Military Communications Conference, no. 1, October 2007 pp. 855-861.