Google Contacts API и авторизация OAuth2

Когда в адресной книге Google набирается несколько тысяч клиентов, становится тяжеловато ворочать этим объемным списком. Импорт/экспорт в странички Excel становится неудобным; кроме того появляются CRM-подобные приложения, в которых хотелось бы интегрировать самые разные базы данных, в том числе и контакты Google. Значит, пришло время доступиться к нашим контактам через консольные приложения, используя Google Contacts API.

Получение списка контактов

Используя API, мы можем не только получить список контактов, но также и видоизменять и дополнять его. В простейшем случае, первые 150 записей из адресной книги можно вытащить так, вбив это в адресную строку браузера:

Можно догадаться, что данные мы получим в формате json, что понятно, поскольку каждой записи в адресной книге соответствует куча полей, также понятно сколько записей будет выведено. И поскольку здесь нет ни нашего логина, ни пароля, можно предположить, что ACCESS_TOKEN – это та самая строка, которая обеспечивает авторизацию. Чтобы понять, как эта авторизация работает, мне в свое время пришлось выполнить несколько танцев с бубном. В этой статье делюсь результатами своих изысканий.

Регистрируемся в Google

Предполагаю, что у вас уже есть Google-аккаунт, или электронная почта. Логинимся на страничке Гугла и идем по адресу https://console.developers.google.com/cloud-resource-manager , где создаем новый проект. Даем ему произвольное название, например Beerware. Дальше переходим в другое место https://console.developers.google.com/apis/credentials. Жмем кнопочку “Создать учетные данные” и выбираем “Идентификатор клиента OAuth”, и дальше отмечаем “Другие типы”. Дадим название идентификатору – скажем Beerware Script.

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

Это все, что нужно было сделать в девелоперских панелях Гугла. Если вы нажмете на редактирование идентификатора, то увидите ID клиента и секрет клиента. Запомним эти названия, они понадобятся нам дальше. Чтобы не путаться с обозначениями при подстановке в другие строки, обозначим их CLIENT_ID и CLIENT_SECRET.

Authorization Flow: как проходит авторизация OAuth2

Конечной целью авторизации является получение ACCESS_TOKEN, который необходимо использовать каждый раз когда мы делаем запрос к адресной книге. Теперь нам нужно внимательно пройтись по всем этапам. Самая главная вещь, которая толком не описана в документации Google – какие этапы выполняются только один раз, а какие нужно выполнять периодически. Я буду это подчеркивать.

Каждый этап – это обращение к серверу Google по HTTPS и получение ответа. Детали запроса я распишу позже, сейчас главное – уяснить общую схему.

Получение кода авторизации

Код авторизации сразу ставит в тупик. Зачем он нужен, если уже есть CLIENT_SECRET?  Разница в том, что код авторизации используется только один раз – для получения токенов. Замечу сразу, что если вы попытаетесь получить по одному и тому же коду авторизации токены еще раз, то получите ошибку. Таким образом, код авторизации действителен пока мы еще не получили токены. После их получения он сразу “протухает”. Но об этом – дальше.

CLIENT_SECRET, как и CLIENT_ID – постоянные строки, скрытые в нашем приложении вдали от посторонних глаз.

Итак, посылаем на сервер CLIENT_ID, CLIENT_SECRET и получаем код авторизации. Назовем его AUTH_CODE.

Получение токенов

И снова заголовок наводит на размышления. Почему токены во множественном числе, когда вначале говорилось только об ACCESS_TOKEN? На самом деле, помимо этого токена, который используется при работе с адресной книгой, нам дают еще REFRESH_TOKEN. Его роль будет ясна ниже.

Посылаем на сервер CLIENT_ID, CLIENT_SECRET, AUTH_CODE и получаем парочку ACCESS_TOKEN, REFRESH_TOKEN.

Казалось бы, тут можно забыть о REFRESH_TOKEN, поскольку ACCESS_TOKEN  у нас в руках, и дальше еще забыть и про авторизацию и спокойно пользоваться ACCESS_TOKEN во всех запросах. Я так поначалу и делал, только обнаружил что в один прекрасный момент сервер перекрыл мне доступ. В чем дело? А причина была в том, что по задумке Google время жизни ACCESS_TOKEN – всего лишь час, после чего он протухает и работать с ним не получится.

Что теперь, снова получать код авторизации и токены? Нет. Про эти два этапа “получение кода авторизации” и “получение токенов” можно полностью забыть и уже никогда к ним не возвращаться. Самое главное, что у нас есть – это REFRESH_TOKEN. Сохраните его в надежном месте, поскольку теперь кроме него нам ничего не нужно.

Замечу, что эти пройденные этапы мы выполняем лично. Наше приложение Beerware Script о них ничего не знает: ему нужны только токены.

Получение ACCESS_TOKEN по REFRESH_TOKEN

Дальше все становится просто. Когда ACCESS_TOKEN протухает, то есть через час становится не действительным, или просто не дожидаясь этого момента, мы посылаем на сервер CLIENT_ID, CLIENT_SECRET, REFRESH_TOKEN и получаем обновленное значение ACCESS_TOKEN, которое используем для запросов к серверу. Важно знать, что при этом REFRESH_TOKEN не меняется. Поэтому для приложения критично запомнить его, например в файле, при получении в самый первый раз.

Все этапы авторизации из командной строки

Для различных языков есть соответствующие библиотеки OAuth2. Мы же, для ясности изложения, все будем делать ручками из командной строки, формируя запросы с помощью утилиты curl. В конце концов, все эти библиотеки делают тоже самое – формируют url запросы к серверу Google.

Начнем с получения кода авторизации. Поскольку эта процедура выполняется только раз, не грех поработать вместо нашего приложения. Вбиваем в адресную строку броузера и наблюдаем:

Запросом response_type=code мы хотим увидеть код авторизации. Он будет переслан по адресу redirect_uri, а поскольку на URI=http://localhost:8080 ни у меня, ни думаю у вас – ничего нет, то естественно браузер даст ошибку. Но это неважно, поскольку искомый код появится в адресной строке браузера и мы возьмем его оттуда, копируя начиная с code= и продолжая до символа #, который присутствует в конце url. Так мы получаем AUTH_CODE.

В середине процедуры вас может пробросить на страницу авторизации, где вы должны подтвердить доступ к адресной книге со стороны проекта Beerware.

Теперь получаем токены. На запрос

сервер выдаст нам долгожданную парочку токенов:

Если мы попробуем получить токены еще раз, с использованным кодом авторизации, нас ожидает ошибка:

Все, код авторизации протух и с ним уже сделать ничего нельзя!

На этом ручная работа закончилась и скрипт Beerware Script может начинать работу. Отдаем ему ACCESS_TOKEN и REFRESH_TOKEN и забываем про авторизацию. Все, что нужно делать скрипту когда ACCESS_TOKEN становится недействительным – это получить его новое значение запросом

Само собой, это будет уже не утилита curl, а https запрос с соответствующей библиотеки нашего приложения Beerware Script.

После запроса мы получим новый ACCESS_TOKEN:

Поработаем с адресной книгой

Теперь самое время посмотреть, как будет выглядеть работа со списком адресов. Как обычно, на этом этапе нам ассистирует Python. Ниже – фрагменты скрипта Beerware Script, которые дают представление об общей идее работы с полученным списком.

Вначале затребуем список:

В комментах видно, в каком месте нужно ловить ошибку авторизации, когда ACCESS_TOKEN устареет. Дальше нужно что-то делать с полученным списком адресов, наверное самое очевидное – это получить номера телефонов.

Делается это в цикле по всей структуре data:

В результате после работы скрипта получим список контактов, где под каждой фамилией будет список телефонов. Тема отдельного рассмотрения – как изменять существующие контакты и заводить новые. Это решается засылкой на сервер соответствующей xml записи. Подробно процедура описана здесь. Думаю, вы и сами отлично справитесь с этой задачей )

Согласованный фильтр 2D: поиск соответствия в изображении

Согласованную фильтрацию можно рассматривать как во временной, так и в частотной области.

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

Еще нагляднее физический смысл проявляет себя в частотной области: согласованный фильтр “доворачивает” спектральные составляющие сигнала ровно настолько, чтобы они складывались синфазным образом, достигая максимального выходного эффекта. Чтобы доворот происходил в направлении компенсации, используется комплексно-сопряженное значение передаточной функции фильтра.

Часто реализацию согласованного фильтра выполняют в частотной области, используя наработанные библиотеки быстрого преобразования Фурье (БПФ).

Вот пожалуй и все, что хотелось бы сказать про согласованный фильтр (СФ). Поехали дальше.

От времени к пространству

Что скажете, если мы займемся фильтрацией пространственных данных? Это немного непривычно, поскольку мы обычно связываем сигнал с изменениями во времени. С другой стороны, когда смотрим на график этого сигнала то видим только рисунок, и ничего более. И фактически работаем с этим рисунком. Только это будет одномерная обработка, где ось времени будет просто абстрактной осью x.

С двумерными изображениями физический смысл ускользает. Как представить этот сигнал изменяющимся во времени, когда он содержит уже две “псевдовременные” оси? Поэтому нам лучше оторваться от привязки ко времени и воспринимать сигнал тем, чем он является – 2D изображением. Что интересно, для многомерных сигналов также существует понятие пространственных частот, и это активно используется при изучении работы объемных антенных решеток.

Маджонг: найти кубик

Чтобы наше повествование не выглядело слишком солидным и серьезным, выберем в качестве входного сигнала изображение россыпи кубиков Маджонг:

Исходная сцена для поиска кубика, соответствующего шаблону

Поставим себе задачу: найти в этой россыпи определенный кубик, например такой:

Шаблон для поиска

Как вы догадались, этот кубик, который я буду использовать в качестве шаблона, просто скопирован из исходной сцены – россыпи. Вот кстати, можно сразу немного поиграть в Маджонг: найдите этот шаблон на сцене!

При этом будем считать, что окружающие кубик куски – это тоже часть шаблона. Не будем обрезать его до идеального, ведь лучшее – враг хорошего )

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

Теперь пришло время дать правильные названия всем действующим лицам и участникам.

Кто есть кто

Итак, наша сцена – это смесь сигнала и помехи. Сигнал – кубик, который мы заприметили (надеюсь что вы уже увидели его на сцене), все остальное – это помеховый фон.

Наша задача: найти этот кубик на сцене с помощью 2D согласованного фильтра, и не только найти, но и сразу определить его местоположение. Структура СФ будет определяться шаблоном для поиска – этим же кубиком, который на этот раз сам по себе.

Поскольку в этой задаче нет никакого времени, попробуем обозначить шаги ее решения в частотной области. СФ работает следующим образом:

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

Перед фильтрацией необходимо найти пространственные спектры сцены и нашего опорного кубика:

Запускаем интерпретатор Питона (да, это был именно он) и смотрим на результаты.

Результат работы согласованного фильтра 2D

Я добавил в программу небольшой вспомогательный код, чтобы отмечать зеленой рамкой на сцене месторасположение максимального отклика на выходе СФ. На рисунке сцена (сигнал+шум) расположена слева, отклик согласованного фильтра – справа. Белый цвет соответствует максимальному отклику.

Согласованный фильтр 2D, 2D Matched Filter

Результат работы согласованного фильтра 2D для поиска шаблона

На картинке отклика СФ хорошо видна яркая точка, соответствующая пику выходного сигнала. Ее расположение в точности соответствует положению верхнего левого угла шаблона. Поэтому можно сказать, что с задачей мы справились: нашли совпадающий кубик по шаблону, или отфильтровали помеху от сигнала, используя опорный сигнал.

Я также провел второй эксперимент, в котором поставил на сцену шаблон еще раз, в другом месте. По идее, СФ должен показать наличие двух согласованных с опорным сигналов. Так оно и есть: на картинке отклика СФ наблюдаем две яркие точки, соответствующие положению двух шаблонов на сцене.

Согласованный фильтр 2D, 2D Matched Filter

Результат работы согласованного фильтра 2D со сценой, содержащей два шаблона

Интересное наблюдение: на картинке отклика СФ наблюдается небольшое светлое пятно, соответствующее определенному совпадению с сигналом шаблона. Я долго не мог понять, что он там нашел, а потом догадался: ведь искомый кубик имеет повторяющуюся структуру, и этой области немного не хватило рисунка, чтобы продолжить следующие шесть точек на юго-восток. Совпадение получилось только наполовину, что дало всплеск на выходе СФ.

Может возникнуть такой вопрос: если помеха отфильтрована, почему на выходе СФ мы не наблюдаем чистый сигнал? Вот такой он, согласованный фильтр: использует всю информацию о сигнале, и на выходе ее уже не остается. Только уровни, которые только и остается что сравнивать. Если бы на выходе мы наблюдали признаки формы сигнала, это означало бы, что СФ не использовал эту информацию в обработке.

Также открою маленький секрет: выход СФ есть не что иное, как двумерная корреляционная функция сцены и шаблона.

Эта статья – аэродром подскока, который мы используем позже, когда начнем распознавать маркеры системы автоматической визуальной посадки беспилотников. Эта игрушка будет посильней Маджонга!

Алгоритм MUSIC: MUltiple SIgnal Classification в оценке спектра

Вот мы наконец и добрались до этого метода. Литературы по этой технике – целая куча, но как обычно смысл ускользает. Само описание MUSIC достаточно простое: это поиск экстремума произведения двух матриц. Однако что происходит внутри этих матриц – с этим нам предстоит разобраться.

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

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

Компактный симпатичный спектр из двух частот

Зададим исходные данные. Будем иметь дело с сигналом, состоящим из двух частот; также подмешаем немного шума, для реальности происходящего:

На самом деле, мы будем наблюдать смесь этих сигналов, и наша задача – определить какие частоты присутствуют в его спектре. Поэтому наблюдаемый сигнал X будет суммой этих массивов:

Суммирование идет по выборкам, о чем говорит выбор оси axis=1. Поэтому размерность полученной матрицы будет N x 1.

Как и во многих алгоритмах линейного предсказания, в том числе и в MUSIC, конкретная реализация сигнала не представляет большого интереса. Гораздо более важной и обобщенной характеристикой является корреляционная, а точнее автокорреляционная матрица Rxx, выявляющая внутренние связи во входных данных X:

Update:

Матрица Теплица использована для удобства расчета автокорреляционной матрицы, каждый элемент которой представляет собой dot-продукт сигнала sig и его смещенной копии. Чтобы не делать смещение в цикле, с помощью матрицы Теплица входной сигнал (вектор Nx1) превращается в заготовку — матрицу XT размером NxN, которая уже содержит все допустимые сдвиги сигнала sig от 0 до N-1.

Остается только получить dot продукт этой заготовки обычным выражением dot=XT*XT.H

А теперь – прощай, сигнал X! В нашем алгоритме ты нам больше не понадобишься. Вместо тебя будет работать твоя корреляционная матрица Rxx. Сразу скажу, что быть на сцене ей тоже осталось недолго: после того как мы находим собственные числа en и векторы ev корреляционной матрицы Rxx, она тоже перестает быть нужной:

Гарантирую, что с этого момента вы потеряли нить и вам расхотелось читать дальше ) Поэтому самое время остановиться и понять смысл того, что мы делаем. Тем более что большую часть алгоритма мы уже прошли: осталось фактически только одно последнее действие ) Вот она, обманчивая простота матриц!

Итак, наступил обещанный момент погружения в матричные пространства.

Зачем нужны собственные числа и векторы

Идея метода MUSIC состоит в разделении пространства входных сигналов на сигнальную часть и помеховую. Для пространства сигналов существует свой базис, в котором может быть разложена корреляционная матрица Rxx. Поскольку Rxx является самосопряженной (сравниваем Rxx и Rxx.H в Питоне – это одно и то же), то базис разложения будет ортогональным и будет представлять из себя не что иное, как собственные векторы матрицы, масштабированные собственными числами. Что такое ортогональное разложение вы конечно же помните из школьной геометрии, когда рисовали проекции вектора на ортогональные оси x и y. Только это было двумерное пространство, которое легко представить геометрически, а в нашем случае размерности пространства N только и остается, что положиться на формулы.

Проверим, соответствует ли Rxx разложение по ортогональному базису:

результат будет соответствовать Rxx.

Теперь мы можем предположить, что одна часть собственных векторов, участвующих в разложении Rxx, соответствует сигналу, а другая часть – помехе. Будем также держаться предположения, что полезных сигналов – P, а все остальное в количестве N-P это помехи или шум. Наше предположение некоторым образом подтвердят собственные числа, если мы расставим их в порядке убывания:

По собственным числам можно судить об уровне входных сигналов: как и ожидалось, первые P=2 это полезный гармонический сигнал, остальное – это помеха. Не откладывая на потом, сразу упорядочим и собственные векторы, чтобы они соответствовали собственным числам, расположенным по убыванию:

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

результат – вектор практически близкий к нулю, что и означает ортогональность.

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

Разложение экспоненциального вектора на базис помехи

Теперь все дело за тем, как правильно записать нотацию искомого разложения. Собственные векторы помехи мы уже выделили раньше: это вектор EV. Вектор комплексных опорных сигналов будет иметь размерность N:

Значения частот будем перебирать из диапазона:

Абсолютное значение спектра будем находить как модуль разложения REF*EV.H*EV*REF.H.

Тогда полный цикл перебора опорного вектора будет выглядеть так:

Для удобства отображения графика, полученные значения масштабируются в логарифмическом масштабе.

Заметим еще раз: в цикле подбирается такое значение частоты, чтобы разложение опорного вектора в базисе помехи было максимально близко нулю. Это будет означать ортогональность по отношению к пространству помехи и как следствие – соответствие текущего опорного вектора одному из сигналов.

показан на рисунке.

Начнем с P=2:

MUltiple SIgnal Classification, MUSIC, Eigenvectors, Eigenvalues, Оценка спектра, Корреляционная матрица, Correlation Matrix

Оценка спектра MUSIC для P=2

Здесь неожиданностей нет. На рисунке четко видно два пика относительной частоты 3.0 и 5.0, причем уровень второго сигнала ниже. Мы четко определили наличие двух синусоид в комплексном сигнале в присутствии шума, причем получили значение частот этих сигналов и относительные амплитуды. Теперь возникает интересный вопрос: что произойдет если мы зададим P=1? По идее алгоритм должен посчитать за полезный только один сигнал, а вторую синусоиду вместе с шумом отнести к помехе. Так оно и есть:

MUltiple SIgnal Classification, MUSIC, Eigenvectors, Eigenvalues, Оценка спектра, Корреляционная матрица, Correlation Matrix

Оценка спектра MUSIC для P=1

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

Продолжаем эксперимент.  Теперь предположим, что на входе три полезных сигнала, то есть P=3. Что произойдет если белый шум также будет засчитан на равных как нечто полезное?

MUltiple SIgnal Classification, MUSIC, Eigenvectors, Eigenvalues, Оценка спектра, Корреляционная матрица, Correlation Matrix

Оценка спектра MUSIC для P=3

Получилось довольно неприятно, но не смертельно. Третий всплеск конечно достаточно большой по амплитуде, и такой же всплеск наблюдаем на нулевой частоте. Но мы сами задали шуму приличный уровень – 0.5, так что метод MUSIC довольно лояльно относится к тому, что мы неточно определили количество полезных сигналов.

Продолжим расширять наше представление о количестве полезных компонент и зададим P=4:

MUltiple SIgnal Classification, MUSIC, Eigenvectors, Eigenvalues, Оценка спектра, Корреляционная матрица, Correlation Matrix

Оценка спектра MUSIC для P=4

Как ни странно, картинка стала даже еще лучше. Как и в предыдущих случаях, два полезных сигнала занимают максимум лепестков диаграммы, и хорошо заметно что ошибка в предсказании P дает ее заметное искажение.

Теперь, после того как мы использовали MUSIC для оценки частотного спектра, можно переходить к пространственным частотам – определению направления прихода сигнала, чем мы так любим заниматься в радиопеленгации. Об этом поговорим в следующей статье. И не забывайте что эта тоже была аэродромом подскока!

 

 

 

АРП DF-2000: что пошло не так с этим радиопеленгатором

Историю современных радиопеленгаторов для аэропортов гражданской авиации можно отсчитывать от момента появления новой версии АРП “Платан” с процессорной обработкой и операционной системой. В то время было принято, что радиоприемные устройства (РПУ) – покупные “Юрки” будут компромиссным решением (за неимением радиоприемника своей разработки). Вначале разрабатываемое цифровое РПУ было частью пеленгационного проекта, но со временем руководство конторы решило выделить его в отдельное направление. Возможно, повлияло желание сделать унифицированный со связным приемник, хотя у каждой унификации есть своя цена. Но не будем забегать вперед )

По завершении разработки нового АРП “Платан” я переключился на собственные проекты, но продолжал интересоваться ходом модернизации пеленгатора, который должен был обзавестись своим радиоприемным трактом. И он появился: РПУ, более известное под названием ФИС, было выполнено на профессиональном уровне инженерами которые тогда еще работали в конторе (ну вот, снова вперед забежал). Классическая супергетеродинная схема с перестраиваемым преселектором обеспечивала отличные характеристики электромагнитной совместимости (ЭМС), такие как избирательность по соседнему каналу, подавление интермодуляционных продуктов. Ведь не секрет что эфир со временем не становится чище, и разнообразных помех, таких как профессиональные и любительские радиостанции, станций GSM, Wi-Fi и других становится все больше и больше. Поэтому обеспечение ЭМС выходит на первый план, тем более что современные радиокомпоненты позволили практически закрыть вопросы чувствительности АРП и улучшения отношения сигнал/шум.

Как и в АРП “Платан” с Юрками, так и с ФИСами у эксплуатации не было никаких нареканий. Но начиная с определенного времени, замечания посыпались. Вплоть до таких, как:

“у радиопеленгатора DF-2000 во время грозы, ложные пеленги на всех частотах. Думаем, что надо чувствительность прм. уменьшать,пока ждем ответа заводчиков” (с форума инженеров ЭРТОС).

На АРП с ФИС нареканий нет:

“У нас один из первых DF-2000 с ФИС ами. Ложных пеленгов на метеоявления, в отличии от АРП-75, не наблюдалось ни разу с 2008 года”

Это удивительно, потому что в радиопеленгаторе “Платан” была эффективная схема фазового обнаружения сигнала, которая давала очень низкие уровни вероятности ложной тревоги. И “пробить” ее на ложный пеленг, тем более при грозовых электромагнитных возмущениях, было нереально. Было очевидно, что что-то пошло не так. В конечном счете, причина была найдена: сбои в работе АРП DF-2000 были связаны с очередной модернизацией, а именно с заменой ФИС на цифровой приемник. Само собой, эта эволюция проходила уже без моего участия.

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

Цифровой радиоприемник в АРП DF-2000: тотальная “оптимизация”

Структурная схема пеленгационного приемника приведена на рисунке. Собственно говоря, это тот же самый приемник RS-2000, который используется в приемных центрах TRS-2000 производимых и поставляемых АО “Азимут”. Разница лишь в фрагменте по правую сторону от АЦП – в программном обеспечении. И в том, что этот аппаратно одночастотный приемник превратился в РПУ, работающий на 4-х частотных каналах одновременно.

Ключевой аспект в этой истории – как раз слово “одновременно”.

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

АРП, DF-2000, Цифровой радиоприемник, блокирование, SDR, Software Defined Radio, АРП Платан

Аналоговая часть РПУ радиопеленгатора DF-2000 представляет приемник прямого усиления.  Разделение частотных каналов происходит после оцифровки АЦП. Преселектор отсутствует, поэтому весь эфир из диапазона 118 -136 МГц поступает на вход АЦП.Внимание: такая схема построения подвержена блокированию и имеет плохие характеристики ЭМС!

Смотрим тракт начиная с антенной системы. Принимаемый сигнал усиливается в приемнике прямого усиления, с помощью АРУ загоняется в диапазон входных сигналов АЦП, и далее цифровая обработка сигналов выделяет свой частотный канал, подавляя сигналы других радиостанций. Поскольку в отличие от классической супергетеродинной схемы здесь нет преселектора, подобная структура имеет все недостатки приемников SDR. В одной статье я уже ссылался на подробное описание этих недостатков, сделаю это еще раз:

“Основным недостатком, ограничивающим широкое применение подобного типа РПУ (с прямой оцифровкой сигнала с антенны – мое примечание), является невозможность обеспечения высоких уровней динамического диапазона по блокированию. Поскольку на входе АЦП отсутствует фильтрация, то АЦП соответственно не может выполнять оцифровку одновременно сигналов большого и малого уровня. В соответствие нормам ГОСТ радиоприемник должен обеспечивать уровень восприимчивости по блокированию не менее 126 дБ/мкВ для РПУ второго класса и 130 дБ/мкВ для РПУ первого класса. Очевидно, что существующие типы АЦП 14-16 бит не в состоянии обеспечить выполнение этого параметра.

Кроме этого, РПУ данного типа недостаточно качественно осуществляют обработку сигналов малых уровней. При приеме сигналов уровней чувствительности, рост ошибок квантования, вызванный недостатком разрядности АЦП, вызывает невозможность качественного приема. Естественно, что эти ограничения разработчики пытаются снижать конструктивными и программными средствами, но до появления на рынке высокочастотных АЦП с разрядностью не менее 24 бит, приемники данного типа не смогут соответствовать современным нормам по электрическим параметрам и составить полноценную конкуренцию аналоговым РПУ”.

Поскольку приемник прямого усиления никак не защищает вход АЦП от помех, то сигналы любого радиопередатчика из диапазона 118 – 138 МГц и не только – будут напрямую давить на вход АЦП и снижать его реальный динамический диапазон. Чужие радиостанции, VOR, DVOR, даже импульсные сигналы локаторов – будут способствовать блокированию АЦП, и дальнейшая цифровая фильтрация будет бессмысленной. Собственно, этот процесс и наблюдается в эксплуатации.

АРП DF-2000 блокирует сам себя: принципиальные ошибки построения тракта обработки

Вернемся к нашему рисунку. Проведем мысленный эксперимент: будем наблюдать одновременное прохождение пеленгуемых частот f1, f2, f3, f4 через приемный тракт. При этом создадим для АРП льготный режим: представим, что помех вообще никаких нет, то есть в районе аэродрома выключены все связные и радионавигационные устройства. И представим, что эти сигналы имеют одинаковый уровень: на связь одновременно вышли четыре борта с одинаковой мощностью радиостанции и на одинаковом расстоянии.

С антенны все четыре сигнала усиливаются в приемнике прямого усиления и подаются на вход АЦП. Автоматическая регулировка усиления (АРУ) наблюдает суммарный сигнал и не в состоянии различать сигналы по частотам, поэтому к 16-разрядной сетке АЦП будет приведена сумма сигналов f1, f2, f3, f4 и как результат каждый из них будет подавлен в 4 раза. Я хочу подчеркнуть еще раз: все, что находится в эфире в полосе 118 – 136 МГц – свои сигналы с борта и многочисленные источники излучения в этом диапазоне, будет усилено и поступит на вход АЦП, поскольку в АРП DF-2000 приемник не имеет преселектора, то есть 2 бита из 16 динамического диапазона АЦП мы уже потеряли. В цифровой части после АЦП помеховые сигналы отфильтровываются четырьмя фильтрами, каждый из которых настроен на частоту канала пеленгования, и извлекается пеленгационная информация. Пока все ОК.

Теперь изменим исходные условия и сделаем их приближенными к реальности. На высоте 10000м на дальности 350км летит борт, который выходит на связь. Такая дальность для АРП не диковинка: ее максимальное значение при такой высоте и мощности радиостанции 5Вт по ТТЗ составляет 360км. Поэтому радиопеленгатор должен отработать без проблем. Поскольку приемник прямого усиления DF-2000 усиливает все подряд в диапазоне 118 – 136МГц, на входе АЦП будет все, что работает в этой широкой полосе в районе аэропорта. Не будем считать мощные помехи от VOR, DVOR, а также гармоники мощных сигналов первичных и вторичных радиолокаторов. Ограничимся рассмотрением передатчиков местного приемо-передающего центра; предположим что в определенный момент на передачу выходят одновременно 8 радиостанций. Тогда на входе АЦП будет смесь слабого сигнала с борта и мощных радиостанций центра.

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

В нашем случае главный подозреваемый на блокирование – АЦП. Если его небольшой динамический диапазон будет перегружен, то никаких нормальных сигналов на выходе мы не увидим.

Продолжаем наши опыты ) Для того, чтобы попасть в динамический диапазон, приемнику придется задействовать АРУ таким образом, чтобы сумма сигналов на входе АЦП не превысила максимального значения. При этом необходимо контролировать не суммарную мощность, а амплитуду. За счет биений суммарный сигнал максимальной амплитуды будет равен сумме амплитуд полезного сигнала и помехи.

Как и в предыдущем примере, АРУ откалибрует суммарный сигнал только по самому сильному составному – в нашем случае по помехам которые создает передающий центр. Усиление будет достаточным только для прохождения помех, а наш сигнал с борта потеряется на уровне младших битов АЦП.

Говоря другими словами, в четырехканальном тракте частота самого сильного сигнала блокирует сигналы более слабых передатчиков. То есть, в этом случае никакой “одновременной” работы четырех каналов радиопеленгатора не получается.

Это гипотеза, осталось подкрепить ее цифрами.

Считаем уровни

Найдем соотношение полезного сигнала и помех. В качестве помехи, как мы условились раньше, будем считать 8 передатчиков передающего центра, расположенные от АРП на расстоянии 500м. Для расчета будем пользоваться зависимостью потерь распространения в свободном пространстве FSPL (Free Space Path Loss, потери распространения в свободном пространстве):

\displaystyle\large FSPL=\bigg(\frac{4{\pi} R}{\lambda}\bigg)^2

Разница в дальностях до борта и передающего центра дает искомое соотношение; для R1=350км, R2=0.5км получаем:

\displaystyle\large \frac{FSPL_2}{FSPL_1}=\bigg(\frac{R_1}{R_2}\bigg)^2=490000=56.9dB

Теперь нужно учесть разницу между мощностями сигналов бортовой и наземных радиостанций, которая составит 100 Вт (земля)/5 Вт (борт) = 20 = 13dB, итого суммарно разница между сильным и слабым сигналом на входе АЦП составит 56.9+13=69.9dB.

По напряжению разница 69.9dB составит 3126 раз. Уточним еще раз: это разница между уровнем по амплитуде одной радиостанции передающего центра и радиостанции борта на входе АЦП. Теперь надо учесть, что радиостанций – восемь. При одновременной передаче максимальные амплитуды суммируются, поэтому разница в уровнях станет еще больше – 3126*8 = 25008. Что там с нашим динамическим диапазоном АЦП? Для 16 разрядов он равен 65536. После того как АРУ уместит суммарный пеленгуемый сигнал в разрядную сетку АЦП, для сигнала борта останется 65536 / 25008 = 2,62 уровня. Это практически 1 бит АЦП, который работает на уровне шума! Для сигнала работает только 1 бит АЦП: вот оно, блокирование.

Заметьте, что теперь нет смысла говорить про частотное разделение сигналов: сигнал с борта до фильтра просто не дойдет. Таким образом, в такой помеховой обстановке АРП DF-2000 борт просто не увидит. Что и наблюдается на практике.

Снова не могу удержаться, чтобы не заметить, что радиотехнику должны разрабатывать не программисты, а инженеры ) Концепция “все загоним в цифру а там уже разберемся” не работает. Как следствие – на выходе дешевое как в смысле стоимости, так и в смысле параметров изделие. Инженеры ушли, оптимизаторы остались.

А жаль, хороший пеленгатор был вначале.

Устойчивость АФАР/AESA радиолокатора F-35 к блокированию T/R модулей

F-35, АФАР, ПФАР, AESA, PESA, Radar, Радиолокатор, Локатор, Antenna  Pattern, блокирование, обнаружение, мощность, TRM, T/R module, Transmit Receive Module

Антенная решетка локатора AN-APG-81 самолета F-35

Бортовые радиолокаторы военных самолетов, предназначеные для поиска и сопровождения целей проходят эволюцию от пассивных фазовых антенных решеток (ПФАР, или PESA – Passive Electronically Scanned Array) к активным фазовым антенным решеткам – АФАР, или AESA: Active Electronically Scanned Array). Базовым элементом и тех и других является приемо-передающий модуль – Transmit/Receive Module, TRM. И если в пассивной решетке он практически в единственном экземпляре, то в активной на каждый элемент приходится по одному TRM.

В локаторе AN/APG-81 истребителя-бомбардировщика F-35 дотошные юзеры насчитали 1676 элементов; можно представить какой объем оборудования займут TRM и какова будет стоимость. АФАР – удовольствие не из дешевых! Но и возможности по сравнению с ПФАР неизмеримо выше: одновременное сопровождение нескольких целей, сканирование произвольных областей пространства, произвольный выбор сигналов и многое другое. Но нас в данном случае интересует не количественное увеличение сложности АФАР, а принципиальные изменения в тракте обработки сигнала, которые за ним последовали.

F-35, АФАР, ПФАР, AESA, PESA, Radar, Радиолокатор, Локатор, Antenna  Pattern, блокирование, обнаружение, мощность, TRM, T/R module, Transmit Receive Module

Transmit-Receive Module, T/R модуль

На фото слева показан T/R модуль, возможно даже от F-35. Каждая сборка обслуживает несколько элементов антенной решетки и содержит малошумящие усилители LNA (цепь приема) и усилители мощности HPA (цепь передачи). Переключение на прием/передачу производится по внешним сигналам управления. Сигнал, принимаемый элементом антенной системы, усиливается LNA и подвергается аналого-цифровому преобразованию. Дальнейшая обработка идет в бортовом сигнальном процессоре.

АФАР/AESA и ПФАР/PESA: что за чем следует

Мы хотим выявить теоретические и практические отличия в образовании диаграммы направленности активной и пассивной антенных систем. В соответствии с принципом обратимости нет разницы, для какого режима – прием или передача проводить анализ, это во первых, и во вторых интересующий нас вопрос блокирования относится сугубо к приему АФАР. Поэтому рассмотрим, как работает диаграммообразующая система (ДОС) в обоих случаях – для AESA и PESA.

F-35, АФАР, ПФАР, AESA, PESA, Radar, Радиолокатор, Локатор, Antenna  Pattern, блокирование, обнаружение, мощность, TRM, T/R module, Transmit Receive Module

Расположение T/R модулей по одношению к диаграммообразующей системе. В АФАР/AESA (активная решетка) T/R модули располагаются до ДОС, в ПФАР/PESA (пассивная решетка) T/R модуль располагается после ДОС. В АФАР фазовый сдвиг вносится в компьютере, в ПФАР – с помощью управляемых фазовращателей

В АФАР сигнал элементов антенны принимается T/R модулями и поступает в сигнальный процессор, который назначает каждому элементу АФАР весовой коэффициент и фазовый сдвиг, после чего после численной обработки все сигналы суммируются. Синфазное суммирование, дающее максимальный сигнал будет формировать основной лепесток диаграммы; сигналы с других направлений будут складываться неоптимальным образом, давая на выходе невысокие уровни, которые мы называем боковыми лепестками.

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

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

Итак, математическая процедура ДОС в случае активной и пассивной решетки совершенно идентична: разница лишь в том, что в локаторе с АФАР формирование диаграммы производится в вычислителе, а в локаторе с ПФАР – аппаратно в самой антенной системе. Таким образом, теоретических различий между этими способами реализации – никаких. С практической точки зрения, особых проблем тоже как-бы не видно. Но это только на первый взгляд.

Сейчас мы пришли к той точке, когда программисты, поставив этот знак равенства, успокаиваются и идут пить кофе, а инженеры начинают беспокойно ерзать на своих стульях. И это неспроста! Инженеры знают, что полная аналогия между программной и аппаратной обработкой оправдана только тогда, когда приемный тракт является линейным по отношению к входным сигналам. В реальных же условиях, тем более с учетом радиолокационного противодействия, это может быть совсем не так. И тут уже появляется принципиальная разница в поведении ДОС у активной и пассивной решетки, и эта разница совсем не в пользу АФАР. Приступаем к эксперименту.

Ставим помеху, или как jamming портит красивую картинку

Эксперимент будет проходить следующим образом. Устанавливаем источник помехи и будем наблюдать, какое воздействие это возымет на АФАР и ПФАР. Требования к помехе не сильно жесткие: достаточно, чтобы ее мощность создавала достаточный уровень в динамическом диапазоне T/R модулей; тип модуляции не принципиален, частота тоже: достаточно чтобы она была в достаточно широкой полосе пропускания антенных систем. Расположение источника помехи тоже некритично: достаточно лишь, чтобы он находился в диапазоне углового сканирования радиолокатора.

На этом этапе, вслед за программистами уходят пить кофе менеджеры и журналисты. Ведь они прекрасно знают, что для этого и формируется диаграмма направленности, чтобы подавлять подобные помехи. Более того, АФАР прекрасно может запеленговать источник и сформировать диаграмму таким образом, чтобы в направлении помежи был нулевой уровень диаграммы. Поэтому помеха будет подавлена провалом в сформированной диаграмме направленности. Тоже на первый взгляд.

Да, это действительно так, но… опять таки справедливо только тогда, когда тракт приема является линейным. Если помеха является блокирующей, то есть нарушающей линейность тракта, то благостная картинка просто перестает существовать. В ГОСТах, которые формируют требования к профессиональной радиоприемной технике, этот параметр так и называется – блокирование, который определяется как “изменение отклика на полезный радиосигнал при наличии на входе радиоприемного устройства хотя бы одной радиопомехи”. Заметьте: в линейной системе сигнал и помеха суммируются независимо друг от друга, поэтому отклик на полезный сигнал не меняется в зависимости от помехи. Это может произойти только в том случае, если помеха нарушает линейность приемного тракта, в нашем случае – приемной цепи T/R модуля, состоящей из LNA и АЦП.

В ПФАР диаграммообразующая система (ДОС) находится до T/R модуля, поэтому последний защищен от блокирующей помехи диаграммой направленности. В идеальном варианте, как было подмечено выше, если источник помехи попадает в ноль диаграммы и на входе T/R модуля она будет равна нулю. Это принципиальный момент, на который я обращаю ваше внимание.

В АФАР ДОС находится после T/R модулей, вследствие чего они беззащитны перед сигналами на своих входах. Минимумы диаграммы подавляющие помехи будут вычисляться также после этих модулей, и поэтому если они будут блокированы, то полезный сигнал на выходе этих модулей просто не попадет – никакие фильтры не помогут.

Постойте, но ведь проблема известна давно. И если покопаться в старинных книжках, то можно найти решение. И действительно, в аналоговой технике радиоприема защитой от блокирования служит большой динамический диапазон, который позволяет проходить маленькому сигналу на фоне неизмеримо более мощной помехи без искажений, что дает возможность отфильтровать помеху в дальнейшем. Такого же подхода можно было ожидать и от приемника TRM – но наличие АЦП в тракте рушит все надежды, и сейчас скажу почему.

Часто можно привести цитату, в которой проблема сформулирована лучше, чем ее можешь сформулировать ты. Сейчас как раз такой случай, поэтому процитирую первоисточник. Он как раз указывает на проблему, присущую радиоприемным устройствам (РПУ) которые используют прямую оцифровку антенного входа с помощью высокочастотных АЦП:

Основным недостатком, ограничивающим широкое применение подобного типа РПУ, является невозможность обеспечения высоких уровней динамического диапазона по блокированию. Поскольку на входе АЦП отсутствует фильтрация, то АЦП соответственно не может выполнять оцифровку одновременно сигналов большого и малого уровня. В соответствие нормам ГОСТ радиоприемник должен обеспечивать уровень восприимчивости по блокированию не менее 126 дБ/мкВ для РПУ второго класса и 130 дБ/мкВ для РПУ первого класса. Очевидно, что существующие типы АЦП 14-16 бит не в состоянии обеспечить выполнение этого параметра.

Вот и все. АЦП принципиально напрочь убивает динамический диапазон, что создает уязвимость АФАР для постановки блокирующей помехи. Осталось только оценить степень ее реализуемости. Для этого нам надо оценить чувствительность T/R модуля в локаторе F-35, чтобы на основе этого значения рассчитать потребную мощность помехи и на каком расстоянии может располагаться ее источник.

Если вы найдете ошибку в нижеследующих расчетах, не стесняйтесь! Смело пишите замечания и предложения в комменты )

Энергетический бюджет радиолинии локатор -> цель -> локатор

Нас интересуют две величины:

  • мощность отраженного от цели сигнала, для оценки потребной мощности джаммера;
  • уровень сигнала на входе антенной системы локатора, для оценки наступления момента блокирования АЦП TRM.

В качестве исходных данных возьмем значения:

Pt = 20kW: мощность передатчика радиолокатора F-35;

λ = 3cm: длина волны для частоты 10ГГц;

Gt = 35dB: коэффициент усиления антенны радиолокатора на передачу, линейное значение: 3162;

R = 400km: дальность до цели;

σ = 3m2 : ЭПР цели.

Фактически, при построении бюджета мы поэтапно воспроизводим основное уравнение радиолокации. Причина, по которой мы его не используем – это необходимость в промежуточных данных и соответственно прозрачность в том, как они получены.

Начнем с самого начала – передатчика. Изотропный излучатель мощностью Pt создаст плотность мощности D на расстоянии R:

\displaystyle\large D=\frac{P_t}{4{\pi}R^{2}} [1]

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

Чтобы ее повысить, используем направленные свойства антенны с коэффициентом усиления Gt, тогда плотность излучаемой мощности [Вт/м2] составит:

\displaystyle\large D=\frac{P_tG_t}{4{\pi}R^{2}} [2]

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

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

\displaystyle\large P_r={DA_e}=\frac{P_tG_tA_e}{4{\pi}R^2} [3]

В свою очередь, эффективная площадь напрямую связана с коэффициентом усиления приемной антенны (читай – цели):

\displaystyle\large A_e=\frac{G_r\lambda^{2}}{4{\pi}} [4]

Выполняя очередную подстановку из [4] в [3], получим значение для уровня принимаемого сигнала в простой радиолинии передающая антенна локатора -> цель:

\displaystyle\large P_r=\frac{P_tG_tG_r\lambda^{2}}{(4{\pi)}^2R^{2}} [5]

Пока все понятно с точки зрения физики за исключением того, как интерпретировать коэффициент усиления цели Gr.

Но мы не будем ломать над этим голову, поскольку этот параметр напрямую связан с показателем ЭПР цели σ соотношением

\displaystyle\large G_r=\frac{4{\pi} \sigma}{\lambda ^2} [6]

Если мы подставим это в предыдущее выражение [5], то получим значение мощности сигнала переотраженного от цели:

\displaystyle\large P_{t2}=\frac{P_tG_t \sigma}{4{\pi}R^2} [7]

Индекс t2 теперь означает, что теперь это другое значение мощности передачи, на этот раз с какой интенсивностью цель светит обратно на локатор.

Теперь распространение пошло в обратном направлении – от цели к приемной антенне локатора, и для радиолинии цель -> приемная антенна локатора мы будем использовать точно такое же выражение [5]:

\displaystyle\large P_{r2}=\frac{P_{t3}G_r G_{r2}\lambda^{2}}{(4{\pi)}^2R^{2}} [8]

Новые обозначения несут следующий смысл:

Pr2: мощность сигнала, принимаемого антенной радиолокатора;

Gr2: коэффициент усиления антенны радиолокатора на прием: очевидно, что он будет таким же, как и Gt. Позже мы вернемся к этому;

Pt3*Gr: мощность отраженного целью сигнала, которая на самом деле есть не что иное, как Pt2.

Подставляя значение Pt2 из [7] вместо произведения Pt3*Gr в [8], получаем:

\displaystyle\large P_{r2}=\frac{P_{t2} G_{r2}\lambda^{2}}{(4{\pi)}^2R^{2}} [9]

\displaystyle\large P_{r2}=\frac{P_tG_t \sigma}{4{\pi}R^2} \cdot \frac{G_{r2}\lambda^{2}}{(4{\pi)}^2R^{2}} [10]

и в результате мощность, принимаемая на выходе антенны радиолокатора, будет равна

\displaystyle\large P_{r2}=\frac{P_t G_t G_{r2}\lambda^{2} \sigma}{(4{\pi)}^3R^{4}} [11]

Я не случайно сделал оговорку: на выходе антенны, поскольку выход – это уже суммирование сигналов T/R элементов, а нас интересует как раз мощность на их входе. Но обо всем по порядку: каркас из формул мы создали, теперь начинаем считать.

Немного о смыслах: физических

Итоговые значения можно схематически представить в следующем виде:

F-35, АФАР, ПФАР, AESA, PESA, Radar, Радиолокатор, Локатор, Antenna  Pattern, блокирование, обнаружение, мощность, TRM, T/R module, Transmit Receive Module

Передаваемые и принимаемые мощности в бюджете радиолинии локатора

Мы можем сразу посчитать порядок значений мощности сигнала отраженного от цели Pt2 [7] для определения сопоставимой мощности, требуемой от источника помехи – джаммера. Что касается мощности Pr2, то это суммарная мощность, образуемая вкладом всех TRM антенны. Собственно в этом физический смысл коэффициента усиления антенны G: собирая сигналы со всех T/R модулей, повышается энергетическая эффективность в направлении синфазного сложения сигналов, то есть в направлении основного лепестка диаграммы. При этом несущественно, является ли антенна дискретной решеткой, как в нашем случае, или представляет собой непрерывную конструкцию, как например рефлекторы спутниковых антенн: все равно, или с физической, или математической точки зрения происходит суммирование (а точнее интегрирование) мощностей, принимаемых парциальными элементами площади рефлектора.

В результате, чтобы оценить мощность сигнала принимаемого каждым T/R модулем, нужно грубо говоря разделить выходную мощность антенны Pr2 на количество модулей, а точнее – убрать значение коэффициента усиления G из формулы [11]. Для сомневающихся предлагаю провести самостоятельный эксперимент: построить диаграмму направленности такой антенны из 1676 модулей и сопоставить площадь основного лепестка с уровнем побочных излучений. Получится тоже самое значение 35 дБ. Собственно говоря, это значение было так и получено.

Тогда уровень сигнала, отраженного от цели на входе TRM будет

\displaystyle\large P_{trm}=\frac{P_t G_t\lambda^{2} \sigma}{(4{\pi)}^3R^{4}} [12]

Вы заметили, как резко снизился порог воздействия на вход TRM – на целых G=35 дБ? Это то, о чем я говорил в начале статьи об особенностях АФАР.

Считаем

Наконец, после долгой возни с формулами, переходим к числам ). Подставляя исходные значения в [7] и [12], получаем:

мощность сигнала отраженного от цели Pt2=-10.2 dBm;

мощность сигнала на входе TRM Ptrm= -144.7 dBm.

Как чувствует себя локатор F-35 с такой не очень маленькой целью (ЭПР 3м2 это небольших размеров самолет) на расстоянии 400км? Абсолютное значение сигнала -144.7 dBm на входе TRM нужно соотнести с уровнем шума, чтобы делать выводы по отношению сигнал/шум. Для этого воспользуемся материалами по потерям в антенно-фидерном тракте бортового радиолокатора AN/APG-81 установленного на F-35.

По приведенным данным, с учетом потерь на распространение шумовая температура всего приемного тракта составит 996К. Это значение получено путем суммирования значений шумовой температуры антенны с учетом атмосферного шума (96К) и потерь в приемном фидере (98К). Шумовая температура приемника 608К получена из комнатной температуры (290К) с учетом коэффициента шума 4,91 дБ – столько вносит собственно приемник, или LNA входящий в состав TRM. С учетом потерь в приемном тракте 1,31 получается искомое значение 996К.

Умножая шумовую температуру на постоянную Больцмана, получаем шумовую плотность мощности, приведенную ко входу приемника 1.374*10-20 Вт/Гц. Это относительная величина, которая показывает мощность шума на единицу ширины спектра. Чтобы получить абсолютное значение шума – шумовую мощность, необходимо учесть ширину полосы принимаемого сигнала. С длительностью зондирующего имульса 1 мкс требуемая полоса пропускания составит около 1 МГц; таким образом будем ориентироваться на шумовую мощность 1.374*10-20 Вт/Гц * 106 Гц =  1.374*10-14 Вт, или -108.62 дБм (мощность в дБ относительно значения 1 мВт). Много это или мало? Предположим, что эта мощность приложена к стандартной нагрузке 50 Ом, тогда шумовое напряжение на входе приемника составит около 0.83 мкВ. Вполне реальное значение.

Таким образом, шумовое значение на входе T/R модуля радиолокатора AN-APG-81 составит минус 109 дБм. Отношение сигнал/шум составит -144.7 dBm – 109 dBm = -35.7 dB. Не очень здорово, скажем так, но не будем забывать что позади еще схема диаграммообразования антенны, в которой сигнал основного лепестка сложится синфазно, шум сложится кое-как, и в результате отношение сигнал/шум на выходе антенны будет -35.7 dB + 35 dB = -0.7 dB, что уже не так плохо.

Подчеркнем еще раз: при воздействии на вход T/R модуля радиолокатор с АФАР теряет преимущество в использовании коэффициента усиления антенны, что ни много ни мало 35 дБ.

Динамический диапазон 12-битного АЦП в составе TRM составляет 72.2 дБ. Предположим что коэффициент передачи усилителя LNA перед АЦП равен единице, поскольку его значение не влияет на физику блокирования АЦП – меняется только масштаб величин. Естественно, что АЦП будет работать при существенно более значимых входных сигналах, но для нас имеет значение только относительный расчет. Тогда диапазон входных сигналов, которые полностью займут разрядную сетку АЦП, составит от -144.7 dBm до -144.7 dBm + 72.2 dB =  -72.5 dBm.

Чтобы стать самым сильным сигналом для АЦП (а это уже почти блокирование), постановщику помехи – джаммеру достаточно иметь мощность -10.2 dBm + 72.2 dB = 62 dBm, или 1.58 кВт. Таким образом, при мощности джаммера 1.58 кВт дальности 400км у радиолокатора F-35 оказывается под вопросом.

На самом деле, картинка несколько сложнее, поскольку мы имеем дело с импульсными сигналами, а значит они не обязательно должны перекрываться во времени. Если джаммер будет работать с duty circle 100%, то подавление будет полным, но этот режим требует больших энергоресурсов джаммера и не может использоваться в течение длительного времени.

Сделаем оценку того, какое воздействие окажет мощность помехи например 5 кВт, или 67 dBm. В этом случае эквивалентная минимальная величина отраженного от цели сигнала составит 67 dBm – 72.2 dB = -5.2 dBm. Такое значение соответствует дальности локатора около 225 км, при этом помеха точно также как и в предыдущем случае займет весь динамический диапазон АЦП, а полезный отраженный сигнал будет находиться на уровне одного бита.

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

Заключение

В статье было исследовано влияние метода прямой оцифровки сигнала с антенного модуля АФАР радиолокатора AN/APG-81 истребителя-бомбардировщика F-35 и связанная с этим возможность блокирования АЦП модуля T/R. Получены оценки потребной мощности постановщика помех (джаммера), который находится на таком же расстоянии, как и цель локатора.

Значение пораженной дальности локатора AN/APG-81 составит 400км при мощности джаммера около 1.58 кВт и 225км при мощности джаммера около 5 кВт. При таком блокировании радиолокатор F-35 теряет возможности формирования диаграммы и подавления джаммера.

Данные приведены при непрерывном излучении джаммера, в импульсном режиме, когда отраженные от цели сигналы и помеха могут не перекрываться, степень подавления уменьшится.

Расчет произведен для 12-разрядных АЦП приемных модулей. С повышением разрядности эффективность подавления также уменьшится. Ее величину можно оценить пользуясь приведенным математическим аппаратом.

Блеск и горечь архитектуры OMAP 3530

Для встраиваемых систем выбор кубиков, которые можно сложить во что-нибудь путное, не так уж и велик. То, что находится прямо перед глазами, не дает однозначного выбора.

ARM хорош и к тому же быстро развивается, сопроцессор с плавающей точкой NEON с распараллеливанием выполнения (pipeline) уже само собой разумеющийся атрибут. В последнее время обозначилась новая мода – использовать GPU для решения вычислительных задач, таких как FFT. Программировать под ARM – одно удовольствие, если пользоваться кросс-компилятором на собственной машине, среда Embedded Linux как правило привычна и дружественна разработчику. За все это заплачено отсутствием реального времени и возможностей обработки данных в синхронном режиме. Что же, для этого есть другие инструменты.

FPGA мыслится как первое что можно поставить скажем после АЦП. Синхронная обработка параллельных данных и возможность фильтрации на высокой частоте выборок (до 500 MS/s) определяют ПЛИС как стандарт де-факто на первом месте в сигнальном тракте. После фильтрации и децимации сигнал получается использовать как в DSP, так и в том же ARM. Конечно, с ПЛИС лучше работать не программисту (который может получить вывих мозга), а традиционному инженеру-схемотехнику. В конечном счете, FPGA есть не что иное как миллионы логических элементов, которые нужно просто соединить правильным образом.

Роль DSP также понятна: числодробилка с собственным pipeline, которая к тому же может принимать данные с синхронного интерфейса и вести обработку на несущей частоте. В современных процессорах операция FFT над выборкой 1К чисел с плавающей точкой занимает буквально несколько микросекунд. Сколько гребенок доплеровского фильтра можно сделать с таким процессором!

Рано или поздно кому-нибудь пришла бы в голову мысль скрестить между собой попарно эти кубики. В результате родилась архитектура Zynq, где возник симбиоз ARM + FPGA, и архитектура OMAP, основанная на ARM + DSP. Вот про вторую конфигурацию я бы хотел поговорить подробнее.

ARM+DSP или DSP+ARM?

Идея работать в дружественной среде Linux и одновременно получить те возможности, которые дает DSP, выглядит очень привлекательно. Для радиоинженера логичной бы выглядела связка DSP+ARM (именно в этой последовательности), в которой сигнал через физический интерфейс поступает в обработку DSP, в результате которой извлекаются информационные параметры сигнала, и ARM принимая эти полученные данные доделывает уже остальное: организует третичную обработку, отображение, управление и контроль.

Однако, все получилось немного не так. По замыслу разработчиков архитектуры OMAP, которая позиционируется как мультимедийная, DSP выступает в роли Accelerator Subsystem, фактически как сопроцессор-акселератор на подхвате у ARM. В принципе понятно, для чего это придумывалось: ARM получает данные с какой нибудь камеры, а DSP сопроцессор берет на себя критичные куски алгоритма, для которых требуется производительность. Но мы не привередливые: пусть будет ARM+DSP, где Linux на первой руке получает блоки данных, пусть и в асинхронном режиме, а условный доплеровский фильтр берет на себя DSP. На том и порешили, после двинемся дальше.

Codec Engine

Поскольку мы имеем представление, что будут делать ARM и DSP порознь, сосредоточимся на том, как они будут обмениваться данными. Хотя эти ядра и расположены на одном кристалле, но все таки это два совершенно разных процессора. Интуитивно понятно, как это может быть сделано: для этих процессоров существует некая общая область памяти, которую заполняет ARM и читает DSP и наоборот, если мы хотим сделать обмен данными двунаправленным. Ну и конечно должны быть библиотеки неких функций, которые можно дергать со стороны ARM, что проявится в виде неких сигналов в подсистеме DSP: данные мол готовы, забирайте.

Для тех, кто сталкивался с обеспечением подобного рода взаимодействия, а точнее – с разработкой протокола, известно с какой головной болью это связано. Поэтому благой вестью для нас является то, что компания Texas Instruments, разработчик SoC OMAP 3530, очень сильно постаралась не только для создания такого протокола, но пошла еще дальше – создала целый программный API под названием Codec Engine. Вот как эта структура выглядит на практике:

OMAP 3530, ARM, DSP, Codec Engine

Codec Engine: передача данных между ARM и DSP

Codec Engine, или CE, берет на себя множество мелочей, в которых так легко сделать ошибку: выделение памяти под передаваемые данные как со стороны ARM, так и со стороны DSP, поддержку функций обмена, средства сборки проекта опять таки со стороны ARM Linux, так и со стороны SYS/BIOS DSP. Кроме этого библиотеки CE включают в себя средства отладки, что вообще замечательно в части DSP, потому как просто так в этот процессор не залезешь.

Механизм обмена между ядрами ARM и DSP я использовал в проекте пассивного радиолокатора, где DSP подсистема использовалась для тяжелонагруженного алгоритма нахождения функции неопределенности сигнала.

Ложка дегтя

Так и стали бы ARM с DSP жить и добра наживать, и потускнел бы заголовок нашей статьи – причем здесь горечь, видны только одни радости? Как обычно бывает, при погружении в каждую технологию начинают всплывать вещи, о которых вначале не подозреваешь. Ничего страшного конечно не происходит, но есть нюанс. Об этой ложке дегтя – далее.

Сам CE – достаточно тяжелое решение. То, что компилируется из исходников, у меня на машине состоит из 103599 файлов – ни много ни мало. Собственные приложения выглядят карликом на фоне этого монстра ) Проект был собран и запущен в работу, и все было ОК. Но как-то появилась необходимость опробовать новые приложения на ARM стороне, которые требовали версии ядра Linux постарше чем 2.16. В чем проблема, накатим новое ядро! И тут опс… Codec Engine не захотел собираться с новым ядром. В чем причина?

Как выяснилось, подсистема Линукс-ядра IOMMU, которая отвечает за отображение памяти на периферийные устройства и которую использует CE, существенно изменилась в версиях Linux старше 3.0.50. Почему именно этот номер версии – потому что это максимум, чего получилось достичь вместе с патчами ядра. Вот тут и  обозначился проблемный аспект архитектуры OMAP: на апгрейд Linux на стороне ARM можно ставить крест. Нет, вы конечно можете использовать только ARM ядро, без DSP с любой версией Linux. Но тогда про DSP можно забыть.

Второе. Само собой разумеется, моим приложениям на ARM понадобилась поддержка операций с плавающей точкой, и я решил поставить дистрибутив с аппаратной поддержкой этих операций. И соответственно перекомпилировать CE с новыми библиотеками.  И тут началось… как выяснилось Texas Instruments как бы это мягче сказать… не вполне наделил свои исходники возможностями брать конфигурацию с корневых make файлов. Я обнаружил кучу кода, который отказывался компилироваться просто по той причине, что он просто игнорировал замену конфигурации с arm-linux-gnueabi на arm-linux-gnueabihf. Приходилось править его вручную. Было заметно, что в дебрях ветвей CE находятся такие древние файлы, что похоже в TI могло не остаться людей которые могут подсказать что они там делают )

Так что будьте осторожны с такими комплексными архитектурами. После экспериментов со связкой ARM+DSP невольно стала напрашиваться мысль что лучше было бы сделать взаимодействие между ними на аппаратном уровне…

Что касается Zynq, то обмен между ARM и FPGA был выполнен на удивление просто: стандартными средствами Linux DMA через обычное устройство /dev/xdma. Простая поддержка файловых операций, не более того. Интересно, почему по этому пути не пошли Texas Instruments в Codec Engine?

 

 

Трансляция видео на два HDMI экрана

Raspberry Pi, HDMI, TV, Разветвитель HDMI, HDMI Splitter, omxplayer

Одновременная трасляция видео на два экрана

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

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

Raspberry Pi с флешкой содержащей видеофильмы и разветвитель HDMI интерфейса. Свисток Wi-Fi используется только для управления RPi по сети

Поскольку RPi содержит только один HDMI выход, нам понадобится разветвитель, или сплиттер. Я ограничился двумя выходами и установил коробочку, которую купил на AliExpress (хвала Поднебесной!). К коробочке не предъявляется никаких особенных требований, за исключением того что сплиттер должен быть активным, т.е. обеспечивать усиление сигнала для компенсации потерь при разветвлении.

Плюс к коробочке – два десятиметровых HDMI кабеля, которые будут подключаться к ТВ экранам. Любой из современных плоских ТВ сейчас имеет HDMI вход, так что с этим проблем нет.

Раздача сигнала по Wi-Fi представляется мне плохой идеей, поскольку во-первых требует от ТВ наличия Smart модуля, что удорожает девайс, а во-вторых – забивает локальную сеть непрерывно идущим видеотрафиком. Поэтому все делаем строго по кабелям.

С точки зрения общего замысла все это выглядит так. RPi проигрывает медиа-файлы, расположенные на флешке, и направляет поток на HDMI выход. К нему подключен сплиттер, который формирует два идентичных выходных потока из входного для двух экранов. Вот и все. Дальше – детали, связанные с тем как всем этим управлять, то есть плавно переходим к программной начинке RPi.

Настройка софта Raspberry Pi

Начнем сначала – с флешки. В качестве таковой используем накопитель на 64Гб, который отформатируем в NTFS:

Флешка на моей машине опознается как sdb1, не перепутайте со своим жестким диском!

Почему NTFS? Чтобы иметь возможность записывать фильмы большого размера (>4Гб) и чтобы иметь возможность использовать флешку отдельно вместе с ТВ, поскольку Linux-файловые системы телевизор не понимает.

Далее, дадим RPi возможность автоматически монтировать флешку на старте (поскольку она все время будет вставлена в разъем), для чего добавляем строчку в /etc/fstab:

На RPi флешка опознается уже как sda1: в общем, смотрите внимательно, чтобы не потерять свой основной накопитель. Здесь есть несколько нюансов: файловая система монтируется как доступная только для чтения (read only), ведь нам ничего не нужно записывать туда, верно? И это страхует нас от необходимости чистить файловую систему ntfs после отключений питания. И кроме этого задаем маску, которая позволяет читать файловую систему всем, иначе доступ к ней будет только из под root.

Уже в этой точке вы можете полюбоваться одновременной трансляцией на два экрана, запустив плеер:

Почему именно omxplayer? Потому что он использует API чипов RPi, которые содержат аппаратные кодеки видео. Поэтому медиа-трансляция не нагружает АРМ процессор – декодирование потока из h.264 выполняется аппаратным кодеком. Запустите на RPi top и увидите, что загрузка CPU редко превышает 30%.

Если вы запустите обычный плеер, то перегруз процессора за 100% при воспроизведении видео вам гарантирован.

Далее, нужно сделать процесс удобоваримым для участников, которые не разбираются в удаленном доступе через ssh и работой в командной строке. Для этого на компе администратора (Ubuntu) я сварганил следующий Питоновский скрипт.

 

Скрипт показывает окошко на машине админа, в котором содержится список фильмов (точнее, видеофайлов). Двойным кликом на имени файла админ запускает трансляцию этого видео, после чего все могут смотреть кино сразу на двух экранах.

Чтобы скрипт работал, нужно обеспечить беспрепятственный доступ к RPi с машины админа, а именно – однократно запустить команду

где rpi.local – адрес малышки RPi. В результате будут сформированы ключи и не нужно будет каждый раз вводить пароль при запуске скрипта.

При запуске скрипт заходит на RPi по ssh и командой ls /mnt формирует список видео, который сохраняется в локальном файле /tmp/out.txt. Мы же помним, что после автомонтирования на /mnt у нас теперь файловая система NFTS флешки? Далее, из этого файла формируется список, который выводится в окне.

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

Если взять скрипт за основу, то можно делать все эти вещи, которые я привел в начале статьи. Да, и чуть не забыл: доступ к RPi обеспечивается через Wi-Fi свисток (донгл), который находится в локальной сети. Если назначение системы – просто непрерывно крутить плейлист, тогда и связь по Wi-Fi не нужна.

Когда будете воспроизводить систему, убедитесь в этом что источник питания RPi содержит достаточный запас по мощности: все таки два занятых USB порта и работающий Wi-Fi это хорошая нагрузка.

 

Импортозамещение СКРС / VCS методом China Copy

Импортозамещение – эвфемизм, который на самом деле указывает на отсутствие собственных производственных возможностей. В области систем связи и радиоэлектроники переход на отечественную комплектацию и решения получился настолько болезненным, что многие фирмы изобрели ряд легких способов как продемонстрировать свою “импортозамещенность”.

В немалой степени этому способствовала неразбериха в формулировках того, какая продукция может считаться отечественной или попросту говоря – собственной разработки. Интуитивно понятно, что помимо российской прописки предприятие должно вести разработку технических решений и программного обеспечения собственными силами. При этом фактор собственного производства не так важен, поскольку производить железо можно где угодно, а вот развивать продукт и создавать на его основе другие решения (создавать “потомство”) можно только обладая интеллектуальным заделом и ноу-хау вплоть до таких важных вещей, как исходные коды программного обеспечения – ПО. Говоря другими словами, только живое дает потомство, а от клона потомства ждать нечего.

Часто встречаешься с абсолютизацией производства, которое приравнивается чуть ли не к характеристике высокого уровня технического развития. Если брать пример телефонов Apple, которые производят на китайских заводах,  то точно также они могут изготавливаться на таиландских или индонезийских. Но ни один из этих заводов не в состоянии разработать следующую генерацию смартфона или по крайней мере ответить на один из множества подобных вопросов: например, как и почему выполнено согласование передающего, приемного модуля и антенны в смартфоне? Поэтому порой доходит до смешного: все хотят видеть огромные цеха со станками как признак продвинутого предприятия. И в то же время на этих станках делают старье, в котором уже никто не разбирается – как оно работает. С другой стороны команда разработчиков из 10 человек создает современные радиолокационные станции, которые изготавливаются по кооперации.

Соотношение возможности разработки и производства я описал в статье “Это действительно ваша разработка?”, где дал определение “красной зоне” разработки и “зеленой зоне” производства.

Понятно, что есть проблемы в замещении критичных компонентов, таких например как высокопроизводительные АЦП LTC2174IUKG-14 американской компании Linear Technology, которые используются в отечественных системах посадки самолетов ILS. На подобные компоненты оформляется экспортная лицензия, которая должна быть одобрена Госдепартаментом США. В случае запрета на поставку можно обойтись микросхемами с характеристиками поскромнее за счет увеличения объема оборудования, снижения быстродействия и ухудшения качества изделия. Это не меняет общей картины, когда ты разрабатываешь ILS и понимаешь как должна работать эта система.

Другая ситуация возникает, когда в определенном направлении нет никакого задела (от слова “совсем”) и на отечественный рынок представляют “цельнотянутое” с Запада изделие с собственными шильдиками и децималями на документации. Тут уже трудно говорить, что в таком продукте является отечественным и насколько его можно отнести к собственной разработке. Производить – да, сколько угодно, но с появлением любого запроса на дальнейшее развитие или модернизацию – увы… Как работает – понимаем только на уровне регулировки, исходных текстов ПО и алгоритмов нет, понимания замысла тоже нет. Тут и возникает понятие China Copy: клонирование чужих изделий на собственных производственных площадях под своим, отечественным именем. Вроде бы уже не перебитые шильдики на передних панелях и не замазанная англоязычная маркировка на платах – свои чертежи и децимальные номера в документации, все по ГОСТу. Но клон от этого не перестает быть таковым – он никогда не даст потомства.

Для оживления повествования проследим историю “импортозамещения” в одной из российских компаний. Для примера возьмем не самое сложное изделие: систему коммутации речевой связи (СКРС), с помощью которой диспетчеры аэропортов ведут радиообмен с пилотами воздушных судов.

Начнем с прелюдии, когда все было просто и понятно: купил на Западе, продал в России.

Прелюдия: поставки радиосредств Rohde&Schwarz серии 200

В начале 2000-х российская компания “Азимут” развернула процесс закупок радиостанций серии 200 фирмы Rohde&Schwarz с последующей перепродажей на российской территории. Поскольку импортное оборудование, по отечественным правилам, нельзя использовать для целей УВД, было принято простое решение: поменять передние панели немецких радиостанций на свои, на которых надписи были уже на русском языке, а вместо логотипа Rohde&Schwarz была нарисована синяя подкова Азимута. Можно сказать, что это было “импортозамещение” начальной, первой ступени, в самом примитивном варианте.

Приемопередатчик XU250A, Tranciever XU250A, Приемопередатчик Азимут, Импортозамещение

Оригинальный трансивер XU250A немецкой компании Rohde&Schwarz серии 200, используемый для связи диспетчер – пилот в гражданской авиации (на верхнем снимке)
Внизу – “Импортозамещенный” приемопередатчик XU250A российской компании “Азимут”. Передняя панель заменена на содержащую надписи на русском языке. Решетка громкоговорителя выполнена отверстиями в отличие от вырезов в оригнале для упрощения технологии изготовления панели.
Назначение приемопередатчика – работа в российских приемо-передающих центрах для обеспечения радиосвязи диспетчер – пилот

Такое же превращение из немецких в российские претерпели модули радиостанции, такие как этот тестовый генератор.Приемопередатчик XU250A, Tranciever XU250A, Приемопередатчик Азимут, Импортозамещение

По фотографиям видно, что с названием радиостанции решили не заморачиваться: как она называлась XU250A в оригинальном варианте, так и осталось. Такие же обозначения остались у модулей приемо – передатчика.

В остальном видно, что компоненты установленные на передней панели – переключатели, разъемы, индикаторы не заменялись. Само собой начинка радиостанции осталась оригинальная немецкая.

Немцы скрепя сердце терпели такое отношение к своему бренду в надежде, что на российской территории будет развернуто изготовление и поставка радиостанций Rohde&Scwarz. Однако сотрудничество не состоялось. И видимо именно по этой причине из нашего повествования выпадает СКРС / VCS-4G Rohde&Schwarz: если дилер не обеспечил поставки одного продукта, то скорее всего со вторым будет то же самое. Поэтому СКРС VCS-4G в дальнейшем уже не рассматривалась как потенциальный кандидат для перепродажи на территории РФ.

К этому моменту “импортозаместительная” схема уже была обкатана и получила свое развитие в попытках наладить партнерство (читай – закупки/продажи) с другими европейскими компаниями.

СКРС Schmid Telecom VCS 200/60

По мере развития отечественного рынка средств УВД заказчики начали соображать, что покупать импортное железо под отечественными шильдиками это в некотором роде контры с государственной политикой в этой отрасли, которая была направлена на поддержку “настоящих” отечественных производителей. Поскольку разрабатывать свое хлопотно и дорого, и хочется быстро и выгодно продавать западную, было придумано “импортозамещение” второй ступени.

Его особенность заключалась в том, что народ начал все меньше интересоваться содержимым плат и узлов и гораздо больше – программным обеспечением. И также вопросами, кому это ПО принадлежит и кто владеет исходными текстами.

Для наглядности я сделал подробную диаграмму, в которой присутствует красная зона – интеллектуальная область разработчика, и зеленая зона – то чем располагает завод. В очередной попытке перепродажи западной СКРС нужно было показать заказчику, что помимо зеленой зоны отечественный поставщик также контролирует красную зону, если попросту – располагает исходными текстами ПО. И такая возможность представилась с известной фирмой Schmid Telecom, Швейцария.

СКРС,VCS 200/60, Shmid Telecom

СКРС VCS 200/60 Shmid Telecom

Эта швейцарская компания – признанный лидер на европейском рынке СКРС. И конечно, она была заинтересована в продвижении своей продукции – СКРС VCS 200/60 на объемный российский рынок. Переговоры шли на высокой ноте, под хрустальный звон бокалов с шампанским и соблазнительной перспективой создания совместного предприятия. Блестки и конфетти мешали руководству конторы вникнуть в смысл лицензионного соглашения, где в разделе Software прописывают условия поставки ПО. В сущности, в подобных документах пишут вполне очевидные вещи, как например:

The Installation Package includes all SW and FW Module Versions that build together a certified SW Release.

Пакет установки включает все Software и Firmware модули, которые собраны в один программный релиз.

Все ясно – это пакет инсталляции ПО, поэтому речь идет о бинарных модулях (зеленая зона). Ну и немного лирики на тему того, что для аборигенов этого вполне достаточно 🙂

The VCS SW and FW are highly configurable. Any dimensioning of the system extension, every kind of functional parameters settings, Touch screen HMI and roles definitions do not require any modification of the SW or FW.

Through a very comfortable Configuration program an authorised user is enabled to define and download all the characteristics of the system. To partially or completely rearrange the operator interfaces HMI.

Due to this enormous flexibility, the need to extension and modification of the running SW and FW is very improbable.

Краткий перевод выглядит следующим:

Программное обеспечение СКРС отлично конфигурируется. Любое изменение параметров не требует какой-либо модификации софта.

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

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

Вот она, игла Кощея: расширение возможностей и модификация работающего ПО. Внимание, красная зона, вход посторонним воспрещен! Если очень нужно, берите инструменты для конфигурации софта, меняйте как хотите картинки на дисплее, но технологии мы вам не дадим – расширять возможности и модифицировать ПО вы не будете. И это правильно: в программном обеспечении сидит вся капитализация Schmid Telecom: вся история развития, ошибки, неудачи и находки, конкурентные преимущества, методы реализации требуемых параметров.

Насколько разработчики Schmid Telecom представляют ценность для компании, демонстрирует следующий пример. Если заказчику нужна доработка системы, которая требует участия программистов, какой бы высокой не была оплата этой опции, программистов на ее реализацию никто отвлекать не будет. Подобные решения принимаются на самом высоком уровне – совете директоров. Если доработка будет признана целесообразной, она будет включена в RoadMap для последующего воплощения. Вот такая мощная башня из слоновой кости.

Желание поскорее двинуть швейцарский продукт под своим шильдиком было настолько велико, что на выставке МАКС 2011 оборудование Shmid Telecom чуть было не “импортозаместили” на ходу путем использования технологии Azimutation Kit: клей, ножницы, бумага 🙂 Благо, на серии 200 все было обкатано, а для выставки пойдет просто поменять фирменные логотипы.

К этому моменту контора сообразила, что без того чтобы продемонстрировать интеллектуальную собственность красной зоны, включая исходные коды ПО, не получится убедить заказчиков, что это самый натуральный российский продукт в стиле “сделаноунас”. Но была проблема. С одной стороны, Шмид ни под каким соусом не соглашался показывать свою исходную программную документацию, с другой – ее все таки надо было демонстрировать проверяющим и сертифицирующим инстанциям. В результате интеллектуальных брифингов родилась схема с легким налетом романтики аферистического толка. Она заслуживает того, чтобы продемонстрировать ее 🙂

В представлении интеллектуалов конторы все должно было выглядеть так. Центральную часть схемы занимает сейф. В этот сейф Шмид приносит исходные тексты ПО и никому не показывая, запирает его на свой ключ. Поскольку владелец ключа ни в коем разе не должен выглядеть европейцем, который разговаривает на немецком (документация-то типа отечественная!), ключ вручается под расписку местному товарищу. В расписке указано что партнер, то есть контора ни одним глазом не может заглянуть в доки – они демонстрируются только проверяющим от государства. Далее в игру должен вступить некий проверяющий и сертифицирующий субъект, которого провожают в комнату с сейфом и он, небрежно пролистывая несколько сотен страниц с распечатками, говорит: йес! верую, что это ваше! Поскольку на сейфе и на каждой странице будет надпечатан логотип конторы.

Гениально, правда? Только почему-то не заработало. Может, проверяющие товарищи не хотели слишком сильно пачкаться, или были другие причины – перспектива убедить соответствующие органы в том что “красная зона” – наша, начала таять.

Когда наконец пришло осознание того, что технологии красной зоны никто отдавать не собирается и от аборигенов требуется только клепать железо в стиле China Copy без подтверждения права на собственный софт, поднялся шум. В результате, как и с Rohde&Schwarz, проект приказал долго жить.

СКРС Sitti “Multiphono”

Следующим партнером, которого можно было приспособить на российской территории под российским брендом, планировалась миланская компания Sitti. Вообще список разработчиков СКРС не так уж и велик – не считая Sitti, осталось рассматривать только австрийскйю компанию Frequentis. Подробный обзор по Sitti у меня есть в отдельной статье, здесь я только дополню этот технический обзор краткой историей о том, как проходила попытка “импортозамещения” уже с этой компанией.

Итальянцы были жизнерадостны и обаятельны: продавать систему – пожалуйста, производить на территории России под брендом партнера – можно подумать, но передавать технологию, то есть исходные коды программ – no, è impossibile. До конторы начало доходить, что все готовы поделиться  (естественно не безвозмездно) своим урожаем, но продавать поле с которого ты кормишься (красная зона) никто не собирается. Никто и никогда не продает свои технологии, и в самом деле, для этого надо быть самоубийцей, чтобы добровольно отдать свой бизнес другому.

Контора сделала последнюю попытку: предолжила Sitti продаться целиком вместе с СКРС. По идее это должно было выглядеть круто, а на самом деле было жалко и смешно. Итальянцы вежливо посмеялись, помахали ручкой и уехали в Милан. На этом все закончилось.

Самое обидное для конторы было то, что технологии отказался продавать даже отечественный разработчик СКРС – небольшая зеленоградская компания 🙂

СКРС собственной разработки

Да-да, такое тоже случилось однажды. Когда продукта для перепродажи нет, в голову приходят невеселые мысли о собственной разработке. Невеселые – потому что своих специалистов нет, а если даже их набирать – плохо вписывается разработка в торгово – закупочную парадигму. Все равно что на автобазе выделить площади для центра высокой моды 🙂

Если сами не умеем, можно заказать у тех кто умеет. Была найдена небольшая компания, продвинутая в разработке VoIP решений – имменно в этом изюминка проекта, поскольку требования Евроконтроля к СКРС описывают именно современные, VoIP решения. И все может быть и состоялось, но концу проекта, когда надо было принять работающую систему у подрядчика, нарисовалась еще одна торгово – закупочная возможность: перепродать СКРС Frequentis VCS3020X.

СКРС Frequentis VCS3020X

Соблазн был слишком велик: с одной стороны, собственная разработка, которую надо сопровождать и развивать, а с другой – готовое решение, которое нужно только грамотно перепродать на территории РФ. И начиная с этого момента судьба собственной разработки была решена: контора начала судебную тяжбу за проект, которая закончилась не в пользу разработчика VoIP СКРС (ну этому удивляться не приходится, зная как работает отечественная судебная система).

Frequentis VCS3020X. Будущее российской импортозамещенной СКРС

И старая торгово-закупочная машина, заправленная новым топливом, завертелась снова. Австрийская компания Frequentis является разработчиком СКРС и точно также как и предыдущие фирмы, начинает штурмовать аэродромные просторы РФ. Вполне возможно, что отечественные диспетчеры получат неплохую западную систему VCS3020X, разработанную в 2004 году, пусть даже и с перебитыми шильдиками и переделанной документацией. Только логотип у фирмы размашистый, придется перекрывать его тоже чем – нибудь значимым 🙂

Остались только вопросы, правда они носят скорее риторический характер.

Вопросы напоследок

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

Почему бы просто не пустить на отечественный рынок такие компании как Thales, Rohde&Schwarz, тот же Frequentis со своей VCS3020X? Конечно, после этого сразу прекратят свое существование торгово – закупочные конторы, занимающиеся “отмывкой” западного оборудования, но зато возникнет внутренний рынок для специалистов, в том числе разработчиков.

Есть еще один аспект, связанный с внедрением пресловутых “закладок” в Firmware чипсетов и ПО. И если для радиолокатора или пеленгатора, использующего импортные компоненты, трудно представить как может быть активирована эта закладка, то для связного и коммуникационного оборудования, каким является СКРС, сам бог велел. Не имея исходных кодов ПО и Firmware “красной зоны”, вы не найдете эту закладку. Активировать ее можно множеством способов: звонок в систему с определенного номера, специально сконструированные кодовые конструкции в цифровом трафике RTP, команды в протоколах сигнализации, связанных с внешними телефонными системами. Возможностей огромное количество, и странно наблюдать спокойствие служб, которые обычно сильно заморочены на шпионских сюжетах в то время как под девизом “прибыль любой ценой” идет затаскивание троянского коня.

Да и в любой момент австрийцам из Frequentis могут напомнить про санкции и озвучат предложение, от которого невозможно отказаться. После этого хайтек оборудование “отечественного производителя” станет просто кирпичами.

Ну а пока лучшие представители российских фирм успешно демонстрируют на форумах и выставках свои China Copy под шумные аплодисменты ничего не подозревающих зрителей и участников 🙂

Это действительно ваша разработка?

При разборе проблем в отечественной промышленной политике обычно обращаются к китайской действительности, где производится большая номенклатура продукции. Да и китайские заводы у всех на слуху. При этом в дискуссиях незаметно происходит фетишизация производства и подмена понятий: создается впечатление, что если завод производит радиоэлектронные изделия, то он знает и понимает как эти изделия создавать. Для многих между этими двумя понятиями стоит знак равенства, но на самом деле между производством и разработкой (R&D, Research and Development) – пропасть.

Приведу небольшой пример. На снимке – небольшое радиоэлектронное устройство. Видно, что оно выполнено по технологии поверхностного монтажа; судя по разъемам и основаниям для крепления экранов, содержит СВЧ компоненты. Завод, производящий эту плату, может демонстрировать ее на выставках и она будет показателем высокого уровня технического развития и соответствия современным технологиям. И это на самом деле так.

Приемный модуль, Receiver

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

Для чего предназначена эта плата и какую роль она выполняет в системе, частью которой она является? Завод об этом не знает (если только не производит всю систему целиком). Собственно, это устройство и было так изготовлено: производителю была передана печать и необходимая документация, перечень элементов, благодаря чему он самостоятельно закупил компоненты, изготовил печатную плату, установил компоненты на плату. При этом производитель не имел ни малейшего понятия, для чего предназначена плата – на все про все ушло 2 недели.

Если плата должна быть проверена на заводе (что совсем не обязательно), это делается по инструкции – включили, увидели, сравнили. И опять-таки без погружения в суть.

Мы, как разработчики, знаем что на снимке – приемник диапазона 60 – 1000 МГц, содержащий синтезатор частот, управляемый по I2C, с возможностью работы от внешнего синтезатора с целью поддержания когерентности системы. Выходной сигнал – квадратурные составляющие I/Q, предназначенные для оцифровки в быстродействующих АЦП. У нас на руках электрическая схема, описание работы и другие документы, которых у завода нет и которые ему не нужны.

Теперь представим, что заказчик, вдохновившись этой платой, которая изготавливается на “передовом производстве”, задает заводчанам вопрос: ребят, а можно нижнюю частоту сделать 50 МГц? Или – у вас внешне подключаемые ФНЧ, какая оптимальная частотная характеристика будет если оцифровку выполнять на скорости 250 млн. выборок в секунду? Или – давайте упростим плату и перенесем синтезатор в другое устройство, какие фазовые шумы нужно обеспечить для того чтобы вы выполнили требования по когерентности? И тут в ответ – тишина… Заводу ответить нечего. И незачем – его задача обеспечивать партию выпуска по той документации, которую ему дал разработчик.

Смешная получается история: солидное предприятие, станки стоят, руководство ходит в галстуках, получает финансирование на развитие и модернизацию… а модернизировать ничего не может. Приходится обращаться к очкарикам, которые сидят в небольшой комнатке со своими приборами, паяльниками и компьютерами 🙂 Смешно потому, что когда рассказываешь о своих проектах, тебя спрашивают: а где у вас производство? Граждане, производство сейчас вообще не проблема! Любую деталь или плату вам сделают за милую душу где угодно – хоть в Рязани хоть в Таиланде. Только платите. Не про производство надо спрашивать, а про IP – интеллектуальную собственность, которая подтверждена реально работающими устройствами.

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

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

Свое и чужое

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

Характерно, что разработчик находящийся в красной зоне (R&D) хорошо представляет как его продукт начинает жить в зеленой (производство), поскольку принимает участие в испытаниях и сопровождении во время изготовления. Обратное далеко не всегда встречается: как правило, заводчане полагают, что знают все об изделии и системе (этим же грешат эксплуатанты), а на самом деле даже не представляют, какой пласт информации кроется за этим. Завод знает о том, как сделано, а разработчик – почему сделано именно так. Чувствуете разницу? В первом случае – конечная станция, просим освободить вагоны, а второй открывает множество дорог в будущее.

Но я немного отвлекся ) Итак, как построена наша схемка. Блоки имеют группировку по вертикали и относятся к наиболее типичным компонентам изделия или системы: антенно – фидерный тракт, аппаратура (сюда включается все – СВЧ узлы, устройства формирования и обработки, компьютерные устройства, средства передачи и отображения данных), программное обеспечение как Firmware – прошивки чипов расположенных на своих платах и программное обеспечение как Software – приложения работающие под управлением операционной системы на встраиваемых платформах SBC (Single Board Computer).

Символично то, что Firmware расположено между аппаратурой и ПО высокого уровня, поскольку это низкоуровневый софт, тяготеющий к железу и являющийся его неотъемлемой частью.

Разработка, R&D, производство

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

Stupid piece of iron

Поскольку я заметил, что заводчане часто без понятия, откуда берется то что они производят, начнем с них, то есть с нижней части схемы. Про плату радиоприемного модуля мы уже сказали, что завод с ней сделать ничего не может (кроме того что изготовить): наличие конструкторской и технологической документации (информация зеленой зоны) не дает абсолютно никакой информации о способах развития и усовершенствования устройства. Возьмем другой пример: антенна радиолокатора. Документация на антенну позволяет изготовить детали и правильно собрать их. Технологическая остнастка обеспечивает достижение точности там, где это критично: например, соблюдение формы рефлектора и расположение излучателя. Антенну красят, устанавливают на пьедестал, запускают двигатели… и – вуаля! Вот тот момент, который обожают заказчики: здоровый кусок железа начал вращаться вокру своей оси. Мы сделали локатор!

Когда я работал в Риме по радиолокационному проекту, итальянцы – разработчики называли этот характерный момент “stupid piece of iron” – тупой кусок железа, который выглядит зрелищно, привлекает внимание, но мало кто понимает что самая соль содержится в небольших узлах обработки сигнала и ПО.

За границей зеленой зоны остается ряд вещей, о которых знает только разработчик. Как достигнут компромисс между уровнем боковых лепестков, шириной основного лепестка и размерами антенны? Как выдержать диаграмму в вертикальной плоскости во всем частотном диапазоне? Как обеспечить ветровую нагрузку? У разработчиков – антенщиков на руках огромное количество вариантов расчетов. Например, таких, которые никто не увидит – ни заводчане, ни даже заказчик:

Электрический расчет антенны, Radar Antenna

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

Забираясь еще глубже, то есть в верхнюю часть красной зоны, мы увидим результаты исследований, которые проводились по анализу построения антенной системы. Завод не знает, что при определенных условиях это могла быть не антенна с рефлектором, а щелевая, или вообще фазированная антенная решетка. И если задать заводу вопрос типа того, что звучал выше: Ребят, а что если… поменять частоту… отжать лепесток от земли… поменять поляризацию… – ответов на эти вопросы в зеленой зоне нет. Нужно идти в маленькую комнату с очкариками, приборами etc.

Эту истину простую очень
Принимай как есть и не сетуй:
Есть дорога из лета в осень,
Нет дороги из осени в лето

(Неизвестный Автор)

Программное обеспечение: эта песня будет вечной

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

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

На самом деле уровней в компетенции ПО еще больше; я не стал рисовать дополнительные блоки на схеме чтобы не загромождать ее. Бинарный модуль – результат компиляции и сборки нескольких программ, каждую из которой разрабатывает кодировщик. В моей терминологии кодировщик – это программист, для которого четко очерчены рамки его программного модуля и что этот модуль должен делать. Кодировщик может себе позволить не знать абсолютно ничего об общей структуре проекта и о других модулях.

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

Несмотря на то, что исходные тексты программ снабжаются комментариями, в ПО сложной архитектуры невозможно по одним комментариям и логике текста программы определить общий замысел. Для этого нужна документация, по структуре соответствующая MIL STD 498, что позволяет поддерживать разработку ПО и развивать ее. Эта документация – на вес золота, потому что в современных изделиях софт берет на себя больше функционала – за счет железа, которое реализуется относительно стандартными блоками. Алгоритмы обработки и формирования, математические модели, обеспечение быстродействия, удачные находки – в этой документации. Само собой, она не покидает стен фирмы и тем более не передается на производство.

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

Все вышесказанное также относится и к Firmware. Это софт весьма специфичен и напоминает разработку драйверов устройств. Как правило, его пишут уже не программисты а чистые инженеры. Поскольку внешний мир для Firmware – это плата, связи между ними являются очень тесными и для производства не документируются. В этом ПО может содержаться существенная часть ноу-хау по обработке данных в критичных условиях: например, софт в ПЛИС обеспечивающий работу АЦП.

Разработчики, заводчики и заказчики

Эта статья принесет мало пользы разработчикам и заводчикам. Первым – по причине того что они и так все это знают, вторым – по причине что они и так прекрасно все это знают, но не в их интересах показывать, как все обстоит на самом деле. А вот для заказчиков польза может быть немалая. Это актуально с учетом последних трендов. До пресловутого импортозамещения все было просто: знай покупай импортную аппаратуру, перебивай шильдики и продавай под своим брендом (если кто-то думает что такое возможно только в ширпотребе, покажу примеры из области радиотехнического обеспечения полетов). Сейчас это уже не прокатывает и приходится действовать тоньше: например, перерисовывать чертежи под своими децимальными номерами и изготавливать узлы на своей производственной базе. Благо, зарубежные компании заинтересованные в российском рынке охотно передают ограниченную документацию для China Copy. Но свою технологию они передавать никогда не будут. А это – вечная зависимость. Ну и нехорошо вводить в заблуждение покупателей ложным термином “отечественная продукция”.

АРП встраиваемый в РЛК “Комар-2”

Если к радиопеленгатору “Пихта-2С” применима фраза “первый микропроцессорный”, то АРП “Комар-2” это следующий процессорный АРП, который базировался на технологиях Пихты. Его особенность в том, что он разрабатывался в составе чехословацкого радиолокационного комплекса “Комар-2”, который создавался по заказу наших ВВС в Тесла Пардубице.

После разработки АРП “Пихта-2С” все пеленгационное направление перешло ко мне. Имеющийся задел требовал своего выхода, и такая возможность скоро представилась.

В начале 90-х почтовые ящики нашего профиля ни шатко ни валко занимались ОКР “Мельхиор”, которая должна была обеспечить полной наземной радиотехнической инфраструктурой все военные стационарные, мобильные и высокомобильные аэродромы. Мы разрабатывали радиопеленгаторы для этой ОКР. В рамках работы должны были разрабатываться передовые технологии, такие как углепластиковые конструктивы, призванные существенно снизить вес оборудования. Углепластик так и не появился, и во время моей очередной встречи с ведущим конструктором ВНИИРА по высокомобильному КДП, который должен был располагаться на вертолете, он с тихой грустью сказал: – “просуммировал массу оборудования по документации всех поставщиков для КДП… вертолет не поднимет”.

Тогда же на совещаниях во ВНИИРА, который был головной конторой по этой ОКР, хорошо была заметна особенность мышления военных заказчиков. Презентовался унифицированный кузов для размещения оборудования, единый для всех разработчиков ОКР. Авторы разработки дали изюминку: пневматические опоры для погрузки кузова на транспортное средство. Изюминка тут же незамедлительно была отправлена в корзину: ни к чему огород городить, солдаты закинут если нужно будет. Время показало, что в этой же корзине оказалась наша электроника, программное обеспечение (за что платить – за дырки в перфоленте, гы-гы) и многое чего. Символом подходов гензаказчика к нашей отрасли для меня стала кувалда, ручка которой покрашена в зеленый цвет (эта кувалда еще всплывет по ходу нашего повествования).

Близко к Мельхиору стояли еще две разработки радиолокационных комплесов: челябинская “Радиан-90” и чешская “Комар-2”. И также ни шатко ни валко у нас до “Пихты-2С” велась разработка встраиваемого АРП для этих комплексов. Техническое руководство нашей конторы исправно ездило в Чехословакию для подписания протокола сопряжения РЛК и радиопеленгатора. То-ли кофе в Пардубицах был славный, то-ли пиво – но протокол никак не хотел подписываться. После очередного вояжа я, уже будучи главным конструктором АРП “Комар-2”, недвусмысленно намекнул боссам, что техникой должны заниматься инженеры, а не начальники. После этого скрепя сердце меня “выпустили” за границу.

Бюджетная песня

90-е годы были под завязку набиты креативом. Тем, кто жил в эти времена, можно зачесть сутки за трое 🙂 Вместе с выборами директоров предприятий, в нашу контору пришел хозрасчет. Я как главный конструктор темы, получил реальный бюджет и чековую книжку, в которой выписывал исполнителям наличные за выполненные по проекту работы. Наличные выплачивались как премия каждый месяц.

После первых же выплат началось невообразимое. Народ забросил свои обычные занятия, как то: разработка по частным заказам металлоискателей и электрических сборщиков пчелиного яда, печать портретов на матричном принтере с фотокамеры на вокзалах и аэропортах, закупка кипятильников и бижутерии для последующей перепродажи в командировках, изготовление ювелирных изделий прямо на рабочем месте паяльником и пассатижами, сбор позолоченных выводов микросхем с последующей обработкой в кислоте и извлечения желтого металла и даже сбор ценного сырья – бычков с последующим извлечением и сушкой табака. Разработка пеленгатора за реальные деньги резко рванула вперед. Буквально за один месяц появились электрические схемы, в которых ядром был процессор 588 серии, плюс софт. Изготовление в цеху вместо пинания конструкторов и производственников превратилось в легкий и приятный процесс. Более того, была разработана и изготовлена складная пеленгационная 8-ми вибраторная антенна: работа, которая при прежних условиях могла занять годы.

АРП, РП, DF, Direction Finder, РЛК Комар-2, Radar Komar-2

Блок АРП “Комар-2”. Встраивался в шкаф радиолокационного комплекса “Комар-2”.

Чековая книжка худела, разработчики АРП начали слыть баснословными богачами, радиопеленгатор появился практически за полгода. Вот что делает животворящий бюджет! Ни до, ни после мне не приходилось возглавлять такой скоростной проект. К этому моменту за одну мою поездку в Тесла Пардубице был наконец согласован протокол сопряжения, где оговаривалось подключение АРП к радиостанциям РЛК и выдача пеленгационной информации. Как сейчас помню, это был стык ИРПС (токовая петля) 20 мА.

В результате, мы погрузили опытный образец, нестандартку, приборы и кувалду для забития костылей в основание антенны (ручка покрашена в зеленый цвет!) в ГАЗ-66 и он взял курс на Пардубице.

Хозрасчетная эпопея длилась недолго. Отчасти потому, что сразу выяснилось какие направления в конторе обеспечены договорами (такое как наше), а какие существуют просто сами по себе – дотационно. Руководство лишилось сильного рычага – перераспределения средств, и поэтому лавочку быстро прикрыли. Плюс был в том, что АРП “Комар-2” к этому моменту успели изготовить. Ну а с минусами понятно – не все смогли дальше работать в прежнем вялотекущем режиме: часть специалистов уволилась, а часть продолжала работать в режиме итальянской забастовки. Надвигался самый пик лихих 90-х с невыплатами зарплат по полгода, сгоревшими вкладами в сберкассах и погружением основной части населения в нищету и беспросветность.

Тесла – Пардубице

К моменту прибытия ГАЗ-66 в Пардубице обосновалась наша небольшая пеленгационная команда. Это был первый наш выезд за границу. Ехали в поезде, в вагоне который гремел буквально каждой железкой. Когда стояли на границе в Бресте и ждали когда поменяют тележки вагонов для перехода на европейскую колею, стала понятна причина, почему вагоны издают звуки имитирующие ведро с болтами. Таможенники зашли в вагон и начали откручивать буквально все, что держалось на винтах, в поисках тайников. Отвинчивали буквально до крышек на потолках. Тщательно проверяли багаж. Причины тотального шмона были понятны: возник огромный перекос в стоимости товаров между бывшим СССР и Западом, что породило целые потоки в прямом и обратном направлении. Чехи с удовольствием возили наши дверные замки и топоры, поскольку в exUSSR железо стоило пока еще дешево, а в Европе – уже дорого, и давно дорого. Были и курьезные ситуации: одно время, после тотальной войны против курильщиков и изчезновения сигарет, государство одумалось и начало спешно закупать импортную продукцию, которая дотировалась. Поэтому, купив в московском магазине блок каких нибудь Rothmans и перепродав его на Западе, можно было получить ощутимую прибыль )

Вспоминая Пардубице, я сразу ощущаю аромат кофе. Казалось, этот гостеприимный запах встречает тебя везде. Нас поселили в небольшой двухэтажной спортивной гостинице рядом с городским стадионом. Вот какие ассоциации вызывает у советского человека слово “гостиница”? В первую очередь конечно “мест нет”, потом “после 24 часов прием посетителей запрещен”, плюс дежурные по этажу, простреливающие своим взглядом тепловозного прожектора все коридоры. Еще анкеты, которые надо заполнять и которые судя по всему никто не читал, поэтому в графе “цель приезда” можно запросто внести запись: “ограбление банка”.

После всего этого небольшим шоком для нас стало то, что хозяйка гостиницы выдала каждому по два ключа. Ну один это понятно – ключ от номера, а второй? Ключ от входной двери гостиницы. Вышли ночью – закрыли за собой, вернулись – открыли и снова закрыли. Все просто и логично, но похоже мы слишком долго жили в другой логике, поэтому такая простая и удобная вещь нам показалась сверхъестестественной. При этом заметно, что это не было новым приобретением освободившейся восточноевропейской страны: похоже, что и при социализме европа никуда не делась.

После этого мне стало особенно близка тихая печаль Радомира Герверта, руководителя проекта РЛК “Комар-2”, когда во время приезда в Махачкалу он ознакомился с местным гостиничным сервисом. В центральной гостинице “Ленинград” ему дали номер в котором не работал замок, и на вполне резонный вопрос от получил ответ типа такого – “а что ты там собрался делать втайне от всех” ) Ну и выделив ему неубиваемое вафельное полотенце, горничная погрозила пальчиком: смотри мол, не сопри, знаем мы вас командировочных. Хотя Радомира конечно этим не удивить: он хорошо поколесил по СССР по позициям где стояли тесловские локаторы, в том числе в войсковых частях. Навидался всякого.

РЛК “Комар-2”

Tesla Pardubice – большая чешская фирма. Вообще для того времени правильнее было бы говорить – чехословацкая, но уже пошел на удивление мирный развод Чехии и Словакии по своим государством, и мы могли наблюдать его по тому, как на кроне появилась гербовая марка, означающая что теперь это чешская валюта, и потом уже появились чешские кроны. Чехия это  фактически центр Европы, и до войны технический уровень развития страны был выше, чем у Германии.

АРП, РП, DF, Direction Finder, РЛК Комар-2, Radar Komar-2

Схема расположения РЛК “Комар-2” на аэродроме

У Теслы радиолокационный комплекс “Комар-2” к моменту нашего появления был почти готов: не хватало радиопеленгатора и сущей мелочи: магнетрона для передатчика. Магнетрон должен был поставить ВНИИРА, но что-то постоянно не клеилось: от приезда к приезду питерских специалистов передающий тракт локатора запустить не получалось. В Пардубице как раз в это время был известный долгострой: автомобильный мост. И тесловские спецы спорили между собой, что случится раньше: появится мост или рабочий магнетрон.

Интересные особенности, которые запомнились после знакомства с проектом.

Конструктив Евромеханика 19”

Все было сделано в этом конструктиве, размеры плат – от 3U до 6U. Мы тогда все еще использовали рекомендованные конструктивные элементы УБНК. Тем не менее, по протоколу сопряжения блок АРП был вписан в то место, которое было отведено для него в шкафу – над радиостанциями.

Z80

Так неожиданно и странно было увидеть этот процессор на плате военного радиолокатора. Легендарный компьютер ZX Spectrum, который мы собирали сами, это одно, а тут… Объяснение было простое: доступно и функционально, поэтому использовали.

Сопряжение

Когда протоколы механического, электрического сопряжения разрабатываются между двумя конторами, одна из которых – зарубежная, то сразу ничего не запустится. Но – запустилось. Разъемы и ответные части подошли друг другу, распайка совпала, радиостанции корректно управлялись от АРП, токовая петля ИРПС 20мА исправно гнала пеленги в локатор, а он их отображал на экране. Никакой интриги, как с магнетроном.

Индикаторы кругового обзора

Именно ИКО мы рассчитывали увидеть, как это принято в военных радарах, но увидели… цветные дисплеи. Это было невероятно, потому что во-первых, наши военные ни за что бы не их не согласовали, а во вторых для тех времен, когда только появились персональные компьютеры и цветной экран был редкостью, цветной монитор в изделии выглядел настоящим модернизмом. На вопрос насчет наших военных заказчиков о замене ИКО на цветные дисплеи Радек ответил коротко, просто и снова логично: “дерьмо ставить не будем”. Вот так.

Два босса

Управление проектом РЛК было разделено: Радомир отвечал за сроки, бюджет и результаты, а другой профи (к сожалению, не помню как зовут) – за технику. Это было непривычно, потому что в нашей системе координат главный конструктор отвечает за все. Понятие бюджета было эфемерным, потому что им всегда распоряжалось руководство конторы (все так и осталось, несмотря на внедрение PMI).

Радомир старался уложиться в бюджет, но похоже из-за магнетрона ему это не очень удалось )

Военпред

Да, на Тесле был наш настоящий представитель заказчика. Когда Чехия начала обособляться от советского блока, его присутствие стало чисто номинальным и вообще потеряло смысл когда фирма начала распродавать изделия, которые разрабатывались по заказу СССР. На территорию фирмы Юру еще пускали, но в планах компании он уже участия не принимал, хотя всячески помогал нам продвигать проект. В ходе очередного приезда, на вопрос: “Как дела?” Юра отвечал – “Отлично, сохраняю советское военное присутствие” )

Наш радиопеленгатор заработал сразу, и мы все ждали того момента, когда в локаторе наконец запустят магнетрон и можно будет провести комплексные испытания. Пользуясь затянувшейся паузой, мы прямо на месте дорабатывали и отлаживали софт, пробуя различные режимы работы АРП. В частности, было интересно пеленговать аппаратную с антенной системой РЛК, которая находилась в отдалении, поскольку как выяснилось она формировала паразитные излучения в широком спектре частот, в том числе и в диапазоне АРП.

Радиопеленгатор простреливает Пардубице

Процессы, которые шли в Чехии и бывшем СССР после распада последнего, разительно отличались. Было ощущение что мы летим в какую – то пропасть с распадом всех существующих связей и страны, а чехи наоборот – возвращаются к себе домой. Никаких конфликтов у чехов со словаками не было – они расстались тихо и незаметно. Универсальный индекс – стоимость кружки пива держался на уровне 5 – 7 крон, в то время когда с рублем творилась настоящая чехарда. Когда в один день встревоженные чехи показали новости по ТВ, где расстреливали здание Верховного Совета (мы в это время находились в Пардубице), это так контрастировало с почти беспечной обстановкой в этом городке. Помню, их сильно удивило то, что люди не бежали, а стояли и смотрели на расстрел – “как в кино”.

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

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

Радек нашел авто с установленной FM радиостанцией и договорился с городским отелем, который располагался в многоэтажном здании. В один прекрасный субботний – или прекрасный воскресный день, сейчас уже не помню, мы вытащили блок АРП из аппаратной РЛК, сняли антенну (благо она складная и поэтому легко транспортируема) и обосновали на крыше отеля пеленгационную позицию. Автомобиль с радиостанцией пошел по маршруту, давая постоянные отсчеты, и мы отмечали пеленги на карте города. Результаты были очень даже неплохими, учитывая что Комар-2 имеет малобазовую 8 – вибраторную антенну. Погрешность составляла до 3 и в некоторых случаях – до 5. Используя триангуляцию, в таком малоэтажном городе как Пардубице, можно было получить хорошие результаты по определению местоположения угнанного авто.

Местные бизнесмены предлагали совместно запустить этот проект, и черт нас дернул преподнести это направление нашей родной конторе. Там эта тема и была похоронена: не вынесла тяжеловесного планирования и тотального отсутствия мотивации. Позиции опытного образца системы были развернуты на зданиях Махачкалы, и там и остались.

Помнится завершение нашей последней поездки: на вокзале ждем наш поезд, который идет с Праги до Москвы. Стоянка всего 5 мин, поэтому нужно быстро найти вагон и оперативно погрузиться со всеми вещами. Благо, на станции есть любовно выполненные макеты поездов с указанием номеров вагончиков. На станцию влетает поезд, мы подбегаем к своему вагону, а он… закрыт. Наши минуты истекают, и мы начинаем барабанить по вагону что есть силы. В результате дверь распахивается и показывается пьяная проводница (когда она успела по дороге из Праги?), которая выпучила глаза и начала кричать: “В Пардубице посадки нет!”. Промелькнула мысль: “ну здравствуй, Родина…” и с этой мыслью, прорываясь сквозь заслон, мы заскочили в вагон.

Завершение истории

Оказывается, РЛК “Комар-2” не остался в 90-х, а получил свое дальнейшее развитие. В сети я нашел ссылки на брошюры этого изделия. Только пеленгатор там конечно уже не наш.

АРП, РП, DF, Direction Finder, РЛК Комар-2, Radar Komar-2

Радиолокатор “Komar-2”

Также я нашел в сети фирму, которая очень хотела делать пеленгационную систему: OM Complex, судя по сайту, она до сих пор здравствует. Сама Тесла прошла несколько трансформаций и по прежнему работает на этом рынке. Много лет спустя мы встретились с Радомиром Гервертом в Чешском доме в Москве и вспомнили старые добрые времена.

Никто из разработчиков этого проекта, включая меня, в конторе уже не работает. На память осталась только фотография пеленгационного блока, даже не помню когда и зачем ее сделали. К сожалению нет фото складной пеленгационной антенны – в ней были использованы оригинальные конструкторские решения. Программное обеспечение разработанное как для Комара, так и для Пихты-2С, легло в основу популярного АРП “Платан” (DF-2000), который я сделал уже 10 с лишним лет спустя.