Всем привет! Меня зовут Алексей Караванов, я руководитель отдела тестирования программного обеспечения в YADRO. В нашем радиочастотном центре (РЧЦ) мы с коллегами разрабатываем и тестируем ПО радиомодулей для базовых станций. И сегодня хочу показать, какой путь проходит оборудование до момента, когда базовая станция будет запущена и начнет создавать покрытие для нашей с вами надежной связи.
Разбирать будем на примере радиомодуля RU B3 (B3 — это один из основных частотных диапазонов в России и мире, работающий на частотах 1800 МГц). Покажу, как выглядит процесс производства от платы до полноценного устройства и как мы тестируем аппаратные комплексы. Посмотрим архитектуру наших тестовых стендов и самих тестов — будет много фото и скринов.
Базовая база: что такое RU и из чего он состоит
Начну с примера: я родился и живу в Нижнем Новгороде. Почти весь наш город покрывает 4G, кое-где поддерживается 3G. В целом картина хорошая.
Так из чего состоят базовые станции (БС), которым мы этим обязаны? Основных элементов несколько:
Антенна — именно она распространяет сигнал.
Радиомодуль (RU) — располагается под антенной. Диапазоны могут быть разные, но в нашем с вами случае это B3.
Baseband Unit (системный модуль обработки, BBU) — модуль, который управляет базовой станцией. Обычно размещается на той же вышке, что и RU, но внизу, внутри аппаратного шкафа. Для корректной работы ему нельзя переохлаждаться и перегреваться.
Сам радиомодуль (дальше по тексту буду называть его RU) состоит из трех компонентов:
Digital Module (DM-плата). Здесь у нас центральной процессор (CPU), оперативная память (DDR), Ethernet-коннекторы (Ethernet управляет интерфейсами, которые приходят от BBU), питание (Power) для управления всем RU и контрольная линия — она соединяет цифровой модуль и PA-плату.
Power Amplifier (PA-плата), усиливающая сигнал. На ней находятся усилитель и RF-каналы (RU может работать в двух каналах параллельно).
Diplexer. По сути, это железка без электронной начинки — волноводы, которые позволяют преобразовать аналоговый сигнал на антенну. Чувствительность радиоустройства во многом зависит от способности диплексера выбирать нужные сигналы, а еще — отфильтровывать внешние помехи и продукты интермодуляции собственного передатчика. Но говорить об этом подробно в этот раз мы не будем.
Функциональная архитектура радиомодуля
DM-плата выглядит примерно так. Внизу расположены источник питания, процессор, коннекторы:
В PA-плате все то же самое. У нас есть главный коннектор, микросхемы управления и детекторы, пара усилителей, волноводная линия, соединяющая DM- и PA-плату:
Все это вместе с диплексером помещается в корпус:
Но прежде чем компоненты собираются в готовый радиомодуль, каждую плату мы отдельно производим и тестируем. Об этом дальше.
Сейчас �� нашем департаменте открыты такие вакансии:
— инженер по ручному тестированию;
— инженер по автоматизиции тестирования;
— инженер по тестированию радиоэлектронной аппаратуры;
— инженер по автоматизации производственного тестирования РЭА.
Ждем ваши резюме. Присоединяйтесь!
Как мы разрабатываем RU
Теперь давайте разбираться, как вообще появляется RU. Этапов несколько:
Proof of Concept (PoC, доказательство концепции). Сначала мы разрабатываем доказательство концепции. Заказываем отладочные платы и проверяем на них проведенные расчеты. Сверяем, соответствуют ли результаты моделирования и характеристики модулей заявленным значениям. Потом собираем на тестовой плате элементы: питание, сигнальный процессор, память и коннекторы.
Engineering Validation Tests (EVT). Когда элементная база собрана, изготавливаем первый образец, где все элементы впервые собраны на одной печатной плате. Дальше мы производим несколько образцов платы и проверяем на недостатки. Например, у нас есть определенный источник питания, он вводит помехи — тогда с помощью образцов мы улучшаем или заменяем его. Новые образцы у нас будут уже с другим источником питания. То же самое с коннекторами и другими элементами: если они работают некорректно, заменяем на более надежные.
Design Validation Test (DVT). Итак, мы уже получили результаты для EVT. А теперь, при необходимости, адаптируем дизайн платы и оптимизируем расположение компонентов так, чтобы следующие этапы производства были быстрыми и надежными.
Manufacturing Pilots и Volume Production — объединю эти два шага в один пункт. Здесь работа идет уже с собранными продуктовыми образцами, которые уходят в продакшн. Обычно если здесь и есть изменения, то незначительные.
С этапами разработки разобрались — приступаем к тестированию на производстве.
Как проводим тестирование
Итак, у нас есть печатная плата, мы ее запекаем, припаиваем элементы, а дальше начинаем все это тестировать. Этапов несколько:
1. Оптическая проверка — смотрим, все ли элементы на месте, не нужно ли что-то заменить, припаять и так далее.
2. Рентгеновская проверка — исследуем слои на запекание и убеждаемся, что все чипы припаялись.
3. Первый запуск и тестирование платы на стендах DMFTS для DM-платы и PAFTS для PA-платы. Звучит страшно, но это просто названия наших тестовых стендов, — подробно о них еще скажу ниже. Здесь мы тестируем каждую плату по отдельности и отсеиваем варианты с неисправными микросхемами. Тонкость в том, что в сборке работать могут даже бракованные платы, но на одиночных тестах все дефекты проявятся.
4. RUFTS после сборки. Так называется главный тестовый стенд, где мы проверяем RU в целом. На этом работа тоже не заканчивается. Дальше мы проводим тестирование на пропускную способность с реальными абонентскими устройствами в виде модемов.
Каждая плата проходит полный цикл тестов. Если стендов много, мы тестируем несколько плат одновременно.
О стендах еще поговорим ниже, а пока покажу нашу диаграмму производственного процесса:
Тестовые стенды
Ребята, которые никогда не работали с тестовыми стендами, часто представляют их себе так: поставил плату, подключил разъем, и готово. В реальности все, конечно, немного сложнее.
Первый стенд — DMFTS
Так выглядит наш стенд DMFTS (Digital Module Functional Test System):
Что тут происходит? Оператору передают плату, он устанавливает ее в ложемент, закрепляет двумя рычагами, подключает разъемы и запускает на экране тесты, которые мы подготовили.
В основном на этом стенде мы:
обновляем ПО и первично загружаем конфигурации в EEPROM цифрового модуля;
верифицируем внутреннюю периферию цифрового модуля;
измеряем ключевые характеристики приемо-передающего тракта;
проводим нагрузочное тестирование Ethernet Switch;
проверяем внешние интерфейсы — AISG, PA connector.
Структурная схема стенда:
У нас есть Switch box, который переключает каналы, чтобы проверить каждый по отдельности. Управление PA-платой реализовано через микроконтроллер — это адаптеры, которые дополнительно подключаются к плате. Это уникальная разработка, которую мы используем в этом стенде. Дальше идет Equipment — оборудование, которое позволяет нам измерить сигнал с DM-платы, чтобы оценить работу цифрового модуля. Всем этим управляет Test Runner — на нем крутится программное обеспечение, о котором мы поговорим чуть позже. Test Runner есть на каждом стенде: мы используем его в качестве тестового образца, чтобы запускать сами тесты.
Второй стенд — PAFTS
Как уже говорил выше, на PAFTS (Power Amplifier Functional Test System) мы тестируем PA-платы:
проверяем системы питания платы;
верифицируем цифровые интерфейсы;
предварительно настраиваем и калибруем режим работы модуля усилителя;
измеряем ключевые характеристики приемника и передатчика.
Стенд PAFTS
Стенд выглядит плюс-минус как предыдущий: есть экран, анализатор и генератор в качестве оборудования. Принцип такой же: кладем плату, зажимаем ее и начинаем проводить тесты. Например, это может быть тест на падение напряжения, потому что PA подключается к DM-плате, и питание идет с цифрового модуля. Или, наоборот, тест на превышение напряжения. Наша цель на этом этапе — отследить поведение PA-платы и RU в целом.
Если у нас падает напряжение на модуле RU, то до PA-платы напряжения тоже доходит меньше. Тогда схема будет примерно такой:
Третий стенд — RUFTS
На RUFTS (Radio Unit Functional Test System, DL&UL) мы тестируем RU в сборе:
калибруем выходную мощность передатчика и приемника;
верифицируем характеристики приемопередающих трактов на соответствие требованиям стандарта 3GPP;
проверяем работу с BBU.
На этом этапе мы уже собрали все платы и проверяем, что каждый радиомодуль соответствует стандартам 3GPP. Здесь же калибруем выходные параметры, выходную и входную мощность.
Посмотрите на фото:
Вы видите, что у нас есть анализатор, Switch box и два генератора. Почему их два? В основном на радиомодуль у нас приходит один общий сигнал, но как он поведет себя при помехах? Второй генератор как раз позволяет это выяснить. Допустим, рядом с нашей антенной висит другая, которая тоже принимает свой сигнал, и один и тот же сигнал будет попадать на ту или иную антенну. Два генератора помогают отследить, как в такой ситуации поведет себя радиомодуль.
Схема выглядит так:
На этом стенде у нас впервые появляются BBU. Switch box представляет собой большую коробку, где разведены все варианты схем, которые мы можем подключить с помощью RU по каналам. Например, подключить Power Meter и посмотреть мощность приемника и трансивера. Из оборудования у нас два генератора и анализатор.
Какие сигналы смотрим на стендах при тестировании RU
Приведу несколько примеров.
Выходной сигнал (TX), который идет на антенну. Проверяем мощность в каждом канале. Запущены две несущие.
Модулированный сигнал — на скрине ниже представлен 256-QAM. Оцениваем его при помощи приборов: они считывают параметры и сверяют с табличными значениями, которые прописаны в нашем тесте. Так мы видим, пройден тест или нет.
Еще мы проверяем, соответствует ли сигнал маскам. Например, у нас есть стандарт 3GPP и есть его маска, которая показывает, какие пороги не должен превышать сигнал. Тесты пом��гают убедиться, что мы в них вписываемся.
Итак, о стендах поговорили, но как насчет самих тестов?
Архитектура тестов
Для реализации тестовых кейсов мы выбрали Pytest. Сроки у нас были сжатые, а команда уже работала с этим фреймворком, когда писала тесты для RND. В Pytest много готовых инструментов как для запуска тестов, так и для работы с отчетами, так что для нас он удобен. Хотя во время разработки мы немного отошли от классической концепции фреймворка — например, внедрили объектно-ориентированный подход (ООП) в написание тестов, а сейчас создаем свои решения для тестов, но это тема для отдельной статьи.
Чтобы управлять устройствами, которые нужны для стенда, мы выбрали Python без зависимости от Pytest. Так мы реализовали набор библиотек, которые представляют некий уровень абстракции. С ними мы можем использовать различные виды измерительного оборудования и версии прошивок RU, не меняя сам код тестов.
На каждом стенде у нас есть экран, где мы выводим информацию. В целом, архитектура наших тестов и тестового фреймворка довольно простая. У нас свое веб-приложение — оно установлено на каждом стенде. В приложении есть доступ к базе данных. Когда тесты заканчиваются, мы записываем туда результаты и прикладываем отчеты. Всем этим управляет система для запуска тестов Test Core ATE (можете не гуглить, это мы придумали такое название). Device Under Test — это сам RU, который мы тестируем.
Так это выглядит на схеме:
Еще у нас есть две дополнительные библиотеки, которые помогают нам в тестах. Первая — это универсальная Equipment Management. Мы устроили ее так, чтобы у нас была возможность работать с любым видом оборудования. Теперь мы можем заменить оборудование одного вендора и поставить другое. Но принцип работы оборудования при этом одинаковый и запросы, которые на него поступают, идентичны. Если анализатор, например, выходит из строя, нам не нужно переписывать библиотеку.
Вторая библиотека — Remote Control. Это доступ к плате и оборудованию. Через нее мы можем удаленно подключаться к оборудованию на стенде.
Все наши тесты универсальны. Мы пишем их один раз, а дальше, если нужно, настройщик или разработчик вносят корректировки. Получается, на каждый тест у нас один конфиг. В нем перечислено, какое оборудование мы используем, какие есть шаги в тестах, какие нужны настройки на анализаторе и на генераторе. По сути, тут собрано все:
Если нам нужно что-то поменять — например, у нас новое оборудование — мы идем в соответствующую область (на скрине ниже выделил красным) и прописываем новые анализатор и генератор. Так тест поймет, к какому оборудованию обращаться.
Здесь же у нас перечислены шаги теста — мы пишем их заранее. Нам не нужно изменять тест и лезть в код. При необходимости мы просто правим конфиг, и тем самым сильно упрощаем себе жизнь для настройки других аспектов тестов.
В поле настройки анализатора и генератора указываем, какие частоты нам нужно проверить. Здесь же можно выставить частоту анализатора:
Как выглядит само веб-приложение? У нас несколько этапов и юзеров. Например, у оператора есть доступ к простому user-тесту: он нажимает на кнопку и через какое-то время получает результат, изменить тесты он не может. А вот разработчик и администратор уже могут настроить их под себя.
На скринах ниже — как раз настройки. Можно создать определенный тест или группу тестов. Если у нас несколько стендов, мы можем перенести тесты конфигом с одного стенда на другой и развернуть окружение там. Любой наш тест можно быстро зациклить и проверить его работоспособность.
В приложении можно отслеживать ход теста. Когда он запущен, у нас бежит желтая строка — смотрите на скрин ниже. Если тест пройден, он окрашивается зеленым. Не пройден — красным.
Настройки тестового стенда в приложении тоже есть. Точнее, это настройки Switch, о котором мы говорили выше. Можно выставить параметры и сконфигурировать стенд так, как нам нужно.
Благодаря DHCP-серверу у нас есть доступ к любому оборудованию, установленному на стенде. Сервер развернут на Test Runner, который позволяет нам следить, что оборудование в сети.
Если тест пройден и отмечен зеленым, мы сразу устанавливаем следующую плату. Если отчет красный, идем разбираться с этой платой, а на ее место устанавливаем другую и запускаем тесты уже для нее. Да-да, конвейерное производство как оно есть.
Во время каждого теста мы сканируем плату, вносим в базу ее порядковый номер, а потом подгружаем к ней отчет с результатами. Мы можем взять любой наш RU, посмотреть номер компонента и увидеть все тесты, которые он проходил. Вся эта инфо��мация хранится в нашей базе.
После тестов в радиочастотном центре начинается «работа в полях», она же полевое тестирование. Происходит это так: есть определенная область, оператор предоставляет нам место и выделяет соту, и мы начинаем гонять оборудование там.
Напоследок хочу отметить, что работать со стендами можно так же вечно, как смотреть на огонь и воду. Не бывает такого, что ты разработал один тестовый стенд, ушел и навсегда про него забыл. Так или иначе в процессе работы появляются идеи, как его усовершенствовать. Мне кажется, это базовое стремление, и без него не было бы развития в профессии.
Ну а теперь я готов отвечать на вопросы по теме. Спасибо, что читали!