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


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

1. Мы рассматриваем именно механический дизайн, не электрический и не программный.
2. Разбираем геостационарный телекоммуникационный КА и его приборы. Не марсианский спускаемый аппарат или космический телескоп. Они могут быть устроены сильно по-другому, хотя общие принципы без сомнения есть.

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

1. Радиационные воздействия.
2. Тепловые воздействия.
3. Механические воздействия.
4. Отсутствие среды (вакуум).
5. Электростатические разряды (ЭСР), или факторы электризации.
6. Электромагнитная совместимость (ЭМС).

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

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

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

1. Система энергопитания (СЭП). Ее задача выдать для потребителей электрической энергии необходимое напряжение. На больших аппаратах это обычно 100В DC. Чем меньше аппарат и его мощность тем, как правило, меньше и напряжение питания. В систему входят солнечные батареи источник энергии, их несущие конструкции и система развертывания. Датчики ориентации солнечных батарей и привода ориентации. Привод (электродвигатель) необходим, чтобы солнечную панель можно было ориентировать на солнце при движении аппарата по орбите. Добавим аккумуляторный блок и электронный прибор, назовем его блоком питания (БП). Основные функции БП: стабилизация напряжения, выдаваемого солнечными батареями, контроль заряда-разряда аккумуляторной батареи, управление приводами батареи, раздача напряжения на остальные приборы. Состав опять же примерный, просто для понимания того, что может быть в СЭП КА.
2. Система ориентации и стабилизации (СОС). Без нее КА будет случайным образом вращаться при движении по орбите. Ему необходимы датчики, которые бы определяли его угловое положение относительно системы отчета (например, связанной с землей) и исполнительные устройства, которые бы корректировали угловое положение. Обычно используется несколько типов датчиков, разной степени точности. Магнитометры, датчики ориентации на землю относятся к грубым. Солнечный датчик, который измеряет угол между направлением на солнце и плоскостью панели, на которой он установлен, используется для более точной настройки. Он, например, может использоваться для ориентации солнечных батарей на солнце. Самый точный и сложный датчик звездный. Он фотографирует видимое положение звезд и сравнивает его с картой, которая заложена в его памяти. И таким образом, очень точно вычисляет угловое положение панели, на которой установлен.
   Для телекоммуникационного спутника целевым критерием работы СОС является точность нацеливания антенн КА в нужную область на поверхности Земли. Расхождение реальной оси нацеливания антенны с теоретической должно составлять порядка 0,1..0,2 по азимуту и углу места. Соответственно, угловое положение КА должно быть еще точнее, т.к. есть погрешность установки антенн на корпусе КА.
   Исполнительными устройствами для СОС являются маховики или гиродины. Маховик может поворачивать КА в противоположную своему вращению направлению за счет реакций в опорах маховика. Необходимо минимум три маховика для корректировки углового положения, но по факту их больше, т.к. любые системы спутника обычно резервируются для надежности. Гиродин это силовой гироскоп, он может создавать момент по нескольким осям и заменяет собой несколько маховиков, но является более сложным и дорогим устройством. Также в любом спутнике есть двигательные установки, обычно несколько, например, маршевая, для смены/удержания орбиты и довыведения, и несколько коррекционных для стабилизации. Раньше это были реактивные двигатели, работавшие на токсичном гидразине и окислителе. Сейчас их заменяют на электрореактивные двигатели. Они имеют меньшую тягу на зато больший удельный импульс (более экономичны) и в качестве рабочего тела используют инертный газ ксенон.
   
3. Двигатели, баки, топливную систему и блоки управления двигателями можно выделить в отдельную систему.
4. Система траекторных измерений необходима, чтобы определять координаты спутника.
5. Командо-телеметрическая система (КТС). КА должен получать сигналы управления с земли, а на землю передавать телеметрию (служебную информацию о параметрах работы). Каналы и антенны этой системы обычно отделены от полезной связной системы, т.к. полезная нагрузка, после отделения от ракеты, включается не сразу.
6. Также отдельно можно выделить бортовой компьютер управления (БКУ). Большой электронный блок, который управляет работой аппарата.
7. Система обеспечения теплового режима (СОТР).
8. Несущие конструкции (корпус КА).

На последних двух системах мы остановимся подробнее, они в наибольшей степени и определяют конструкцию всех электронных приборов КА (в том числе, входящих в состав упомянутых выше систем).

Эти две системы физически представляют собой почти единое целое, поэтому рассматривать их будем совместно. Итак, что собой представляет корпус современного КА? Опять простой ответ это параллелепипед (коробочка) со стенками из сотовых панелей. Что такое сотопанель разберем попозже, пока просто запомним, что стенки имеют толщину 20-50мм, они достаточно легкие и прочные. Стенки скреплены между собой уголками на болтах/винтах. Да, вот так, без всяких нанотехнологий. Посмотрим на картинку КА с развернутыми антеннами и солнечными панелями. Так он может выглядеть на орбите.


У геостационарного аппарата стенки нашей коробочки будут ориентированы вполне определенным образом. Панели (1) ориентированы на южный и северный полюс Землю. Они также называются панелями-радиаторами, на них (с внутренней стороны) установлено оборудованием ретранслятора и с них же сбрасывается основная часть выделяемого тепла. Крылья Солнечных батарей закреплены на данных панелях, до развертывания они закрывают их внешнюю сторону. Панели (2) называются антенными, они ориентированы на запад и восток. Эти панели обычно отличаются от панелей-радиаторов применяемыми материалами. На них установлены большие рефлектора зеркальных антенн (3) полезной нагрузки. Облучатели зеркальных антенн могут быть расположены, как на антенных панелях, так и на торцевой панели (4). Она ориентирована на землю. Эта панель обычно служит для установки разного оборудования: дополнительных антенн полезной нагрузки, антенн КТС, датчиков СОС, облучателей зеркальных антенн и т.д. Противоположный торец это условно низ спутника. К нижней панели крепится адаптер, алюминиевый или углепластиковый конус с механизмами разделения (см. фото ниже).


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

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

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


Для любопытствующих, вот примеры раскрытия солнечных батарей при наземных испытаниях.


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


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


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

Мы немного разобрались, как выглядит КА снаружи. Теперь заглянем внутрь.

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

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



Собственно само оборудование ретранслятора это множество приборов установленных на плоскости панелей-радиаторов (с внутренней стороны) и объединенных кабелями или волноводами. Как это выглядит в процессе сборки можно посмотреть на фото.



Трубу с нижним отсеком обычно называют модулем служебных систем (МСС). Его внешний вид представлен на фото.


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


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



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

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


На картинке мы можем видеть структуру панели. Два тонких алюминиевых листа, обычно 0,3-0,5мм толщиной, между ними шестиугольные соты из алюминиевой фольги, высотой от 20 до 50мм. Если кто-то желает ознакомиться с технологией изготовления сотозаполнителя подробнее, можно начать с этих ссылок
www.kuranty.pro/sotovyiy-zapolnitel/obzor1 (отечественный производитель)
www.plascore.com/honeycomb/honeycomb-cores/aluminum (иностранный производитель)

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


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


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


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

Если есть желание еще полюбоваться на сотопанели в разных вариациях, можно открыть каталог производителя.
www.apco-technologies.eu/apco-content/uploads/2018/04/Catalogue-PdV-LR.pdf

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

Из трех видов теплопередачи в космосе у нас остается всего два. Конвекция исключается, современные спутники делаются негерметичными, как и большинство приборов внутри. Так получается легче и надежнее. Герметичные бочки старых аппаратов тяжелые по сравнению с сотовыми панелями и обеспечить надежную герметизацию в течение 15 лет (стандартный срок службы современных геостационарных КА) очень тяжело. Кондуктивный теплообмен возможен только внутри спутника, сбросить тепловую мощность в окружающее пространство можно только излучением. Посмотрим на следующую картинку.



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

T температура тела в Кельвинах, а постоянная равна 5,6710^-8 Вт/(м²K⁴). Чтобы панель находилась в тепловом равновесии, излучаемый тепловой поток должен быть равен получаемому от Солнца, т.е. . Путем несложных вычислений можно определить, что равновесная температура будет равна примерно 120С. А температура обратной стороны панели, обращенной в космос, будет равна температуре космического пространства. Это условная температура равная температуре абсолютно черного тела, излучающего поток энергии равный потоку тепловой энергии, всегда присутствующей в космическом пространстве. Источником данной энергии является реликтовое излучение, считается, что оно возникло в результате большого взрыва. Его температура равна 3 К. Для практических расчетов ей легко можно пренебречь, т.к. по закону Стефана-Больцмана плотность энергии пропорциональна четвертой степени температуры и для 3 К она будет ничтожна мала. Возвращаясь к нашей условной панели ее солнечная сторона будет нагрета до 120С, а затененная охлаждена до -270С. Нечто подобное происходит с солнечными батареями, они всегда должны быть развернуты перпендикулярно Солнцу. Их реальные температуры конечно меньше, т.к. их пластинки далеко не идеальный теплоизолятор и часть тепловой энергии излучается с затененной стороны. Но термоциклирование в диапазоне примерно 100С они должны выдерживать. Радиоэлектронная аппаратура в таких условиях нормально функционировать не сможет.

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

Посмотрим на картинку, полученную по результатам многолетних измерений специальной миссии NASA Clouds and Earth Radiant Energy System (CERES)



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


Для целей теплового расчета КА берут крайние средние значения: максимальный средний тепловой поток (средний за виток, полученный за все время 5-летних измерений для конкретного наклонения орбиты, на картинке солнечная синхронная орбита) и максимальный средний альбедо и оба минимума. Также к этим максимумам добавляем максимальный поток от Солнца (), а к минимумам минимальный поток от Солнца (1322). Также учитывается деградация характеристик оптических покрытий. Расчет ведут с постоянными значениями для всего витка. Такой расчет весьма консервативен (что для космоса стандартный подход), т.к. в реальности альбедо и тепловой поток обычно примерно обратны, а здесь берутся крайние значения. Это называется горячий и холодный случай. Горячий определяет максимальную рабочую температуру эксплутации приборов, холодный соответственно минимальную. Под температурой приборов понимается температура посадочной поверхности прибора (температура внутренней обшивки панелей-радиаторов). Внутри самих приборов температуры естественно выше (если в них есть источники тепла). Холодный случай также используется для расчета требуемой мощности обогревателей для ситуации, когда полезная нагрузка (основной источник тепла) отключена, и спутник не должен замерзать.

Картинки взяты из этой статьи, кто хочет, может погрузиться в вопрос поглубже.
ttu-ir.tdl.org/bitstream/handle/2346/72957/ICES_2017_142.pdf?sequence=1&isAllowed=y

Естественно, что необходимо учитывать движение КА по орбите, при котором углы поворота панелей относительно солнца постоянно изменяются, Земля вращается и т.д. Вручную этим давно никто не занимается. Используются специальные модули для CAE-систем, которые умеют учитывать повороты модели КА при движении по разным типам орбит. Например, MSC Thermica.

Итак, мы выяснили, что на КА прилетает непосредственно от Солнца, теплового излучения Земли и скажем отраженного. Правда, это для низкоорбитального КА. Для ГСО эти дополнительные потоки будут во много раз меньше, т.к. радиус ГСО в 6 раз больше радиуса Земли. Но ведь есть еще собственная мощность. Для современных телекоммуникационных КА она может доходить до 15 кВт. А сколько могут сбросить в космос радиаторы с коэффициентом излучения =1, например, при +50С (стандартная максимальная рабочая температура панели для МПН). Используя тот же закон Стефана-Больцмана получим всего 600 Вт с одного м². Не очень-то и много. Проблема здесь кроется в том, что для теплообмена излучением важна только площадь проекции радиатора на холодную поверхность (на которую он излучает), а ребра, как у радиаторов для теплообмена конвекцией, бесполезны. Ребра будут переизлучать энергию друг на друга, и такой радиатор все равно будет работать, как плоская панель. Соответственно площадь наших панелей-радиаторов, обращенных в космос должна быть не меньше 25 м². Уже не мало, и не забываем про тепловые нагрузки, описанные выше. От них, в идеале, надо избавиться. Чтобы приблизиться к этому идеалу используют терморегулирующие покрытия, которые создают нужные коэффициенты поглощения и отражения ( и ) внешних и внутренних поверхностей КА для определенного спектра электромагнитного излучения.

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


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

1. Хорошо поглощает/излучает оба спектра (оптический и инфракрасный). Это уже упомянутая черная краска.
2. Хорошо поглощает/излучает инфракрасный спектр, отражает оптический. Это будет покрытие для внешней стороны панелей-радиаторов. Они должны хорошо излучать инфракрасные волны в космос, но не нагреваться от солнца.
3. Хорошо поглощает/излучает оптический спектр, не излучает инфракрасный. Такие покрытия нам собственно без надобности, даже если они существуют.
4. Хорошо отражают оба спектра.

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

Терморегулирующее покрытие второго типа это, например, белая краска. Она хорошо излучает в инфракрасном диапазоне, если для черной краски =0,95, для белой он лишь немного хуже, порядка 0,85..0,9. При этом для обычной белой краски альбедо (коэффициент отражения солнечного излучения) будет порядка 0,7, а для специальной космической может достигать 0,9. В принципе, 0,9 уже достаточно, чтобы обеспечить тепловой режим КА. Но, к сожалению, с космическими красками есть две проблемы. Они механически весьма непрочные с плохой адгезией к окрашиваемым поверхностям. А также под действием солнечной радиации и микрометеоритов они меняют цвет и их оптические свойства сильно проседают за 15 лет САС, что приводит к перегреву аппарата. Для панелей-радиаторов используют более продвинутое покрытие, называемое солнечным отражателем. По сути, он представляет собой зеркало. На пластинку из кварцевого стекла с одной стороны наносят напыление из серебра. Пластинки наклеивают на панель-радиатор с внешней стороны. Стекло хорошо излучает в инфракрасном диапазоне, порядка 0,8, а солнечные лучи отражают от серебряного напыления с до 0,95. Характеристики солнечных отражателей деградируют гораздо меньше, чем у белой краски.

Вот как выглядит внешняя сторона панели-радиатора.



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



Эта золотистая пленка называется экранно-вакуумная теплоизоляция (ЭВТИ). Она состоит из нескольких слоев пленки (для космоса обычно полиимидной) на которую напылен тонкий слой металла: золота, серебра или алюминия. Перечисленные металлы имеют очень низкий коэффициент излучения для обоих спектров, оптического и инфракрасного. Их будет порядка 0,05 для алюминия и 0,03 для золота и серебра. Правда это верно для тонкой однородной фольги или полированного металла. У обычной алюминиевой детали этот коэффициент будет выше из-за шероховатости поверхности (излучение переотражается от микронеровностей и у него выше шанс поглотиться), а также покрытия или оксилов на поверхности. ЭВТИ состоит из нескольких слоев металлизированной пленки, между которыми проложена сетка для уменьшения кондуктивной теплопередачи. Как это выглядит внутри видно на фото.


Каждый слой дает коэффициент отражения в интересном нам диапазоне электромагнитного излучения порядка 0,95. Т.е. второй слой пленки поглотит всего 0,050,05 прилетевшей извне энергии (если не учитывать кондуктивную теплопередачу). В целом, энергия, которая проникает под такую защиту ничтожна. ЭВТИ не всегда снаружи красивая и блестящая, наружный слой может быть черным, как на одном из первых фото, где КА закреплен на поворотном механизме. Такую ЭВТИ используют, например, для верхней панели КА, где расположены датчики ориентации и нежелательно, чтобы солнечные блики, отраженные от блестящей поверхности их засвечивали. Верхний слой естественно будет сильно нагреваться, но если общее количество слоев достаточно, то теплопередача все равно будет минимальна. Несмотря на металлизацию по своим конструкционным свойствам ЭВТИ это ткань. И обращаются с ней примерно, как с текстильным материалом. К панелям его обычно крепят на липучки (hook and loop fasteners по-иностранному, или Velcro название фирмы). К матам ЭВТИ липучки пришиваются или приклеиваются. В случае приклейки весь мат ЭВТИ рядом с местом приклейки скрепляется специальной пластиковой булавкой. Конструкцию можно посмотреть на картинке.



Насколько я понимаю, прошитая ЭВТИ имеет меньшее тепловое сопротивление в месте прошивки из-за того, что слои сильно прижимаются друг к другу и кондуктивная теплопередача улучшается, поэтому способ с булавками и приклейкой более прогрессивен. Маленькие белые ленточки на черной ЭВТИ, на уже упомянутом выше фото, как раз должны закрывать места установки булавок.

Также можно ознакомиться с каталогом российского производителя.
www.niikam.ru/products.html

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

С данной составляющей СОТР, мы вроде разобрались. Теперь разберемся с тем, как обеспечивается кондуктивный теплообмен внутри КА. Сама по себе сотопанель не очень хороший проводник тепла, несмотря на то, что она алюминиевая. Ее внешние листы весьма тонкие, а сотозаполнитель практически пустой. Его обычная плотность порядка 50 кг/м3, а плотность например АМг6 2640 кг/м3, это значит, что теплопроводность сотозаполнителя будет в 2640/50 раз меньше, чем у алюминия. Если поставить приборы просто на сотопанель, то под ними, на стороне панели, обращенной в космос, будут горячие пятна, а остальная панель будет холодной. Необходимо распределить тепло по всей панели и ключевую роль в этом играют тепловые трубы (ТТ), встроенные внутрь панели-радиатора. Тепловые трубы для космоса отличаются от обычных компьютерных трубок. Для тех, кто не помнит принципы работы тепловой трубы небольшое пояснение.


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



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



Аксиальные ТТ заправляют не водой, а аммиаком, или смесью других, тоже токсичных веществ. Водой заправлять нельзя, т.к. в условиях, образующихся внутри ТТ она будет сильно корродировать с алюминием. Дополнительный бонус в том, что такой теплоноситель работает при отрицательных температурах, до -40С. Данная температура обычно является температурой холодного старта для приборов МПН. Т.е. температурой, при которой они первый раз включаются после развертывания КА на рабочей орбите. В дальнейшем термоциклирование приборов происходит в более узком диапазоне температур, обычно -10...+50 (рабочий диапазон температур). В отечественных КА верхнюю границу обычно делают не более +40 из-за низкой надежности нашей элементной базы.

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



С помощью изогнутых труб можно перераспределять тепло между разными панелями. Пример на фото.



На самом деле собирать тепло с поперечных труб и распределять его между панелями можно с помощью жидкостного контура. Он обеспечит меньшие тепловые сопротивления и обеспечит большую гибкость в плане компоновки приборов на панели: можно расположить больше источников тепла в одном месте, если это удобно из прочих соображений (длины кабелей и волноводов например). Но это при условии, если удается сохранить столько же высокую надежность системы с насосами и клапанами, как у пассивной системы из тепловых труб. Кому интересно, может ознакомиться с сайтом производителя или презентацией.
www.bradford-space.com/products-avionics-mechanically-pumped-fluid-loop.php
tfaws.nasa.gov/TFAWS04/Website/program/Speakers/TFAWS2004PresentationonMechLoops-v1.pdf

Осталось добавить в нашу систему СОТР нагреватели и электронные блоки, которые будут управлять их работой. Нагреватели устроены довольно просто две полиимидные пленки, между которыми вклеен резистивный контур.



Их наклеивают на панели над полками ТТ на площадях свободных от приборов. Чисто для справки: полиимидная пленка с нанесенным акриловым адгезивом вполне легитимный космический скотч (kapton), который может использоваться для срочной доработки нашего КА.

Собственно на этом хотелось бы завершить первую статью. Мы получили общее представление о несущих конструкциях КА и более подробно разобрали функционирование СОТР. Надеюсь стало понятно, как определяются максимальные и минимальные температуры посадочной поверхности для приборов внутри спутника. Для тех, кто хочет узнать больше о СОТР и теплообмене КА рекомендуется книга Spacecraft Thermal Control Handbook, David G. Gilmore. В ней масса всего интересного: описаны разного рода экзотические устройства, типа раскрываемых радиаторов, тепловых аккумуляторов или переключателей теплового интерфейса. Про тепловые трубы мне также нравится книжка Тепловые трубы для охлаждения и термостатирования радиоэлектронной аппаратуры, В.А. Алексеев, В.А. Арефьев. В следующей статье планирую рассмотреть механические нагрузки (вибрации и удары), воздействующие на КА и то, как они преобразуются в механические нагрузки на приборы.

Спасибо за внимание!

Сап, котятки.

Я пришёл рассказать о проекте UAVCAN новом сетевом стандарте для организации взаимодействия узлов и компонентов современных транспортных средств с высоким уровнем автономности/автоматизации. Название является акронимом от Uncomplicated Application-level Vehicular Communication And Networking (несложные бортовые сети и коммуникации уровня приложения).

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

Конъюнктура

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

Мы наблюдаем быстрый рост сложности бортовых систем, связанный с развитием функциональных возможностей транспортных средств (особенно беспилотных) в целом, и систем автоматического управления в частности. Когда мы говорим "бортовая система", мы подразумеваем совокупность автоматики, необходимой для реализации базовых функций транспорта; например, БСУ/ЭДСУ летательных аппаратов, всевозможные ЭБУ в автомобиле, полётный контроллер в дроне или космическом аппарате, сенсоры (радары, камеры), датчики, исполнительные механизмы, и т.п.

Бортовая электроника (электрика) автомобиля конца 20-го века может быть исчерпывающе описана довольно тривиальной схемой; вот, например, схема ВАЗ 21099:

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

Сегодняшние транспортные средства являются в значительной мере программно-определяемыми в том смысле, что существенная часть функциональности и поведений задаётся не столько электрической/механической конфигурацией, сколько программным обеспечением (ПО), что порождает соответствующий перекос концептуальной сложности в сторону бортового ПО. В контексте космических аппаратов это обстоятельство было подмечено ещё инженерным коллективом NASA, работающим над программой Аполлон. В равной мере это применимо и к современным автомобилям (показательна известная история ранней Tesla Model 3, где проблемы антиблокировочной системы были исправлены удалённым накатыванием обновлений без участия владельцев), и к летательным аппаратам (в особенности с ЭСДУ).

Абстракции позволяют нам обойти когнитивное ограничение на количество сущностей, единовременно удерживаемых в сознании. В теории систем этот принцип известен как "чёрный ящик". Любой человек, хоть раз державший в руках компилятор, знает, как это работает: сложные подсистемы описываются не непосредственно, а в виде ограниченных функциональных блоков со строго определённым интерфейсом, скрывающим их реализацию. В рамках дискурса общих информационных технологий безусловно делается предположение, что человеку, мыслящему на определённом уровне абстракции, нет нужды вникать в специфику реализации задействованных на данном уровне блоков, иначе нарушается принцип чёрного ящика. Это предположение не является безусловно корректным если речь идёт о критических системах, где необходима высокая живучесть/отказоустойчивость. Объясняется это тем, что второстепенные функциональные особенности различных компонентов в совокупности могут порождать потенциально опасные непредусмотренные поведения (как это демонстрируют былинные отказы Mars Climate Orbiter, Airbus A400M в Севилье, Ariane 5, и т.п.).

Растущая сложность бортового оборудования отражается в развитии стандартов безопасности. Более сложные системы создаются композицией более сложных подсистем, что формирует спрос на конкретные гарантии поведенческих характеристик компонентов (если у нас есть, скажем, радар, мы хотим точно знать, в каких условиях и как он будет работать, как его характеристики коррелируют с параметрами среды, и вообще неплохо бы убедиться, что его разработчики мышей ловят). Примером ответа индустрии на этот запрос будет концепция Safety Element out of Context (SEooC), введённая в новом автомобильном стандарте ISO 26262. Строго говоря, тема стандартизации не имеет прямого отношения к нашему сугубо техническому проекту, но она отражает общие тренды в индустрии к переходу к композициям более сложных компонентов и как следствие, более сложных интерфейсов.

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

Здесь следует внести разъяснения касательно специфики реального времени и высокой надёжности для читателя, не являющегося специалистом в этой области. Разработчик прикладного ПО, веб-сервера или типичной бытовой встраиваемой системы (вроде компьютерной периферии) сочтёт покрытие тестами достаточной гарантией адекватности ПО. Проблемы реального времени в сложных системах такого рода возникают редко, а когда они возникают, цена временных отклонений обычно достаточно мала, чтобы можно было пренебречь жёстким ресурсным планированием или формальным анализом планировки задач (schedulability analysis). Процессы жёсткого реального времени обычно либо просты, либо цена ошибки несущественна (в качестве примера бытового жёсткого реального времени можно принять логику работы печатающей головки струйного принтера, привод экструдера 3D печати или аудиокодек). Эмпирические методы в целом преобладают над формальными; повсеместно применяется бенчмаркинг и амортизационный анализ. Если продукт показывает приемлемые результаты в подавляющем числе случаев, он принимается соответствующим требованиям; более строгие подходы обычно нецелесообразны финансово.

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

Говоря о балансе проектировочных затрат и рисков, интересная тенденция сейчас имеет место в космической отрасли: как метко отмечает Casey Handmer, наблюдаемое ныне снижение стоимости вывода космических аппаратов (КА) сдвигает оптимальный баланс в сторону решений с менее строгими гарантиями безопасности и менее затратной разработкой. В случае же БПЛА наблюдается обратный тренд ввиду распространения более ответственных применений и увеличения числа аппаратов в эксплуатации.

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

Различия в предпосылках также объясняют, почему прекрасно зарекомендовавшие себя в ИКТ решения (тысячи их: очереди сообщений, фреймворки, сетевые стеки с TCP/IP во главе, распределённые БД, операционные системы, etc.) обычно непригодны для ответственных применений и почему безопасные системы часто отдают предпочтение специализированным технологиям.

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

Обычный порошок

Картина положения дел в индустрии будет неполной без хотя бы поверхностного рассмотрения существующих технологий построения отказоустойчивых распределённых систем реального времени. Решения эти обычно интересны технически, созданы с оглядкой на многолетний опыт и проверены временем в реальных продуктах. Однако, тем не менее, горшки CiA/SAE/RTCA/EUROCAE/AUTOSAR/OMG/etc. обжигают отнюдь не боги.

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

1. Аналоговые схемы

Просто и прямолинейно. Электрические, пневматические, гидравлические, механические средства непосредственного взаимодействия между узлами и компонентами попадают в эту категорию. Приведённая ранее схема ВАЗ 21099 тоже отсюда.

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

2. Логическая шина

Шина данных есть довольно общий термин. Мы здесь под этим подразумеваем модель взаимодействия, где атомарной единицей данных является структура из логически связанных сигналов/параметров, и внимание проектировщика в значительной мере сосредоточено на определении этих структур и логики их обмена.

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

Начнём с первого. Если компонент А непрерывно сообщает компоненту Б больше одного параметра, имеет смысл временное разделение (мультиплексирование) сигналов. Такое уплотнение позволяет наращивать число параметров при постоянном числе физических межкомпонентных соединений, что удешевляет/облегчает конструкцию. Практическим примером будет ARINC 429 древний и незамысловатый авиационный протокол, реализующий обмен фиксированными 18-битными словами с щепоткой метаданных по выделенным (некоммутируемым) линиям. Типичная топология выглядит так:

Диаграмма адаптирована из "The Evolution of Avionics Networks From ARINC 429 to AFDX", Fuchs, 2012.

ARINC 429 довольно атипичен как бортовая шина тяжело привести другой пример использования физической топологии точка-многоточка (хотя причастные к малым дронам могли бы вспомнить здесь DShot и MAVLink; последний изначально предназначен для беспроводной связи с наземной станцией, но иногда применяется для внутрибортовой коммуникации). Этот подход имеет особый смысл в простых критических системах жёсткого реального времени, потому что временные свойства процесса доставки сигнала от отправителя к получателю абсолютно очевидны и не требуют сложного анализа. Среда передачи не разделяется с другими компонентами, поэтому нет нужды оценивать вклад каждого в загрузку среды и результирующие побочные эффекты. Однако, этот метод не масштабируется и делает логику взаимодействия сильно зависимой от физических параметров сети (если к компоненту не потрудились пробросить кабель при проектировании, соответствующих данных он никогда не получит).

Широкое распространение получила шинная топология (мы говорим о физическом уровне, не забывайте). Вероятно, CAN не нуждается в представлении; на нём основано множество протоколов и стандартов верхнего уровня. Здесь же FlexRAY, LIN, MIL-STD-1553 и ранние стандарты Ethernet (современный Ethernet используется только в коммутируемой конфигурации).

CAN показателен в контексте реакции отрасли на рост сложности продукции. Введённая в 1986 первая версия стандарта предлагала крайне ограниченный MTU в 8 байт на пакет. В 2012 появился CAN FD с MTU в целых 64 байта и увеличенной пропускной способностью. С конца 2018 года в активной разработке находится CAN XL с MTU 2 КиБ и ещё чуть более высокой скоростью (начало ISO стандартизации запланировано на 2021 год).

Говоря о физических шинах, нельзя не вспомнить интереснейшее начинание под названием Wireless Avionics Intra-Communications (WAIC). WAIC предлагает повысить отказоустойчивость бортовых критических сетей введением гетерогенной избыточности, где резервным каналом станет беспроводной. В целом, беспроводные бортовые сети можно считать фундаментально менее надёжными, чем бортовые проводные/оптические, ввиду слабого контроля за состоянием среды обмена (эфир один на всех). Однако, в совокупности с традиционными сетями, беспроводные позволяют поднять отказоустойчивость из-за устранения отказов общего вида, свойственных проводным сетям, ведь механическое повреждение элемента конструкции может с высокой вероятностью повредить все избыточные проводные соединения:

Диаграмма с сайта WAIC.

Физическая шина размещает всех участников на едином сегменте сети, что создаёт проблемы масштабируемости, ведь все узлы вынуждены организовывать обмен внтутри общего домена коллизий. Сложные транспортные средства на острие прогресса (скажем, современные авиалайнеры и космические аппараты) не в состоянии организовать работу систем в пределах ограничений существующих физических шин, поэтому в ход идут коммутируемые сети. Из значимых следует вспомнить SpaceWire (чрезвычайно узкоспециализированная технология; насколько мне известно, совершенно не представлена вне КА) и, конечно, Ethernet.

В современном аэрокосмосе широко применяется коммутируемый Avionics Full-Duplex Switched Ethernet (AFDX) как на стомегабитной медной паре, так и на оптике (см. Boeing 787). Несмотря на передовой физический уровень, логически это всё тот же ARINC 429, где физические соединения точка-точка заменены их виртуальными репрезентациями. Это решает проблемы масштабируемости, но не предоставляет новых инструментов проектирования логики. Сети AFDX проектируются со статическим планированием обмена с применением автоматических доказательств, что позволяет получить гарантированные временные характеристики доставки несмотря на привнесённые коммутацией сложности. Широко применяется полное дублирование сетевого аппаратного обеспечения (коммутаторов и кабельной системы) для отказоустойчивости. Ниже показан пример физической топологии AFDX подсети космического аппарата с дублированием; при этом логическая сеть ARINC 429, построенная поверх (не показана), определяется конфигурацией ПО коммутаторов вместо физической конфигурации кабельной системы:

Диаграмма из "Communications for Integrated Modular Avionics", Alena, 2007.

Гарантированные параметры сети объясняют почему в сетях жёсткого реального времени редко применяется подтверждение доставки. Вторая причина в том, что процессы реального времени часто предполагают сторого периодический обмен данными, где затраты времени и ресурсов сети (которые, замечу, под строгим учётом) на отправку подтверждения или второй копии данных оказываются неоправданными из-за скорой отправки очередного пакета с более новыми данными в рамках естественного течения процесса. Поэтому, в частности, AFDX построен на (слегка модифицированном) протоколе UDP/IPv4. Использование классических "надёжных" протоколов вроде TCP/IP в подобной среде было бы не просто излишним, а контрпродуктивным они несовместимы с особенностями процессов реального времени.

Общая характеристика рассмотренных технологий и построенных на их основе высокоуровневых протоколов заключается в их ориентированности на организацию низкоуровневых сценариев взаимодействия, где фокус внимания проектировщика сосредоточен на группах определённых параметров и их пересылке между конкретными аппаратными и программными компонентами. На логическом уровне мы всё так же имеем дело со жгутами виртуальных проводов, как на схеме ВАЗ 21099. Подобно тому, как рост сложности решений заставил индустрию ИКТ пережить несколько смен парадигмы за последние десятилетия, подходы к построению архитектуры распределённых бортовых систем претерпевают изменения под давлением спроса на автономность и автоматизацию транспортных средств. В 2020 мы наблюдаем первые симптомы несостоятельности традиционных методов и попытки к переходу на качественно более мощные средства, о чём будет следующий раздел.

3. Распределённые вычисления

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

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

Пожалуй, наиболее значимым на сегодня примером такого подхода будет граф распределённых вычислений из Robot Operating System (ROS) (строго говоря, ROS не является операционной системой, это скорее высокоуровневый фреймворк). Изначально ROS был создан в качестве SDK для окологуманоидного робота PR2 от Willow Garage, но исследователи быстро увидели потенциал фреймворка в других робототехнических системах (от пылесосов и манипуляторов до БПЛА и робоавтомобилей), и он превратился в самостоятельный проект. За несколько лет вокруг ROS развилась богатая экосистема программного обеспечения, решающего многие типовые задачи вроде компьютерного зрения, локализации и картографирования, взаимодействия с аппаратным обеспечением, и т.п. Если изначально фреймворк создавался для исследовательских задач, то интенсивное развитие его экосистемы (и отрасли в целом) со временем поставило вопрос о продуктизации и трансфере наработок из лабораторий в полевые условия, с чем возникли значительные трудности.

Пример визуализации распределённых процессов на ROS. На схеме показан фрагмент системы управления автономного БПЛА в режиме программно-аппаратного моделирования. Овалы обозначают процессы, прямоугольники и стрелки обозначают связи издатель-подписчик.

Описание полного спектра проблем продуктизации основанных на ROS изделий приведёно в статье Why ROS 2 [Gerkey], которая, как нетрудно догадаться из названия, решительно предлагает выпустить вторую версию с оглядкой на новые потребности индустрии. Одной из ключевых проблем здесь является неспособность изначально исследовательского фреймворка удовлетворить радикально более жёсткие требования продуктовых систем к предсказуемости и гарантиям безопасности, которые зачастую обусловлены не только коммерческим интересом, но и законодательным регулированием (особенно в случае автомобильной или аэрокосмической отрасли). Коммуникационная подсистема ROS, обеспечивающая межкомпонентные взаимодействия, является одной из наиболее критических и сложных частей фреймворка. В первой версии использовалась собственная реализация, созданная с нуля, принципиально несовместимая с ответственными применениями, из-за чего во второй версии в роли коммуникационной подсистемы использовали популярное готовое решение Data Distribution Services (DDS).

DDS является сильно отдалённым потомком CORBA, ориентированным на реальное время и модель издатель-подписчик (с недавних пор предлагается также встроенная поддержка клиент-серверных взаимодействий, но на практике первый тип наиболее востребован). DDS широко применяется не только в транспорте и робототехнике, но и в промышленности вообще, зачастую выступая в роли выделенного коммуникационного слоя (собственно, как в случае ROS 2) для вышележащих технологий. Особого упоминания здесь заслуживает Future Airborne Capability Environment (DDS FACE) для критической авионики; однако, на сегодняшний день, большая часть реальных применений DDS в аэрокосмосе приходится на немногочисленные военные системы, которые не следуют гражданским стандартам безопасности.

Как было упомянуто, DDS дальними корнями уходит в CORBA оба стандарта поддерживаются одной организацией. Последняя изначально не предназначалась для систем реального времени, но отраслевые реалии заставили исследователей начать рассматривать вопросы её адаптации для реального времени ещё в конце прошлого века. В работе "The Design of the TAO Real-Time Object Request Broker" [Schmidt et al, 1999] большое внимание уделяется тому факту, что проектирование адекватной сети реального времени самой сетью не ограничивается обязательному анализу подлежат вопросы реализации логики протокола на конечных узлах с соблюдением временных гарантий. В разрезе CORBA синопсис рассматриваемых проблем приведён ниже; эти же принципы легко переносятся на практически любую современную технологию того же толка:

Цифрами обозначены ключевые аспекты реализации, где предписан анализ временных характеристик внутренних алгоритмов протокола. Диаграмма из "The Design of the TAO Real-Time Object Request Broker", Schmidt et al, 1999.

Шмидт с коллегами воплотил идеи в популярной ныне C++ библиотеке TAO (The ACE ORB), которая легла в основу некоторых современных реализаций DDS. Сама по себе TAO насчитывает более двухсот тысяч строк кода без учёта специфики DDS, которая привносит ещё дополнительный код сверху. Из более современных и независимых от TAO инкарнаций DDS упомяну, пожалуй, наиболее многообещающую на сегодня eProsima Fast-DDS (это оценочное суждение, а не реклама) без сторонних зависимостей и тестов она занимает более трёхсот тысяч строк C++ кода (и реализует при этом не все опциональные возможности стандарта). Эти сведения приведены с целью иллюстрации порядка концептуальной сложности DDS.

Как нетрудно догадаться из вышеизложенного, DDS также отличается высокими требованиями к вычислительной платформе, что помимо прочего ограничивает использование во встраиваемых системах. Конкретно эта проблема отчасти решается специализированным подмножеством DDS For Extremely Resource Constrained Environments (DDS-XRCE). Но, согласно нашей модели, это решение уже выходит далеко за пределы концепции распределённых вычислений в силу своей глубокой зависимости от центрального координирующего агента и ограниченной функциональности. Для рассматриваемого здесь вопроса эта технология большой ценности не представляет и рассматривать мы её не будем, равно как мы обойдём стороной и связанный проект micro-ROS.

Из других решений есть смысл поверхностно упомянуть SOME/IP часть автомобильного стандарта AUTOSAR v4+, предлагающую сервисы построения распределённых систем поверх стека IP. В отличие от DDS, SOME/IP сфокусирован исключительно на автомобильных применениях и оперирует существенно более низкоуровневыми концепциями со слабой сегрегацией по уровням абстракции. В совокупности с довольно вольготным обращением с распределёнными состояниями (об этом поговорим далее) и значительным логическим зацеплением между коллабораторами это вызывает вопросы о будущем SOME/IP при наличии сильного конкурента в лице DDS.

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

Высокая внутренняя сложность существующих технологий распределённых вычислений обусловлена широким спектром поддерживаемых сценариев и типов взаимодействия, лишь малая часть которых актуальна для интересующей нас области применений. Мы полагаем, что это утверждение верно даже для специализированных решений (как SOME/IP), чья архитектура может подлежать улучшениям путём целостного пересмотра подходов к проектированию бортовых распределённых систем. Аккуратное переосмысление основных требований к коммуникационной подсистеме позволило нам достичь более взвешенного баланса между внутренней сложностью (и, как следствие, стоимостью валидации и верификации и обеспечения гарантированных характеристик) и доступными инструментами построения мощных абстракций.

Наш подход

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

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

   
   

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

   
   

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

   
   

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

   
   

5. Открытость. Это не техническое требование, а юридическое, но это не делает его менее значимым. Невозможно обеспечить серьёзные внедрения закрытой технологии, если существенная часть отрасли живёт открытыми стандартами и открытым ПО. Этот пункт подразумевает свободное распространение всей документации и кода под разрешительными лиценизиями (CC BY, MIT) без обязательных членских взносов.

   
   

В части погони за простотой как одной из ключевых характеристик можно усмотреть реминисценции известного в определённых кругах алгоритма распределённого консенсуса Raft, чьи создатели точно так же, как и мы, начали с вопроса о том, как сделать сложные вещи простыми. Хотя область их деятельности не имеет ничего общего с нашей, они, как и мы, в конечном итоге решали проблему восприятия, где единственной гарантированно достоверной метрикой является человеческий опыт. В отличие от авторов Raft, мы не проверяли трудность понимания наших спецификаций на больших массах людей (N.B.: они показали видео-лекцию 43-м студентам и потом оценили понимание при помощи теста, сравнив результаты с конкурирующей технологией). Однако, у нас есть вот такое практическое свидетельство, где господин зашёл с улицы и сделал минимальную реализацию UAVCAN с нуля за "пару недель" (с его слов):

Желающие увидеть код найдут его на гитхабе как libuavesp. Я, обратите внимание, умываю руки мы к этой реализации отношения не имеем. Заявление автора о том, что "UAV" в названии "UAVCAN" имеет отношение к БПЛА, не соответствует действительности и вызвано банальным недоразумением.

Как нетрудно догадаться из предваряющей этот раздел вводной, UAVCAN широко заимствует ценные принципы из флагманов современной индустрии, в первую очередь опираясь на ROS, DDS, AFDX, WAIC и множество высокоуровневых CAN протоколов, которые даже нет смысла здесь перечислять. Однако, вопросы организации распределённых вычислений одними транспортными протоколами, очевидно, не ограничиваются, особенно если учесть заявленную в ключевых целях потребность в "высокоуровневых абстракциях". UAVCAN удобно рассматривать в виде трёхуровневой модели (мы намеренно игнорируем семиуровневую модель OSI ввиду её чрезмерной детализации):

• Уровень приложения. На этом уровне представлены общие для всех бортовых систем функции: мониторинг состояния, логирование, передача файлов, управление конфигурацией, телеметрия, и т.п. На этом же уровне создаются специализированные сервисы согласно потребностям конкретного приложения. В распоряжении пользователя два вида взаимодействий: анонимный статически типизированный издатель-подписчик и статически же типизированный удалённый вызов процедур с явной адресацией (т.е. не анонимный).

  
  

• Уровень представления отвечает за маршалинг доменных объектов в связях издатель-подписчик и при удалённом вызове процедур. Этот уровень реализован средствами специального предметно-ориентированного языка, на котором даётся строгое определение типов данных для сетевого обмена: Data Structure Description Language (DSDL). На основе DSDL-дефиниций можно автоматически генерировать код (можно и не автоматически).

  
  

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

  
  
  • UAVCAN/CAN работает поверх классического CAN и CAN FD. Вероятно, в будущем также появится поддержка CAN XL, но это не точно.
  • UAVCAN/UDP работает поверх UDP/IP. По состоянию на 2020-й год, спецификация этого транспорта ещё находится в стадии ранней альфы и может быть изменена до стабилизации (хотя предпосылок к этому нет).
  • UAVCAN/serial работает поверх любого байт-ориентированного протокола (UART, RS-232/422/485, USB CDC ACM) и ещё подходит для хранения дампов в неструктурированных бинарных файлах. Этот транспорт тоже ожидает стабилизации.
  • Поскольку интерфейс между транспортом и верхними уровнями хорошо определён, в будущем возможно добавление новых транспортных протоколов. В числе таковых рассматривается, например, беспроводной IEEE 802.15.4.
  
  

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

Первое из исходных предположений таково: нижележащая транспортная сеть (например, CAN или Ethernet, в зависимости от выбранного транспорта) предлагает хорошо охарактеризованную минимальную кривую обслуживания и нулевую вероятность потерь пакетов при отсутствии неблагоприятных воздействий внешней среды. Последнее означает, что потери не могут возникнуть в результате процессов, протекающих внутри сети, как, например, переполнение буфера на сетевом узле; однако, допускаются кратковременные нарушения, вызванные внешними факторами, как, например, электромагнитная интерференция. Это предположение полностью совместимо с реалиями настоящих бортовых систем, и оно позволяет нам существенно упростить логику протокола. Компенсация потерь ввиду внешних воздействий выполняется путём превентивной отправки дубликатов (только в тех случаях, где требуется). Рассмотрение этого метода даётся в статье Idempotent interfaces and deterministic data loss mitigation. Хотя описанные особенности выглядят чуждыми для традиционных систем, они вполне оправданы для нашей области.

Крайне аккуратное обращение с разделяемым состоянием позволяет нам сильно сократить пространство состояний сетевых узлов в сравнении со схожими решениями. В результате сокращается техническая сложность реализации, упрощается её анализ и тестирование, о чём подробно сказано в официальном руководстве. Сетевой узел UAVCAN делает минимум предположений о состоянии своих коллабораторов; например, если в случае традиционного фреймворка издатель-подписчик обычно выделяется явная процедура установления подписки, где подписчик сообщает издателю о своей заинтересованности в конкретных данных (см. SOME/IP, DDS, ROS, практически все MQ*, etc.), в UAVCAN издатель слепо отправляет данные в сеть, позволяя заинтересованным агентам их принять или проигнорировать.

Последнее обстоятельство создало бы существенные преграды для масштабирования, если бы не широкое использование аппаратной фильтрации пакетов в обязательном порядке. Известные нам другие протоколы (кроме AFDX) необоснованно игнорируют тот факт, что всё современное аппаратное обеспечение для высокоскоростной коммуникации, за исключением лишь некоторых маргинальных представителей, предоставляет мощные аппаратные инструменты автоматической фильтрации. Разумная эксплуатация этого факта позволила нам ввести радикальные упрощения без ущерба функциональности, о чём говорится в статье Alternative transport protocols in UAVCAN.

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

Например, динамическое выделение адреса в сети поддерживается опциональным механизмом plug-and-play (впрочем, конкретно для UAVCAN/UDP он не определён ввиду наличия стандартного DHCP). Механизм этот также поддерживает избыточные аллокаторы для отказоустойчивых систем, где консенсус реплик обеспечивается при помощи упомянутого ранее алгоритма Raft.

Второй аспект статичности заключается в предоставлении ресурсного потолка для любой части системы на этапе проектирования. Так, определяемые при помощи упомянутого ранее DSDL типы всегда имеют верхний предел размера любого поля переменной длины, из чего следует, что максимальное время передачи, максимальное время сериализации/десериализации, и, в общем случае, максимальное время обработки всегда можно определить статически. Ниже показано DSDL-определение стандартного типа журнальной записи под именем uavcan.diagnostic.Record, где можно видеть, что максимальная длина сообщения задана явно и ограничена 112-ю байтами (кодировка всегда UTF-8):

# Generic human-readable text message for logging and displaying purposes.# Generally, it should be published at the lowest priority level.uavcan.time.SynchronizedTimestamp.1.0 timestamp# Optional timestamp in the network-synchronized time system; zero if undefined.# The timestamp value conveys the exact moment when the reported event took place.Severity.1.0 severityuint8[<=112] text# Message text.# Normally, messages should be kept as short as possible, especially those of high severity.@assert _offset_ % 8 == {0}@assert _offset_.max <= (124 * 8)     # Two CAN FD frames max

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

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

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

Для примера я продемонстрирую сериализацию и публикацию сообщения, определённого ниже, содержащего три константы и два поля. Константы не участвуют в обмене, поскольку они и так известны всем узлам, имеющим доступ к соответствующему определению типа. Поля сериализуются в плоский остроконечный бинарный формат (младший байт идёт первым) примерно как в ASN.1 UPER (другой порядок байт), но с местной спецификой (ценители сериализации данных должны посмотреть мою заметку, где я рассматриваю популярные форматы и сравниваю их с DSDL).

uint16 VALUE_LOW  = 1000uint16 VALUE_HIGH = 2000uint16 VALUE_MID = (VALUE_HIGH + VALUE_LOW) / 2# Рациональная арифметика произвольной точности!uint16 valueuint8[<=100] key  # Динамический массив от 0 до 100 элементов.

Если мы, скажем, присвоим полям значения value=1234 и key=Hello world!, результат в шестнадцатиричной нотации будет следующим:

D2 04 0C 48 65 6C 6C 6F 20 77 6F 72 6C 64 21

Где D2 04 соответствует 1234, 0C длина массива (если бы максимальная длина была более 255 элементов, тут было бы два или четыре байта), и остаток приходится на приветствие.

Публикация сообщения через классический CAN будет выглядеть предельно незамысловато все счастливые CAN протоколы похожи друг на друга (надо ли говорить, что в случае CAN FD всё вошло бы в один кадр):

$ candump -decaxta any(7.925)  vcan2  TX - -  1013373B   [8]  D2 04 0C 48 65 6C 6C A0   '...Hell.'(7.925)  vcan2  TX - -  1013373B   [8]  6F 20 77 6F 72 6C 64 00   'o world.'(7.925)  vcan2  TX - -  1013373B   [4]  21 F9 02 60               '!..`'

Лишний подозрительный байт в конце каждого кадра содержит метаданные транспорта. В конце последнего кадра есть два байта циклического избыточного кода для проверки корректности декадрирования.

Колонка со значением 0x1013373B здесь представляет CAN ID, что является битовой маской из нескольких полей с метаданными. Наиболее интересным здесь является значение 0x1337 (4919 в десятичной системе), которое называется идентификатором темы (subject-identifier) в отличие от некоторых более сложных протоколов (как DDS), UAVCAN не поддерживает именованные топики, предлагая вместо них нумерованные темы (похоже на SOME/IP и практически любой протокол поверх CAN). Это значение проектировщик выбирает произвольно, сообразно своим представлениям о системе.

Теперь мы можем повторить упражнение для UAVCAN/UDP на localhost. Wireshark, к сожалению, пока не имеет диссектора для UAVCAN, да и пёс с ним, ведь и так всё ясно:

Дотошный читатель спросит, откуда взялся порт назначения 21303, на что я отвечу, что он вычисляется как сумма идентификатора темы (4919 у нас) и фиксированного смещения 16384. Смещение выбрано таким образом, чтобы сдвинуть порты UAVCAN в эфемерный диапазон с целью минимизации конфликтов. Исходный порт полезной информации не несёт и выбирается произвольно. Нашу полезную нагрузку (D2 04 0C ...) предваряют 24 байта метаданных, добавленных стеком UAVCAN; там содержится информация о приоритете, фрагментах (тут их нет) и последовательном номере сообщения.

Будет ошибкой думать, что внедрение UAVCAN/UDP в обязательном порядке требует полного IP стека. Когда на практике поднимается вопрос об IP стеке, обычно подразумевается TCP/IP, сложность которого несопоставима с UDP/IP. Последний можно собрать с нуля на C в несколько сотен строк, как наглядно продемонстрировал Lifelover в 2011-м году в серии публикаций "Подключение микроконтроллера к локальной сети".

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

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

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

Поверх UAVCAN предполагается создание специализированных отраслевых стандартов уровня приложения, примерно как стандартные классы USB существуют поверх ядра USB, как профили CANopen или Bluetooth, или как DDS FACE поверх DDS. Схематически мы это изображаем следующим образом:

Из отраслевых стандартов сейчас в работе один так называемый Drone Standard 15, или DS-015, к которому активно прикладывают руки, среди прочих, компании из Dronecode Foundation. Мы предвидим появление других отраслевых спецификаций в будущем, поскольку UAVCAN сегодня можно встретить далеко за пределами одних только дронов но об этом позже.

Техническая сторона здесь прозрачна, но есть и другая. Сложные распределённые системы требуют дисциплинированного подхода к проектированию сетевых сервисов и их интерфейсов. Контакты с сообществом разработчиков встраиваемых систем показали, что эта аудитория может глубоко разбираться в вопросах, традиционно характерных для их области деятельности (реальное время, операционные системы, связующее ПО, и т.п.), но при этом иметь очень ограниченное представление о проектировании адекватных сетевых сервисов. Накопленный опыт работы с несколько более низкоуровневыми технологиями, по-видимому, подталкивает людей к неуместному заимствованию практик, что неоднократно на нашем опыте приводило к появлению дефектных интерфейсов, работа с которыми наполовину состоит из страдания. Решение этой нетехнической проблемы является столь же нетехническим мы опубликовали учебный материал, где подробно объясняется, как выглядит сетевой сервис здорового человека. Материал этот опубликован в официальном руководстве UAVCAN в главе Interface Design Guidelines.

Внедрение

Прогресс в области вычислительной техники, элементов питания, машинного обучения, генеративного проектирования и других передовых областей порождает новые проекты транспортных систем, которые зачастую реализуются малыми предприятиями при минимальном финансировании и низкой стартовой вовлечённостью в релевантные отрасли. Практические примеры автономных дронов и роботов, электрических конвертопланов, кубсатов, робоавтомобилей, и т.п. в изобилии присутствуют в новостных лентах, так что приводить их здесь нет смысла. Каждое такое средство, будучи передовым продуктом 21-го века, критически зависимо от грамотной огранизации бортовых вычислительных систем, и часто также несёт груз правового регулирования и доказательства функциональной безопасности. Такие проекты неспособны подняться без широкого применения именно открытых стандартов и свободных решений, потому что как коммерческие альтернативы, так и доморощенные велосипеды рискуют не вписаться в бюджет. Стартап, скажем, с летательным аппаратом, намеревающийся следовать стандартам консервативной аэрокосмической отрасли на первом же шаге выложит десятки тысяч евро за PDF документы; в то же время будет ошибкой думать, что внедрение этих стандартов является необходимым или даже желательным условием для успеха.

UAVCAN полностью открыт для распространения и внедрения, не предписывает никаких лицензионных ограничений: вся документация распространяется под CC BY 4.0, а исходный код референсных реализаций под MIT. Вероятно, любой другой подход к лицензированию сегодня обрёк бы проект на забвение.

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

Согласно принципам открытости, вся разработка ведётся в полностью публичной манере на форуме и на GitHub оба этих ресурса вместе содержат не меньше 90% дискуссий разработчиков по существу, так что любое просочившееся в спецификацию решение оставляет перманентный бумажный след. Этот подход радикально отличается от традиционных практик, где обычно предполагается платное членство и участие в закрытых сессиях, закрытых ревью стандартов и закрытых же списках рассылок.

На гитхабе поддерживаются референсные библиотеки, среди которых Libcanard минимальная реализация UAVCAN/CAN для однокристалок на C11, объём кода которой фигурирует в названии этой статьи. Также там базируется uavcan.rs мультитранспортная реализация на Rust, которая по состоянию на июль 2020 ищет нового мейнтейнера.

Там же поддерживается Yukon десктопная программа на питоне-электроне для разработки, отладки и диагностики UAVCAN сетей, представляющая собой смесь RViz, Wireshark и LabView. Раньше у нас была ещё утилита на PyQt для предыдущей экспериментальной версии протокола, но теперь она устарела безнадёжно, и усилия сосредоточены на Yukon. На форуме есть бесконечно длинные треды с обсуждениями, но дальше обсуждений мы практически не продвинулись из-за острой недостачи фронтендеров. На сегодня последнее демо выглядит так:

Некоторый интерес представляет использование API ROS поверх UAVCAN вместо DDS. Смысл здесь в том, чтобы сделать развитую экосистему пакетов ROS доступной в системах реального времени и младших микроконтроллерах с использованием UAVCAN, обеспечив при этом также нативную совместимость с обычными UAVCAN устройствами, ничего не знающими о ROS. Краткая вводная дана в заметке на форуме "An exploratory study: UAVCAN as a middleware for ROS"; разыскиваются коллабораторы.

Среди множества компаний и учреждений, принимающих участие развитии стандарта, следует особо выделить NXP Semiconductors. На недавней конференции они представили неплохой доклад "Getting started using UAVCAN v1 with PX4 on the NXP UAVCAN Board", демонстрирующей, в том числе, кое-какие их новые референсы для UAVCAN приложений.

Не менее ценным партнёром является Amazon Prime Air со своим крутейшим автономным доставочным дроном. Эти господа производят не железо, а код копирайты Амазона щедро разбросаны по нашим исходникам.

Законченное UAVCAN-совместимое железо вроде сервоприводов, приводов электромоторов, системы воздушных сигналов, автопилотов, систем впрыска топлива, всевозможных датчиков и отладочных плат сегодня предлагают многие вендоры, чьё перечисление тут вряд ли оправданно.

Согласно опросу, проведённому в конце 2019 года, а также основываясь на наших личных контактах с интеграторами, UAVCAN сегодня применяется в пилотируемых (~10% компаний) и беспилотных (~80% компаний) летательных аппаратах, в малых космических аппаратах (~5% компаний, на 2020 год на орбите есть около 20 кубсатов, согласно доступным нам данным), в микро транспорте (вроде электросамокатов) и разнообразных робототехнических системах. Наша выборка, впрочем, подвержена систематической ошибке и приводится только в общеинформативных целях; распределение может не соответствовать действительности. Краткая сводка по опросу доступна отдельно.

Статус и будущее проекта

Наша глобальная амбициозная цель-максимум: стать полноценной альтернативой технологиям класса DDS для отказоустойчивых высоконадёжных систем реального времени; стать стандартом де-факто для новых видов интеллектуального транспорта.

Согласно опросу, главным препятствием на пути к цели являются проблемы не технические, а социальные: 47% респондентов в последнем опросе указало, что главным препятствием на пути внедрения UAVCAN в новых разработках является низкая представленность технологии в профессиональном дискурсе. Вероятно, просветительские публикации вроде этой проекту помогут.

uavcan.org

Вячеслав Ермолин, 23 июня 2020 г.



Миссия:
Запуск навигационного спутника третьего поколения BeiDou-3 для китайской навигационной системы. Запуск завершает формирование штатной численности навигационной системы BeiDou (BDS). Спутник выведен на геопереходную орбиту ракетой-носителем Chang Zheng-3B/G3 с космодрома Сичан.



Девиз:
Есть полное количество. Глобальные услуги за три шага.

Время и место старта:
23 июня 2020 г. в 01:43:04 UTC. Космодром Сичан (XSLC). Стартовый комплекс-2 (LC-2).

Ракета-носитель:
Chang Zheng-3B/G3. Трехступенчатая ракета-носитель для выведения тяжелых нагрузок на геостационарную орбиту. Грузподъёмность более 5 000 кг на ГПО.

Полезная нагрузка:
Beidou-3 GEO-3. Навигационный спутник третьего поколения для геостационарной орбиты. Третий аппарат в серии. Вес 4 600 кг.

Орбита:
45807/2020-040A. Целевая орбита GEO. Геопереходная орбита 218 x 35 784 км с наклонением 28.411, период обращения 631.38 мин.

Интересное:
15-й запуск Китая в этом году. Два запуска аварийные.
336-й запуск ракета-носителей серии Chang Zheng (Великий поход).
17-й запуск ракеты-носителя Chang Zheng-3B/G3(Y68). Без аварий.
55-й запуск спутника навигационной системы BeiDou (BDS).
Сейчас на орбите 49 спутников BeiDou. 43 используется по целевому назначению. Не используются по целевому назначению 6. Для предоставления услуг используются спутники Beidou-2 и Beidou-3.
Штатный состав BeiDou из 35 аппаратов: 27 спутников на MEO, 5 спутников на GEO и 3 спутника на IGSO.
Есть возможность региональной передачи коротких текстовых сообщений через спутники Beidou.
Стоимость запуска ракеты-носителя около 70 млн $.
Стоимость вывода 1 кг полезной нагрузки на LEO не менее 6 000 $.

Ссылка на изображение в высоком качестве
Статья от Everyday Astrounavt

Логотипы и патчи миссии

Легенда к шапке

Исследователи из Лаборатории реактивного движения NASA (JPL NASA) в Калифорнии разработали алгоритм машинного обучения, который позволяет находить новые кратеры на поверхности Марса. NASA заявило, что это первый случай использования искусственного интеллекта для идентификации ранее неизвестных воронок от метеоритов на Красной планете, сообщает портал Space.com.
В качестве исходных данных для своего алгоритма ученые взяли изображения, полученные с помощью камеры на орбитальном аппарате NASA Mars Reconnaissance Orbiter (MRO).


Аппарат Mars Reconnaissance Orbiter над Южным полюсом Марса. Рисунок художника. Источник: space.com

Контекстная камера (CTX) MRO делает снимки с низким разрешением, которые могут охватить сотни километров за раз. Это позволяет найти следы взрыва вокруг места удара и сузить область поиска на поверхности планеты. Для захвата более мелких деталей и идентификации отдельных кратеров ученые делают ставку на используемую MRO камеру высокого разрешения HiRISE. Она позволяет разглядеть с орбиты на поверхности планеты объекты длиной всего 30 см. Сначала анализируются снимки камеры CTX, затем на интересные области наводится HiRISE. Однако, чтобы идентифицировать небольшие объекты на поверхности Марса и отобрать их для дальнейшего изучения, требуется кропотливый анализ изображений. В NASA рассчитывают, что AI позволит ускорить этот процесс.
Для более точного нахождения воронок исследователи NASA обучили алгоритм на 6830 изображениях, сделанных контекстной камерой. Этот процесс включал снимки областей, где люди ранее идентифицировали столкновения с поверхностью планеты, а также областей без кратеров, чтобы инструмент мог научиться правильно различать особенности поверхности на Марсе.

Кластер небольших марсианских кратеров, идентифицированный искусственным интеллектом. Фото: NASA

После обучения алгоритма ученые загрузили в него еще 112 000 изображений поверхности Красной планеты, снятых контекстной камерой. Благодаря этим снимкам искусственный интеллект смог различить группу кратеров под названием Noctis Fossae, что подтвердили и исследователи с помощью инструмента HiRISE. Таким образом, были обнаружены 20 дополнительных интересных для изучения областей, которые эксперты будут исследовать более подробно.
Искусственный интеллект, конечно, не может анализировать изображения так же квалифицированно, как это делают ученые. Но такие инструменты, как этот новый алгоритм, могут им в этом помочь. Это открывает путь к захватывающему симбиозу людей и искусственного интеллекта, работающих совместно для ускорения научных открытий, считает Кири Вагстафф, специалист из JPL NASA.
Было бы невозможно обработать более 112 000 изображений за разумный промежуток времени без распределения работы среди множества компьютеров, отмечает ее коллега Гэри Доран.
В NASA надеются использовать аналогичную технологию классификации и на будущих орбитальных аппаратах Марса. По мнению сотрудников Национального управления по аэронавтике и исследованию космического пространства, это позволит получить более полную картину того, как часто метеоры падают на Марс.