Групповая адаптивная маршрутизация

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

- Транспортный и прикладной уровень

Стандарт SW не определяет данный уровень, но описывается общие рекомендации. Транспортный уровень может вообще отсутствовать и тогда за сетевым сразу должен быть прикладной протокол, если же необходимо повысить надежность доставки пакета в сети, транспортный протокол может быть. При этом пакет SpW инкапсулирует пакеты протоколов, передающихся через сеть SpW. Структура инкапсуляции на слайде. Поле PID это идентификатор протокола транспортного уровня, на уровне стандарта пока определено несколько идентификаторов при возможных 256-ти. В диапазоне от 240-254 разработчики вправе использовать номера для собственных протоколов. Одновременно в сети могут присутствовать сразу несколько протоколов, разные идентификаторы предотвращают их столкновение.

- Прикладной уровень

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

Протокол RMAP

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

- может быть установлена проверка данных перед исполнением команды или нет (проверка контрольной суммы);

- есть ли необходимость в отправке ответного пакета или нет.

В качестве буфера узла назначения может использоваться или буфер типа FIFO (как правило) или же буфер в виде последовательных ячеек памяти. Данный выбор также указывается в поле инструкций. Контроль правильности доставки применяется отдельно для заголовка RMAP пакета и для поля данных (две контрольные суммы), при этом применяется один и тот же 8-ми битный циклических избыточный код. Код вида (n+8,n) n-количество бит охвата расчета CRC, n должно быть выровнено по байтам (кратно 8), 8 - количество рассчитанных избыточных бит. Рассчитывается по формуле . Структура ответных пакетов однотипна для всех типов команд, включает 2 основных информативных поля: поле состояния и поле данных. Если пакет принят без ошибки, то в поле состояния будет - 0Х00.

Формат команды «запись ».

Рассмотрим поля:

1. Target SpW address содержит адрес узла назначения при путевой (физической, аппаратной) адресации, количество байт может быть несколько или вообще отсутствовать, если путевая адресация не используется

2. Target Logical Address – логический адрес узла назначения. 8 бит. Если логическая адресация не используется, то записан символ 0xFE.

3. Protocol Identifier – поле идентификации протокола. У RMAP всегда 0x01.

4. Instruction – поле инструкций. Определяет тип пакета (команда или ответ на команду) и поле длины адреса ответа. И определяет необходимость проверки данных, отправки ответного пакета и определяет тип буфера FIFO или последовательная нумерация ячеек.

5. Key – поле ключа. Содержит ключ, который приложение пользователя на стороне принимающей должно использовать для авторизации команд.

6. Reply address – поле адреса ответа. Содержит адрес узла, на который отправляется ответ на принятую команду. Используется при путевой адресации, при логической – не используется.

7. Initiator Logical Address содержит логический адрес инициатора. Если логического адреса нет, то там записано 0xFE.

8. Transaction Identifier 2 байта, используется на прикладном уровне для идентификации процесса передачи.

9. Extended address field и address определяют начальный адрес в памяти приемника, начиная с которого мы пересылаем данные. Размер 40 бит.

10. Data – данные. 24 бита. Определяет размер поля данных.

11. Header CRC

12. Data – не более 2 в 24 степени.

13. Data CRC

14. EOP – символ конца пакета.

Формат ответного пакета .

Основные поля рассмотрены ранее.

Status – это поле сообщает об успехе выполнения команды, если оно содержит 0х00, то команда выполнена успешно, если ошибка в этом поле указывается ее код. Стандарт не определяет конкретные кода ошибок, разработчик вправе сам назначить коды ошибок.

Процедура записи

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

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

Аналогичным образом устроены форматы команд чтения, чтение/модификация/записи, ответные пакеты и процедуры их выполнения.

Сетевая архитектура

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

Рассмотрим сетевую архитектуру бортовых систем управления для малых космических аппаратов.

Для бортовых систем управления предложено несколько вариантов построения бортовых комплексов управления с сетевой архитектурой. Для малых КА типа «двойная звезда», для сверхмалых КА «одинарная звезда + кольцо». На рисунке БК – это бортовой компьютер, НЧ КИС – цифровая часть командно-измерительной системы, МП - модуль питания, МИ – модуль интерфейса (система сбора данных), МК – маршрутизирующие коммутаторы.

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

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

Сетевая архитектура для БКУ сверхмалого КА не предусматривает резервирования узлов. Но имеется возможность резервирования линий передачи данных как при отказе центрального маршрутизатора, так и при отказе отдельных каналов передачи данных.

Таким образом, SpaceWire позволяет строить отказоустойчивые сети.