eng
Содержание
Содержание
Предисловие редактора перевода 11
ЧАСТЬ I. Операционная среда 12
Глава 1. Введение 13
1.1.
Программируемые радиосистемы 13
1.1.1.
Аспекты программируемых радиосистем 14
1.2.
Архитектура программируемых средств связи 16
1.2.1.
Развитие архитектуры программируемых средств связи 17
1.2.2.
Понятие SCA 19
1.2.3.
Общие представления об SCA 20
1.2.4.
Цели применения SCA 23
1.3.
Операционная среда 25
1.3.1.
Структурная организация 26
1.3.2.
Ограничения интерфейса операционной среды 27
1.4.
Структура спецификации SCA 28
1.5.
Выводы 32
Глава 2. Cценарий использования 33
2.1.
Запуск системы 33
2.2.
Завершение работы 38
2.3.
Установка/удаление приложения 40
2.4.
Создание экземпляра приложения (инстанциация) 43
2.5.
Управление приложением 45
2.6.
Настройка системы 47
Глава 3. Общие требования и службы 48
3.1.
Нефункциональные требования 48
3.1.1.
Общие положения 49
3.1.2.
Общие требования к программному обеспечению 50
3.1.3.
Требования к архитектуре аппаратного обеспечения 50
3.1.4.
Структура интерфейса 52
3.2.
Служба имен (Name Service) 54
3.3.
Служба событий 56
3.3.1.
Типы событий 57
3.4.
Служба регистрации 59
3.4.1.
Типы данных 61
3.4.2.
Исключения 61
3.4.3.
Типы 61
3.4.4.
Команды типа LogStatus 66
3.4.5.
Операции LogAdministrator 68
3.4.6.
Операции LogProducer 70
6
Содержание
3.4.7.
Операции LogConsumer 74
3.5.
Файловая система 76
3.5.1.
Исключения 78
3.5.2.
Типы и константы 78
3.5.3.
Типы 80
3.5.4.
Операции 81
3.6.
Файл 90
3.6.1.
Исключения 90
3.6.2.
Атрибуты 91
3.6.3.
Операции 92
Глава 4. Базовые интерфейсы и типы данных 97
4.1.
Интерфейс TestableObject 98
4.1.1.
Исключения 98
4.1.2.
Операции 98
4.2.
Интерфейс PortSupplier 100
4.2.1.
Исключения 100
4.2.2.
Операции 101
4.3.
Интерфейс LifeCycle 101
4.3.1.
Исключения 102
4.3.2.
Операции 102
4.4.
Интерфейс PropertySet 103
4.4.1.
Исключения 103
4.4.2.
Операции 104
4.5.
Интерфейс Resource 106
4.5.1.
Исключения 106
4.5.2.
Атрибуты 107
4.5.3.
Операции 107
4.6.
ResourceFactory 109
4.6.1.
Исключения 109
4.6.2.
Атрибуты 110
4.6.3.
Операции 110
4.7.
Интерфейс Port 113
4.7.1.
Исключения 115
4.7.2.
Операции 116
Глава 5. Устройства и диспетчер устройств 118
5.1.
Введение 118
5.1.1.
Абстрактное представление устройств архитектуры SCA 119
5.2.
Интерфейс Device 121
5.2.1.
Исключения 122
5.2.2.
Типы и константы 122
5.2.3.
Атрибуты 123
5.2.4.
Операции 130
5.3.
LoadableDevice 134
Содержание 7
5.3.1.
Типы 135
5.3.2.
Исключения 136
5.3.3.
Операции 136
5.4.
ExecutableDevice 140
5.4.1.
Типы и константы 141
5.4.2.
Исключения 141
5.4.3.
Операции 143
5.5.
AggregateDevice 147
5.5.1.
Типы и атрибуты 147
5.5.2.
Операции 148
5.6.
Менеджер устройств (DeviceManager) 149
5.6.1.
Типы данных 150
5.6.2.
Атрибуты 151
5.6.3.
Операции 153
Глава 6. управление доменом 164
6.1.
Интерфейс DomainManager (менеджер домена) 164
6.1.1.
Типы данных 164
6.1.2.
Исключения 166
6.1.3.
Атрибуты 168
6.1.4.
Инстанциация менеджера домена 170
6.1.5.
Операции 171
6.2.
Интерфейс FileManager 192
6.2.1.
Типы 194
6.2.2.
Исключения 195
6.2.3.
Операции 195
6.3.
Интерфейс ApplicationFactory 198
6.3.1.
Исключения 198
6.3.2.
Атрибуты 199
6.3.3.
Операции 200
6.4.
Интерфейс Application 207
6.4.1.
Типы данных 207
6.4.2.
Атрибуты 209
6.4.3.
Операции 211
6.4.4.
Общие требования 214
Глава 7. Безопасность операционной среды 217
7.1.
Требования по безопасности SCA 217
7.1.1.
Интерфейс Application 217
7.1.2.
Интерфейс ApplicationFactory 218
7.1.3.
Менеджер домена 219
Глава 8. Сертификация 220
8.1.
Порядок сертификации 220
8
Содержание
8.2.
Варианты сертификации
операционной среды 221
8.2.1.
OЕ-1 221
8.2.2.
OЕ-2 224
8.2.3.
ОЕ-3 224
8.3.
Сертификация и оценка приложений с параметрами сигнала 224
ЧАСТЬ II. Профиль домена 227
Глава 9. Профиль домена 228
9.1.
Обзор 228
9.2.
XML-файлы профиля домена SCA 228
9.3.
Типы данных профиля домена 231
Глава 10. Основные файлы дескриптора 232
10.1.
Дескриптор свойств 232
10.1.1.
Тип Simple 232
10.1.2.
Тип Simple Sequence 235
10.1.3.
Тип Struct 235
10.1.4.
Свойство Struct Sequence 237
10.1.5.
Свойство Test 237
10.2.
Softpkg 238
10.2.1.
Элемент title 239
10.2.2.
Элемент author 239
10.2.3.
Элемент description 239
10.2.4.
Элемент propertyfi le 239
10.2.5.
Элемент descriptor 239
10.2.6.
Элемент implementation 240
10.3.
Дескриптор программного компонента 243
10.4.
Дескриптор пакета устройств 245
Глава 11. Дескриптор конфигурации устройства 247
11.1.
Обзор компонентов 247
11.2.
Компонент deviceconfi guration 247
11.2.1.
Элемент description 248
11.2.2.
Элемент devicemanagersoftpkg 248
11.2.3.
Элемент componentfi les 248
11.2.4.
Элемент partitioning 249
11.2.5.
Элемент connections 251
11.2.6.
Элемент domainmanager 251
11.2.7.
Элемент fi lesystemnames 251
Глава 12. Дескриптор менеджера доменов 252
12.1.
Обзор 252
Содержание 9
Глава 13. Дескриптор сборки программного обеспечения 253
13.1.
Обзор 253
ЧАСТЬ III. Разработка SCA-совместимой системы 260
Глава 14. Операционная система POSIX 261
14.1.
Операционная среда 261
14.2.
Ядро Linux 2.6 265
14.2.1.
Недоступные вызовы POSIX 271
14.2.2.
Еще о недоступных вызовах POSIX 282
Глава 15. Потоки POSIX 287
15.1.
Потоковый объект 288
15.2.
Безымянные семафоры 292
15.3.
Переменные Mutex 296
15.4.
Атрибуты потока 302
15.5.
Условные переменные 308
15.6.
Менее интересные вызовы потоков 312
Глава 16. ORBы всякие нужны 315
16.1.
Основы CORBA 317
16.1.1.
Запуск серванта 320
16.1.2.
Получение объектной ссылки 321
16.2.
Группа по управлению объектами 322
16.3.
C ORB против C++ ORB 323
16.4.
Начальные службы 325
16.4.1.
Запуск клиента 326
16.5.
Хранилище интерфейсов 326
16.5.1.
Типовые коды 326
16.6.
Архитектура minimum CORBA 327
16.7.
Переносимый объектный адаптер 329
16.7.1.
Политики 330
16.7.2.
Производительность 331
16.7.3.
Совмещенные модели ORB 332
16.7.4.
Односторонняя, двусторонняя и блокирующая модели 334
16.8.
Real-time CORBA 335
16.9.
Обзор существующих ORB 336
16.9.1.
TAO ORB 337
16.9.2.
ORBexpress 337
16.9.3.
ORBit2 338
16.9.4.
MICO 338
16.9.5.
OMNI 338
Глава 17. Службы 340
17.1.
Интероперабельная служба имен 340
10
Содержание
17.1.1.
Универсальные уникальные идентификаторы 350
17.1.2.
Использование службы имен ядром SCA 351
17.1.3.
Использование службы имен приложением 351
17.2.
Служба событий 352
17.2.1.
Использование ядра службой событий 365
17.2.2.
Использование службы событий интерфейсом Resource 366
17.3.
Служба регистрации 366
17.3.1.
Использование службы регистрации ядром SCA 372
17.3.2.
Использование службы регистрации ресурсом 373
Глава 18. Изучаем домен 374
18.1.
Атрибуты интерфейса Application Factory 375
18.2.
Атрибуты интерфейса Application 377
18.3.
Атрибуты интерфейса DeviceManager 381
18.4.
Атрибуты интерфейса Device 383
18.5.
Атрибуты интерфейса AggregateDevice 385
18.6.
Атрибуты менеджера домена 387
18.7.
Свойства домена 389
18.8.
Порты управления 393
18.9.
Выводы 395
Глава 19. SCA-совместимое приложение 399
19.1.
Традиционное приложение Hello World 399
19.2.
SPD традиционного приложения Hello World 404
19.3.
Приложения пользовательского интерфейса 408
19.4.
Завершение работы 413
19.5.
SCA-совместимое приложение Hello World 413
19.5.1.
SCA-совместимое терминальное устройство 414
19.5.2.
Профиль домена для терминального устройства 423
19.5.3.
SCA-совместимое приложение 427
19.5.4.
Многопоточный сервант 432
19.5.5.
Файлы XML приложения Talk 435
19.5.6.
Модификации для совместимости с Minimum CORBA 441
19.5.7.
Заключение 442
Приложение A 444
Обязательные вызовы POSIX 444
Приложение B 446
Литература к части III 446
Приложение C 448
Список английских сокращений 446
Предметный указатель 450
Предисловие редактора перевода
На современном этапе развития общества особое внимание уделяется развитию
систем связи и управления, функционирующих в едином информационном про-
странстве Российской Федерации.
Определяющей технологией, на базе которой планируется создавать такие
системы, является программно-конфигурируемое радио (Software Defi ned Radio —
SDR). Все его настройки и параметры задаются программно. Конфигурация SDR
определяется с помощью программного обеспечения. Для этой цели использу-
ются либо процессоры цифровой обработки DSP, либо матрицы FPGA (Field-
Programmable Gate Array — программируемая пользователем вентильная матрица,
одна из типов ПЛИС — программируемых логических интегральных схем).
Имеется международный опыт разработки программно-конфигурируемого
радио для тактического звена. Так, в США создана JTRS (Joint Tactical Radio System)
— военная система для связи в американской армии. Изначально JTRS была
предназначена для замены 25—30 различных типов военных систем связи (неко-
торые из них не могли связываться между собой) на одну программную радио-
систему, которая могла бы работать во всех диапазонах частот. Помимо военных
(WNW-BEAM, OFDM, AJ, LPI и др.) система JTRS должна поддерживать сотовую
связь различных стандартов (GSM, CDMA), а также транкинговую связь стандар-
тов TETRA и TETRAPOL.
Концепция американской программы JTRS использовалась для разработки
двух европейских программ: ESSOR и SVFuA.
ESSOR (European Secure Software Radio Program) создается усилиями шести
стран (Финляндия, Франция, Италия, Польша, Испания, Швеция) и базируется
на открытом стандарте SCA (Software Communication Architecture — архитектура
программной связи).
SVFuA является немецкой национальной программой и предназначена для
применения Бундесвером (Федеральными вооруженными силами Германии).
Наличие разработанной в JTRS архитектуры SCA позволило европейским
странам ускорить и удешевить программы ESSOR и SVFuA. Поэтому мы надеем-
ся, что перевод книги, посвященный SCA, позволит и отечественным разработчи-
кам за короткие сроки и с меньшими затратами реализовать проекты, аналогич-
ные JTRS, ESSOR и SVFuA.
Книга в первую очередь адресована специалистам по разработке систем ради-
освязи двойного назначения. Для работы с книгой требуется базовая подготовка
в области радиотехники и прикладного программирования. По причине отсут-
ствия устоявшейся русскоязычной терминологии большинство сокращений дано
на английском языке. Их список с русским переводом выделен в отдельное при-
ложение.
Радько Н.М.
Часть I
ОПЕРАЦИОННАЯ СРЕДА
В первой части книги приводится спецификация архитектуры программно опре-
деляемых средств связи (SCA, software communications architecture). Цель этой ча-
сти — дать общую информацию по SCA с пояснениями относительно толкования
и функциональных требований к ней. Эта часть книги может использоваться как
отдельный справочник по SCA.
ГЛАВА 1
ВВЕДЕНИЕ
Фундаментальной задачей SCA является обеспечение общей инфраструктуры
программного обеспечения (ПО) для управления радиосистемами. Несмотря
на то, что ПО является ключевым компонентом современных радиосистем, бла-
годаря которому они получают новые функции и возможности, каждый произво-
дитель радиосистем использует собственную архитектуру и/или инфраструктуру
системы, поэтому для загрузки и управления ПО используются особые, уникаль-
ные для каждого производителя механизмы. Как было сказано выше, программ-
но-определяемое радио относится к классу радиосистем, характеристики которых
не просто обусловлены программным обеспечением, но используют инфраструк-
туру, в которой взаимозаменяемы и компоненты, и функции.
В этой главе содержится основная информация об SCA. В спецификации SCA
описываются компоненты архитектуры, их структура и объединение их в систе-
му, формирующую радиосигнал. Все эти элементы образуют инфраструктуру для
создания программно-определяемой радиосистемы (Software defi ned radio, SDR).
1.1. Программируемые радиосистемы
Радиосистему можно представить в абстрактном виде, рассматривая форму сиг-
нала и используемый диапазон частот (см. рис. 1.1). Низший уровень схемы за-
нимает комплекс аппаратных средств, который обеспечивает работу ПО, форми-
рующего сигнал и выполняющего вспомогательные задачи. Обработка данных
может осуществляться одним из четырех устройств: универсальным центральным
процессором (ЦП), цифровым сигнальным процессором (ЦСП), программируе-
мой логической схемой (ПЛИС) или специализированной большой интеграль-
ной схемой (СБИС). Строго говоря, такую БИС нельзя использовать как основу
программируемой радиосистемы, так как конфигурация этой микросхемы зада-
ется при изготовлении и не может быть изменена (перепрограммирована) в про-
цессе работы, что нарушает один из фундаментальных принципов SDR. Однако,
по мнению авторов, БИС можно применять в SDR, при условии, что она обеспе-
чивает возможность гибкой взаимозаменяемости функциональных компонентов
обработки сигналов внутри микросхемы. Например, вызов какого-либо алгорит-
ма внутри БИС должен осуществляться аналогично вызову программных функ-
ций.
Рис. 1.1 демонстрирует две ортогональные проекции процесса разработки
SDR. Создание сигнала начинается с разработки комплекса требований, имита-
ционной или математической модели или другого концептуального представле-
ния сигнала. По мере разработки формы сигнала параметры его реализации (про-
пускная способность и мощность) обычно задаются на языке высокого уровня
и для их выполнения на ЦП или ЦСП. Для повышения пропускной способности
системы необходимо использовать ПЛИС или СБИС.
ЦП, как правило, применяется для управления всей системой. Находящие-
ся выше процессора ОС с пакетом ПО служат основой динамической структуры
радиосистемы. В терминах SCA эта структура называется ядром SCA (SCA Core
Framework). Над ней на рисунке находятся приложения, формирующие сигнал
и выполняющие прочие задачи.
1.1.1. Аспекты программируемых радиосистем
Систему SDR можно рассматривать с четырех аспектов, каждый из которых об-
разует функциональную группу объектов и служб в радиосистеме (рис. 1.2):
Radio System
Спецификация сигнала
Модель Требования Моделирование
Waveform Implementation
C/C++ RTL/VHDL
Digital Subsystem
GPP FPGA ASIC
Диапазон частот
Абстракция формы сигнала
Аналоговая
подсистема
Цифровая передача данных
Усилители
Преобразователи
Радиочастотный
Сигнал
Операционная
Система
CF
DSP
Аналого-
цифровой
Цифро-
аналоговый
Рис. 1.1. Абстрактное представление системы радиосвязи
• Аппаратные средства — физическая структура радиокомплекса, т. е. сово-
купность входящих в нее устройств.
• Программное обеспечение — службы и интерфейсы, которые согласуют
с основными аппаратными средствами все сигнальные приложения.
• Приложения — к этому аспекту относятся приложения для создания фор-
мы сигнала и службы, которые предоставляет радиосистема.
• Пользователь — взаимодействует с радиокомплексом. Существуют два ос-
новных режима взаимодействия: пользователь либо контролирует систему
в целом (например, задает параметры системы), либо управляет работой
приложений и передачей данных (например, определяет коэффициент
усиления в момент передачи).
SCA можно рассматривать как реализацию аспекта ПО с некоторыми эле-
ментами аспекта приложений. Она определяет логическую инфраструктуру и аб-
страктное представление аппаратных средств и компонентов ПО цифровой об-
работки, входящих в формирующее сигнал приложение. SCA также характеризует
функции системы и интерфейсы управления, загрузки и конфигурирования при-
ложений, формирующих сигнал, внутри системы.
Аспекты программируемого радио cd
Физический элемент
Приложение ПО
AppComponent LogicalDevice Event
Компонент ПО
Сигнал Служба
Порт
Свойство
Radio
Приложение и Службы
Инфраструктура
программного
обеспечения
Аппаратные средства
Пользователь
радиосистемы
Мощность
Пользователь
Resource
Processor RF Antenna
GPP DSP FPGA
Устройство
ввода-вывода
NIC AD-DA
«реализует»
зависимая величина
1..
1..
1
выдает
0..
контро-
лирует
управ-
ляет
0..
«реализует»
0..*
подключается
через
«реализует»
«реализует»
зависимая величина
1
обеспечивает интерфейс
1
требуется
1
выделена
1..
зависимая величина
Рис. 1.2. Аспекты программируемого радио
1.2. Архитектура прграмируемых средств связи Любая новая концепция или технология требует времени и определенных знаний
для ее освоения, и концепция SCA — не исключение. Она определяет инфраструк-
туру ПО для управления SDR. Она не подчинена какой-либо особой структуре или
реализации аппаратных средств и приложений. Перед детальным рассмотрением
SCA рекомендуется ознакомиться с тем, что есть и чем не является SCA, историей
ее развития, и причинами, побуждающими ее использовать или отказаться от нее.
SCA основана на нескольких взаимосвязанных технологиях: объектно-ори-
ентированные (ОО) методы создания ПО, общая архитектура брокера объектных
запросов (common object request broker architecture — CORBA), и модель компо-
нентов CORBA (CORBA components model — CCM).
Объектно-ориентированные языки используются в течение нескольких деся-
тилетий, начиная с языка Simula, появившегося в конце 1960-х годов, Smalltalk
и Flavors — в начале 1980-х и завершая современными ОО-языками — C++,
Python, Ruby и Java. По мере совершенствования систем с распределенной ар-
хитектурой и структурой клиент-сервер CORBA стала промышленным стандар-
том для описания интерфейсов на псевдoкоде, т. е. языке описания интерфейсов
(interface defi nition language — IDL). IDL обеспечивает средства для указания до-
ступных интерфейсов и, при помощи «компилятора» IDL, генерирует исходный
код, который компилируется для каждого приложения. Сгенерированный код
содержит служебные алгоритмы, необходимые для поддержки удаленных вызо-
вов процедур между процессами на одном и том же компьютере и между разными
компьютерами, т. е. в распределенной среде. Таким образом, программист был
избавлен от рутиной работы по созданию кода межпроцессорной связи низкого
уровня, и, что более важно, код CORBA, созданный одним лицом, был совме-
стим с кодом, созданным другим лицом, при единственном условии, что оба авто-
ра клиентского и серверного приложения использовали один и тот же язык IDL.
Вместе с выделением внутренней логики в самостоятельный элемент (инкапсу-
ляцией) это было важным шагом в направлении совершенствования модульно-
го программного обеспечения: единственным требованием стало использование
единого языка IDL разработчиками и клиентского, и серверного приложений.
Несмотря на то, что технология CORBA имела ряд важных преимуществ,
стало очевидным, что механизм развертывания системы все еще требовал руч-
ной настройки параметров конфигурации. При загрузке ПО необходимо явно
указать требования для его установки, то есть какие ресурсы требуются для этих
приложений. Для описания компонентов системы и сопутствующих требований
по установке используются XML-файлы. XML (eXtensible Markup Language) — это
текстовый язык, использующий ключевые слова (теги) для определения элемен-
тов данных, их атрибутов и значений. На языке XML CCM основан язык XML
профиля домена SCA (Domain profi le XML).
1.2.1. Развитие архитектуры программируемых средств связи
Во время проведения военных операций военное ведомство США столкнулось
с острой необходимостью обеспечить надежную связь с высоким уровнем совме-
стимости и малыми затратами. Большое количество радиосистем было основа-
но на аппаратной платформе, с ограниченными возможностями по формирова-
нию сигналов, и это стало одним из главных препятствий на пути создания SCA.
Кроме того, было невозможно обновлять существующие или добавлять новые
сигналы без значительных затрат на модернизацию аппаратных средств. Вместе
с тем, за последние двадцать лет значительно повысилась мощность процессоров,
и стали общедоступными специальные процессоры ЦСП и ПЛИС, также непре-
рывно повышались производительность и разрешающая способность аналого-
во-цифровых и цифрово-аналоговых систем. Как результат, для обработки боль-
шинства сигналов вместо аналоговых систем стали использоваться цифровые,
реализованные программно. Ранние эксперименты в области SDR (например,
система SpeakEasy) показали, что программно-реализованная архитектура име-
ет значительные преимущества. Многие производители радиосистем уже начали
работы по реализации программных компонентов обработки базового сигнала.
Первые многоканальные радиосистемы, разработанные в 1990-х годах — боевой
информационный терминал (Joint Combat Information Terminal, JCIT) и цифровая
блочная радиостанция (Digital Modular Radio, DMR) обеспечивали программную
инфраструктуру для управления ресурсами радиосистемы.
Из-за необходимости улучшения возможностей перенастройки системы,
поддержки совместных действий и снижения затрат на эксплуатацию и обслу-
живание, для разработки нового семейства программно-реализованных рекон-
фигурируемых радиосистем было создано Управление по разработке совместных
программ (Joint Program Offi ce, JPO) Joint Tactical Radio System (JTRS, совместные
тактические радиосистемы). Одной из первых задач Управления было определе-
ние общей инфраструктуры программного обеспечения для использования в но-
вых семействах радиосистем. Таким образом и возникла SCA.
На рис. 1.3 показаны несколько ключевых этапов развития спецификации
SCA. Были разработаны несколько предварительных ее версий, но первой, ис-
пользованной для разработки первоначальной реализации SCA стала версия 1.0.
После следующей версии 1.1 значительная часть спецификации была перерабо-
тана, и появилась версия 2.0. Она имела некоторые недостатки, для устранения
которых нужно было пересмотреть все аспекты инфраструктуры программного
обеспечения. Тем не менее, были разработаны несколько реализаций версии 2.0,
которые обеспечили важную для разработки следующих версий информацию «об-
ратной связи» (feedback). Следующая версия 2.1 появилась в середине 2001 года,
а в ноябре была выпущена версия 2.2. В целом, версия 2.2 считалась достаточно
завершенной для реализации и применения в системе SDR.1
В июне 2002 года фирма Boeing получила от CECOM (Communication and Electronic
Command, командование связи и электроники) заказ на разработку пер-
вой базовой программы внедрения SCA. Первым проектом, использующим SCA
версии 2.2, стал Cluster 1, который позже получил название Ground Mobile Radio
(GMR, наземная радиостанция мобильной связи). Позднее стали разрабатывать-
ся другие программы JTRS Cluster, и в апреле 2004 года, почти через три года по-
сле появления спецификации 2.2, была выпущена версия 2.2.1. В этой версии
были устранены многие ошибки и внесены несколько уточнений и улучшений.
Наиболее важным изменением в версии 2.2.1 было исключение из специфика-
ции SCA службы Log Service (служба регистрации) и замена ее на службу OMG
Lightweight Log (упрощенная регистрация OMG — группы по управлению объ-
ектами). В середине 2004 года OMG выпустила свою спецификацию SDR. Спец-
ификация OMG была создана группой специалистов, которые участвовали в раз-
работке SCA. Их первоначальной целью было сделать возможным использование
SCA как промышленного стандарта, а не только военного. Но, как только спец-
ификация OMG появилась на свет, стало ясно, что она существенно отличается
от спецификации SCA.
В то же время в программах JTRS Cluster обнаружились проблемы, связанные
с совместимостью сигналов. Проблема заключалась в том, что код, написанный
для ЦП, был совместим с различными аппаратными платформами, но код для
ЦСП и ПЛИС оставался «привязаным» к определенной платформе и архитектуре
системы2.
1 Несмотря на это, для того, чтобы стать достаточно надежной и эффективной, вер-
сия 2.2 требует некоторых корректировок и уточнений. Например, интерфейс IDL, пред-
ставленный в Приложении С спецификации SCA, не соответствует заданным параметрам
из-за конфликта имен с интерфейсом POSIX.
2 Совместимость моделей сигналов стала существенной проблемой внутри сообще-
ства SCA. Это ни в коем случае не является фундаментальным требованием SCA. Совме-
January 00 December 06
1/01 1/02 1/03 1/04 1/05 1/06
8/06
SCA 2.2.2 (Draft)
11/01
SCA 2.2
5/01
SCA 2.1
4/04
SCA 2.2.1
8/04
SCA 3.0
6/02
Начало программы Cluster 1
2/00
SCA 1.0
7/00
SCA 1.1
12/00
SCA 2.0
5/04
Спецификация SDR OMG
dtc/04-05-04
Рис. 1.3. Хронология SCA
Эта проблема наиболее остро проявилась в конце 2004 года, что побудило JPO
созвать нескольких семинаров для решения проблемы совместимости процессоров
ЦСП и ПЛИС. Их результатом стало появление спецификации SCA 3.0. В отли-
чие от предыдущей, новая версия SCA имела незначительные отличия от прошлой.
Но в ней появились дополнительные ограничения на системные вызовы, которые
могут быть использованы кодом ЦСП, задан предполагаемый набор сигнальных
компонентов, предложена высокоуровневая схема передачи данных (получившая
название HAL-C) и была появился API антенны. Специалисты сошлись во мне-
нии, что необходимо доработать спецификацию — несмотря на наличие потенци-
ально полезных концепций и подходов, для успешной реализации проекта требует-
ся более детальный анализ спецификации.
С конца 2005 до начала 2006 года управление JPO было реорганизовано для
более успешного решения проблем с программами Cluster. Отдел по реализации
программы был перенесен из Вашингтона в Сан-Диего и передан в подчинение
Командованию боевых космических и морских систем (Navy SPAWAR). В середи-
не 2006 года была выпущена версия 2.2.2 — развитие версии SCA 2.2.1. При этом
на веб-сайте JTRS указано, что версия 3.0 «не поддерживается». Поэтому на мо-
мент выхода данной публикации версия 2.2.2 является последней поддерживае-
мой версией SCA.
1.2.2. Понятие SCA
Основной задачей SCA является определение программного обеспечения опе-
рационной среды (ОС) — инфраструктуры, или ядра SCA. Оно используется для
управления, развертывания, настройки и регулирования радиосистем и приложе-
ний, которые запускаются на платформе радиосистемы. Для того, чтобы полу-
чить представление о том, что такое SCA и чем она не является, целесообразно
обратиться к введению спецификации SCA. Ниже приводится выдержка из этой
части.
Спецификация программируемых средств связи (SCA) опубликована Управ-
лением по разработке совместных программ (JPO) JTRS. Управление было орга-
низовано для создания перспективных систем средств связи с учетом передово-
го опыта использования технологии по улучшению совместимости средств связи
и снижению затрат на их разработку и развертывание. Основными задачами про-
граммы JTRS являются:
• значительное повышение операционной гибкости и совместимости гло-
бальных систем связи;
стимость формы сигнала можно рассматривать как возможность снизить затраты при соз-
дании радиосистем. Но из-за различий в аппаратных средствах, процессоре и архитектуре
передачи данных невозможно обеспечить элементарную передачу сигнала от одной систе-
мы к другой, не внося в них изменения.
• снижение затрат на техническую поддержку;
• возможность модернизации, то есть внедрения новых технологий и улучше-
ния характеристик;
• снижение затрат на приобретение и эксплуатацию систем.
Для успешного решения этих задач спецификация SCA была структурирована
с целью:
• обеспечения совместимости программного обеспечения приложений
между различными реализациями SCA;
• использования коммерческих стандартов для снижения затрат на разра-
ботку;
• снижения сроков разработки новых форм сигналов посредством исполь-
зования модулей;
• совершенствования промышленной инфраструктуры и архитектуры.
• SCA V2.2, 17 ноября 2001 года, стр. 7.
Ни одна из вышеуказанных задач не связана ни с техническим проектом
и процессом разработки, ни с реализацией сигналов в радиосистеме. Поэтому
первой фундаментальной целью SCA является совершенствование технико-эко-
номического обоснования проекта (ТЭО) с целью улучшения рабочих характери-
стик средств связи и их материально-технического обеспечения.
Для успешного решения этой задачи структура SCA призвана обеспечить со-
вместимость программного обеспечения приложений, использование промыш-
ленных стандартов, поддержка повторного использования модулей, формирую-
щих сигнал, а также совершенствование промышленной инфраструктуры. Наряду
с задачами, обозначенными в предыдущем параграфе, структура SCA фокусиру-
ется на процессах проектирования и разработки, обеспечивая повторное исполь-
зование проектных модулей и применение коммерческого ПО и стандартов.
1.2.3. Общие представления об SCA
В предыдущем разделе было дано краткое описание SCA. Не секрет, что для
разных индивидуумов технологии зачастую могут подаваться и пониматься по-
разному — некоторые представления основаны на реальных фактах, другие же
базируются на неполном понимании сути технологии. Ниже будут изложены не-
которые из типичных заблуждений относительно SCA.
1.2.3.1. SCA определяет техническую архитектуру программируемого
радио
Спецификация SCA не содержит информацию о технических характеристиках
или инструкции по проектированию и реализации программируемого радио.
Спецификация SCA, основанная на компонентах модели CORBA, определяет
архитектуру для развертывания приложений. В SDR в качестве приложений ис-
пользуются модели сигналов.
1.2.3.2. SCA дает возможность повторного использования модулей
SCA повышает возможность повторного использования программных модулей
с двух точек зрения. Во-первых, спецификация SCA определяет единый пакет
интерфейсов для базовой начальной конфигурации и для управления приложе-
ниями. Таким образом, со стороны пользовательских интерфейсов и внешне-
го управления системой, для загрузки, запуска и остановки сигналов например,
стандарта SINCGARS используются те же интерфейсные вызовы, что и для сиг-
налов стандарта FM3TR. Во-вторых, дополнение API к спецификации обеспе-
чивает повторное использование компонентов программного обеспечения через
общие интерфейсы сигналов. Данная тема требует дальнейшего обсуждения, по-
скольку все разработчики радиосистем имеют собственные представления о том,
какие интерфейсы должны быть у разработанных ими сигналов.
1.2.3.3. Сигнал может быть перемещен с одной платформы SCA на другую
без преобразования
Многие понимают понятие переносимости сигналов SCA как возможность мно-
гократного их применения без внесения каких-либо изменений. Спецификация
SCA определяет общие интерфейсы высокого уровня для развертывания, на-
стройки, управления и контроля аппаратных систем и программных приложений
внутри радиосистемы. Это облегчает процесс переноса приложений, поскольку
интерфейсы не меняются. Но возможность использования одних и тех же сигна-
лов в различных радиосистемах без внесения в них изменений никогда не рассма-
тривалось как непременное требование.
1.2.3.4. Архитектура SCA влияет на параметры сигнала в системе
После того, как SCA загрузит сигнал в радиосистему, ядро SCA переходит в режим
ожидания и использует лишь малую часть времени процессора. Кроме того, SCA
исключает влияние на сигналы, реализованные на процессорах ПЛИС или ЦСП.
SCA может оказывать некоторое влияние на объем используемой памяти, так как
она требуется для работы ядра SCA. Тем не менее, рабочие группы SDR Forum,
NASA и некоторые другие исследуют возможности уменьшения объема занимае-
мой памяти. В случае, когда ядро SCA запускается на ЦП, который используется
и для обработки сигналов, возможно некоторое ухудшение производительности.
В этом случае для определения допустимого диапазона нагрузок необходимо про-
вести стандартный системный анализ
1.2.3.5. Для передачи данных необходимо использовать CORBA
Об использовании CORBA стоит думать в первую очередь, однако это не является
обязательным условием в том случае, если применение CORBA ухудшает произ-
водительность. Стоит отметить, что пользователи часто ошибаются, приписывая
задержки передачи данных CORBA, хотя в действительности они происходят
на уровне протокола TCP/IP. CORBA же — это протокол, скорее похожий на про-
токол передачи гипертекста HTTP, и находится на верхнем уровне механизма
передачи данных. Большинство современных ORB поддерживают подключаемые
интерфейсы транспорта данных, обеспечивая гибкую настройку и оптимизацию
фактического потока передачи данных.
1.2.3.6. SCA пригодна только для небольших радиосистем
SCA изначально не разрабатывалась для применения в радиосистеме какого-либо
определенного класса. При создании SCA-совместимой системы малого размера и с
ограниченными ресурсами возникают больше сложностей, связанных с ограниче-
ниями по весу, размеру и мощностью, чем при разработке переносной или ранцевой
радиостанции. Обычно это связано с тем, что ЦП малой радиостанции активно ис-
пользуется для обработки сигналов, и, если ЦП будет обрабатывать и ядро SCA, это
может оказать значительное влияние на производительность системы.
1.2.3.7. SCA и/или CORBA не годятся для больших, сложных систем
SCA основана на программе JTRS, целью которой была разработка систем такти-
ческого радио. Существует множество модификаций таких систем, начиная от не-
больших переносных радиостанций и заканчивая системами для монтажа в стой-
ку (для автомобилей, кораблей и самолетов). Хотя такие системы не оснащены
сложными терминальными системами, SCA может использоваться и в больших си-
стемах. В этом случае стоит уделить больше внимания архитектуре системы. Возмо-
жет вариант, когда SCA управляет базовым набором радиоаппаратуры и загрузкой
сигналов, управляясь командами от системы высшего уровня. Ключевым аспектом
является то, что SCA управляет аппаратным и программным обеспечением, кото-
рое используются для реализации и поддержки комплексного приложения.
Если говорить о применении CORBA в крупных системах, то она широко
используется во всех отраслях промышленности. Фактически, крупные, распре-
деленные приложения, основанные на Java и использующие удаленные вызовы
процедур CORBA и Java, используют протокол CORBA. В системе управления
спутниковой сети связи Iridium COTS-системы OS/COMET объединены ком-
плексной инфраструктурой CORBA. Конечная система запускалась на более чем
50 компьютерах и одновременно выполняла несколько сотен процессов.
1.2.3.8. SCA не годится для систем, работающих на частотах выше 2 ГГц
Обычно эта причина обосновывается тем, что разработанные в рамках программы
JTRS тактические радиостанции работали на частотах ниже 2 ГГц. Но специфи-
кация SCA не содержит каких-либо элементов, которые могли бы в явной или
скрытой форме ограничить способности SCA работать на частотах более 2 ГГц.
1.2.4. Цели применения SCA
Учитывая, что SCA не является технической архитектурой программируемой ра-
диосистемы, возникает вопрос о необходимости ее применения. Как было ска-
зано выше, частично это объясняется тем, что задачей SCA является достижение
коммерческой эффективности при снижении затрат на модернизацию, обновле-
ния и обслуживание. Это те преимущества, которые главным образом реализуют-
ся заказчиком или пользователем системы SCA. Таким образом, основной при-
чиной использования SCA является то, что этого требует проект. Для обеспечения
долговечности и достаточной приемлемости проекта разработчики должны иметь
обоснованные коммерческие причины ее использования.
Далее перечислены некоторые причины, которые необходимо учитывать при
рассмотрении вопроса об использовании архитектуры.
1.2.4.1. SCA обеспечивает общую инфраструктуру для развертывания
распределенного приложения
Хотя SCA была разработана для систем радиосвязи, базовую инфраструктуру для
размещения компонентов приложения можно использовать практически в любой
системе. Это касается тех элементов системы, которые имеют отношение к обработ-
ке радиосигналов, либо же это могут быть узлы, не имеющие отношения к радио —
например, процессорное управление устройствами и ПО на транспортном средстве.
1.2.4.2. SCA обеспечивает быструю интеграцию внешних приложений
Компактность пакета интерфейсов внутри SCA позволяет легко интегрировать
внешние приложения с помощью языка IDL, предназначенного для загрузки, пуска,
остановки и управления приложениями внутри системы SCA. В качестве примера
можно привести интеграцию системы SCA внутри сети систем. Общее управление
узлами радиосистемы часто осуществляется с помощью сетевого управления (network
management и network control). Такие системы управления часто используют
протокол администрирования сети (SNMP) или язык Java, которые имеют собствен-
ную поддержку CORBA. Таким образом, в случае, когда с помощью ПО управления
сетью требуется загрузить сигнал или коммуникационное ПО в SCA, то для этого
достаточно использовать запуск удаленных процедур Java (Java RPC). При использо-
вании протокола SNMP можно использовать прокси-сервер SNMP, который служит
интерфейсом SNMP в сетевой системе и обеспечивает Java RPC в SCA-радиосистеме.
1.2.4.3. SCA обеспечивает быстрое внедрение новых технологий
Поскольку SCA задает интерфейсы для развертывания, настройки, управления
и мониторинга аппаратного и программного обеспечения в SCA-системе, новые
технологии могут внедряться с меньшими затратами и без ухудшения рабочих па-
раметров. Например, часть описания приложения в SCA определяет программный
компонент, который, который выполняет некоторую функцию. В этом описании
могут присутствовать несколько различных программных реализаций (например,
одна для запуска на ЦСП, другая — для ЦП Intel с ОС WxWorks и т. д.). Таким обра-
зом, благодаря современным возможностям совместимости приложение, которое
можно было запускать только на ЦСП, теперь может работать и на универсальном
ЦП. (Однако это не значит, что для переноса элемента с одной системы на другую
не потребуется определенных усилий. Это лишь означает, что разработка, предна-
значенная для определенной системы, может быть размещена и сконфигурирована
на этой системе без перенастройки всего приложения.) Поскольку SCA позволя-
ет использовать многократные реализации приложений, новая реализация может
быть развернута на уже имеющейся системе, которая оснащена ЦП, но не имеет
ЦСП, при этом не требуется изменения остальных аппаратных компонентов. Та-
кая же концепция применяется и к новому оборудованию.
1.2.4.4. SCA обеспечивает инфраструктуру для расширения и интеграции
SCA является базой для проектирования и разработки комплексных радиосистем.
Она определяет пакет требуемых интерфейсов и алгоритмы, заложенные в ин-
фраструктуре и дает возможность проектировать и создавать приложения с улуч-
шенными рабочими параметрами и характеристиками. С системой SCA, обеспе-
чивающей высокоуровневое управление и контроль радиоресурсов, могут быть
интегрированы технологии типа когнитивного радио. Например, несколько SCA-
радиосистем, имеющих когнитивную карту их окружения и временной логики
могут согласовывать взаимную конфигурацию, повышая тем самым надежность
связи. Это может достигаться путем изменения параметров существующих сигна-
лов внутри системы, или загрузке новых сигналов, согласованных с остальными
радиосистемами.
1.2.4.5. SCA снижает объем единовременных затрат при проектировании
системы
Благодаря наличию единого пакета управляющих программ и инструментов, стан-
дартизация на единой инфраструктуре ПО снижает затраты, связанные с разработ-
кой систем в будущем. Это способствует оптимизации графика выполнения работ
и снижению затрат на модернизацию. Важно разработать стандартную инфраструк-
туру, которая применима для различных систем, поддерживающих SCA. Последний
пункт является основным в для организации принципов разработки систем и ис-
пользовании спецификации SCA.
Теперь, после рассмотрения «плюсов» и «минусов» использования SCA, мож-
но продолжить краткий обзор технических аспектов SCA. Остаток этой главы по-
священ вопросам операционной среды SCA и структуры ее спецификации, и ста-
нет основой для последующих глав.
1.3. Операционная среда
Архитектура программируемых средств связи JTRS определяет требования для
единой операционной среды программируемого радио. Операционная среда
включает в себя ядро SCA, брокер объектных запросов CORBA и операционную
систему. Операционная среда определяет интерфейсы, правила, ограничения
и процедуры, которые необходимо соблюдать для реализации SCA-совместимой
радиосистемы.
Ядро SCA обеспечивает:
• пакет общих служб, используемых сигналами и другими приложениями;
• ПО для установки, настройки, управления и контроля сигналов;
• интегрированную файловую систему для выполнения общих операций
с файлами, а также обеспечения доступа к множественным вычислитель-
ным платформам;
• интерфейсы устройств, которые обеспечивают общую абстракцию ком-
понентов аппаратного обеспечения.
На рис. 1.4, ядро SCA, представленное как уровень управления системой, изо-
бражено по вертикальной оси. Сигналы и компоненты, образующие уровень при-
ложений, представлены на горизонтальной оси.
1.3.1. Структурная организация
По своей структуре радиосистема SCA состоит из трех элементов: загрузка мо-
дели сигнала (Waveform Deployment), ядро (Core Framework) и профиль домена
(Domain Profi le). В свою очередь, каждый из трех указанных элементов можно
рассматривать как физический и логический элементы. С точки зрения загрузки
модели сигнала аппаратные средства являются физической структурой радиоси-
Красная аппаратная шина
Сетевые стеки и службы последовательного интерфейса
Операционная система
ORB и службы CORBA SCA СА Приложения и службы
Черная аппаратная шина
Сетевые стеки и последовательные службы интерфейса
Операционная система
ORB и службы CORBA SCA СА Приложения и службы
Черная шина CORBA (CF IDL) Красная шина CORBA (CF IDL)
Компонент
модема
Адаптер
Модема
Компоненты
системы
безопас-
ности
Адаптер
системы
безопас
ности
Адаптер
системы
безопас-
ности
Радио-
частота
Не-CORBA
компоненты
модема
Связь,
Сетевые
Компо-
ненты
Связь,
Сетевые
Компо-
ненты
Адаптер
ввода-
вывода
Компо-
ненты
ввода-
вывода
Не-CORBA
компоненты
ввода-вывода
Не-CORBA
компоненты
безопасности
Компоненты
ядра
Компо-
ненты
COTS
Название: Структура программного обеспечения SCA
Пакет: Модель компонента
Version: 2.2
Author: V. Kovarik
Маршрут передачи данных/обработки сигнала
Настройка и управление устройством
и приложениями формирования сигнала
Аппаратные
средства
Сигнал
Рис. 1.4. Структура компонента формы сигнала SCA
стемы. Но сигналы реализуются с помощью ПО, которое выполняется на физи-
ческих элементах.
Существуют два уровня логической структуры радиосистемы. Первый уровень
включает в себя пакет компонентов, которые образуют приложение, реализующее
сигнал или какую-либо другую службу в системе. Второй уровень — это приложение,
которое обеспечивает интерфейс высшего уровня и управление пакетом компонен-
тов.
Ядро SCA включает в себя все программные средства, необходимые для
управления радиосистемой и развертывания приложений. Его так же можно рас-
сматривать как физическую и логическую структуры. Физическая структура ядра
обеспечивает высокоуровневое управление физическими устройствами в радио-
системе. Логическая структура обеспечивает ту же функцию для приложений,
формирующих сигнал и других служб.
Профиль домена включает в себя XML-файлы, которые содержат описание
аппаратных средств радиосистемы, структуру приложения, формирующего сиг-
нал, взаимосвязи и зависимости программных компонентов и аппаратных ресур-
сов (рис. 1.5).
1.3.2. Ограничения интерфейса операционной среды
На рис. 1.6 показаны взаимосвязи между основными компонентами SCA-
совместимой системы. На нижнем уровне находятся службы, обеспечиваемые ОС
(которая формирует профиль среды приложения) как интерфейсы POSIX.
Дескриптор
конфигурации
устройства
Device Manager
Служба
имен
DAC-1
ADC-1
FPGA-1
GPP-1
B
C
A
B
Приложения
Компоненты
Аппаратное обеспечение радиосистемы
D
B
Канал связи-1
Телеметрия-1
Приложение
App Factory
канала связи
A
A
Менеджер
файлов
Ресурсы Менеджер домена
File
System
SCA Devices
Connections
Взаимосвязи
Компоненты
Размещение сигнала Ядро
XML профиля домена
Physical Logical
Физическая логика ??
Канал связи-2
Telemetry
Waveform
Сигнал
канала связи
Дескриптор
пакета ПО (SAD)
Дескриптор
менеджера устройства
Телеметрия
App Factory
Рис. 1.5. Уровни абстракции в системе SCA
Профиль среды приложения (Application Environment Profi le) пред-
назначен для обеспечения ограниченного набора строго определенных
системных вызовов, которые минимизируют влияние на код приложе-
ния. Это применимо лишь для ОС, работающей на ЦП, поскольку ЦСП
и ПЛИС не имеют операционной системы. Тем не менее, некоторые про-
цессоры ЦСП поддерживают ОС и CORBA. В этом случае для обеспече-
ния доступа к функциям операционной системы необходимо использо-
вать интерфейс POSIX. Все остальные компоненты (CORBA ORB, ядро
SCA, компоненты без использования CORBA и драйверы устройств) могут иметь
неограниченный доступ к операционной системе.
CORBA ORB обеспечивает единое связующее ПО для системы, и имеет не-
ограниченный доступ к базовой операционной системе. Ядро SCA — это реали-
зация спецификации SCA, определяющей необходимые компоненты и службы
радиосистемы. Компоненты и драйверы устройств, не совместимые с CORBA,
включают в себя низкоуровневые драйверы, подобные тем, которые поставляют-
ся производителем какого-либо устройства для различных ОС. Приложение со-
стоит из набора компонентов и ресурсов, которые формируют рабочий сигнал.
И наконец, ОС обеспечивает базовый набор зависящих от платформы служб.
Приложения CORBA ORB, ядро и драйверы устройств имеют неограничен-
ный доступ к системным вызовам и службам ОС. Но, как показано на рис. 1.6,
приложения имеют доступ только к набору системных вызовов POSIX. Это огра-
ничение введено потому, что, если приложение имеет ограниченный набор ин-
терфейсов, то оно легче переносится (портируется) на другие платформы. В свою
очередь, для обеспечения совместимости с SCA программная платформа радио-
системы должна поддерживать системные вызовы POSIX.
Несмотря на преимущества такого подхода, для обеспечения совместимо-
сти при портировании сигнала приходится устранять многочисленные проблемы
и ограничения POSIX. Это становится особенно ощутимо в том случае, если раз-
работанное сигнальное приложение использует в качестве одного из функциональ-
ных узлов цепи формирования сигнала ЦСП или ПЛИС.
1.4. Ñòðóêòóðà ñïåöèôèêàöèè SCA
Спецификация SCA состоит из трех основных частей:
• спецификация программируемых средств связи (JTRS-5000SCA),
• дополнения API (JTRS-5000API),
• дополнения по безопасности (JTRS-5000SEC).
Спецификация SCA является основой для разработки SCA-совместимых ра-
диосистем. Она определяет требования к операционной среде и основным функ-
циональным характеристикам. В данной книге основное внимание уделено со-
держанию спецификации SCA.
В дополнениях API (JTRS-5000API) содержатся инструкции и требования
по разработке модульных и портативных компонентов приложений. Некоторые
аспекты дополнений API рассмотрены в этой книге. Однако подробное рассмо-
трение дополнений API и вопросов создания портативных приложений потребует
описания значительно большего числа подробностей, чем позволяет объем дан-
ной книги.
Дополнение по безопасности определяет специальные требования к безопас-
ности и API, относящиеся к проектированию и построению защищенной радиоси-
стемы первого типа. Некоторые разделы книги посвящены системе безопасности,
поскольку то важно для понимания других разделов. Так же, как и для дополнений
API, подробности, связанных с вопросами защиты информации при создании SCA-
совместимых радиосистем, остаются за рамками данной книги.
Раздел 3 спецификации SCA описывает требования к определению архитектуры
базового программного обеспечения.
Организационная структура раздела 3 показана на рис. 1.7. В подразделе
Operating Environment (Операционная среда) рассматриваются службы и ядро
SCA. В разделе 3.2 содержится описание интерфейсов приложений и функцио-
Ресурсы приложения, Базовое приложение ядра
CORBA ORB Ядро SCA
(Интерфейсы
служб и
управления
ядра)
Не-CORBA
компоненты,
драйверы
устройств
и т. д.
Неограниченный доступ ОС
CORBA API
Ограниченный доступ SCA AEP
к ОС
Приложение использует
ядро для доступа к файлам
и службам
Logical device adapter
OS (function) that supports the SCA
Рис. 1.6. Ограничения интерфейса SCA
28 Глава 1. Введение
нальные требования. Раздел 3.3 определяет требования к интерфейсу устройства
SCA, а в разделе 3.4 перечислены общие требования.
Операционная среда (раздел 3.1 спецификации SCA) определяет требования,
которым должна удовлетворять SCA-совместимая система. Она содержит общие
компоненты ядра — менеджер домена (Domain Manager), службу регистрации
(Log Service), компоненты, необходимые CORBA и другие.
В разделе 3.2 определены требования, которым должны соответствовать при-
ложения SCA. Эти приложения позволяют полностью реализовать сигнал, поэто-
му раздел будет более всего интересен разработчикам сигнальных приложений.
Тем не менее, некоторые связанные с приложениями аспекты представлены как
компоненты ядра.
Управление устройствами радиосистемы и их настройка осуществляются че-
рез интерфейс логического устройства. Для того, чтобы успешно интегрировать
устройство в SCA-cистему, производитель устройств и/или системный интегратор
должен обеспечить реализацию этого интерфейса. Эти требования определены
в разделе 3.3. Содержимое разделов 3.1—3.3 и основные области функциональных
требований будут подробно описаны в последующих главах. Общие требования
к ПО (раздел 3.4) и другие нефункциональные требования будут описаны в этом
разделе.
На рис. 1.8. показано, как соотносится спецификация SCA и ее реализация.
Спецификация SCA обеспечивает интерфейс и характерные высокоуровневые
параметры, реализуемые ядром. Рисунок также иллюстрирует разработанные
группой OMG стандарты, которые рассмотрены в спецификации SCA.
Группа интерфейсов ядра и спецификации поведения (behavioral
specifi cations) находятся в пакете ядра. Профиль домена задает XML-
3 Определение
программируемой
архитектуры
3.1 Операционная
среда
3.2 Приложения 3.3 Логическое
устройство
3.4 Общие правила
программного
обеспечения
3.1 Операционная среда
+ 3.1 Операционная среда
+ 3.1.1 Операционная система
+ 3.1.2 Промежуточное ПО и службы
+ 3.1.3 Ядро SCA
+ 3.1.3.4 Профиль домена
+ 3.1.1 Операционная система
+ 3.1.2 Промежуточное ПО и службы
+ 3.1.3. Ядро SCA
3.2 Приложения
+ 3.2 Приложения
+ 3.2.1 Общие требования к приложению
+ 3.2.2 Интерфейсы приложения
3.3 Логическое устройство
+ 3.3 Логическое устройство
+ 3.3.1 Службы ОС
+ 3.3.2 Службы CORBA
+ 3.3.3 Интерфейсы ядра
+ 3.3.4 Профиль
3.4 Общее правило ПО
+ 3.4 Общие правила ПО
+ 3.4.1 Языки разработки ПО
+ 3.4.1.1 Новое ПО
+ 3.4.1.2 Устаревшее ПО
Рис. 1.7. Структура спецификации SCA
файлы, которые используются для описания основных компонентов ап-
паратного и программного обеспечения и взаимосвязей, необходимых
для загрузки сигнала.
Существует несколько толкований термина «профиль домена”. Не-
которые подразумевают под ним набор XML-файлов, по мнению дру-
гих — это обработанные структуры данных из этих файлов, третьи же
называют профилем домена внутренние структуры данных, которые со-
держат сведения о домене SCA-системы.
Рис. 1.8. Спецификация SCA в зависимости от реализации
Спецификации OMG
Спецификация SCA Реализация SCA
Профиль домена
+ Автор
+ Код
+ Дескриптор
+ Дескрипторы
+ Дескриптор конфигурации устройства
+ Дескриптор пакета устройств
+ Дескриптор конфигурации менеджера домена
+ Типы профиля домена
+ Карта ПЛИС
+ Реализация
+ Группа ОС
+ Дескриптор свойств
+ Файл свойств
+ Дескриптор компоновки программного обеспечения
+ Дескриптор программного компонента
+ Дескриптор программного пакета
CF_Impl
+ AppComponent
+ Мощность
+ Событие
+ Ввод/вывод
+ LogicalDevice
+ SDRт
+ Процессор
+ Радио
+ Ресурс
+ Служба
+ Приложение ПО
+ Компонент ПО
+ Сигнал
+ Приложение
+ Ядро
+ Компоненты
+ CORBA
+ Устройства
+ Файловая система
+ Реализация регистрации
+ Ресурсы
Служба регистрации
+ AdministrativeStateType
+ AdministrativeStateType
+ AvailabilityStatusType
+ AvailabilityStatusType
+ LogFullActionType
+ LogLevel
+ LogLevelType
+ LogRecordType
+ LogTimeType
+ OperationalStateType
+ OperationalStateType
+ ProducerLogRecordType
+ LogAdministrator
+ LogConsumer
+ LogProducer
+ LogStatus
StandardEvent
+ DomainManagementObjectAddedEventType
+ DomainManagementObjectRemovedEventType
+ SourceCategoryType
+ StateChangeCategoryType
+ StateChangeEventType
+ StateChangeType
PortTypes
Облегченная регистрация
Служба событый
Служба имен
Начиная с версии
SCA 2.2.1, служба
регистрации была
исключена из
спецификации
и использован
вариант
облегченной
регистрации OMG.
Ядро
+ AdminType
+ ComponentElementType
+ ComponentProcessIdType
+ DataType
+ DeviceAssignmentSequence
+ DeviceAssignmentType
+ DeviceSequence
+ ErrorNumberType
+ ErrorNumberType
+ FileException
+ FileInformationType
+ FileType
+ InvalideObjectReference
+ InvalidFileName
+ InvalidFileSystem
+ InvalidProfile
+ LoadType
+ MountPointAlreadyExists
+ MountSequence
+ MountType
+ NonExistentMount
+ OctetSequence
+ OperationalType
+ Properties
+ ServiceType
+ StringSequence
+ String Sequence
+ Unknown Properties
+ UsageType
+ AggregateDevice
+ Приложение
+ ApplicationFactory
+ Устройство
+ DeviceManager
+ DomainManager
+ ExecutableDevice
+ Файл
+ FileManager
+ FileSystem
+ LifeCycle
+ LoadableDevice
+ SDRт
+ Поставщик SDRта
+ Набор параметров
+ Ресурс
+ ResourceFactory
+ TestableObject
+ UnknownProperties
Исполь-
зует
«реализует»
«реализует»
«realize»
Использует
Использует
Ис-
поль-
зует
Ис-
поль-
зует
Авторы данной книги придерживаются точки зрения, что XML-файлы пред-
ставляют собой удобочитаемую версию профиля домена, а внутренние структуры
данных, созданные как часть обработки XML-профиля, формируют внутренний
профиль домена, используемый ядром SCA в процессе создания сигнала. Иерар-
хическая древовидная структура, сгенерированная синтаксическим анализатором
(парсером) рассматривается как промежуточная структура данных, которая пре-
образует текстовые XML-файлы в каноническую форму, позволяющую быстрое
извлечение из них необходимой для загрузки сигнала информации. Несомненно,
можно пропускать обработку структуры XML-файла и непосредственно исполь-
зовать его как представление внутреннего профиля домена. Но такая форма пред-
ставления данных будет неэффективна при использовании строгих ограничений
(constraint enforcement), которые используются компонентом ядра SCA ApplicationFactory
при создании экземпляров приложения.
Все вышеперечисленные абстракции базируются на единых службах, которые
обеспечивают важнейшие функции для всех компонентов SCA:
Служба имен (Name service) — позволяет компоненту радиосистемы найти требу-
емую службу или приложение и подключиться к нему.
Служба событий (Event service) — обеспечивает асинхронный механизм для
трансляции компонентами событий в канал событий и регистрацию компонентов
для получения этих событий.
Служба регистрации (Log service) — обеспечивает базовую функцию регистра-
ции внутри радиосистемы SCA, которая позволяет компонентам создавать запи-
си, описывающие какие-либо действия или состояния, снабженные временными
метками и сохранять их в файле с возможностью последующего извлечения.
Файловая служба (File service) — возможно, это одна из важнейших служб, ко-
торая обеспечивает единую абстракцию файловой системы для всех компонентов
SCA-системы, независимо от фактической реализации ОС и файловой системы.
Первая глава книги организована в соответствии с описанными выше высо-
коуровневыми абстракциями. Во второй главе рассматриваются общие службы
фреймворка, обеспечивающие основу для компонентов и ссылок, используемых
в описании остальных логических интерфейсов. После описания общих служб
в последующих главах рассматриваются описанные выше логические абстракции,
начиная с менеджера ресурсов и заканчивая менеджером домена.
1.5. Выводы
Спецификация SCA обеспечивает независимую от реализации инфраструктуру
для реализации и развертывания приложений. Общие требования SCA опреде-
ляют набор аппаратных и программных требований, которым должна соответ-
ствовать система. В следующей главе представлен концептуальный обзор работы
SCA-совместимой системы, использующий модельный принцип прецедентов,
или сценариев использования (Use сase) унифицированного языка моделирова-
ния UML.
ГЛАВА 2
Сценарий использования
Функционирование системы удобно описывать с помощью прецедентов (сцена-
риев использования), которые описывают общее поведение системы при взаимо-
действии с пользователем либо с внешней средой. В этом разделе описываются
различные прецеденты SDR. Они предназначены для подробного анализа рабо-
чих параметров абстрактной SCA-совместимой радиосистемы. Детальное описа-
ние какой-либо конкретной радиосистемы требует более широкого набора опера-
ционных сценариев и прецедентов.
На рис. 2.1 показаны субъекты, имеющие отношение к радиосистеме, и раз-
ичные действия, которые они выполняют. Конечный пользователь радиосисте-
мы — это обычный оператор радиостанции. Он по сути работает с радиосистемой
на базовом уровне оборудования, например, включает и выключает питание или
инициализирует систему. На более абстрактном уровне пользователь взаимодей-
ствует с радиосистемой, управляя сигнальными приложениями. На этом уровне
начинает проявляться уникальность программно-определяемого радио. Пользо-
ватель может конфигурировать систему для загрузки и запуска сигнала в дина-
мическом режиме, то есть, радиостанция по требованию может быть (пере)на-
строена для выполнения компонентов, поддерживающих различные сигнальные
приложения.
Настройку интеграцию тестирование радиосистемы и установку сигнальных
приложений выполняет радиоинженер.
В следующих параграфах представлен качественный анализ необходимых
действий, рассмотренных в каждом из показанном на рис. 2.1 прецеденте. Цель
этого подхода — обеспечить единую модель поведения и взаимоотношений для
ключевых функций SCA-совместимой радиосистемы и показать все необходимые
шаги и режимы работы. Так как мы занимаемся исследованием конкретных по-
веденческих факторов компонентов ядра SCA, этот же подход будет применен и в
следующих главах. Необходимо отметить, что диаграммы, представленные в сле-
дующих разделах, в общем виде иллюстрируют взаимодействия между процесса-
ми и не являются точным отображением UML-модели этих взаимодействий.
2.1. Запуск системы
Прецедент «Пуск» (Startup) выполняется при переводе радиосистемы из выклю-
ченного состояния во включенное, когда выполняется включение и инициализа-
ция всех аппаратных компонентов системы и загрузка и инициализация ядра SCA.
Рис. 2.2 показывает основные связи между прецедентами, образующими стар-
товую последовательность.
Установка приложения
+ Установить приложение
+ Загрузить профиль домена
+ Удалить приложение
+ Выгрузить профиль домена
Запуск радиостанции
+ Запустить устройство
+ Запустить менеджер устройства
+ Запустить менеджер домена
+ Запустить канал событий
+ Запустить файловую систему
+ Запустить регистрацию
Пользователь радио
Радиоинженер
Инстанцировать сигнал
+ Выделить память
+ Конфигурировать
+ Создать приложение
Отключение радиостанции
+ Отключить устройство
+ Отключить менеджер устройства
+ Отключить менеджер домена
+ Отключить канал событий
+ Отключить файловую систему
+ Отключить регистрацию
Управление сигналом
+ Освободить память
+ Выполнить запрос
+ Выгрузить приложение
+ Запустить приложение
+ Остановить приложение
Конфигурация системы
+ Создать профиль домена
+ Подтвердить профиль
домена
Система безопасности
+ Ввод ключа управления
Менеджер
безопасности
Маршрут Маршрут
Маршрут Маршрут
Маршрут Маршрут
Маршрут
Рис. 2.1. Функции и действия пользователей радиосистемы
Прецедент «Start Device Manager» (запустить менеджер устройств) описывает
запуск устройства, которое обычно называют «узел» (node). Здесь этот термин ис-
пользуется для обозначения аппаратного компонента (например, плата с интер-
фейсом VME или Compact PCI), который включает в себя одно или несколько
физических устройств, выполняющих какие-либо необходимые для реализации
SCA-совместимой радиосистемы вычисления. Как правило, в качестве исходно-
го или загрузочного узла используется одноплатный компьютер (SBC) или иное
устройство с центральным процессором и операционной системой.
Основным условием запуска системы SCA является наличие загрузочного
устройства и его менеджера (Device manager), который управляет запуском и ини-
циализацией ядра SCA и связанных с ней компонетов. Начав работу, менеджер
устройств запускает ряд служб и приложений (рис. 2.3), начиная с инициализа-
ции файловой системы (File system). Файловая система выделяет для менеджера
устройств и связанных с ним компонентов некоторый объем памяти. Затем ме-
неджер устройств запускает службу регистрации (Log Service), которая дает воз-
можность записывать системные сообщения, предупреждения и неисправности
всех аппаратных и программных компонентов системы SCA. Далее, менеджер
устройств запускает менеджер домена (Domain manager), который служит основ-
ным хранилищем (репозиторием) и пунктом управления системой. После этого
менеджер устройств запускает все связанные с ним компоненты.
Пользователь
радиосистемы
Запуск
менеджера
устройств
Запуск
менеджера
домена
Запуск
файла
регистрации
Запуск
файловой
системы
Запуск
устройства
Запуск
канала
событий
«включение»
0..
1
«включение»
0..1
1
«расширение»
1..
«расширение»
0..1
«расширение»
0..
«включение»
Рис. 2.2. Запуск радиосистемы
Рассмотренный выше принцип стал использоваться лишь в текущей версии
SCA. При текущем подходе невозможно гарантировать то, что компонент, в слу-
чае его инициализацией клиентом, будет полностью инициализирован и готов
к приему поступающих запросов CORBA. Например, менеджер устройств на за-
грузочном устройстве может запускать менеджер домена, но при попытке реги-
страции последний может не загрузиться полностью и не инициализироваться.
Таким образом, только при наличии в компонентах ядра SCA встроенного меха-
низма автоматического перезапуска они, скорее всего, будут запущены без сбоев.
После включения питания загрузочный узел задействует загрузочное ПЗУ
(Boot ROM), которое запускает необходимые начальные процедуры и инициали-
Запуск системы
Пользователь
радио
Запустить
менеджер
устройства
Запустить
файловую
систему
Запустить
файл
регистрации
Запустить
менеджер
домена
Запустить
устройство
Архитектура SCA 2.2
обеспечивает запуск
Менеджера домена,
который рассматри-
вается как часть пуска
Менеджера устройств
загрузочного узла.
PowerOn
(включение питания)
Загрузочное ПЗУ
Загрузить ОС
Обработать
Инстанцировать
Инициализировать
[Если задано в XML]:* Инстанцировать
Инициализировать
[Для каждого устройства]:* Обработать
Инициализировать
Журнал
регистрации
Список
устройств
[Для каждого устройства]:*
Получить данные об устройстве
Запустить другие менеджеры устройств
Готовность
системы
Запустить службу имен
Загрузить менеджер устройств
Запустить менеджер устройств
Рис. 2.3. Последовательность операций при запуске радиосистемы
зирует оборудование. После этого запускается операционная система. Она обе-
спечивает основные службы и функции для загрузки и управления базовыми про-
граммными компонентами SCA.
После того, как загрузилась ОС, система готова для загрузки компонентов
ядра SCA. Первый элемент, который необходимо загрузить — это служба имен
CORBA, которая позволяет приложениям определять местоположение доступ-
ных служб и других приложений. Этой службой регистрируются компоненты ядра
SCA, таким образом, она должна быть доступна до инициализации этих компо-
нентов.
На данном этапе выполняется загрузка программной реализации менедже-
ра устройств. После инициализации, он в первую очередь должен считать де-
скриптор конфигурации устройства (DCD), связанного с менеджером устройств.
DCD — это XML-файл, содержащий информацию о конфигурации и параметры
для запуска устройства. Синтаксическая структура дескриптора DCD и XML-
файлов рассматривается во второй части книги, некоторые примеры приведены
в третьей.
Считанный и обработанный менеджером устройств DCD определяет допол-
нительные программные компоненты и устройства, которые должны быть запу-
щены в процессе общей инициализации менеджера устройств. Как правило, одна
из первых задач, выполняемая менеджером устройств — это инициализация фай-
ловой системы (ФС). ФС SCA — это абстрактное, основанное на CORBA пред-
ставление некой конкретной ФС, реализованной на базовом аппаратном обе-
спечении и операционной системе. Обычно менеджер устройств инициализирует
лишь одну ФС, но, в зависимости от типа конфигурации аппаратного обеспе-
чения и операционной системы, а также характеристик базового оборудования,
ассоциированного с менеджером устройств, могут быть инициализированы не-
сколько ФС (или же инициализация ФС не производится вообще).
Следующий инициализируемый компонент — это канал событий (Event Channel),
обеспечивающий механизм асинхронных уведомлений, благодаря которому
компоненты могут публиковать сообщения об изменении своего статуса и других
событиях. Компоненты, которым необходимо считывать определенные сообще-
ния, должны лишь подписаться на соответствующий канал. Функциональные ха-
рактеристики канала событий в SCA перечислены в документе OMG Document
formal/01-03-01: Event Service, v.1.1.
После создания канала событий менеджер устройств запускает службу ре-
гистрации. До появления версии 2.2 SCA служба регистрации была определена
как часть спецификации SCA. Начиная с версии SCA 2.2.1, в архитектуре SCA
указывается спецификация упрощенной регистрации OMG. Обе службы анало-
гичны по функциональности и используют одинаковый интерфейс IDL. Служба
регистрации обеспечивает кратковременный, находящийся в ОЗУ файл данных,
которая может быть доступен любому компоненту SCA. Файл данных постоянно
использует буферную память.
После запуска службы регистрации, если это указано в XML-файле DCD, ме-
неджер устройств запускает менеджер домена. Последний обеспечивает храни-
лище верхнего уровня для всех устройств и программных компонентов, которые
входят в домен радиосистемы, и управляет ими.
На этом этапе менеджер устройств запускает и инициализирует все устрой-
ства, указанные в XML-файле DCD. После этого менеджер устройств регистри-
рует через менеджер домена каждое запущенное устройство. Для всех зареги-
стрированных устройств менеджер домена запрашивает параметры устройства
и информацию о его конфигурации.
Наконец, если это необходимо для старта системы, менеджер устройств за-
грузочного узла может запустить дополнительные менеджеры устройств. Каждый
последующий запуск менеджера устройств осуществляется по той же по схеме,
что и запуск менеджера устройств загрузочного узла. Однако, далее уже не нужно
запускать менеджер домена или канал событий, поскольку для работы системы
требуется лишь однократный запуск этих компонентов. Необходимость же ини-
циализации ФС и службы регистрации зависит от ресурсов и требований к радио-
системе.
2.2. Завершение работы
Весьма интересен тот факт, что процесс отключения радиосистемы не описан под-
робно в спецификации SCA. Рассуждая логически, можно предположить (как по-
казано на рис. 2.4), что менеджер домена осуществляет управление всей радиоси-
стемой и именно он выдает команду отключения радиостанции. Это итеративная
операция, во время которой зарегистрированные менеджером домена менеджеры
устройств получают от него команду на отключение (рис. 2.5). В свою очередь,
каждый менеджер устройств отправляет всем связанным с ним устройствам ко-
манду завершения их работы. После этого менеджер устройств останавливает свя-
занную с ним файловую систему и службу регистрации, если таковая запущена.
Завершив все указанные действия, менеджер устройств прекращает свою рабо-
ту. Следует иметь в виду, что после остановки менеджера устройств и связанных
с ним компонентов получить ответный сигнал от устройств невозможно, так как
они перестают существовать в системе.
Как только все менеджеры устройств получает команду об отключении, ме-
неджер домена завершает работу. Но, так как в процессе отключения устройств
они могут посылать уведомления об ошибках или иных событиях, менеджер до-
мена должен ждать некоторое время для того, чтобы проконтролировать отключе-
ние всех устройств, и только после этого закончить свою работу.
Поскольку один из менеджеров устройств работает как загрузочный узел,
и обычно он же запускает менеджер домена, он может использовать интерфейс-
ные запросы к ОС на аппаратное отключение или перезагрузку. Независимо
от того, реализовано это или нет, менеджер устройств для процессора, на котором
запущен менеджер домена, должен ждать до тех пор, пока менеджер домена пре-
кратит работу. После того, как это произойдет, менеджер устройств выполняет
собственную процедуру отключения. Таким образом, когда менеджер устройств
получает запрос от менеджера домена на отключение, он откладывает процесс
фактического отключения до тех пор, пока менеджер домена и прочие процессы
SCA не завершат процедуры своего отключения. Только тогда менеджер устройств
завершает свою работу и/или обращается к ОС с запросом на перегрузку или пе-
резапуск.
2.3. Установка / удаление приложения
Установка приложения в SCA-совместимой радиосистеме считываются
XML-файлы, описывающие необходимые для размещения сигнала в системе ап-
паратные и программные компоненты,. Ключевой момент здесь — то, что сиг-
нальное ПО не загружается в оборудование. На этом этапе требуется лишь список
ud Отключение радиостанции
Пользователь
радиосистемы
Отключить
устройство
Отключить
Менеджер
устройств
Отключить
файловую
систему
Отключить
файл
регистрации
Заверщить
Менеджер
домена
Завершить
канал событий
«расширение»
«использование»
1..
0..1
«расширение»
0..
«расширение»
1..
«расширение»
Рис. 2.4. Отключение радиосистемы
39
устройств, на которые загружаются программные компоненты, и связей, объеди-
няющие их в функциональное приложение.
Результат установки приложения — загрузка файла дескриптора компоновки
программного обеспечения (Software Assembly Descriptor — SAD). Файл дескрип-
тора SAD — это высокоуровневый XML-файл, который определяет компоненты,
схемы соединений, а также ограничения для заданного сигнального приложения.
Термин «профиль домена» иногда используется для обозначения и XML-
файлов, и внутренних структур данных, представляющих содержание XML-
файлов в удобной для использования компонентами ядра форме. Хотя в спец-
ификации SCA под профилем домена подразумевается именно XML-файлы,
обрабатывать их при каждой загрузке сигнала затратно с точки зрения вычисли-
тельных ресурсов.
Большинство реализаций ядра SCA преобразуют информацию в легкий для
обработки «машинный» формат. Это может быть XML-дерево или объектная мо-
Отключение системы
Пользователь
радиосистемы
Завершить
менеджер
домена
Завершить
менеджер
устройств
Завершить
файловую
систему
Отключить
устройство
Завершить
файл
регистрации
В зависимости от архитектуры
реализация устройства может быть
запущена как поток внутри процесса
менеджера устройств.
Таким образом, прекращение работы
приводит к прекращению потока.
Реализация устройства для
универсального ЦП, на котором
запущен менеджер устройств,
может далее инициировать
перезагрузку, перезапуск или
отключение основного
устройства, связанного
с менеджером устройств.
Отключение
[Для каждого Менеджера устройств]: Отключить
[Для каждого устройства]: Отключить
Прекратить
работу
Отключить
Прекратить
работу
Отключить
Завершение
работы
выполнено
Отключение
системы
Прекратить работу
Прекратить
работу
Перезагрузить/
Перезапустить
Завершение процесса
Рис. 2.5. Последовательность отключения компонентов радиосистемы
дель документов (DOM), созданная парсером XML. Однако при обработке парсе-
ром XML-дерева теряются семантические связи между компонентами профиля.
Это приводит к необходимости обхода вершин дерева при создании экземпляра
(инстанциации) приложения.
В результате некоторые реализации ядра SCA создают внутренний набор
структур данных, которые обеспечивает более эффективное представление для
восстановления и обновления при создании и уничтожении экземпляра прило-
жения.
При удалении приложения соответствующая информация профиля домена
так же удаляется. (В спецификации SCA изначально было указано, что XML-
файлы с информацией профиля домена также должны быть удалены из файловой
системы. Однако в версии SCA 2.2.1 эти XML-файлы сохраняются.)
Такое требование создает проблему для тех ядер SCA, которые используют
внутренние структуры данных для представления проанализированного и уста-
новленного сигнального приложения, так как удаление приложения подразуме-
вает простое физическое удаление внутренних структур данных, представляющих
профиль сигнала.
Кроме этого, удаление файлов вызывает проблемы с операционной системой
в случае, если конечный пользователь обеспечивает возможность деинсталляции
приложения. Внутренние структуры данных не удаляются, т. к. в противном слу-
чае обработка радиосигнала была бы невозможна до повторной загрузки XML-
файлов (т. е. до повторной инсталляции приложения формы сигнала). Другими
словами, это привело бы к удалению исходных XML-файлов, описывающих про-
филь.
Некоторые реализации SCA позволяют указывать, удалять ли физически
XML-файлы, связанные с сигналом, или это относится лишь к внутренним струк-
турам данных. Это дает возможность деинсталлировать приложение, освободив
тем самым внутренние ресурсы и память для других приложений, в то же время
давая возможность при необходимости переустановить сигнал.
При установке сигнального приложения выполняется считывание и обра-
ботка (парсинг) набора XML-файлов, задающих структуру сигнала. Прецедент
«Установка приложения» (рис. 2.6) создает базовые внутренние структуры дан-
ных, определяющих необходимые для загрузки сигнального приложения компо-
ненты и аппаратные средства. «Загрузка профиля домена» обеспечивает нужную
для создания внутренней модели профиля сигнала информацию, извлеченную
из XML-файлов.
Прецедент «Проверка профиля домена» выполняет анализ обработанных
XML-файлов в зависимости от определения типа документа (Document Type Defi -
nition, DTD), указанного в спецификации SCA. Последовательность процедур
по установке/удалению приложения показана на рис. 2.7.
Деинсталляция приложения влечет за собой удаление из системы всех вну-
тренних структур данных с информацией о профиле сигнала и, возможно, файлов
XML, которые образуют профиль. Нужно отметить, что, хотя удаление файлов
XML заявлено как обязательная функция, смысла в этом нет, так как для пере-
установки приложения требуется повторная загрузка XML-файлов в систему.
Кроме этого (как показано на рис. 2.6), деинсталляция сигнального приложе-
ния не влияет на создание экземпляра сигнала. Хотя на первый взгляд концепция
создания экземпляра деинсталлированного сигнального приложения выглядит
противоречивой, она не лишена здравого смысла. После создания экземпляра
сигнала приложению больше не требуется информация о профиле — так как ин-
формация о профиле использовалась в процессе создания. В результате все не-
обходимые компоненты уже загружены, а ресурсы распределены. Поэтому соз-
данный экземпляр сигнала можно запускать, останавливать, конфигурировать
и выполнять с ним любые другие действия, допустимые для созданного экзем-
пляра приложения и не требующие доступа к информации профиля.
ud App Install
Установить
приложение
Удалить
приложение
Радио-
инженер
Загрузка
профиля
домена
Проверка
профиля
домена
Выгрузка
профиля
домена
«расширение»
«расширение»
«включение»
Рис. 2.6. Установка/удаление приложения
Это позволяет создавать экземпляры сигнала, а затем их удалять, освобождая
оперативную память и другие ресурсы, что может быть полезным, например, при
установке другого сигнального приложения. Но если сигнал деинсталлирован
(даже если созданные экземпляры приложения продолжают работать, не имею
доступа к информации профиля), то выполнить создание новых экземпляров сиг-
нала невозможно до тех пор, пока не сигнал не будет заново установлен, обеспе-
чив необходимую информацию профиля.
Аналогичным образом, если радиостанция отключилась, при включении си-
стемы менеджер домена переустанавливает все сигнальные приложения, которые
были установлены на момент отключения. Если же сигнал был удален (даже если
перед отключением его реализация была запущена), то менеджер домена не смо-
жет его переустановить.
На современном этапе развития общества особое внимание уделяется развитию
систем связи и управления, функционирующих в едином информационном про-
странстве Российской Федерации.
Определяющей технологией, на базе которой планируется создавать такие
системы, является программно-конфигурируемое радио (Software Defi ned Radio —
SDR). Все его настройки и параметры задаются программно. Конфигурация SDR
определяется с помощью программного обеспечения. Для этой цели использу-
ются либо процессоры цифровой обработки DSP, либо матрицы FPGA (Field-
Programmable Gate Array — программируемая пользователем вентильная матрица,
одна из типов ПЛИС — программируемых логических интегральных схем).
Имеется международный опыт разработки программно-конфигурируемого
радио для тактического звена. Так, в США создана JTRS (Joint Tactical Radio System)
— военная система для связи в американской армии. Изначально JTRS была
предназначена для замены 25—30 различных типов военных систем связи (неко-
торые из них не могли связываться между собой) на одну программную радио-
систему, которая могла бы работать во всех диапазонах частот. Помимо военных
(WNW-BEAM, OFDM, AJ, LPI и др.) система JTRS должна поддерживать сотовую
связь различных стандартов (GSM, CDMA), а также транкинговую связь стандар-
тов TETRA и TETRAPOL.
Концепция американской программы JTRS использовалась для разработки
двух европейских программ: ESSOR и SVFuA.
ESSOR (European Secure Software Radio Program) создается усилиями шести
стран (Финляндия, Франция, Италия, Польша, Испания, Швеция) и базируется
на открытом стандарте SCA (Software Communication Architecture — архитектура
программной связи).
SVFuA является немецкой национальной программой и предназначена для
применения Бундесвером (Федеральными вооруженными силами Германии).
Наличие разработанной в JTRS архитектуры SCA позволило европейским
странам ускорить и удешевить программы ESSOR и SVFuA. Поэтому мы надеем-
ся, что перевод книги, посвященный SCA, позволит и отечественным разработчи-
кам за короткие сроки и с меньшими затратами реализовать проекты, аналогич-
ные JTRS, ESSOR и SVFuA.
Книга в первую очередь адресована специалистам по разработке систем ради-
освязи двойного назначения. Для работы с книгой требуется базовая подготовка
в области радиотехники и прикладного программирования. По причине отсут-
ствия устоявшейся русскоязычной терминологии большинство сокращений дано
на английском языке. Их список с русским переводом выделен в отдельное при-
ложение.
Радько Н.М.
Часть I
ОПЕРАЦИОННАЯ СРЕДА
В первой части книги приводится спецификация архитектуры программно опре-
деляемых средств связи (SCA, software communications architecture). Цель этой ча-
сти — дать общую информацию по SCA с пояснениями относительно толкования
и функциональных требований к ней. Эта часть книги может использоваться как
отдельный справочник по SCA.
ГЛАВА 1
ВВЕДЕНИЕ
Фундаментальной задачей SCA является обеспечение общей инфраструктуры
программного обеспечения (ПО) для управления радиосистемами. Несмотря
на то, что ПО является ключевым компонентом современных радиосистем, бла-
годаря которому они получают новые функции и возможности, каждый произво-
дитель радиосистем использует собственную архитектуру и/или инфраструктуру
системы, поэтому для загрузки и управления ПО используются особые, уникаль-
ные для каждого производителя механизмы. Как было сказано выше, программ-
но-определяемое радио относится к классу радиосистем, характеристики которых
не просто обусловлены программным обеспечением, но используют инфраструк-
туру, в которой взаимозаменяемы и компоненты, и функции.
В этой главе содержится основная информация об SCA. В спецификации SCA
описываются компоненты архитектуры, их структура и объединение их в систе-
му, формирующую радиосигнал. Все эти элементы образуют инфраструктуру для
создания программно-определяемой радиосистемы (Software defi ned radio, SDR).
1.1. Программируемые радиосистемы
Радиосистему можно представить в абстрактном виде, рассматривая форму сиг-
нала и используемый диапазон частот (см. рис. 1.1). Низший уровень схемы за-
нимает комплекс аппаратных средств, который обеспечивает работу ПО, форми-
рующего сигнал и выполняющего вспомогательные задачи. Обработка данных
может осуществляться одним из четырех устройств: универсальным центральным
процессором (ЦП), цифровым сигнальным процессором (ЦСП), программируе-
мой логической схемой (ПЛИС) или специализированной большой интеграль-
ной схемой (СБИС). Строго говоря, такую БИС нельзя использовать как основу
программируемой радиосистемы, так как конфигурация этой микросхемы зада-
ется при изготовлении и не может быть изменена (перепрограммирована) в про-
цессе работы, что нарушает один из фундаментальных принципов SDR. Однако,
по мнению авторов, БИС можно применять в SDR, при условии, что она обеспе-
чивает возможность гибкой взаимозаменяемости функциональных компонентов
обработки сигналов внутри микросхемы. Например, вызов какого-либо алгорит-
ма внутри БИС должен осуществляться аналогично вызову программных функ-
ций.
Рис. 1.1 демонстрирует две ортогональные проекции процесса разработки
SDR. Создание сигнала начинается с разработки комплекса требований, имита-
ционной или математической модели или другого концептуального представле-
ния сигнала. По мере разработки формы сигнала параметры его реализации (про-
пускная способность и мощность) обычно задаются на языке высокого уровня
и для их выполнения на ЦП или ЦСП. Для повышения пропускной способности
системы необходимо использовать ПЛИС или СБИС.
ЦП, как правило, применяется для управления всей системой. Находящие-
ся выше процессора ОС с пакетом ПО служат основой динамической структуры
радиосистемы. В терминах SCA эта структура называется ядром SCA (SCA Core
Framework). Над ней на рисунке находятся приложения, формирующие сигнал
и выполняющие прочие задачи.
1.1.1. Аспекты программируемых радиосистем
Систему SDR можно рассматривать с четырех аспектов, каждый из которых об-
разует функциональную группу объектов и служб в радиосистеме (рис. 1.2):
Radio System
Спецификация сигнала
Модель Требования Моделирование
Waveform Implementation
C/C++ RTL/VHDL
Digital Subsystem
GPP FPGA ASIC
Диапазон частот
Абстракция формы сигнала
Аналоговая
подсистема
Цифровая передача данных
Усилители
Преобразователи
Радиочастотный
Сигнал
Операционная
Система
CF
DSP
Аналого-
цифровой
Цифро-
аналоговый
Рис. 1.1. Абстрактное представление системы радиосвязи
• Аппаратные средства — физическая структура радиокомплекса, т. е. сово-
купность входящих в нее устройств.
• Программное обеспечение — службы и интерфейсы, которые согласуют
с основными аппаратными средствами все сигнальные приложения.
• Приложения — к этому аспекту относятся приложения для создания фор-
мы сигнала и службы, которые предоставляет радиосистема.
• Пользователь — взаимодействует с радиокомплексом. Существуют два ос-
новных режима взаимодействия: пользователь либо контролирует систему
в целом (например, задает параметры системы), либо управляет работой
приложений и передачей данных (например, определяет коэффициент
усиления в момент передачи).
SCA можно рассматривать как реализацию аспекта ПО с некоторыми эле-
ментами аспекта приложений. Она определяет логическую инфраструктуру и аб-
страктное представление аппаратных средств и компонентов ПО цифровой об-
работки, входящих в формирующее сигнал приложение. SCA также характеризует
функции системы и интерфейсы управления, загрузки и конфигурирования при-
ложений, формирующих сигнал, внутри системы.
Аспекты программируемого радио cd
Физический элемент
Приложение ПО
AppComponent LogicalDevice Event
Компонент ПО
Сигнал Служба
Порт
Свойство
Radio
Приложение и Службы
Инфраструктура
программного
обеспечения
Аппаратные средства
Пользователь
радиосистемы
Мощность
Пользователь
Resource
Processor RF Antenna
GPP DSP FPGA
Устройство
ввода-вывода
NIC AD-DA
«реализует»
зависимая величина
1..
1..
1
выдает
0..
контро-
лирует
управ-
ляет
0..
«реализует»
0..*
подключается
через
«реализует»
«реализует»
зависимая величина
1
обеспечивает интерфейс
1
требуется
1
выделена
1..
зависимая величина
Рис. 1.2. Аспекты программируемого радио
1.2. Архитектура прграмируемых средств связи Любая новая концепция или технология требует времени и определенных знаний
для ее освоения, и концепция SCA — не исключение. Она определяет инфраструк-
туру ПО для управления SDR. Она не подчинена какой-либо особой структуре или
реализации аппаратных средств и приложений. Перед детальным рассмотрением
SCA рекомендуется ознакомиться с тем, что есть и чем не является SCA, историей
ее развития, и причинами, побуждающими ее использовать или отказаться от нее.
SCA основана на нескольких взаимосвязанных технологиях: объектно-ори-
ентированные (ОО) методы создания ПО, общая архитектура брокера объектных
запросов (common object request broker architecture — CORBA), и модель компо-
нентов CORBA (CORBA components model — CCM).
Объектно-ориентированные языки используются в течение нескольких деся-
тилетий, начиная с языка Simula, появившегося в конце 1960-х годов, Smalltalk
и Flavors — в начале 1980-х и завершая современными ОО-языками — C++,
Python, Ruby и Java. По мере совершенствования систем с распределенной ар-
хитектурой и структурой клиент-сервер CORBA стала промышленным стандар-
том для описания интерфейсов на псевдoкоде, т. е. языке описания интерфейсов
(interface defi nition language — IDL). IDL обеспечивает средства для указания до-
ступных интерфейсов и, при помощи «компилятора» IDL, генерирует исходный
код, который компилируется для каждого приложения. Сгенерированный код
содержит служебные алгоритмы, необходимые для поддержки удаленных вызо-
вов процедур между процессами на одном и том же компьютере и между разными
компьютерами, т. е. в распределенной среде. Таким образом, программист был
избавлен от рутиной работы по созданию кода межпроцессорной связи низкого
уровня, и, что более важно, код CORBA, созданный одним лицом, был совме-
стим с кодом, созданным другим лицом, при единственном условии, что оба авто-
ра клиентского и серверного приложения использовали один и тот же язык IDL.
Вместе с выделением внутренней логики в самостоятельный элемент (инкапсу-
ляцией) это было важным шагом в направлении совершенствования модульно-
го программного обеспечения: единственным требованием стало использование
единого языка IDL разработчиками и клиентского, и серверного приложений.
Несмотря на то, что технология CORBA имела ряд важных преимуществ,
стало очевидным, что механизм развертывания системы все еще требовал руч-
ной настройки параметров конфигурации. При загрузке ПО необходимо явно
указать требования для его установки, то есть какие ресурсы требуются для этих
приложений. Для описания компонентов системы и сопутствующих требований
по установке используются XML-файлы. XML (eXtensible Markup Language) — это
текстовый язык, использующий ключевые слова (теги) для определения элемен-
тов данных, их атрибутов и значений. На языке XML CCM основан язык XML
профиля домена SCA (Domain profi le XML).
1.2.1. Развитие архитектуры программируемых средств связи
Во время проведения военных операций военное ведомство США столкнулось
с острой необходимостью обеспечить надежную связь с высоким уровнем совме-
стимости и малыми затратами. Большое количество радиосистем было основа-
но на аппаратной платформе, с ограниченными возможностями по формирова-
нию сигналов, и это стало одним из главных препятствий на пути создания SCA.
Кроме того, было невозможно обновлять существующие или добавлять новые
сигналы без значительных затрат на модернизацию аппаратных средств. Вместе
с тем, за последние двадцать лет значительно повысилась мощность процессоров,
и стали общедоступными специальные процессоры ЦСП и ПЛИС, также непре-
рывно повышались производительность и разрешающая способность аналого-
во-цифровых и цифрово-аналоговых систем. Как результат, для обработки боль-
шинства сигналов вместо аналоговых систем стали использоваться цифровые,
реализованные программно. Ранние эксперименты в области SDR (например,
система SpeakEasy) показали, что программно-реализованная архитектура име-
ет значительные преимущества. Многие производители радиосистем уже начали
работы по реализации программных компонентов обработки базового сигнала.
Первые многоканальные радиосистемы, разработанные в 1990-х годах — боевой
информационный терминал (Joint Combat Information Terminal, JCIT) и цифровая
блочная радиостанция (Digital Modular Radio, DMR) обеспечивали программную
инфраструктуру для управления ресурсами радиосистемы.
Из-за необходимости улучшения возможностей перенастройки системы,
поддержки совместных действий и снижения затрат на эксплуатацию и обслу-
живание, для разработки нового семейства программно-реализованных рекон-
фигурируемых радиосистем было создано Управление по разработке совместных
программ (Joint Program Offi ce, JPO) Joint Tactical Radio System (JTRS, совместные
тактические радиосистемы). Одной из первых задач Управления было определе-
ние общей инфраструктуры программного обеспечения для использования в но-
вых семействах радиосистем. Таким образом и возникла SCA.
На рис. 1.3 показаны несколько ключевых этапов развития спецификации
SCA. Были разработаны несколько предварительных ее версий, но первой, ис-
пользованной для разработки первоначальной реализации SCA стала версия 1.0.
После следующей версии 1.1 значительная часть спецификации была перерабо-
тана, и появилась версия 2.0. Она имела некоторые недостатки, для устранения
которых нужно было пересмотреть все аспекты инфраструктуры программного
обеспечения. Тем не менее, были разработаны несколько реализаций версии 2.0,
которые обеспечили важную для разработки следующих версий информацию «об-
ратной связи» (feedback). Следующая версия 2.1 появилась в середине 2001 года,
а в ноябре была выпущена версия 2.2. В целом, версия 2.2 считалась достаточно
завершенной для реализации и применения в системе SDR.1
В июне 2002 года фирма Boeing получила от CECOM (Communication and Electronic
Command, командование связи и электроники) заказ на разработку пер-
вой базовой программы внедрения SCA. Первым проектом, использующим SCA
версии 2.2, стал Cluster 1, который позже получил название Ground Mobile Radio
(GMR, наземная радиостанция мобильной связи). Позднее стали разрабатывать-
ся другие программы JTRS Cluster, и в апреле 2004 года, почти через три года по-
сле появления спецификации 2.2, была выпущена версия 2.2.1. В этой версии
были устранены многие ошибки и внесены несколько уточнений и улучшений.
Наиболее важным изменением в версии 2.2.1 было исключение из специфика-
ции SCA службы Log Service (служба регистрации) и замена ее на службу OMG
Lightweight Log (упрощенная регистрация OMG — группы по управлению объ-
ектами). В середине 2004 года OMG выпустила свою спецификацию SDR. Спец-
ификация OMG была создана группой специалистов, которые участвовали в раз-
работке SCA. Их первоначальной целью было сделать возможным использование
SCA как промышленного стандарта, а не только военного. Но, как только спец-
ификация OMG появилась на свет, стало ясно, что она существенно отличается
от спецификации SCA.
В то же время в программах JTRS Cluster обнаружились проблемы, связанные
с совместимостью сигналов. Проблема заключалась в том, что код, написанный
для ЦП, был совместим с различными аппаратными платформами, но код для
ЦСП и ПЛИС оставался «привязаным» к определенной платформе и архитектуре
системы2.
1 Несмотря на это, для того, чтобы стать достаточно надежной и эффективной, вер-
сия 2.2 требует некоторых корректировок и уточнений. Например, интерфейс IDL, пред-
ставленный в Приложении С спецификации SCA, не соответствует заданным параметрам
из-за конфликта имен с интерфейсом POSIX.
2 Совместимость моделей сигналов стала существенной проблемой внутри сообще-
ства SCA. Это ни в коем случае не является фундаментальным требованием SCA. Совме-
January 00 December 06
1/01 1/02 1/03 1/04 1/05 1/06
8/06
SCA 2.2.2 (Draft)
11/01
SCA 2.2
5/01
SCA 2.1
4/04
SCA 2.2.1
8/04
SCA 3.0
6/02
Начало программы Cluster 1
2/00
SCA 1.0
7/00
SCA 1.1
12/00
SCA 2.0
5/04
Спецификация SDR OMG
dtc/04-05-04
Рис. 1.3. Хронология SCA
Эта проблема наиболее остро проявилась в конце 2004 года, что побудило JPO
созвать нескольких семинаров для решения проблемы совместимости процессоров
ЦСП и ПЛИС. Их результатом стало появление спецификации SCA 3.0. В отли-
чие от предыдущей, новая версия SCA имела незначительные отличия от прошлой.
Но в ней появились дополнительные ограничения на системные вызовы, которые
могут быть использованы кодом ЦСП, задан предполагаемый набор сигнальных
компонентов, предложена высокоуровневая схема передачи данных (получившая
название HAL-C) и была появился API антенны. Специалисты сошлись во мне-
нии, что необходимо доработать спецификацию — несмотря на наличие потенци-
ально полезных концепций и подходов, для успешной реализации проекта требует-
ся более детальный анализ спецификации.
С конца 2005 до начала 2006 года управление JPO было реорганизовано для
более успешного решения проблем с программами Cluster. Отдел по реализации
программы был перенесен из Вашингтона в Сан-Диего и передан в подчинение
Командованию боевых космических и морских систем (Navy SPAWAR). В середи-
не 2006 года была выпущена версия 2.2.2 — развитие версии SCA 2.2.1. При этом
на веб-сайте JTRS указано, что версия 3.0 «не поддерживается». Поэтому на мо-
мент выхода данной публикации версия 2.2.2 является последней поддерживае-
мой версией SCA.
1.2.2. Понятие SCA
Основной задачей SCA является определение программного обеспечения опе-
рационной среды (ОС) — инфраструктуры, или ядра SCA. Оно используется для
управления, развертывания, настройки и регулирования радиосистем и приложе-
ний, которые запускаются на платформе радиосистемы. Для того, чтобы полу-
чить представление о том, что такое SCA и чем она не является, целесообразно
обратиться к введению спецификации SCA. Ниже приводится выдержка из этой
части.
Спецификация программируемых средств связи (SCA) опубликована Управ-
лением по разработке совместных программ (JPO) JTRS. Управление было орга-
низовано для создания перспективных систем средств связи с учетом передово-
го опыта использования технологии по улучшению совместимости средств связи
и снижению затрат на их разработку и развертывание. Основными задачами про-
граммы JTRS являются:
• значительное повышение операционной гибкости и совместимости гло-
бальных систем связи;
стимость формы сигнала можно рассматривать как возможность снизить затраты при соз-
дании радиосистем. Но из-за различий в аппаратных средствах, процессоре и архитектуре
передачи данных невозможно обеспечить элементарную передачу сигнала от одной систе-
мы к другой, не внося в них изменения.
• снижение затрат на техническую поддержку;
• возможность модернизации, то есть внедрения новых технологий и улучше-
ния характеристик;
• снижение затрат на приобретение и эксплуатацию систем.
Для успешного решения этих задач спецификация SCA была структурирована
с целью:
• обеспечения совместимости программного обеспечения приложений
между различными реализациями SCA;
• использования коммерческих стандартов для снижения затрат на разра-
ботку;
• снижения сроков разработки новых форм сигналов посредством исполь-
зования модулей;
• совершенствования промышленной инфраструктуры и архитектуры.
• SCA V2.2, 17 ноября 2001 года, стр. 7.
Ни одна из вышеуказанных задач не связана ни с техническим проектом
и процессом разработки, ни с реализацией сигналов в радиосистеме. Поэтому
первой фундаментальной целью SCA является совершенствование технико-эко-
номического обоснования проекта (ТЭО) с целью улучшения рабочих характери-
стик средств связи и их материально-технического обеспечения.
Для успешного решения этой задачи структура SCA призвана обеспечить со-
вместимость программного обеспечения приложений, использование промыш-
ленных стандартов, поддержка повторного использования модулей, формирую-
щих сигнал, а также совершенствование промышленной инфраструктуры. Наряду
с задачами, обозначенными в предыдущем параграфе, структура SCA фокусиру-
ется на процессах проектирования и разработки, обеспечивая повторное исполь-
зование проектных модулей и применение коммерческого ПО и стандартов.
1.2.3. Общие представления об SCA
В предыдущем разделе было дано краткое описание SCA. Не секрет, что для
разных индивидуумов технологии зачастую могут подаваться и пониматься по-
разному — некоторые представления основаны на реальных фактах, другие же
базируются на неполном понимании сути технологии. Ниже будут изложены не-
которые из типичных заблуждений относительно SCA.
1.2.3.1. SCA определяет техническую архитектуру программируемого
радио
Спецификация SCA не содержит информацию о технических характеристиках
или инструкции по проектированию и реализации программируемого радио.
Спецификация SCA, основанная на компонентах модели CORBA, определяет
архитектуру для развертывания приложений. В SDR в качестве приложений ис-
пользуются модели сигналов.
1.2.3.2. SCA дает возможность повторного использования модулей
SCA повышает возможность повторного использования программных модулей
с двух точек зрения. Во-первых, спецификация SCA определяет единый пакет
интерфейсов для базовой начальной конфигурации и для управления приложе-
ниями. Таким образом, со стороны пользовательских интерфейсов и внешне-
го управления системой, для загрузки, запуска и остановки сигналов например,
стандарта SINCGARS используются те же интерфейсные вызовы, что и для сиг-
налов стандарта FM3TR. Во-вторых, дополнение API к спецификации обеспе-
чивает повторное использование компонентов программного обеспечения через
общие интерфейсы сигналов. Данная тема требует дальнейшего обсуждения, по-
скольку все разработчики радиосистем имеют собственные представления о том,
какие интерфейсы должны быть у разработанных ими сигналов.
1.2.3.3. Сигнал может быть перемещен с одной платформы SCA на другую
без преобразования
Многие понимают понятие переносимости сигналов SCA как возможность мно-
гократного их применения без внесения каких-либо изменений. Спецификация
SCA определяет общие интерфейсы высокого уровня для развертывания, на-
стройки, управления и контроля аппаратных систем и программных приложений
внутри радиосистемы. Это облегчает процесс переноса приложений, поскольку
интерфейсы не меняются. Но возможность использования одних и тех же сигна-
лов в различных радиосистемах без внесения в них изменений никогда не рассма-
тривалось как непременное требование.
1.2.3.4. Архитектура SCA влияет на параметры сигнала в системе
После того, как SCA загрузит сигнал в радиосистему, ядро SCA переходит в режим
ожидания и использует лишь малую часть времени процессора. Кроме того, SCA
исключает влияние на сигналы, реализованные на процессорах ПЛИС или ЦСП.
SCA может оказывать некоторое влияние на объем используемой памяти, так как
она требуется для работы ядра SCA. Тем не менее, рабочие группы SDR Forum,
NASA и некоторые другие исследуют возможности уменьшения объема занимае-
мой памяти. В случае, когда ядро SCA запускается на ЦП, который используется
и для обработки сигналов, возможно некоторое ухудшение производительности.
В этом случае для определения допустимого диапазона нагрузок необходимо про-
вести стандартный системный анализ
1.2.3.5. Для передачи данных необходимо использовать CORBA
Об использовании CORBA стоит думать в первую очередь, однако это не является
обязательным условием в том случае, если применение CORBA ухудшает произ-
водительность. Стоит отметить, что пользователи часто ошибаются, приписывая
задержки передачи данных CORBA, хотя в действительности они происходят
на уровне протокола TCP/IP. CORBA же — это протокол, скорее похожий на про-
токол передачи гипертекста HTTP, и находится на верхнем уровне механизма
передачи данных. Большинство современных ORB поддерживают подключаемые
интерфейсы транспорта данных, обеспечивая гибкую настройку и оптимизацию
фактического потока передачи данных.
1.2.3.6. SCA пригодна только для небольших радиосистем
SCA изначально не разрабатывалась для применения в радиосистеме какого-либо
определенного класса. При создании SCA-совместимой системы малого размера и с
ограниченными ресурсами возникают больше сложностей, связанных с ограниче-
ниями по весу, размеру и мощностью, чем при разработке переносной или ранцевой
радиостанции. Обычно это связано с тем, что ЦП малой радиостанции активно ис-
пользуется для обработки сигналов, и, если ЦП будет обрабатывать и ядро SCA, это
может оказать значительное влияние на производительность системы.
1.2.3.7. SCA и/или CORBA не годятся для больших, сложных систем
SCA основана на программе JTRS, целью которой была разработка систем такти-
ческого радио. Существует множество модификаций таких систем, начиная от не-
больших переносных радиостанций и заканчивая системами для монтажа в стой-
ку (для автомобилей, кораблей и самолетов). Хотя такие системы не оснащены
сложными терминальными системами, SCA может использоваться и в больших си-
стемах. В этом случае стоит уделить больше внимания архитектуре системы. Возмо-
жет вариант, когда SCA управляет базовым набором радиоаппаратуры и загрузкой
сигналов, управляясь командами от системы высшего уровня. Ключевым аспектом
является то, что SCA управляет аппаратным и программным обеспечением, кото-
рое используются для реализации и поддержки комплексного приложения.
Если говорить о применении CORBA в крупных системах, то она широко
используется во всех отраслях промышленности. Фактически, крупные, распре-
деленные приложения, основанные на Java и использующие удаленные вызовы
процедур CORBA и Java, используют протокол CORBA. В системе управления
спутниковой сети связи Iridium COTS-системы OS/COMET объединены ком-
плексной инфраструктурой CORBA. Конечная система запускалась на более чем
50 компьютерах и одновременно выполняла несколько сотен процессов.
1.2.3.8. SCA не годится для систем, работающих на частотах выше 2 ГГц
Обычно эта причина обосновывается тем, что разработанные в рамках программы
JTRS тактические радиостанции работали на частотах ниже 2 ГГц. Но специфи-
кация SCA не содержит каких-либо элементов, которые могли бы в явной или
скрытой форме ограничить способности SCA работать на частотах более 2 ГГц.
1.2.4. Цели применения SCA
Учитывая, что SCA не является технической архитектурой программируемой ра-
диосистемы, возникает вопрос о необходимости ее применения. Как было ска-
зано выше, частично это объясняется тем, что задачей SCA является достижение
коммерческой эффективности при снижении затрат на модернизацию, обновле-
ния и обслуживание. Это те преимущества, которые главным образом реализуют-
ся заказчиком или пользователем системы SCA. Таким образом, основной при-
чиной использования SCA является то, что этого требует проект. Для обеспечения
долговечности и достаточной приемлемости проекта разработчики должны иметь
обоснованные коммерческие причины ее использования.
Далее перечислены некоторые причины, которые необходимо учитывать при
рассмотрении вопроса об использовании архитектуры.
1.2.4.1. SCA обеспечивает общую инфраструктуру для развертывания
распределенного приложения
Хотя SCA была разработана для систем радиосвязи, базовую инфраструктуру для
размещения компонентов приложения можно использовать практически в любой
системе. Это касается тех элементов системы, которые имеют отношение к обработ-
ке радиосигналов, либо же это могут быть узлы, не имеющие отношения к радио —
например, процессорное управление устройствами и ПО на транспортном средстве.
1.2.4.2. SCA обеспечивает быструю интеграцию внешних приложений
Компактность пакета интерфейсов внутри SCA позволяет легко интегрировать
внешние приложения с помощью языка IDL, предназначенного для загрузки, пуска,
остановки и управления приложениями внутри системы SCA. В качестве примера
можно привести интеграцию системы SCA внутри сети систем. Общее управление
узлами радиосистемы часто осуществляется с помощью сетевого управления (network
management и network control). Такие системы управления часто используют
протокол администрирования сети (SNMP) или язык Java, которые имеют собствен-
ную поддержку CORBA. Таким образом, в случае, когда с помощью ПО управления
сетью требуется загрузить сигнал или коммуникационное ПО в SCA, то для этого
достаточно использовать запуск удаленных процедур Java (Java RPC). При использо-
вании протокола SNMP можно использовать прокси-сервер SNMP, который служит
интерфейсом SNMP в сетевой системе и обеспечивает Java RPC в SCA-радиосистеме.
1.2.4.3. SCA обеспечивает быстрое внедрение новых технологий
Поскольку SCA задает интерфейсы для развертывания, настройки, управления
и мониторинга аппаратного и программного обеспечения в SCA-системе, новые
технологии могут внедряться с меньшими затратами и без ухудшения рабочих па-
раметров. Например, часть описания приложения в SCA определяет программный
компонент, который, который выполняет некоторую функцию. В этом описании
могут присутствовать несколько различных программных реализаций (например,
одна для запуска на ЦСП, другая — для ЦП Intel с ОС WxWorks и т. д.). Таким обра-
зом, благодаря современным возможностям совместимости приложение, которое
можно было запускать только на ЦСП, теперь может работать и на универсальном
ЦП. (Однако это не значит, что для переноса элемента с одной системы на другую
не потребуется определенных усилий. Это лишь означает, что разработка, предна-
значенная для определенной системы, может быть размещена и сконфигурирована
на этой системе без перенастройки всего приложения.) Поскольку SCA позволя-
ет использовать многократные реализации приложений, новая реализация может
быть развернута на уже имеющейся системе, которая оснащена ЦП, но не имеет
ЦСП, при этом не требуется изменения остальных аппаратных компонентов. Та-
кая же концепция применяется и к новому оборудованию.
1.2.4.4. SCA обеспечивает инфраструктуру для расширения и интеграции
SCA является базой для проектирования и разработки комплексных радиосистем.
Она определяет пакет требуемых интерфейсов и алгоритмы, заложенные в ин-
фраструктуре и дает возможность проектировать и создавать приложения с улуч-
шенными рабочими параметрами и характеристиками. С системой SCA, обеспе-
чивающей высокоуровневое управление и контроль радиоресурсов, могут быть
интегрированы технологии типа когнитивного радио. Например, несколько SCA-
радиосистем, имеющих когнитивную карту их окружения и временной логики
могут согласовывать взаимную конфигурацию, повышая тем самым надежность
связи. Это может достигаться путем изменения параметров существующих сигна-
лов внутри системы, или загрузке новых сигналов, согласованных с остальными
радиосистемами.
1.2.4.5. SCA снижает объем единовременных затрат при проектировании
системы
Благодаря наличию единого пакета управляющих программ и инструментов, стан-
дартизация на единой инфраструктуре ПО снижает затраты, связанные с разработ-
кой систем в будущем. Это способствует оптимизации графика выполнения работ
и снижению затрат на модернизацию. Важно разработать стандартную инфраструк-
туру, которая применима для различных систем, поддерживающих SCA. Последний
пункт является основным в для организации принципов разработки систем и ис-
пользовании спецификации SCA.
Теперь, после рассмотрения «плюсов» и «минусов» использования SCA, мож-
но продолжить краткий обзор технических аспектов SCA. Остаток этой главы по-
священ вопросам операционной среды SCA и структуры ее спецификации, и ста-
нет основой для последующих глав.
1.3. Операционная среда
Архитектура программируемых средств связи JTRS определяет требования для
единой операционной среды программируемого радио. Операционная среда
включает в себя ядро SCA, брокер объектных запросов CORBA и операционную
систему. Операционная среда определяет интерфейсы, правила, ограничения
и процедуры, которые необходимо соблюдать для реализации SCA-совместимой
радиосистемы.
Ядро SCA обеспечивает:
• пакет общих служб, используемых сигналами и другими приложениями;
• ПО для установки, настройки, управления и контроля сигналов;
• интегрированную файловую систему для выполнения общих операций
с файлами, а также обеспечения доступа к множественным вычислитель-
ным платформам;
• интерфейсы устройств, которые обеспечивают общую абстракцию ком-
понентов аппаратного обеспечения.
На рис. 1.4, ядро SCA, представленное как уровень управления системой, изо-
бражено по вертикальной оси. Сигналы и компоненты, образующие уровень при-
ложений, представлены на горизонтальной оси.
1.3.1. Структурная организация
По своей структуре радиосистема SCA состоит из трех элементов: загрузка мо-
дели сигнала (Waveform Deployment), ядро (Core Framework) и профиль домена
(Domain Profi le). В свою очередь, каждый из трех указанных элементов можно
рассматривать как физический и логический элементы. С точки зрения загрузки
модели сигнала аппаратные средства являются физической структурой радиоси-
Красная аппаратная шина
Сетевые стеки и службы последовательного интерфейса
Операционная система
ORB и службы CORBA SCA СА Приложения и службы
Черная аппаратная шина
Сетевые стеки и последовательные службы интерфейса
Операционная система
ORB и службы CORBA SCA СА Приложения и службы
Черная шина CORBA (CF IDL) Красная шина CORBA (CF IDL)
Компонент
модема
Адаптер
Модема
Компоненты
системы
безопас-
ности
Адаптер
системы
безопас
ности
Адаптер
системы
безопас-
ности
Радио-
частота
Не-CORBA
компоненты
модема
Связь,
Сетевые
Компо-
ненты
Связь,
Сетевые
Компо-
ненты
Адаптер
ввода-
вывода
Компо-
ненты
ввода-
вывода
Не-CORBA
компоненты
ввода-вывода
Не-CORBA
компоненты
безопасности
Компоненты
ядра
Компо-
ненты
COTS
Название: Структура программного обеспечения SCA
Пакет: Модель компонента
Version: 2.2
Author: V. Kovarik
Маршрут передачи данных/обработки сигнала
Настройка и управление устройством
и приложениями формирования сигнала
Аппаратные
средства
Сигнал
Рис. 1.4. Структура компонента формы сигнала SCA
стемы. Но сигналы реализуются с помощью ПО, которое выполняется на физи-
ческих элементах.
Существуют два уровня логической структуры радиосистемы. Первый уровень
включает в себя пакет компонентов, которые образуют приложение, реализующее
сигнал или какую-либо другую службу в системе. Второй уровень — это приложение,
которое обеспечивает интерфейс высшего уровня и управление пакетом компонен-
тов.
Ядро SCA включает в себя все программные средства, необходимые для
управления радиосистемой и развертывания приложений. Его так же можно рас-
сматривать как физическую и логическую структуры. Физическая структура ядра
обеспечивает высокоуровневое управление физическими устройствами в радио-
системе. Логическая структура обеспечивает ту же функцию для приложений,
формирующих сигнал и других служб.
Профиль домена включает в себя XML-файлы, которые содержат описание
аппаратных средств радиосистемы, структуру приложения, формирующего сиг-
нал, взаимосвязи и зависимости программных компонентов и аппаратных ресур-
сов (рис. 1.5).
1.3.2. Ограничения интерфейса операционной среды
На рис. 1.6 показаны взаимосвязи между основными компонентами SCA-
совместимой системы. На нижнем уровне находятся службы, обеспечиваемые ОС
(которая формирует профиль среды приложения) как интерфейсы POSIX.
Дескриптор
конфигурации
устройства
Device Manager
Служба
имен
DAC-1
ADC-1
FPGA-1
GPP-1
B
C
A
B
Приложения
Компоненты
Аппаратное обеспечение радиосистемы
D
B
Канал связи-1
Телеметрия-1
Приложение
App Factory
канала связи
A
A
Менеджер
файлов
Ресурсы Менеджер домена
File
System
SCA Devices
Connections
Взаимосвязи
Компоненты
Размещение сигнала Ядро
XML профиля домена
Physical Logical
Физическая логика ??
Канал связи-2
Telemetry
Waveform
Сигнал
канала связи
Дескриптор
пакета ПО (SAD)
Дескриптор
менеджера устройства
Телеметрия
App Factory
Рис. 1.5. Уровни абстракции в системе SCA
Профиль среды приложения (Application Environment Profi le) пред-
назначен для обеспечения ограниченного набора строго определенных
системных вызовов, которые минимизируют влияние на код приложе-
ния. Это применимо лишь для ОС, работающей на ЦП, поскольку ЦСП
и ПЛИС не имеют операционной системы. Тем не менее, некоторые про-
цессоры ЦСП поддерживают ОС и CORBA. В этом случае для обеспече-
ния доступа к функциям операционной системы необходимо использо-
вать интерфейс POSIX. Все остальные компоненты (CORBA ORB, ядро
SCA, компоненты без использования CORBA и драйверы устройств) могут иметь
неограниченный доступ к операционной системе.
CORBA ORB обеспечивает единое связующее ПО для системы, и имеет не-
ограниченный доступ к базовой операционной системе. Ядро SCA — это реали-
зация спецификации SCA, определяющей необходимые компоненты и службы
радиосистемы. Компоненты и драйверы устройств, не совместимые с CORBA,
включают в себя низкоуровневые драйверы, подобные тем, которые поставляют-
ся производителем какого-либо устройства для различных ОС. Приложение со-
стоит из набора компонентов и ресурсов, которые формируют рабочий сигнал.
И наконец, ОС обеспечивает базовый набор зависящих от платформы служб.
Приложения CORBA ORB, ядро и драйверы устройств имеют неограничен-
ный доступ к системным вызовам и службам ОС. Но, как показано на рис. 1.6,
приложения имеют доступ только к набору системных вызовов POSIX. Это огра-
ничение введено потому, что, если приложение имеет ограниченный набор ин-
терфейсов, то оно легче переносится (портируется) на другие платформы. В свою
очередь, для обеспечения совместимости с SCA программная платформа радио-
системы должна поддерживать системные вызовы POSIX.
Несмотря на преимущества такого подхода, для обеспечения совместимо-
сти при портировании сигнала приходится устранять многочисленные проблемы
и ограничения POSIX. Это становится особенно ощутимо в том случае, если раз-
работанное сигнальное приложение использует в качестве одного из функциональ-
ных узлов цепи формирования сигнала ЦСП или ПЛИС.
1.4. Ñòðóêòóðà ñïåöèôèêàöèè SCA
Спецификация SCA состоит из трех основных частей:
• спецификация программируемых средств связи (JTRS-5000SCA),
• дополнения API (JTRS-5000API),
• дополнения по безопасности (JTRS-5000SEC).
Спецификация SCA является основой для разработки SCA-совместимых ра-
диосистем. Она определяет требования к операционной среде и основным функ-
циональным характеристикам. В данной книге основное внимание уделено со-
держанию спецификации SCA.
В дополнениях API (JTRS-5000API) содержатся инструкции и требования
по разработке модульных и портативных компонентов приложений. Некоторые
аспекты дополнений API рассмотрены в этой книге. Однако подробное рассмо-
трение дополнений API и вопросов создания портативных приложений потребует
описания значительно большего числа подробностей, чем позволяет объем дан-
ной книги.
Дополнение по безопасности определяет специальные требования к безопас-
ности и API, относящиеся к проектированию и построению защищенной радиоси-
стемы первого типа. Некоторые разделы книги посвящены системе безопасности,
поскольку то важно для понимания других разделов. Так же, как и для дополнений
API, подробности, связанных с вопросами защиты информации при создании SCA-
совместимых радиосистем, остаются за рамками данной книги.
Раздел 3 спецификации SCA описывает требования к определению архитектуры
базового программного обеспечения.
Организационная структура раздела 3 показана на рис. 1.7. В подразделе
Operating Environment (Операционная среда) рассматриваются службы и ядро
SCA. В разделе 3.2 содержится описание интерфейсов приложений и функцио-
Ресурсы приложения, Базовое приложение ядра
CORBA ORB Ядро SCA
(Интерфейсы
служб и
управления
ядра)
Не-CORBA
компоненты,
драйверы
устройств
и т. д.
Неограниченный доступ ОС
CORBA API
Ограниченный доступ SCA AEP
к ОС
Приложение использует
ядро для доступа к файлам
и службам
Logical device adapter
OS (function) that supports the SCA
Рис. 1.6. Ограничения интерфейса SCA
28 Глава 1. Введение
нальные требования. Раздел 3.3 определяет требования к интерфейсу устройства
SCA, а в разделе 3.4 перечислены общие требования.
Операционная среда (раздел 3.1 спецификации SCA) определяет требования,
которым должна удовлетворять SCA-совместимая система. Она содержит общие
компоненты ядра — менеджер домена (Domain Manager), службу регистрации
(Log Service), компоненты, необходимые CORBA и другие.
В разделе 3.2 определены требования, которым должны соответствовать при-
ложения SCA. Эти приложения позволяют полностью реализовать сигнал, поэто-
му раздел будет более всего интересен разработчикам сигнальных приложений.
Тем не менее, некоторые связанные с приложениями аспекты представлены как
компоненты ядра.
Управление устройствами радиосистемы и их настройка осуществляются че-
рез интерфейс логического устройства. Для того, чтобы успешно интегрировать
устройство в SCA-cистему, производитель устройств и/или системный интегратор
должен обеспечить реализацию этого интерфейса. Эти требования определены
в разделе 3.3. Содержимое разделов 3.1—3.3 и основные области функциональных
требований будут подробно описаны в последующих главах. Общие требования
к ПО (раздел 3.4) и другие нефункциональные требования будут описаны в этом
разделе.
На рис. 1.8. показано, как соотносится спецификация SCA и ее реализация.
Спецификация SCA обеспечивает интерфейс и характерные высокоуровневые
параметры, реализуемые ядром. Рисунок также иллюстрирует разработанные
группой OMG стандарты, которые рассмотрены в спецификации SCA.
Группа интерфейсов ядра и спецификации поведения (behavioral
specifi cations) находятся в пакете ядра. Профиль домена задает XML-
3 Определение
программируемой
архитектуры
3.1 Операционная
среда
3.2 Приложения 3.3 Логическое
устройство
3.4 Общие правила
программного
обеспечения
3.1 Операционная среда
+ 3.1 Операционная среда
+ 3.1.1 Операционная система
+ 3.1.2 Промежуточное ПО и службы
+ 3.1.3 Ядро SCA
+ 3.1.3.4 Профиль домена
+ 3.1.1 Операционная система
+ 3.1.2 Промежуточное ПО и службы
+ 3.1.3. Ядро SCA
3.2 Приложения
+ 3.2 Приложения
+ 3.2.1 Общие требования к приложению
+ 3.2.2 Интерфейсы приложения
3.3 Логическое устройство
+ 3.3 Логическое устройство
+ 3.3.1 Службы ОС
+ 3.3.2 Службы CORBA
+ 3.3.3 Интерфейсы ядра
+ 3.3.4 Профиль
3.4 Общее правило ПО
+ 3.4 Общие правила ПО
+ 3.4.1 Языки разработки ПО
+ 3.4.1.1 Новое ПО
+ 3.4.1.2 Устаревшее ПО
Рис. 1.7. Структура спецификации SCA
файлы, которые используются для описания основных компонентов ап-
паратного и программного обеспечения и взаимосвязей, необходимых
для загрузки сигнала.
Существует несколько толкований термина «профиль домена”. Не-
которые подразумевают под ним набор XML-файлов, по мнению дру-
гих — это обработанные структуры данных из этих файлов, третьи же
называют профилем домена внутренние структуры данных, которые со-
держат сведения о домене SCA-системы.
Рис. 1.8. Спецификация SCA в зависимости от реализации
Спецификации OMG
Спецификация SCA Реализация SCA
Профиль домена
+ Автор
+ Код
+ Дескриптор
+ Дескрипторы
+ Дескриптор конфигурации устройства
+ Дескриптор пакета устройств
+ Дескриптор конфигурации менеджера домена
+ Типы профиля домена
+ Карта ПЛИС
+ Реализация
+ Группа ОС
+ Дескриптор свойств
+ Файл свойств
+ Дескриптор компоновки программного обеспечения
+ Дескриптор программного компонента
+ Дескриптор программного пакета
CF_Impl
+ AppComponent
+ Мощность
+ Событие
+ Ввод/вывод
+ LogicalDevice
+ SDRт
+ Процессор
+ Радио
+ Ресурс
+ Служба
+ Приложение ПО
+ Компонент ПО
+ Сигнал
+ Приложение
+ Ядро
+ Компоненты
+ CORBA
+ Устройства
+ Файловая система
+ Реализация регистрации
+ Ресурсы
Служба регистрации
+ AdministrativeStateType
+ AdministrativeStateType
+ AvailabilityStatusType
+ AvailabilityStatusType
+ LogFullActionType
+ LogLevel
+ LogLevelType
+ LogRecordType
+ LogTimeType
+ OperationalStateType
+ OperationalStateType
+ ProducerLogRecordType
+ LogAdministrator
+ LogConsumer
+ LogProducer
+ LogStatus
StandardEvent
+ DomainManagementObjectAddedEventType
+ DomainManagementObjectRemovedEventType
+ SourceCategoryType
+ StateChangeCategoryType
+ StateChangeEventType
+ StateChangeType
PortTypes
Облегченная регистрация
Служба событый
Служба имен
Начиная с версии
SCA 2.2.1, служба
регистрации была
исключена из
спецификации
и использован
вариант
облегченной
регистрации OMG.
Ядро
+ AdminType
+ ComponentElementType
+ ComponentProcessIdType
+ DataType
+ DeviceAssignmentSequence
+ DeviceAssignmentType
+ DeviceSequence
+ ErrorNumberType
+ ErrorNumberType
+ FileException
+ FileInformationType
+ FileType
+ InvalideObjectReference
+ InvalidFileName
+ InvalidFileSystem
+ InvalidProfile
+ LoadType
+ MountPointAlreadyExists
+ MountSequence
+ MountType
+ NonExistentMount
+ OctetSequence
+ OperationalType
+ Properties
+ ServiceType
+ StringSequence
+ String Sequence
+ Unknown Properties
+ UsageType
+ AggregateDevice
+ Приложение
+ ApplicationFactory
+ Устройство
+ DeviceManager
+ DomainManager
+ ExecutableDevice
+ Файл
+ FileManager
+ FileSystem
+ LifeCycle
+ LoadableDevice
+ SDRт
+ Поставщик SDRта
+ Набор параметров
+ Ресурс
+ ResourceFactory
+ TestableObject
+ UnknownProperties
Исполь-
зует
«реализует»
«реализует»
«realize»
Использует
Использует
Ис-
поль-
зует
Ис-
поль-
зует
Авторы данной книги придерживаются точки зрения, что XML-файлы пред-
ставляют собой удобочитаемую версию профиля домена, а внутренние структуры
данных, созданные как часть обработки XML-профиля, формируют внутренний
профиль домена, используемый ядром SCA в процессе создания сигнала. Иерар-
хическая древовидная структура, сгенерированная синтаксическим анализатором
(парсером) рассматривается как промежуточная структура данных, которая пре-
образует текстовые XML-файлы в каноническую форму, позволяющую быстрое
извлечение из них необходимой для загрузки сигнала информации. Несомненно,
можно пропускать обработку структуры XML-файла и непосредственно исполь-
зовать его как представление внутреннего профиля домена. Но такая форма пред-
ставления данных будет неэффективна при использовании строгих ограничений
(constraint enforcement), которые используются компонентом ядра SCA ApplicationFactory
при создании экземпляров приложения.
Все вышеперечисленные абстракции базируются на единых службах, которые
обеспечивают важнейшие функции для всех компонентов SCA:
Служба имен (Name service) — позволяет компоненту радиосистемы найти требу-
емую службу или приложение и подключиться к нему.
Служба событий (Event service) — обеспечивает асинхронный механизм для
трансляции компонентами событий в канал событий и регистрацию компонентов
для получения этих событий.
Служба регистрации (Log service) — обеспечивает базовую функцию регистра-
ции внутри радиосистемы SCA, которая позволяет компонентам создавать запи-
си, описывающие какие-либо действия или состояния, снабженные временными
метками и сохранять их в файле с возможностью последующего извлечения.
Файловая служба (File service) — возможно, это одна из важнейших служб, ко-
торая обеспечивает единую абстракцию файловой системы для всех компонентов
SCA-системы, независимо от фактической реализации ОС и файловой системы.
Первая глава книги организована в соответствии с описанными выше высо-
коуровневыми абстракциями. Во второй главе рассматриваются общие службы
фреймворка, обеспечивающие основу для компонентов и ссылок, используемых
в описании остальных логических интерфейсов. После описания общих служб
в последующих главах рассматриваются описанные выше логические абстракции,
начиная с менеджера ресурсов и заканчивая менеджером домена.
1.5. Выводы
Спецификация SCA обеспечивает независимую от реализации инфраструктуру
для реализации и развертывания приложений. Общие требования SCA опреде-
ляют набор аппаратных и программных требований, которым должна соответ-
ствовать система. В следующей главе представлен концептуальный обзор работы
SCA-совместимой системы, использующий модельный принцип прецедентов,
или сценариев использования (Use сase) унифицированного языка моделирова-
ния UML.
ГЛАВА 2
Сценарий использования
Функционирование системы удобно описывать с помощью прецедентов (сцена-
риев использования), которые описывают общее поведение системы при взаимо-
действии с пользователем либо с внешней средой. В этом разделе описываются
различные прецеденты SDR. Они предназначены для подробного анализа рабо-
чих параметров абстрактной SCA-совместимой радиосистемы. Детальное описа-
ние какой-либо конкретной радиосистемы требует более широкого набора опера-
ционных сценариев и прецедентов.
На рис. 2.1 показаны субъекты, имеющие отношение к радиосистеме, и раз-
ичные действия, которые они выполняют. Конечный пользователь радиосисте-
мы — это обычный оператор радиостанции. Он по сути работает с радиосистемой
на базовом уровне оборудования, например, включает и выключает питание или
инициализирует систему. На более абстрактном уровне пользователь взаимодей-
ствует с радиосистемой, управляя сигнальными приложениями. На этом уровне
начинает проявляться уникальность программно-определяемого радио. Пользо-
ватель может конфигурировать систему для загрузки и запуска сигнала в дина-
мическом режиме, то есть, радиостанция по требованию может быть (пере)на-
строена для выполнения компонентов, поддерживающих различные сигнальные
приложения.
Настройку интеграцию тестирование радиосистемы и установку сигнальных
приложений выполняет радиоинженер.
В следующих параграфах представлен качественный анализ необходимых
действий, рассмотренных в каждом из показанном на рис. 2.1 прецеденте. Цель
этого подхода — обеспечить единую модель поведения и взаимоотношений для
ключевых функций SCA-совместимой радиосистемы и показать все необходимые
шаги и режимы работы. Так как мы занимаемся исследованием конкретных по-
веденческих факторов компонентов ядра SCA, этот же подход будет применен и в
следующих главах. Необходимо отметить, что диаграммы, представленные в сле-
дующих разделах, в общем виде иллюстрируют взаимодействия между процесса-
ми и не являются точным отображением UML-модели этих взаимодействий.
2.1. Запуск системы
Прецедент «Пуск» (Startup) выполняется при переводе радиосистемы из выклю-
ченного состояния во включенное, когда выполняется включение и инициализа-
ция всех аппаратных компонентов системы и загрузка и инициализация ядра SCA.
Рис. 2.2 показывает основные связи между прецедентами, образующими стар-
товую последовательность.
Установка приложения
+ Установить приложение
+ Загрузить профиль домена
+ Удалить приложение
+ Выгрузить профиль домена
Запуск радиостанции
+ Запустить устройство
+ Запустить менеджер устройства
+ Запустить менеджер домена
+ Запустить канал событий
+ Запустить файловую систему
+ Запустить регистрацию
Пользователь радио
Радиоинженер
Инстанцировать сигнал
+ Выделить память
+ Конфигурировать
+ Создать приложение
Отключение радиостанции
+ Отключить устройство
+ Отключить менеджер устройства
+ Отключить менеджер домена
+ Отключить канал событий
+ Отключить файловую систему
+ Отключить регистрацию
Управление сигналом
+ Освободить память
+ Выполнить запрос
+ Выгрузить приложение
+ Запустить приложение
+ Остановить приложение
Конфигурация системы
+ Создать профиль домена
+ Подтвердить профиль
домена
Система безопасности
+ Ввод ключа управления
Менеджер
безопасности
Маршрут Маршрут
Маршрут Маршрут
Маршрут Маршрут
Маршрут
Рис. 2.1. Функции и действия пользователей радиосистемы
Прецедент «Start Device Manager» (запустить менеджер устройств) описывает
запуск устройства, которое обычно называют «узел» (node). Здесь этот термин ис-
пользуется для обозначения аппаратного компонента (например, плата с интер-
фейсом VME или Compact PCI), который включает в себя одно или несколько
физических устройств, выполняющих какие-либо необходимые для реализации
SCA-совместимой радиосистемы вычисления. Как правило, в качестве исходно-
го или загрузочного узла используется одноплатный компьютер (SBC) или иное
устройство с центральным процессором и операционной системой.
Основным условием запуска системы SCA является наличие загрузочного
устройства и его менеджера (Device manager), который управляет запуском и ини-
циализацией ядра SCA и связанных с ней компонетов. Начав работу, менеджер
устройств запускает ряд служб и приложений (рис. 2.3), начиная с инициализа-
ции файловой системы (File system). Файловая система выделяет для менеджера
устройств и связанных с ним компонентов некоторый объем памяти. Затем ме-
неджер устройств запускает службу регистрации (Log Service), которая дает воз-
можность записывать системные сообщения, предупреждения и неисправности
всех аппаратных и программных компонентов системы SCA. Далее, менеджер
устройств запускает менеджер домена (Domain manager), который служит основ-
ным хранилищем (репозиторием) и пунктом управления системой. После этого
менеджер устройств запускает все связанные с ним компоненты.
Пользователь
радиосистемы
Запуск
менеджера
устройств
Запуск
менеджера
домена
Запуск
файла
регистрации
Запуск
файловой
системы
Запуск
устройства
Запуск
канала
событий
«включение»
0..
1
«включение»
0..1
1
«расширение»
1..
«расширение»
0..1
«расширение»
0..
«включение»
Рис. 2.2. Запуск радиосистемы
Рассмотренный выше принцип стал использоваться лишь в текущей версии
SCA. При текущем подходе невозможно гарантировать то, что компонент, в слу-
чае его инициализацией клиентом, будет полностью инициализирован и готов
к приему поступающих запросов CORBA. Например, менеджер устройств на за-
грузочном устройстве может запускать менеджер домена, но при попытке реги-
страции последний может не загрузиться полностью и не инициализироваться.
Таким образом, только при наличии в компонентах ядра SCA встроенного меха-
низма автоматического перезапуска они, скорее всего, будут запущены без сбоев.
После включения питания загрузочный узел задействует загрузочное ПЗУ
(Boot ROM), которое запускает необходимые начальные процедуры и инициали-
Запуск системы
Пользователь
радио
Запустить
менеджер
устройства
Запустить
файловую
систему
Запустить
файл
регистрации
Запустить
менеджер
домена
Запустить
устройство
Архитектура SCA 2.2
обеспечивает запуск
Менеджера домена,
который рассматри-
вается как часть пуска
Менеджера устройств
загрузочного узла.
PowerOn
(включение питания)
Загрузочное ПЗУ
Загрузить ОС
Обработать
Инстанцировать
Инициализировать
[Если задано в XML]:* Инстанцировать
Инициализировать
[Для каждого устройства]:* Обработать
Инициализировать
Журнал
регистрации
Список
устройств
[Для каждого устройства]:*
Получить данные об устройстве
Запустить другие менеджеры устройств
Готовность
системы
Запустить службу имен
Загрузить менеджер устройств
Запустить менеджер устройств
Рис. 2.3. Последовательность операций при запуске радиосистемы
зирует оборудование. После этого запускается операционная система. Она обе-
спечивает основные службы и функции для загрузки и управления базовыми про-
граммными компонентами SCA.
После того, как загрузилась ОС, система готова для загрузки компонентов
ядра SCA. Первый элемент, который необходимо загрузить — это служба имен
CORBA, которая позволяет приложениям определять местоположение доступ-
ных служб и других приложений. Этой службой регистрируются компоненты ядра
SCA, таким образом, она должна быть доступна до инициализации этих компо-
нентов.
На данном этапе выполняется загрузка программной реализации менедже-
ра устройств. После инициализации, он в первую очередь должен считать де-
скриптор конфигурации устройства (DCD), связанного с менеджером устройств.
DCD — это XML-файл, содержащий информацию о конфигурации и параметры
для запуска устройства. Синтаксическая структура дескриптора DCD и XML-
файлов рассматривается во второй части книги, некоторые примеры приведены
в третьей.
Считанный и обработанный менеджером устройств DCD определяет допол-
нительные программные компоненты и устройства, которые должны быть запу-
щены в процессе общей инициализации менеджера устройств. Как правило, одна
из первых задач, выполняемая менеджером устройств — это инициализация фай-
ловой системы (ФС). ФС SCA — это абстрактное, основанное на CORBA пред-
ставление некой конкретной ФС, реализованной на базовом аппаратном обе-
спечении и операционной системе. Обычно менеджер устройств инициализирует
лишь одну ФС, но, в зависимости от типа конфигурации аппаратного обеспе-
чения и операционной системы, а также характеристик базового оборудования,
ассоциированного с менеджером устройств, могут быть инициализированы не-
сколько ФС (или же инициализация ФС не производится вообще).
Следующий инициализируемый компонент — это канал событий (Event Channel),
обеспечивающий механизм асинхронных уведомлений, благодаря которому
компоненты могут публиковать сообщения об изменении своего статуса и других
событиях. Компоненты, которым необходимо считывать определенные сообще-
ния, должны лишь подписаться на соответствующий канал. Функциональные ха-
рактеристики канала событий в SCA перечислены в документе OMG Document
formal/01-03-01: Event Service, v.1.1.
После создания канала событий менеджер устройств запускает службу ре-
гистрации. До появления версии 2.2 SCA служба регистрации была определена
как часть спецификации SCA. Начиная с версии SCA 2.2.1, в архитектуре SCA
указывается спецификация упрощенной регистрации OMG. Обе службы анало-
гичны по функциональности и используют одинаковый интерфейс IDL. Служба
регистрации обеспечивает кратковременный, находящийся в ОЗУ файл данных,
которая может быть доступен любому компоненту SCA. Файл данных постоянно
использует буферную память.
После запуска службы регистрации, если это указано в XML-файле DCD, ме-
неджер устройств запускает менеджер домена. Последний обеспечивает храни-
лище верхнего уровня для всех устройств и программных компонентов, которые
входят в домен радиосистемы, и управляет ими.
На этом этапе менеджер устройств запускает и инициализирует все устрой-
ства, указанные в XML-файле DCD. После этого менеджер устройств регистри-
рует через менеджер домена каждое запущенное устройство. Для всех зареги-
стрированных устройств менеджер домена запрашивает параметры устройства
и информацию о его конфигурации.
Наконец, если это необходимо для старта системы, менеджер устройств за-
грузочного узла может запустить дополнительные менеджеры устройств. Каждый
последующий запуск менеджера устройств осуществляется по той же по схеме,
что и запуск менеджера устройств загрузочного узла. Однако, далее уже не нужно
запускать менеджер домена или канал событий, поскольку для работы системы
требуется лишь однократный запуск этих компонентов. Необходимость же ини-
циализации ФС и службы регистрации зависит от ресурсов и требований к радио-
системе.
2.2. Завершение работы
Весьма интересен тот факт, что процесс отключения радиосистемы не описан под-
робно в спецификации SCA. Рассуждая логически, можно предположить (как по-
казано на рис. 2.4), что менеджер домена осуществляет управление всей радиоси-
стемой и именно он выдает команду отключения радиостанции. Это итеративная
операция, во время которой зарегистрированные менеджером домена менеджеры
устройств получают от него команду на отключение (рис. 2.5). В свою очередь,
каждый менеджер устройств отправляет всем связанным с ним устройствам ко-
манду завершения их работы. После этого менеджер устройств останавливает свя-
занную с ним файловую систему и службу регистрации, если таковая запущена.
Завершив все указанные действия, менеджер устройств прекращает свою рабо-
ту. Следует иметь в виду, что после остановки менеджера устройств и связанных
с ним компонентов получить ответный сигнал от устройств невозможно, так как
они перестают существовать в системе.
Как только все менеджеры устройств получает команду об отключении, ме-
неджер домена завершает работу. Но, так как в процессе отключения устройств
они могут посылать уведомления об ошибках или иных событиях, менеджер до-
мена должен ждать некоторое время для того, чтобы проконтролировать отключе-
ние всех устройств, и только после этого закончить свою работу.
Поскольку один из менеджеров устройств работает как загрузочный узел,
и обычно он же запускает менеджер домена, он может использовать интерфейс-
ные запросы к ОС на аппаратное отключение или перезагрузку. Независимо
от того, реализовано это или нет, менеджер устройств для процессора, на котором
запущен менеджер домена, должен ждать до тех пор, пока менеджер домена пре-
кратит работу. После того, как это произойдет, менеджер устройств выполняет
собственную процедуру отключения. Таким образом, когда менеджер устройств
получает запрос от менеджера домена на отключение, он откладывает процесс
фактического отключения до тех пор, пока менеджер домена и прочие процессы
SCA не завершат процедуры своего отключения. Только тогда менеджер устройств
завершает свою работу и/или обращается к ОС с запросом на перегрузку или пе-
резапуск.
2.3. Установка / удаление приложения
Установка приложения в SCA-совместимой радиосистеме считываются
XML-файлы, описывающие необходимые для размещения сигнала в системе ап-
паратные и программные компоненты,. Ключевой момент здесь — то, что сиг-
нальное ПО не загружается в оборудование. На этом этапе требуется лишь список
ud Отключение радиостанции
Пользователь
радиосистемы
Отключить
устройство
Отключить
Менеджер
устройств
Отключить
файловую
систему
Отключить
файл
регистрации
Заверщить
Менеджер
домена
Завершить
канал событий
«расширение»
«использование»
1..
0..1
«расширение»
0..
«расширение»
1..
«расширение»
Рис. 2.4. Отключение радиосистемы
39
устройств, на которые загружаются программные компоненты, и связей, объеди-
няющие их в функциональное приложение.
Результат установки приложения — загрузка файла дескриптора компоновки
программного обеспечения (Software Assembly Descriptor — SAD). Файл дескрип-
тора SAD — это высокоуровневый XML-файл, который определяет компоненты,
схемы соединений, а также ограничения для заданного сигнального приложения.
Термин «профиль домена» иногда используется для обозначения и XML-
файлов, и внутренних структур данных, представляющих содержание XML-
файлов в удобной для использования компонентами ядра форме. Хотя в спец-
ификации SCA под профилем домена подразумевается именно XML-файлы,
обрабатывать их при каждой загрузке сигнала затратно с точки зрения вычисли-
тельных ресурсов.
Большинство реализаций ядра SCA преобразуют информацию в легкий для
обработки «машинный» формат. Это может быть XML-дерево или объектная мо-
Отключение системы
Пользователь
радиосистемы
Завершить
менеджер
домена
Завершить
менеджер
устройств
Завершить
файловую
систему
Отключить
устройство
Завершить
файл
регистрации
В зависимости от архитектуры
реализация устройства может быть
запущена как поток внутри процесса
менеджера устройств.
Таким образом, прекращение работы
приводит к прекращению потока.
Реализация устройства для
универсального ЦП, на котором
запущен менеджер устройств,
может далее инициировать
перезагрузку, перезапуск или
отключение основного
устройства, связанного
с менеджером устройств.
Отключение
[Для каждого Менеджера устройств]: Отключить
[Для каждого устройства]: Отключить
Прекратить
работу
Отключить
Прекратить
работу
Отключить
Завершение
работы
выполнено
Отключение
системы
Прекратить работу
Прекратить
работу
Перезагрузить/
Перезапустить
Завершение процесса
Рис. 2.5. Последовательность отключения компонентов радиосистемы
дель документов (DOM), созданная парсером XML. Однако при обработке парсе-
ром XML-дерева теряются семантические связи между компонентами профиля.
Это приводит к необходимости обхода вершин дерева при создании экземпляра
(инстанциации) приложения.
В результате некоторые реализации ядра SCA создают внутренний набор
структур данных, которые обеспечивает более эффективное представление для
восстановления и обновления при создании и уничтожении экземпляра прило-
жения.
При удалении приложения соответствующая информация профиля домена
так же удаляется. (В спецификации SCA изначально было указано, что XML-
файлы с информацией профиля домена также должны быть удалены из файловой
системы. Однако в версии SCA 2.2.1 эти XML-файлы сохраняются.)
Такое требование создает проблему для тех ядер SCA, которые используют
внутренние структуры данных для представления проанализированного и уста-
новленного сигнального приложения, так как удаление приложения подразуме-
вает простое физическое удаление внутренних структур данных, представляющих
профиль сигнала.
Кроме этого, удаление файлов вызывает проблемы с операционной системой
в случае, если конечный пользователь обеспечивает возможность деинсталляции
приложения. Внутренние структуры данных не удаляются, т. к. в противном слу-
чае обработка радиосигнала была бы невозможна до повторной загрузки XML-
файлов (т. е. до повторной инсталляции приложения формы сигнала). Другими
словами, это привело бы к удалению исходных XML-файлов, описывающих про-
филь.
Некоторые реализации SCA позволяют указывать, удалять ли физически
XML-файлы, связанные с сигналом, или это относится лишь к внутренним струк-
турам данных. Это дает возможность деинсталлировать приложение, освободив
тем самым внутренние ресурсы и память для других приложений, в то же время
давая возможность при необходимости переустановить сигнал.
При установке сигнального приложения выполняется считывание и обра-
ботка (парсинг) набора XML-файлов, задающих структуру сигнала. Прецедент
«Установка приложения» (рис. 2.6) создает базовые внутренние структуры дан-
ных, определяющих необходимые для загрузки сигнального приложения компо-
ненты и аппаратные средства. «Загрузка профиля домена» обеспечивает нужную
для создания внутренней модели профиля сигнала информацию, извлеченную
из XML-файлов.
Прецедент «Проверка профиля домена» выполняет анализ обработанных
XML-файлов в зависимости от определения типа документа (Document Type Defi -
nition, DTD), указанного в спецификации SCA. Последовательность процедур
по установке/удалению приложения показана на рис. 2.7.
Деинсталляция приложения влечет за собой удаление из системы всех вну-
тренних структур данных с информацией о профиле сигнала и, возможно, файлов
XML, которые образуют профиль. Нужно отметить, что, хотя удаление файлов
XML заявлено как обязательная функция, смысла в этом нет, так как для пере-
установки приложения требуется повторная загрузка XML-файлов в систему.
Кроме этого (как показано на рис. 2.6), деинсталляция сигнального приложе-
ния не влияет на создание экземпляра сигнала. Хотя на первый взгляд концепция
создания экземпляра деинсталлированного сигнального приложения выглядит
противоречивой, она не лишена здравого смысла. После создания экземпляра
сигнала приложению больше не требуется информация о профиле — так как ин-
формация о профиле использовалась в процессе создания. В результате все не-
обходимые компоненты уже загружены, а ресурсы распределены. Поэтому соз-
данный экземпляр сигнала можно запускать, останавливать, конфигурировать
и выполнять с ним любые другие действия, допустимые для созданного экзем-
пляра приложения и не требующие доступа к информации профиля.
ud App Install
Установить
приложение
Удалить
приложение
Радио-
инженер
Загрузка
профиля
домена
Проверка
профиля
домена
Выгрузка
профиля
домена
«расширение»
«расширение»
«включение»
Рис. 2.6. Установка/удаление приложения
Это позволяет создавать экземпляры сигнала, а затем их удалять, освобождая
оперативную память и другие ресурсы, что может быть полезным, например, при
установке другого сигнального приложения. Но если сигнал деинсталлирован
(даже если созданные экземпляры приложения продолжают работать, не имею
доступа к информации профиля), то выполнить создание новых экземпляров сиг-
нала невозможно до тех пор, пока не сигнал не будет заново установлен, обеспе-
чив необходимую информацию профиля.
Аналогичным образом, если радиостанция отключилась, при включении си-
стемы менеджер домена переустанавливает все сигнальные приложения, которые
были установлены на момент отключения. Если же сигнал был удален (даже если
перед отключением его реализация была запущена), то менеджер домена не смо-
жет его переустановить.