Передача данных: multicast под запретом
В сетях, используемых для управления, часто применяется групповая рассылка сообщений (multicast и broadcast). Так, например, многие оконечные станции потребляют навигационную информацию, поступающую из одного источника.
Изначальная ориентация на обмены «точка–точка», обусловленная самой идеологией процессов Хоара, предопределила чужеродность понятия multicast (групповой рассылки) для сети SpaceWire, хотя её ограниченная форма и введена в стандарт под названием «packet distribution». Под этим термином имеется в виду только групповая рассылка из узла через ближайший коммутатор в оконечные станции (узлы), подсоединённые непосредственно к этому коммутатору [2, разд. 10.2.7, 10.4]. Позволим себе в этой связи привести длинную цитату из [3, стр. 88]:
«Стандарт SpaceWire определяет средства, которые могут использоваться коммутатором для копирования и раздачи пакетов SpaceWire по нескольким узлам, подсоединённым к различным портам коммутатора. Они были включены со специальной целью распределения одних и тех же данных по нескольким процессорам в параллельно работающей системе. Они могут вызвать значительные проблемы, будучи использованы в сети SpaceWire, и [потому] их использование не рекомендуется. К примеру, если пакет, прибывающий по одному порту коммутатора, должен быть роздан по нескольким другим портам, а узел, подсоединённый к одному из этих портов, по какой-либо причине больше не способен принимать данные, то данные, идущие во все остальные процессоры, будут приостановлены. Любой сбой фактически размножается».
Поясним, почему разрешается только ограниченная форма групповой рассылки. Допустим, мы введём multicast в чистой форме. Тогда возможна следующая ситуация, ведущая к deadlock'у (см. рис. 9).
Рассылка красного сообщения захватывает на коммутаторе K2 оба порта (1 и 2) и пытается захватить порт 1 на коммутаторе K3, уже занятый под рассылку синего сообщения. Но рассылка синего сообщения захватывает оба порта на коммутаторе K3 и пытается захватить порт 1 на коммутаторе K2, уже занятый под рассылку красного сообщения. Возникает классический deadlock.
Ясно, что упомянутые ограничения – это замазывание принципиального недостатка, не позволяющего осуществлять групповые рассылки по содержательному принципу, а не технологические ограничения.
При необходимости групповой или широковещательной рассылки стандарт [2, разд. 10.2.7.1] рекомендует не самый элегантный выход из положения – обычную поочерёдную посылку в каждый узел-приёмник.
Передача данных: неравноправное равноправие
Рассмотрим жизненную ситуацию: осуществляется, во-первых, multicast-рассылка крохотных сообщений объёмом в 1 байт в адрес примерно десятка узлов (поочерёдная, по рекомендации стандарта) – на рисунке 10 они изображены красным цветом – и, во-вторых, пересылка массивного изображения объёмом в 1 МБ, разбитого, опять-таки по рекомендации стандарта, на 10 фрагментов по 100 КБ – на рисунке 10 они изображены синим цветом. При отправке одноприоритетных сообщений из выходного порта коммутатора арбитраж выполняется равноправно – по круговой схеме.
Обе серии сообщений затратят на прохождение через коммутатор одно и то же время – 0,1 с, но для multicast-сообщений, которым следовало бы быть одновременными, эта разбежка по времени (0,1 с) может оказаться неприемлемой. Таково ещё одно неприятное следствие монополизации порта сообщением и неограниченности длины сообщения.
Передача данных: последствия сбоев
Маркеры управления потоком (FCT)
Вполне в духе транспьютерной сети вопрос о потере маркера управления потоком в стандарте [2] на SpaceWire даже не рассматривается. Такая потеря служит ещё одной, не упомянутой выше, причиной блокировки сообщения.
В равной степени не рассматривается вопрос об избыточной посылке FCT – случись такая, в типичном случае будут потеряны следующие 8 байт сообщения, хотя в зависимости от реализации вместо них могут быть потеряны предыдущие 8 байт. Сравните с замечанием к пункту c) в разделе 8.3 стандарта [1]: «В типичном случае приёмный буфер представляет собой FIFO».
Маркеры конца пакета (EOP)
Как и маркеры FCT, маркеры EOP также подвержены потере и появлению избыточных маркеров. В первом случае это может повести к искажению сообщения и переполнению буфера на той оконечной станции, куда адресовано сообщение, замыкавшееся потерянным EOP, а также к потере следующего сообщения, которое не будет доставлено по назначению. Во втором случае может быть усечено сообщение, в тело которого попадёт избыточный маркер EOP, а из остатка усечённого сообщения может появиться фантомное сообщение, адресованное бог весть куда.
Очень длинное сообщение
При случайной программной ошибке, выразившейся в очень большом значении длины сообщения, порты на всём пути будут блокированы на очень долгое время. Таким образом, SpaceWire беззащитен от «дурака».
Искажение NULL на холостом ходу
Когда линк находится на холостом ходу (он активен, но вместо информации по нему непрерывно передаются символы NULL), при искажении как минимум двух битов символа NULL, не нарушающем чётности, искажённый символ станет частью сообщения, которое появится на линке неопределённое время спустя. В самом деле, как утверждает стандарт [2, разд. 8.2.1]:
«Управляющий символ NULL <…> может рассматриваться как L-Char. Такие символы на пакетный уровень не передаются» (в отличие от символов EOP – конца пакета и EEP – конца ошибочного пакета).
Это означает, что последующие символы NULL просто игнорируются, не возбраняя искажённому символу стать частью последующего сообщения.
Искажённый NULL послужит адресным байтом на следующем коммутаторе, и сообщение окажется адресованным не туда со всеми вытекающими последствиями.
В действительности дело обстоит даже хуже: при долго простаивающем линке на следующем коммутаторе произвольный выходной порт окажется захваченным на продолжительное время (тайм-ауты, напомним, в SpaceWire должны быть большими), т.е. ни с того ни с сего трафик по этому порту окажется заблокированным. По истечении же тайм-аута следующее сообщение (которое прибудет неизвестно когда) окажется аннулированным, если коммутатор будет следовать методике, предлагаемой в [4]. А учитывая, что все проложенные провода сети SpaceWire представляют собой набор антенн, непрерывно работающих на приём помех…
Время и факт доставки сообщения
Подводя промежуточный итог, мы можем констатировать, что при благоприятном стечении обстоятельств информация будет доставлена за обозримое (хотя и не поддающееся оценке) время, однако при малейших сбоях поведение сети становится непредсказуемым.
Распространение единого времени
Интерпретация маркеров времени
Стандарт SpaceWire [2] предлагает механизм распространения времени, где цена младшего бита рассылаемого маркера времени составляет величину кванта системного времени на узле. Кроме того, стандарт предлагает осуществлять рассылку маркера времени периодически с периодом величиной в тот же квант системного времени. Таким образом, к величине кванта времени предъявляются противоположные требования:
- уменьшение размера этого кванта для повышения точности;
- увеличение размера кванта для уменьшения нагрузки на сеть.
В качестве примера компромиссного значения величины кванта системного времени стандарт приводит 1 миллисекунду [2, разд. 8.12.2, c), стр. 84]; обеспечиваемая точность при этом составляет порядка 10 мкс.
Существует очевидное решение, позволяющее на порядки повысить точность системного времени с сохранением всех механизмов, но почему-то в стандарте не рассмотренное. Возможно увеличить квант времени до 1 секунды, сохранив точность в 10 мкс, объявив, например, самообновляющийся регистр часов на узле состоящим из трёх составных частей: грубое значение времени (с дискретностью в 64 секунды, т.е. примерно в 1 минуту), корректируемая компонента времени (сопоставляемая с маркером времени и с дискретностью в 1 секунду) и быстрый счётчик (с дискретностью в 1/220 секунды, т. е. примерно микросекунда), как это изображено на рисунке 11.
Кратковременной стабильности локального кварцевого генератора в 10–6 хватит на то, чтобы удержать достаточную точность часов порядка единиц микросекунд при потере нескольких маркеров времени. Возникающие при этом проблемы скачков времени и, в частности, его немонотонности, в принципе решаемы, но здесь их обсуждение выходит за рамки данной статьи.
Задатчик времени (time master)
В сети SpaceWire предусматривается единственный узел-задатчик времени [3, разд. 5.4]. А что будет, если он выйдет из строя? Процесс передачи функций задатчика времени в стандарте не описывается.
Выводы
Протокол SpaceWire ни в коей мере не создавался специально для использования в космической промышленности. Он был получен из системы внутримашинных обменов путём наложения «заплаток» на самые заметные «дыры». Эти «заплатки» так и не превратили протокол SpaceWire в полноценную сеть реального времени, а все предложения по его дальнейшему развитию напоминают строительство замка на песке.
Несмотря на это, получившийся продукт обладает рядом достоинств: относительная простота и дешевизна реализации, возможность использования среднескоростных интерфейсов – до 100 Мбит/c (400 Мбит/с оставим на совести авторов). Он вполне может использоваться на борту космических аппаратов либо как внутримашинный интерфейс, либо там, где процессы протекают небыстро, оконечные станции немногочисленны и слабо вычислительно связаны. А ещё лучше – как соединение «точка–точка» без всякой сети.
Что касается использования SpaceWire для построения критичных сетей в космической отрасли, то единственное, чем это может быть обосновано, – наличием слова Space в названии. Для применения в авиации и других областях даже это основание отсутствует. Увы.
Литература
- Журавлёв В., Немытов А., Осипов Ю., Першин А. SpaceWire: взгляд со стороны. Часть 1 // Современная электроника. 2017. №8.
- ECSS-E-ST-50-12C «SpaceWire – Links, nodes, routers and networks», ECSS Secretariat ESA-ESTEC, Requirements & Standards Division, Noordwijk, The Netherlands, 31 July 2008.
- Steve Parkes. «SpaceWire User’s Guide». STAR-Dundee Limited, 2012.
- SpW-10X SpaceWire Router. User Manual», University of Dundee/Austrian Aerospace/ESTEC, January 7, 2015.
Если вам понравился материал, кликните значок - вы поможете нам узнать, каким статьям и новостям следует отдавать предпочтение. Если вы хотите обсудить материал - не стесняйтесь оставлять свои комментарии : возможно, они будут полезны другим нашим читателям!
