Программа JTRS — Joint Tactical Radio System должна была увязать сетью цифровой радиосвязи все виды и рода вооруженных сил США. Радиостанции, выполненные по технологии SDR, могли быть выполнены в носимом и возимом варианте; предусматривалось применение как в сухопутных войсках, так и в ВВС и ВМФ.
Программа стартовала в 1997 году, на НИОКР было выделено 6 млрд. долларов. После того как деньги были израсходованы, программа была закрыта. После этого была попытка оживить JTRS, которая опять-таки закончилась очередным закрытием в 2012 году.
И как это бывает в затянувшихся проектах, пока все ожидали результатов JTRS, военное ведомство США тем временем было вынуждено приобретать обычные средства связи, что вылилось в дополнительные 11 млрд. долл. Само собой, после появления в войсках радиостанций JTRS эти вновь купленные средства связи должны были быть списаны.
Таким образом, в результате 15 лет, потраченных впустую и минус 17 млрд. долларов. Что пошло не так?
Какая связь нужна
Совершенно очевидно, что на поле боя без связи — никуда. Перед глазами сразу появляются картинки из советских фильмов, когда связист накручивает индуктор телефона ТА-57 и кричит в трубку под грохот разрывов: «Тополь, тополь, я береза, дайте огня по высоте безымянной!». Только в современности двусторонняя связь отходит в прошлое. Появилось модное слово — сетецентричность, хотя зачем выдумывать новые сущности? И так ясно, что это должна быть сеть связи, поверх которой работают системы боевого управления.
Эти системы, при том же количестве ресурсов — танков, артиллерии, беспилотников, авиации и так далее — позволяют достичь двукратного преимущества за счет только информационного обмена, координации и управления. Пример: локатор на соседней позиции засекает разведывательный БЛА противника и определяет его координаты. Координатная информация тут же идет командиру подразделения, над которым завис беспилотник — вплоть до трека реального времени на командирском планшете. Командир дает команду другому узлу визуально опознать БЛА, после чего получает на свой планшет возможную классификацию БЛА и его фото. После этого идет запрос к серверу баз данных, в результате чего командир получает информацию по боевым и разведывательным возможностям беспилотника. Весь этот блок данных — тип БЛА, его местоположение в реальном времени и его ТТХ — идет в вышестоящий узел сети для принятия решения. Если принимается решение поразить цель, то аналогично данные идут зенитному расчету.
Очевидно, что наладить подобное взаимодействие без помощи развитых средств связи немыслимо. И такие средства связи предполагалось создать с помощью JTRS. Большим подспорьем в этом проекте явилась технология Software Define Radio, SDR. С помощью нее все проблемы формирования излучаемого сигнала — частоты, мощности, модуляции уходили в программную область компьютера радиостанции. Так же и по отношению к радиоприему: большая часть тракта обработки принимаемого сигнала — демодуляция, декодирование, передача данных и голоса — теперь также приходилась на программную область. И этот подход до сих пор оправдал себя на практике вплоть до наших дней: любой мобильник представляет из себя SDR устройство. Чего же не хватило программе JTRS для того, чтобы быть успешной?
Евангелие от создателя продукта
Ключевая особенность JTRS заключалась в том, радиостанции создавались как программируемые устройства с возможностью дальнейшего апгрейда и развития софта, а также чтобы создавать новые приложения, которые могут стать необходимыми в будущем. Для того, чтобы разрабатывать ПО для каждого из вида радиосигналов (waveforms), требуется участие квалифицированных инженеров / программистов третьих сторон, то есть из команд, которые не являются частью больших компаний — исполнителей проекта. Необходимость подобного привлечения уже никто не оспаривает после того как военные обожглись на создании своей собственной операционной системы: задача по написанию и отладке более 15 миллионов строк кода (значение приведено для версии ядра Linux от 4.0) оказалась неподъемной ни за какие деньги, и поэтому с тех пор используются ОС, которые разрабатываются на коммерческом и открытом рынке.
Поскольку военные люди все делают по приказу, то по причине того, что некому было отдать такой приказ, или командиры не потрудились изучить, каким образом успешные бизнесы привлекают к своим проектам профессионалов, это направление было упущено. В подобных разработках притически важно создать успешный тренд, который будет развиваться самостоятельно (поддерживать тренды, в которых никто не хочет участвовать, не хватит никаких сил и денег).
Особенность самоподдерживающегося тренда состоит в том, что участники или вкладываются в успешный тренд и количество их увеличивается, либо они спрыгивают с тонущего корабля. Это хорошо понимали в таких компаниях как Microsoft и Apple, где для создания позитивного самоподдерживающегося тренда работают специальные люди — «евангелисты». Евангелист сосредотачивается на том, чтобы привлечь сторонних разработчиков программного обеспечения, чьи ранние инвестиции (личным ресурсом) в инструменты, повторно используемые компоненты и приложения имеют решающее значение для запуска тренда. Если завоевать симпатии комьюнити не получится, то дальше идти бесполезно: продукт умрет.
В программе JTRS не было своих евангелистов, чтобы вовлечь в разработку специалистов, которые работают за пределами военной области в обширном гражданском коммерческом секторе. JTRS соответствовала стилю разработки программного обеспечения и жизненным циклам системы, распространенным в сугубо военных приложениях, но которые не подходят для более широкого коммерческого применения.
В недрах программы JTRS была рождена стандартная программная платформа: Software Communications Architecture (SCA), которой должны были соответствовать все программные разработки. В результате между идеологией этой платформы и стилем разработки, принятым на открытом рынке возникли непримиримые противоречия, которые приведены в этой таблице:
Характерные особенности программы JTRS | Подходы в военной области | Подходы на коммерческом рынке |
Стандартная платформа | Заказывается централизованно, ограниченный объем поставок регулируется также централизованно | Выбирается владельцами бизнеса на основе признанных стандартов и протоколов, объем поставок большой |
«Военный» процесс разработки | Большие команды разработки
Высокий порог вхождения: дороговизна инструментов разработки Фокус на соответствие требованиям и правильность |
Небольшие гибкие команды
Малые вложения в инструменты разработки, как правило бесплатные лицензии Фокус на сокращение времени выхода продукта на рынок |
«Военный» жизненный цикл изделия | Длительный жизненный цикл
Стоимость сопровождения превышает стоимость разработки |
Короткий жизненный цикл
Стоимость разработки и производства преобладают |
Создатели RCA определили жизненный цикл SDR радиосредств, созданных на ее основе — 10 лет. Это значит они заглянули на 10 лет вперед и решили, что военные радиостанции будут современными и актуальными и в конце этого срока. Между тем, когда начиналась разработка JTRS, не было таких технологий как WiFi, 3G и 4G, и потоковая передача видео через Интернет. Лучшие военные умы создавали каналы цифровой связи скоростью аж 9600 бод. За это время жизнь ушла далеко вперед: WiFi стал массовым, народ смотрит потоковое видео с разрешением HD, что раньше нельзя было себе представить (и все это без технических заданий), а JTRS с добротными ТЗ осталась далеко позади.
Платформа RCA оказалась настолько сложной, что отпугнула многих внешних разработчиков ПО, которые могли бы создавать приложения для нее (вместо самоподдерживающегося тренда военные просто отпихнули чужих специалистов). Далее, RCA использовала древнюю технологию обмена данными Corba, что предполагает наличие программного интерфейсного модуля Corba в каждом сменном блоке. Это не проблема для тех блоков которые содержат процессор, под который разработка ПО ведется на языке высокого уровня. Однако, для ПЛИС, а также подобных низкоуровневых устройств, имеющих весьма специфическую архитектуру и систему команд, поддержка стека протокола Corba оказалось сложной и насла дополнительные накладные расходы, связанные со сложностью разработки и потерей быстродействия при передаче данных.
В результате, платформа RCA так и не смогла преодолеть круг разработчиков военного ведомства, и задача привлечения квалифицированных сторонних разработчиков ПО так и не была выполнена.
В этом программа JTRS полностью повторила ошибки военных по созданию языка программирования Ада, когда ограничение доступа к разработке приложений на новом языке привело к тому, что программисты переключились на другие, более доступные языки, и специалистов по Ада сейчас — кот наплакал.
Вы видели блоки в мобильнике?
На физическом уровне платформа RCA обеспечивает взаимодействие унифицированных модулей, которые могут заменяться в полевых условиях. Каждый конструктив имеет как минимум один процессорный модуль. Для ручных радиостанций использовался точно такой же подход, несмотря на то что модули жестко интегрированы в трубку и не подлежат оперативной замене. Это было вызвано необходимостью повторного использования ПО, которое было разработано для реально заменяемых модулей.
Как мы сейчас уже знаем, в противоположность такому подходу в коммерческих радио-продуктах используются чипы с высокой степенью интеграции, что исключает необходимость механической компоновки узлов и использования шины обмена (RCA), что связано с дополнительными потерями по быстродействию. В рамках коммерческого подхода радиочастотный модуль объединяется с преобразователями АЦП/ЦАП (аналоговый чип), в то время как в цифровом чипе совместно работают процессор общего применения и DSP/FPGA. Так например выполнена архитектура OMAP процессоров Texas Instruments.
Несмотря на то, что эти структуры обладают малой масштабируемостью, они используют эффективные платформы разработки и располагаются в существенно менее габаритном форм-факторе и цены на такие интегрированные компоненты существенно ниже. Поэтому в современном мобильном телефоне вы никогда не увидите такие блоки — они располагаются внутри чипа.
В результате архитектура JTRS была не только сориентирована на узкий круг специализированных исполнителей, но также и не использовала распространенные COTS решения огромного коммерческого рынка приложений, по причине своей жесткости. В результате открытый рынок, использующий собственные рентабельные стандарты, ушел далеко вперед (а что не уйти, если все деньги и лучшие специалисты — на этом рынке?)
И это все только на этапе разработки. На этапе обслуживания и сопровождения закрытые решения также обещали лечь тяжелым бременем на эксплуатацию.
Идея о том, что многообразие передаваемых и принимаемых сигналов — waveforms будет поддерживаться в программной области, а оборудование будет стандартизированным и его номенклатура будет ограниченной, вначале выглядела прекрасной. Далее, однако, выяснилось, что радиостанция — это все-таки инженерный, а не программисткий продукт. Программные модули для разных типов FPGA не получилось использовать за счет условной компиляции — для каждого типа ПЛИС пришлось писать свой код. Радиотракты (как и антенны) были сильно зависимы от диапазона и ломали архитектуру оборудования, а следом — соответственно начинала плыть архитектура ПО.
Кроме этого, одной из проблем JTRS было то, что войска нуждались в цифровой (новой) и аналоговой (для совместимости с унаследованным парком оборудования) связи в одной коробке. Данный фактор также препятствовал созданию полностью унифицированных модулей. Технические проблемы нарастали, и к ним еще начали добавляться сложности в управлении этим проектом, а также стало очевидным, что сами концептуальные основы JTRS начали подвергаться сомнению.
Кризис концепции и методологии — больше чем технические проблемы
Как вам нравятся предсказатели будущего, которые знают, каким будет мир через 10 лет, какое к этому времени будет железо, софт и технологии? Куда пойдет вектор развития? Вы представляете это ТЗ, которое рассчитано на 10 лет вперед?
Ладно, техническое задание — это конкретика. Поговорим о более философских вещах — концептуальных основах проекта. На концепции, как на фундаменте, стоят архитектуры, протоколы и технические решения JTRS. Одним из краеугольных камней программы было положение о том, что меняя программное обеспечение в FPGA, можно сократить номенклатуру плат и достичь реализации всего многообразия waveforms. Намек понятен: железо дорого и хлопот с ним много, его надо производить, поддерживать и ремонтировать, а софт — штука простая, один раз написал и прошивай все подряд.
Не знаю, были ли знакомы авторы программы JTRS с законом Мура, но они просто обязаны были предположить, что так будет не всегда. Сейчас стоимость аппаратных компонентов снижается с настолько драматичной скоростью, что гораздо проще и дешевле было бы иметь специализированные, заточненные под одну waveforms / вид сигнала платы, которые можно было паковать вместе, и не иметь никакого громоздкого унифицированного железа.
Методология исполнения JTRS как проекта также была раскритикована и названа главной причиной провала. Хотя проект развивался вполне в соответствии с принятыми в то время правилами Waterfall, или как сейчас его называют традиционной разработки (это то, как привыкли работать у нас и работают до сих пор). Идея методологии Waterfall (посмотрите на картинку и поймете почему это называется водопадом) очень проста: все необходимые действия надо выполнять последовательно.
В программе JTRS подобных блоков и субблоков было конечно гораздо больше, чем на картинке.
Я не исключаю, что именно после провалов проектов подобных JTRS, начался принципиальный пересмотр методов управления проектом, в результате чего возникли итеративные подходы к разработке.
Принципиальный недостаток подобной последовательной схемы можно продемонстрировать только одним фактом: в течение 13 лет разработчики последовательно выполняли программу, закрывая один этап и открывая другой, и в результате образцы радиостанций попали в войска, на тестирование конечным пользователям только в 2010 году.
Вдумайтесь! Тринадцать лет те, которым предстояло эксплуатировать эти радиостанции, не имели возможность высказаться и повлиять на процесс разработки. И когда тринадцать лет спустя в войсках увидели эти результаты, новые современные радиостанции JTRS получили нелицеприятную оценку «radio that weighed as much as a drill sergeant, took too long to set up, failed frequently, and didn’t have enough range» (радио весит столько же, сколько мой сержант-инструктор, слишком долго настраивается, часто отказывает и не дает дальности, которая нужна).
Что у нас?
Конечно, все что было сказано про боевое управление и связь относится также и к отечественным реалиям. Хронология получилась такая: в конце 2012 года появилось сообщение о том, что в войска начнут массово поступать цифровые радиостанции VI поколения «Азарт — П1». Конечно, нумерация поколений впечатляет, или может они ведут свое начало с искровых передатчиков?
Процесс появления новой радиостанции вызвал бурное обсуждение в комьюнити. Далее, в новости этого года было сказано, что радиостанции «Р-187П1 удалось не просто догнать, но и по некоторым позициям превзойти зарубежные образцы». Видимо, речь идет о той же радиостанции в портативном исполнении; в сети информация по возимому варианту отсутствует. В этой же новости было сказано, что радиостанция уязвима к средствам РЭБ и что к 2021 году будет производиться «сверхзащищенная» ее версия. Что-то мне подсказывает, что дополнительных версий будет еще много…
Конечно же, эта радиостанция — сетецентричная. Опять таки, нет данных, как реализована сетевая функция и какие waveforms используются. Вот тут, в наших реалиях точно нет никаких евангелистов и самоподдерживающихся трендов. Пирожок маленький, а желающих много: на всех не хватит.
Судя по всему, работы продолжаются, хотя очевидно и не с таким размахом как JTRS. Будем надеяться, что отечественные разработчики сделали выводы по результатам этой программы. В свое время было много отсылок на JTRS, типа «вот у американцев целый сетевой проект», потом отклики поутихли.
Ответить