Как мы аппаратную часть Baseband Unit разрабатывали: от идеи до серийного производства

Привет, Хабр! Меня зовут Руслан Лисевич, я разрабатываю BBU, а это — восьмая статья цикла о разработке базовых станций в YADRO.

В 2022 году перед нашей командой стояла амбициозная цель: создать конкурентоспособную базовую станцию мирового уровня. Сегодня покажу, как мы ее достигали на примере разработки аппаратной части BBU — YADRO BTS8100. Обсудим требования к оборудованию операторского класса, подготовку концепции, прототипирование, структурную схему BBU, плату вычислительного модуля и не только.

Сначала — работа с требованиями

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

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

• Стандарты и нормативная база. Изучали OBSAI, Telcordia, ITU-T. Наше оборудование должно соответствовать государственным нормам и проходить сертификацию. К тому же оно должно быть в реестре ЕРРРП МинПромТорга, а чтобы туда попасть, нужно выполнить ряд условий — в том числе по использованию отечественной компонентной базы. Критерии ужесточаются достаточно быстро, поэтому нужно сразу смотреть наперед. 

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

• Наша экспертиза. В 2022 году мы отлично умели делать серверы и СХД. Но в телеком-оборудовании есть свои особенности, и их нам только предстояло освоить — причем быстро. Тогда у нас уже было собственное производство (SMT, сборка), а значит, технологические ограничения фабрики нужно было закладывать в требования заранее. В то же время шло строительство нашего завода. Мы разрабатывали платы с учетом будущих возможностей производства печатных плат, многие из которых должны были проясниться только по результатам пусконаладочных работ оборудования.

• Видение продуктовой и SW-команды. Несмотря на долгий опыт работы с оборудованием зарубежных вендоров, нашу команду поддержали в желании абстрагироваться от готовых решений и двигаться в сторону классических требований в духе «Необходимо обеспечить…». Также наша аппаратная платформа должна исполнять специализированное ПО, ведь BBU — это часть программно-аппаратного комплекса. Мы ходили с вопросами к программистам — и вполне логично, что ответов у них еще не было: software тоже только начинал разрабатываться. В итоге на старте мы какое-то время двигались вперед на допущениях, четко фиксировали и перепроверяли их. 

Первый набор требований сложился из стандартов, анализа конкурентов, согласований с операторами, собственного опыта и видения продуктовой и смежных команд. Часть была жесткой (compliance, форм-фактор), часть — плавающей: ее мы закрывали эмпирически по мере продвижения. А еще важная характеристика для любого продукта — это его целевая себестоимость: фраза «мирового уровня» говорит не только об определенных характеристиках, но и о цене. Это действительно краеугольный фактор, который оказывает значительное влияние на архитектуру аппаратной платформы. 

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

Все открытые вакансии смотрите на карьерном сайте YADRO.

Подготовка концепции: на что ориентировались

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

Требования к оборудованию операторского класса

Условия эксплуатации

Блок BBU проектируется для indoor-применений. Чаще всего место установки — климатический шкаф, который может располагаться на столбах, опорах, стенах или крышах зданий. На самом деле список возможных мест значительно шире.

Помимо самого BBU, в шкафу обычно также располагается электропитающая установка: она питает не только BBU, но и другое оборудование, которое находится вне климатического шкафа. Аккумуляторная батарея, панель для распределения питания, различные датчики и другие компоненты. Запитывается BBU от -48 В постоянного тока.

Так это выглядит в реальности:

Когда мы говорим о базовых станциях, часто звучит термин «оборудование операторского класса» (Carrier Grade). Это не просто стандартная формулировка, а целый набор требований к надежности и производительности. Оборудование, соответствующее этому стандарту, может работать в ключевой инфраструктуре и предоставлять услуги пользователям. Чтобы достичь такого уровня, мы должны соответствовать техническим рекомендациям и нормативам. Один из них — устойчивость к физическим воздействиям: стандарт Telcordia SR-3580. Наши базовые станции спроектированы так, чтобы выдерживать воздействия, соответствующие уровню 3 по этому стандарту. Это значит, что они рассчитаны на высокую нагрузку и могут бесперебойно работать даже в сложных условиях эксплуатации.

В зависимости от конфигурации оборудования (frame, shelf), применяются разные требования. В нашем случае оборудование относится к shelf-level. Что это значит на практике?

BBU должен работать без перерыва в предоставлении сервиса в диапазоне от −5 до +55 °C. Работа в диапазонах от −5 до +5 °C и от +50 до +55 °C должна быть ограничена по времени до 96 часов. При отказе одного вентилятора в системе вентиляции шасси верхняя граница понижается до +40 °C. Относительная влажность воздуха должна быть в пределах от 5 до 93%, а температура не должна меняться более чем на 30 °C в час. Все это применимо на высотах до 1829 м над уровнем моря.

Условия и рабочая зона оборудования:

Чтобы оборудование соответствовало Carrier Grade, оно должно быть надежно на «пять девяток» 99,999%. Это значит, что суммарное время простоя не должно превышать 0,001% — то есть 5 минут 15 секунд за год. В пересчете на реальность из всего оборудования, которое мы устанавливаем в полях, за год может выйти из строя лишь ничтожная доля. Операторы прямо прописывают это в контрактах: все, что выходит из строя сверх допустимого процента, производитель должен менять за свой счет. На практике даже у зарубежных поставщиков, работающих на телеком рынке десятки лет, процент выхода оборудования из строя достигает 2–3%. Это говорит о сложных условиях эксплуатации, которые необходимо учитывать при проектировании оборудования Carrier Grade-класса.

Время простоя при этом суммарное на весь программно-аппаратный комплекс (ПАК). В телекоме все достаточно жестко: критические проблемы в ПО должны решаться за несколько часов, с немедленным выпуском исправленных версий, а поддержка работает 24/7.

Жизненный цикл  

Телеком-оборудование не только должно быть надежным и работать без остановок — еще оно должно легко обслуживаться: все-таки это не ЦОД, куда можно прийти и спокойно что-то поменять. К тому же оно должно легко адаптироваться под меняющиеся потребности операторов.

Так, перед нами стояла задача сделать шасси, которое позволит гибко масштабировать вычислительную мощность и при этом не потеряет актуальности на протяжении нескольких лет, чтобы его не приходилось менять при обновлении продуктовой линейки. Что это значило для нас? Недостаточно было закрыть целевые потребности «здесь и сейчас» — нам нужно было заглянуть в будущее и предсказать, как продукт будет развиваться. А потом заранее заложить все необходимое в железо.

Отсюда три конкретных требования:

• Обслуживание без специального инструмента. Все сервисные операции должны выполняться прямо на месте эксплуатации и без специализированного инструмента: открутил компонент руками, легко достал и заменил.

• Модульное наращивание. Если оператору в конкретной точке нужна большая вычислительная мощность, он наращивает ее локально, а не меняет BBU целиком.

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

Анализ оборудования топ-вендоров

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

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

Приведу маленький пример на одной и той же задаче ввода питания в шасси:

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

• У другого ввод питания был организован через модули управления, а режим запитывания всего шасси выбирался прикручиванием медной перемычки на backplane.

• У третьего стояла отдельная плата ввода питания с фильтрами и защитами, а сами преобразователи размещались на модулях.

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

Прототипирование

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

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

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

Пока мы ждали изготовления и тестировали отдельные узлы, параллельно шла разработка целевых плат. К моменту окончания тестов прототипов, инженерные версии контрольной и вычислительной плат были практически готовы. Оставалось учесть ошибки, найденные при проверках. Разработка самого сложного узла вычислительной платы (прототипа) заняла около трех месяцев, остальных около полутора: дробление на отдельные узлы позволило вести их разработку и проверку параллельно. Дальше мы все это «утрамбовывали» — и теперь одна плата управления (CB) и одна вычислительная (BB) спокойно помещаются в компактном корпусе современной BBU.

Покажу пару фотографий с тех времен. Слева — стенд для работы с EVT-платами вне шасси. Справа — два комплекта прототипов платы управления и вычислительной платы, соединенные между собой: это и есть будущая минимальная конфигурация BBU.  

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

Какая концепция получилась

Учитывая все вышеперечисленное, мы пришли к такой архитектуре BBU:

• централизованный ввод электропитания;

• сервисные процедуры не требуют извлечения шасси из КШ/стойки и не требуют специализированного инструмента;

• все модули доступны с передней панели, и могут устанавливаться опционально (модули ввода питания и вентиляции всегда устанавливаются);

• шасси с возможностью обновления на модули нового поколения в будущем;

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

Общий вид

Перечислю, что здесь расположено слева направо: модули ввода питания и вентиляции, затем модуль управления, три вычислительных и модуль внешней синхронизации, затем снова модуль управления, три вычислительных и два модуля внешних аварий. Модули DC_IN, FAN, SYN, EAM — общие для всего шасси.

Устанавливается BBU в стандартную 19-дюймовую стойку. Занимает 3U в высоту. Глубина корпуса 400.0 мм.

• Два модуля управления на схеме обозначены CB (выделены фиолетовым цветом).

• Шесть емкостных модулей на схеме обозначены BB (выделены синим цветом). В BBU их часто называют емкостными модулями. Именно их количество и тип определяют емкость станции: сколько секторов, несущих и активных абонентов она обработает.

• Модуль вентиляции шасси — на схеме это FAN (выделен зеленым цветом). 

• Модуль внешней синхронизации SYN (выделен желтым цветом). 

• Два модуля контроля внешних аварий EAM (выделены голубым). 

• Модуль ввода питания DC_IN (выделен красным).

• Общий backplane для соединения всех модулей между собой. 

Структурная схема BBU

Чтобы понять, как устроен BBU, давайте посмотрим на главные части устройства и общие связи между ними. Схема упрощена и не отражает полный набор связей, зато отражает суть:

Что здесь стоит отметить:

• Через модули управления (CB-1, 2) происходит управление базовой станцией. Подключается BBU в транспортную сеть оператора по Ethernet (Backhaul interface на рисунке). У модуля управления есть как медные гигабитные порты, так и порты для подключения SFP-трансиверов с оптикой. У CB есть общий канал управления модулями FAN, SYN, EAM. Между CB есть связь, обеспечивающая взаимодействие между двумя половинками шасси. Емкостные модули (BB1–6) обрабатывают данные, поступающие от RU. Подключается BB модуль к RU также по Ethernet (Fronthaul interface на рисунке). У каждой BB есть связь со своей CB внутри своей половинки через backplane. В этой статье я в основном говорю про аппаратную платформу, но об обработке данных и функциях можно прочесть в другой статье цикла про разработку БС в YADRO.

• Модули управления и вычисления можно использовать в половинках как независимо друг от друга, так и вместе, чтобы они работали на одну технологию. В теории получается, что в одном шасси можно сделать две базовые станции. Одна половинка будет работать на 4G, другая — на 5G. А можно объединить их, чтобы они работали на одну технологию и обслуживали больше абонентов. Модули CB, BB изначально проектировались так, чтобы поддержать не только GSM/LTE, но и 5G — через обновление ПО в будущем.

• Вентиляторы продувают шасси слева направо и не дают оборудованию перегреваться. 

• SYN-модуль позволяет получать или выдавать сигналы синхронизации. Также можно подключить внешнюю антенну: внутри модуля SYN стоит GNSS-приемник, он используется для получения точного времени, которое критично для работы базовой станции. 

• У EAM-модулей сухие контакты, которые позволяют подключить BBU к датчикам в климатическом шкафу. Когда происходит авария, оператор получает сигнал. 

• Backplane объединяет все модули. Также в системе через него распределяется питание, которое заводится в шасси.

Распределение питания

Питание 48 В заводится параллельно в CB и BB, а модули FAN, SYN, EAM получают питание уже с модуля управления.  

• Рабочий диапазон входного напряжения для номинала 48 В: 38,4–60,0 В. 

• Единый ввод питания для всего шасси с возможностью подключения проводами до 16 мм². 

• Защиты по входному питанию и преобразование напряжения реализованы непосредственно на модулях BB, CB. На каждом модуле стоит защита от переполюсовки, помех и микросекундных импульсов — например, когда поблизости ударяет молния. 

• Питание модулей FAN, SYN, EAM осуществляется вторичным питанием с CB по OR-ing между ними. То есть при извлечении одного модуля, второй продолжает обеспечивать питание.

Охлаждение

Как я уже писал выше, нам нужно работать в диапазоне температур от -5 °C до + 55 °C. Наш модуль охлаждения состоит из трех вентиляторов 92х92х38 мм с суммарным целевым расходом воздуха 600 м³/час. Система охлаждения реализована так, что если любой из вентиляторов выйдет из строя, оборудование продолжит работать без потери производительности, но при этом температура окружающей среды за бортом у нас должна быть не выше, чем +40 °C. На фото выше видно распределение потоков воздуха с одного из прогонов модели. О моделировании системы охлаждения читайте в другой статье цикла. 

Источники синхронизации

Здесь требования делятся на три измерения:

• Частотная: несущая частота должна держаться с точностью до миллиардных долей (3GPP требует ±50 ppb).

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

• Временна́я: абсолютное время (дата и время) должно совпадать у всех элементов сети.

При этом BBU должен поддерживать различные источники синхронизации:

• IEEE1588 (PTP) — позволяет синхронизировать частоту, фазу и время. Данные ходят по L2/3 уровню передачи данных.

• SyncE — только частотная синхронизация через транспортную сеть (не дает фазовой и временной синхронизации). Работает на физическом уровне передачи данных (L1).

• SYN-x — модуль внешней синхронизации, позволяет подключиться:

  • к другой базовой станции или оборудованию с разъемом, соответствующим ITU-T G.703, для получения фазы и времени;

  • к антенне и получать время и фазу от спутникового сигнала;

  • 2/10 МГц тактовый сигнал, для частотной синхронизации, через SMA.

Но что делать, если источник синхронизации перестал работать? Например, испортилась погода, и у нас пропал спутниковый сигнал. Для этого на модулях управления установлен OCXO (Oven-Controlled Crystal Oscillator) — термостатированный кварцевый генератор, который «держит» частоту и фазу сигналов синхронизации. При этом:

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

• поддержка двунаправленного 1PPS (Pulse Per Second) + ToD (Time of Day) между CB позволяет им работать в режиме ведущего или ведомого (в том числе с целью резервирования);

• один модуль управления может раздавать синхронизацию для всего шасси.

В реальной сети SyncE и PTP могут работать в паре: SyncE дает частоту, PTP — фазу и время. Технически PTP умеет и то и другое, но их сознательно разводят, чтобы каждая задача решалась своим, более точным путем. SyncE также позволяет увеличить длительность удержания времени при пропаже PTP или GNSS.

Общий бюджет времени

Давайте посмотрим на общий бюджет ошибки времени и ограничения. Вся цепочка «спутник → транспортная сеть → BBU → эфир» должна уложиться в ±1,5 мкс. Если мы получаем синхронизацию не с GNSS-приемника в BBU, а через транспортную сеть, то на всю базовую станцию остается в худшем случае 400 нс. Этот запас делится между BBU и RRU.

Почему синхронизация важна? В FDD (Frequency Division Duplex) прием и передача шли на разных частотах — хватало только частотной синхронизации. В TDD (Time Division Duplex) прием и передача делят одну частоту и разнесены по времени — значит, соседние станции обязаны договориться о том, «кто и когда передает». Ошибся на микросекунду — одна станция передает, пока соседняя слушает, и получаются взаимные помехи. Отсюда и наносекундные требования.

Распространение сигналов синхронизации в BBU

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

• Значение ToD «время суток» — это просто данные. Их передача не критична по времени, главное — успеть до синхроимпульса.

• Синхроимпульс 1PPS — «вот сейчас загрузи это время и начни считать». Медленный и, как понятно из названия, частота его — 1 Герц. Также несет фазу. 

• Общий тактовый сигнал — обычно восстановленный SyncE, от которого все локальные счетчики времени считают синхронно, чтобы не «уплыть» между обновлениями. Критична только его частота, не фаза. Также в качестве источника подойдет OCXO.

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

• Задержка распространения на плате ~6.6 пс на 1 мм, при этом длина трасс в backplane может без труда достигать одного метра в длину.

• Один проход через буфер дает до 3 нс задержки.

• Точность PHY при формировании метки времени от единиц до десятков нс.

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

• Zero-Delay Buffer. По сути, PLL с петлей обратной связи через трассу длиной равной длине компенсируемого участка: он выравнивает вход и выход почти до нуля, «пряча» задержку буфера.

• Round-Trip Time. Измерение задержки туда-обратно по backplane с расчетом поправки, которую применяют к фазе синхроимпульса или к самому значению времени.

Чем жестче класс точности, тем меньше права на «замерить задержки один раз в лаборатории».

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

К какому емкостному модулю мы пришли

В этой статье из всего BBU мы посмотрим только на BB (Baseband Board), потому что емкость станции, число секторов, несущих и абонентов определяет именно она. Ключевые зоны выделены цветами:

Если смотреть слева направо, то первое, что мы видим, — это разъемы, которые обеспечивают подключение к объединительной плате в шасси. Сразу над ними зона преобразования питания из 48 В в 12 В (выделена красным). В этой зоне также реализован комплекс конструктивных и схемотехнических решений, обеспечивающий стойкость к воздействию высоковольтных разрядов и превышению напряжения на линиях питания. Дальше у нас зона с SoC-ми, основная функция которых — это планирование использования ресурсов радиоканала (L2) и цифровой обработки радиосигналов (L1). Небольшая зона в центре используется для реализации синхронизации тактовых сигналов. SoC-3 и FPGA совместно обеспечивают функцию управления и мониторинга аппаратной части модуля. И в конце у нас располагаются шесть SFP-разъемов, которые обеспечивают подключение к RU (раньше упоминались fronthaul-интерфейсы — это именно они). У каждого FH-порта есть индикация, которая показывает в каком состоянии находится подключение. Также есть общая индикация статуса модуля. 

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

С радиатором:

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

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

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

Еще статьи из цикла про разработку базовых станций в YADRO:

— «Как базовая станция превращает данные в радиосигнал: разбираем цифровой тракт радиомодуля».

— «Какие этапы разработки и тестирования проходит радиомодуль в YADRO».

— «Эволюция сетевой подсистемы базовой станции: как мы пришли от программного маршрутизатора к аппаратному ускорению».

— «„Железо“ под давлением: как протестировать тысячи плат для базовых станций».

— «Задача сложная, времени мало: какие упрощенные модели мы использовали для тепловых расчетов BBU».