CC BY
140
УДК 004.728.5
РАЗРАБОТКА ТРАНСПОРТНОГО ПРОТОКОЛА СТП-ИСС ДЛЯ БОРТОВЫХ СЕТЕЙ SPACEWIRE
© 2014 Ю.Е. Шейнин1, В.Л. Оленев1, И.Я. Лавровская1, И.Л. Коробков1, С.Г. Кочура2, С И. Опенько2, Д.В. Дымов2
1 Санкт-Петербургский государственный университет аэрокосмического
приборостроения
2 ОАО «Информационные спутниковые системы» им. академика М.Ф. Решетнёва
Поступила в редакцию 02.10.2014
В статье описан новый транспортный протокол СТП-ИСС для бортовых сетей SpaceWiгe, разработанный совместно с ОАО «Информационные спутниковые системы» им. академика М.Ф. Решетнева» для применения в российской космической промышленности. Приводится обзор и анализ существующих транспортных протоколов, функционирующих поверх SpaceWiгe, а также формулируются необходимые требования к транспортному протоколу, который будет работать поверх сети SpaceWiгe. Представлено описание основных механизмов разрабатываемого протокола СТП-ИСС первой редакции. Для проведения верификации, тестирования и исследования механизмов нового протокола были разработаны различные имитационные модели, которые также описываются. На основе результатов, полученных в ходе моделирования, была выпущена первая редакция спецификации СТП-ИСС.
Ключевые слова: транспортный протокол, СТП-ИСС, бортовые сети, SpaceWire, моделирование
Длительное время основной технологией, применяемой в космическом и авиационном электронном оборудовании, была коммуникационная шина MIL-STD 1553. В условиях растущих требований MIL-STD 1553 уже не справляется с поставленными задачами, поскольку её средняя скорость передачи данных в 1 Мбит/с и шинная топология накладывают серьезные ограничения на оборудование. В связи с этим в космических аппаратах начинают внедрять новые технологии, к которым относится и протокол SpaceWire [1]. SpaceWire на данный момент используется более чем в 30 важных космических миссиях. Протокол SpaceWire охватывает три нижних уровня модели OSI и не специфицирует
Шейнин Юрий Евгеньевич, доктор технических наук, профессор, заведующий кафедрой аэрокосмических компьютерных и программных систем. E-mail: sheynin@aanet.ru
Оленев Валентин Леонидович, кандидат технических наук, заведующий лабораторией EmCoMobile. E-mail: valentin. olenev@guap. ru Лавровская Ирина Яковлевна, магистр Коробков Илья Леонидович, магистр Кочура Сергей Григорьевич, кандидат технических наук, доцент, заместитель генерального конструктора по электрическому проектированию и системам управления космических аппаратов. E-mail: kochura@iss-reshetnev.ru
Опенько Сергей Иванович, главный конструктор электрического проектирования и испытаний космических аппаратов. E-mail: openkosi@iss-reshetnev.ru Дымов Дмитрий Валерьевич, начальник сектора 2202. E-mail: dymov@iss-reshetnev.ru
транспортный уровень. Поэтому на данный момент существует ряд протоколов транспортного уровня, разработанных специально для работы поверх SpaceWire. Аналитический обзор данных протоколов кратко представлен далее по тексту.
1. Remote Memory Access Protocol (RMAP) -протокол удаленного доступа к памяти [2]. RMAP может быть использован для системного администрирования, сбора информации, установки/проверки параметров устройства. Протокол RMAP обладает следующими особенностями:
• протокол без установки соединения;
• может работать с путевой, региональной и логической адресацией;
• запись данных возможна с/без подтверждений и с/без верификации;
• осуществляет чтение и запись данных в память устройства отправкой одной команды (команда чтение-модификация-запись);
• отсутствует механизм таймаутов;
• не поддерживается управление потоком;
• определяет 3 вида команд: команды записи, команды чтения, команды чтения-модификации-записи [2, 3];
• предоставляет качество сервиса «Негарантированная доставка» в режиме без подтверждений и «Гарантированную доставку» в режиме передачи данных с подтверждениями.
2. CCSDS Packet Transfer Protocol (PTP) -протокол передачи пакетов, который служит для инкапсуляции данных в SpaceWire пакеты для их дальнейшей передачи устройству назначения через сеть SpaceWire [4]. Протокол PTP обладает
следующими особенностями:
• протокол без установки соединения;
• переменная или фиксированная длина пакетов (минимальный размер пакета 7 байт, максимальный - 65542 байт);
• односторонняя передача данных от пользовательского приложения к приложению назначения без подтверждений;
• отсутствует повторная пересылка в случае потери данных;
• не поддерживает периодичность отправки данных;
• не отвечает за сборку пакета и его проверку на корректность (за это отвечает пользовательское приложение);
• не поддерживает гарантированную доставку данных [4].
3. Serial Transfer Universal Protocol (STUP) - универсальный протокол последовательной передачи данных. Служит для организации передачи данных в сети SpaceWire [5]. Протокол STUP обладает следующими особенностями:
• протокол без установки соединения;
• простота реализации (минимальная сложность протокола);
• определяет всего 2 вида команд: запись и чтение;
• не обеспечивает гарантированную доставку данных;
• корректность пакетов может быть определена по контрольной суммой [5].
4. Joint Reliable Data Delivery Protocol (JRDDP) - протокол надежной доставки данных. Служит для обеспечения сервиса надежной доставки данных к множеству приложений, используя для этого канальный уровень SpaceWire [6]. Протокол JRDDP обладает следующими особенностями:
• протокол с установлением соединения;
• поддерживает множественные логические соединения;
• обнаруживает потерянные, повторяющиеся пакеты (механизм таймаутов);
• упорядочивает пакеты, пришедшие не по порядку;
• выполняет фрагментацию и повторную сборку пакетов;
• поддерживает следующие типы качества сервиса: с приоритетами, гарантированную и негарантированную доставку данных.
• обнаружение ошибок и обеспечение отказоустойчивости (механизм таймаутов, поле с порядковым номером пакета и CRC поле).
5. Streaming Transport Protocol (STP) -транспортный протокол, разработанный для одновременной передачи множества когерентных информационных потоков в сетях SpaceWire [7]. Протокол STP обладает следующими особенностями:
• протокол с установлением соединения;
• безопасное соединение (трехэтапное квитирование);
• ассиметричность (передача данных от ведомого устройства к ведущему);
• поддержка многопоточности (до 64К отдельных соединений);
• порции данных фиксированной длины;
• периодическая через заданный интервал передача данных (по установленным параметрам на протяжении всего соединения);
• доставка данных без подтверждений, без повторной посылки;
• управление потоком данных (механизм остановки/разрешения передачи данных по конкретному соединению и возможность настройки частоты отправки пакетов данных);
• обнаружение ошибок и обеспечение отказоустойчивости (проверка полей команды, CRC поля; механизм таймаутов; процедура опроса статуса терминального узла).
Основные характеристики представленных протоколов приведены в таблице 1 [8].
Таблица 1. Сравнение транспортных протоколов
———^_^_Протоколы Свойства ———^^^^ RMAP PTP STUP JRDDP STP
одновременная работа с несколькими приложениями - - - V V
поддержка приоритетности данных - - - V -
планирование отправки данных - - - - -
управление потоком данных - - - V V
гибкость в настройке работы V - - - -
установление транспортного соединения - - - V V
сегментация - - - V -
проверка корректности данных V - V V V
проверка последовательности данных - - - V -
повторная передача данных - - - V -
наличие подтверждений V - - V -
Из таблицы 1 видно, что в семействе транспортных протоколов SpaceWire на данный момент нет такого протокола, который бы предоставлял надежность, сервисы гарантированной доставки данных и планирования, а также гибкую настройку при передаче данных. Отсюда можно сделать вывод о необходимости разработки нового транспортного протокола, работающего поверх SpaceWire. Совместно со специалистами ОАО «Информационные спутниковые системы» им. академика М.Ф. Решетнева» были выработаны требования к новому транспортному протоколу таким образом, чтобы новый протокол покрывал все нерешенные проблемы в уже существующих протоколах.
A. Интерфейсы транспортного уровня должны обеспечивать передачу: команд управления, сообщений прикладного процесса, маркеров времени, кодов прерываний и их подтверждений.
B. Сегментация. Сообщения прикладного процесса большого размера должны разбиваться на меньшие по размеру сегменты на прикладном уровне. Транспортный протокол должен обеспечивать возможность собирать передаваемые сегменты на прикладном уровне, отправляя необходимую информацию для сбора в заголовке пакета.
C. Потоки данных и их приоритеты Каждый информационный поток должен
передаваться с определенным приоритетом. Приоритеты информационных потоков относительно друг друга приведены ниже (элементы в начале списка имеют более высокий приоритет):
1. Команды управления.
2. Срочные сообщения (если несколько, то в порядке вхождения в очередь).
3. Обычные сообщения (если несколько, то в порядке вхождения в очередь).
D. Буферизация на передатчике. Для данных каждого приоритета должен быть предусмотрен отдельный логический буфер на передающей стороне.
E. Качество сервиса. Должны обеспечиваться дополнительные механизмы обнаружения ошибок поверх физического соединения SpaceWire: контрольная сумма CRC; подтверждения корректного приема данных; таймауты для обнаружения потерянных пакетов. Каждый транспортный поток данных характеризуется своими особенностями и требует определенного качества сервиса. Приоритетный тип качества сервиса требуется для всех потоков данных. Для команд управления и срочных сообщений должна обеспечиваться гарантированная доставка данных. Обычные сообщения могут доставляться как гарантированно, так и негарантированно.
Принимая во внимание проведенный обзор транспортных протоколов и основные технические требования к транспортному протоколу, были предложены решения, вошедшие в основу нового протокола СТП-ИСС, описание которого приведено ниже.
Транспортный протокол СТП-ИСС. На рРис. 1 показан пример бортовой сети SpaceWire, разбитой на регионы, для малого космического аппарата.
Регион сети #2
Рис. 1. Пример бортовой сети SpaceWire для малого космического аппарата
Протокол СТП-ИСС выполняет функции транспортного уровня и определяет информационно-логическое взаимодействие, регламентирует правила передачи сообщений и форматы передаваемых данных между абонентами бортовой сети SpaceWire. Место СТП-ИСС в семействе стандартов SpaceWire и соответствие эталонной модели OSI [9] показано на рРис. 2. Протокол
СТП-ИСС обеспечивает транспортировку данных между удаленными узлами сети с предоставлением требуемого качества сервиса в соответствии с приоритетами потоков данных. Данный протокол предоставляет возможность повторной передачи данных и обнаружения ошибок в принимаемых данных, таким образом, обеспечивая надежность доставки данных.
Бортовое программное обеспечение КА (приложения 5расе\ЛЛге) 1 Прикладной уровень
Представительский уровень
Сеансовый уровень
. . ' 1 V.' . . ' \ 0
РМАР РТР БТиР ЛТООР ЭТР СТП-ИСС Транспортный уровень
1
Стандарт ЭрасеУМге ЕС88-Е-8Т-50-12С 1 1 1 Сетевой уровень
Канальный уровень
Физический уровень
I
Рис. 2. СТП-ИСС и модель OSI
А Интерфейсы транспортного уровня. Для взаимодействия с прикладными процессами предусмотрены три интерфейса: интерфейс данных, конфигурационный интерфейс и интерфейс системных кодов. Для взаимодействия со SpaceWire - два интерфейса: интерфейс пакетов SpaceWire и интерфейс системных кодов (см. рРис. 3). Через интерфейс данных передаются команды управления, а также сообщения с двумя уровнями приоритетов: срочные (высокоприоритетные) и обычные (низкоприоритетные) сообщения. Сообщения прикладных процессов и команды управления на удаленные узлы передаются в пакетах SpaceWire. Конфигурационный интерфейс служит для смены значений конфигурационных параметров СТП-ИСС, передачи статусной информации и команд сброса. Интерфейс системных кодов отвечает за распространение маркеров системного времени и системных прерываний во все узлы сети посредством технологии SpaceWire.
Рис. 3. Интерфейсы транспортного протокола СТП-ИСС
B. Сегментация. Сообщения прикладных процессов на транспортном уровне должны быть помещены в пакеты SpaceWire и переданы на удаленный узел (см.р _
Сообщение / сегмент
транспортный интерфейс
----^---------
Заголовок
Адрес Заголовок назначения тр. уровня
Данные
рпр Информационный пакет ^ СТП-ИСС
Данные сообщения / ррр сегмента
С
сетевой интерфейс 8расе\Л/1ге
D. Рис. 4). Размер каждого сообщения прикладного процесса не должен превышать 2048 байт. Сообщения большего размера должны быть разбиты на сегменты прикладным уровнем, а транспортный протокол СТП-ИСС должен воспринимать данные сегменты как обычные независимые сообщения. На удаленном узле объединение сегментов в сообщение осуществляет также прикладной уровень узла-получателя. Выполняется это, основываясь на указанных в заголовках сегментов идентификаторах. Для этих целей вводится вторичный заголовок пакета СТП-ИСС, в котором прикладной процесс может передавать информацию, необходимую для сборки сообщений из сегментов (например, номера сегментов). СТП-ИСС обеспечивает надежную передачу данных посредством защиты передаваемых данных и заголовка пакета контрольной суммой CRC-16, проверяемой на приемнике.
Рис. 4. Формирование пакетов SpaceWire в СТП-ИСС
Е Буферы повтора. На передающей стороне транспортного протокола предусмотрен отдельный логический буфер на каждый тип передаваемых данных: • буфер команд управления;
• буфер срочных сообщений;
• буфер обычных сообщений.
Организация буферов на передающей стороне изображена на рРис. 5. Размеры этих буферов задаются в соответствии с размером сообщения, которое будет использовать сетевой узел для обмена с другими узлами, а также в соответствии с типом устройства, работающего по протоколу СТП-ИСС. Однако, для каждого из буферов (на приемной или передающей части) рекомендуется задавать размер таким образом, чтобы он вмещал как минимум два пакета данных. На приемной стороне транспортного протокола предусмотрен единый буфер на все типы информационных потоков. Это связано с тем, что данные из интерфейса SpaceWire приходят последовательно в пакетах SpaceWire.
Рис. 5. Организация буферов на передающей стороне СТП-ИСС
F. Таймеры времени жизни СТП-ИСС. В протоколе СТП-ИСС предусмотрен механизм таймера времени жизни пакетов, который отсчитывает время, пока пакет с данной информацией актуален для передачи по сети SpaceWiгe. Каждый пакет хранится в соответствующем буфере на передатчике в течение времени жизни, которое для него определено. Величина таймера времени жизни пакета является конфигурационным параметром протокола СТП-ИСС и может задаваться на этапе конфигурации. При этом каждому типу пакетов (пакет команды управления, срочного сообщения, обычного сообщения) соответствует отдельная величина таймера времени жизни. Таймер времени жизни взводится в момент записи пакета в буфер, а по истечении времени таймера соответствующий ему пакет из буфера удаляется. Таким образом, пакет в буфере должен храниться до возникновения одного из следующих событий:
• получение пакета подтверждения на данный пакет;
• отправка пакета в сеть при негарантированной доставке данных;
• срабатывание таймера времени жизни данного пакета.
& Качество сервиса СТП-ИСС. Одним из преимуществ протокола СТП-ИСС является обеспечение передачи сообщений и команд управления со следующими типами качества сервиса:
• Качество сервиса «С приоритетами»;
• Качество сервиса «Гарантированная доставка данных»;
• Качество сервиса «Негарантированная доставка данных».
К. Качество сервиса «С приоритетами» является основным и должен поддерживаться всеми устройствами, на которых реализован транспортный протокол СТП-ИСС. СТП-ИСС поддерживает 7 уровней приоритетов:
1. Пакеты подтверждения (наивысший приоритет);
2. Пакеты команд управления;
3. Повторные пакеты команд управления;
4. Пакеты срочных сообщений;
5. Повторные пакеты срочных сообщений;
6. Повторные пакеты обычных сообщений;
7. Пакеты обычных данных (самый низкий приоритет).
Данные с более высоким приоритетом должны быть переданы первыми.
¡.Качество сервиса «Гарантированная доставка данных» обеспечивает подтверждение корректной доставки данных посредством отправки пакетов подтверждения, а также повторную пересылку данных источником в случае отсутствия подтверждения (механизм таймеров повтора). Повторная отправка осуществляется на основе нумерации пакетов, которая осуществляется на прикладном уровне. Прикладной уровень нумерует все передаваемые данные от каждого прикладного процесса. Таким образом, комбинация идентификатора приложения и номера передаваемого сообщения однозначно идентифицирует каждый пакет.
Для реализации данного типа качества сервиса, при отправке данных на сетевой уровень должен быть взведен таймер повтора. Он определяет временной интервал, по истечению которого считается, что пакет не был доставлен до адресата корректно, либо был потерян пакет подтверждения. По истечению таймера повтора пакет, соответствующий данному таймеру, повторно отправляется адресату. Таймер повтора взводится в момент отправки последнего символа пакета на сетевой уровень. Каждому новому пакету соответствует свой отдельный таймер повтора. Для того чтобы уведомить отправителя о корректном приеме пакета используются пакеты подтверждения. Они отправляются, если отсутствует ошибка CRC, длина поля данных корректна и в заголовке пакета выставлен флаг «Требование подтверждения приема», определяющий для данного пакета качество сервиса «Гарантированная доставка данных». Пакет подтверждения несет в себе комбинацию идентификатора приложения и номера передаваемого сообщения. При приеме пакета подтверждения, пакет, соответствующий принятому номеру, должен быть удален из буфера повтора передатчика. Все таймеры, ассоциированные с номером этого пакета, должны быть остановлены и удалены.
J. Качество сервиса «Негарантированная доставка данных» обеспечивает передачу данных без подтверждений приема. Такие пакеты
содержат в заголовке бит 'Требование подтверждения приема', установленный в 0, и для них не взводится таймер повтора. При приеме информационного пакета, не требующего подтверждения, приемник также проверяет CRC и корректность длины поля данных, но в случае обнаружения ошибки в принятом информационном пакете, и в случае, если пакет был завершен символом EEP, данные пакета все равно должны быть переданы на прикладной уровень с уведомлением об ошибке.
K. Конфигурационные параметры СТП-ИСС. Важной особенностью протокола СТП-ИСС является его гибкость по отношению к конфигурации. Протокол имеет ряд конфигурационных параметров, которые позволяют настраивать протокол в зависимости от требований к качеству предоставляемого сервиса и типа используемой аппаратуры. Конфигурация протокола СТП-ИСС производится через конфигурационный интерфейс и выполняется в следующих случаях:
• включение устройства;
• перезагрузка устройства;
• переключение комплектов;
• восстановление из аварийного состояния.
В текущей версии протокола СТП-ИСС определено 5 конфигурационных параметров:
1. Время жизни пакета команды управления;
2. Время жизни пакета срочного сообщения;
3. Время жизни пакета обычного сообщения;
4. Таймаут повтора (длительность таймера повтора);
5. Гарантированная или негарантированная доставка данных.
L. Сигналы Reset и Flush. Через конфигурационный интерфейс могут подаваться сигналы Reset и Flush. По приходу сигнала Reset буферы на передатчике и приемнике очищаются, все таймеры, связанные с данными в буферах, должны быть сброшены, а конфигурационные параметры установлены в значения по умолчанию. Если же в СТП-ИСС подается команда Flush, то выполняется только очистка буферов и сброс взведенных таймеров.
Верификация и тестирование протокола СТП-ИСС. Для проведения верификации и тестирования механизмов, предложенных в протоколе СТП-ИСС, были разработаны следующие модели: С++ референс-код, SDL модель и сетевая SystemC модель (см. рис. 6).
Рис. 6. Процесс подготовки спецификации СТП-ИСС
Под С++ референс-кодом понимается программная реализация протокола СТП-ИСС на языках С/С++, представляющая собой программный код, наиболее точно соответствующий спецификации протокола. Он описывает логическую структуру протокола, его интерфейсы и внутренние механизмы протокола. Референс-код содержит подробные комментарии, позволяющие лучше понять алгоритм функционирования СТП-ИСС. Кроме того, программный код описывает тестовое окружение, которое позволяет запускать определенный набор тестовых сценариев работы протокола, что позволяет проверить функционирование протокола в различных условиях.
Модель СТП-ИСС на языке SDL (Spécification and Description Language) [10] отражает структуру протокола СТП-ИСС и формально описывает все механизмы и функциональность, заявленные в спецификации СТП-ИСС. Верификация протокола проводилась при помощи программного обеспечения IBM Rational SDL Suite. Тестовая система представляла собой 2 узла, взаимодействующих через модель канала SpaceWire. Использование SDL модели позволило провести верификацию и тестирование всех внутренних механизмов, а также проверить выполнение функциональных требований, предъявляемых к протоколу СТП-ИСС российской космической промышленностью.
Целью разработки сетевой модели протокола СТП-ИСС на языке SystemC [11, 12] являлась имитация сетевого взаимодействия устройств (коммутаторов и узлов) через каналы SpaceWire на различных топологиях. Сетевая модель состоит из следующих компонентов:
• модель протокола SpaceWire, состоящая из узлов SpaceWire, коммутаторов и каналов с помехами;
• модель транспортного протокола СТП-ИСС, работающая поверх стандарта SpaceWire в каждом узле;
• генератор трафика, позволяющий генерировать различные тестовые последовательности пакетов для тестирования сетевого взаимодействия устройств в сети.
Сетевая модель позволяет детально настраивать такие технические характеристики узлов и коммутаторов, как частота работы уст-
ройств, количество отправляемых пакетов, маршруты передачи данных, размеры буферов приема и т.д. На основе результатов, полученных в ходе верификации, тестирования и моделирования протокола СТП-ИСС, была выпущена спецификация редакции 1.
Выводы: в статье представлена разработка нового транспортного протокола СТП-ИСС для бортовых сетей SpaceWire, спроектированного совместно с ОАО «Информационные спутниковые системы» им. академика М.Ф. Решетне-ва» для применения в российской космической промышленности. Планируется дальнейшее развитие протокола СТП-ИСС и выпуск редакции 2 с добавлением следующих механизмов в СТП-ИСС:
1. Качество сервиса с планированием, при котором каждому узлу сети SpaceWire будет задан определенный временной интервал, в течение которого он сможет передавать данные.
2. Передача данных с предварительной установкой соединения.
3. Механизм управления потоком для каждого транспортного соединения.
4. Обнаружение повторно полученных пакетов. Редакция 2 должна быть полностью совместимой с редакцией 1 вплоть до совместимости форматов пакетов.
СПИСОК ЛИТЕРАТУРЫ:
1. ESA Standard ECSS-E-50-12C SpaceWire - Links, nodes, routers and networks. European cooperation for space standardization // ESA Publications Division ESTEC. - The Netherlands, Noordwijk, 2008. 129 p.
2. ESA Standard ECSS-E-ST-50-52C SpaceWire - Remote memory access protocol. European cooperation for space standardization // ESA Publications Division ESTEC. - The Netherlands, Noordwijk, 2010. 109 p.
3. ESA Standard ECSS-E-50-11 Draft E SpaceWire -Remote memory access protocol. European cooperation for space standardization // ESA Publications Division ESTEC. - The Netherlands, Noordwijk, 2006. 58 p.
4. ESA Standard ECSS-S-ST-50-53C. SpaceWire -CCSDS Packet Transfer Protocol. European cooperation for space standardization // Noordwijk: ESA Publications Division ESTEC. - The Netherlands, Noordwijk, 2010. 21 p.
5. EADS Astrium SMCS-ASTD-PS-001 1.1 STUP SpaceWire Protocol Protocol Specification // EADS Astrium. 2009. 7 p.
6. Sandia report SAND2011-3500 Joint Architecture Standard Reliable Data Delivery Protocol Specification // Sandia National Laboratories. - Albuquerque, New Mexico, 2011. 39 p.
7. Sheynin, Y.Streaming Transport Protocols for SpaceWire Networks / Y. Sheynin, E. Suvorova, F. Schutenko, V. Goussev / International SpaceWire Conference 2010. - Saint Petersburg, 2010. P. 21-29.
8. Olenev, V. Analysis of the Transport Protocol Requirements for the SpaceWire On-board Networks of Spacecrafts. Proceedings of 15th Seminar of Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program / V. Olenev, I. Lavrovskaya, I.
Korobkov, D. Dymov. - Saint-Petersburg: Saint-Petersburg University of Aerospace Instrumentation, 2014. P. 65-71.
9. Таненбаум, Э. Компьютерные сети / Э. Таненбаум, Д. Уэзеролл. Пер. с англ. А. Гребеньков. 5-е изд. -СПб.: Питер: 2012. 955 с.
10. ITU-T Recommendation Z.100: Specification and description language (SDL). - 1999. 244 p.
11. OSCI IEEE 1666™-2005 Standard for SystemC. 2011. 614 p.
12. Black, D. C: From the Ground Up // D. Black, J. Donovan, B. Bunton, A. Keist. - Springer, 2010. 279 p.
DEVELOPMENT OF THE STP-ISS TRANSPORT PROTOCOL FOR THE ONBOARD SPACEWIRE NETWORKS
© 2014 Yu.E. Sheynin1, V. L. Olenev1, I.YA. Lavrovskaya1, I.L. Korobkov1, S.G. Kochura2, S.I. Openko2, D.V. Dymov2
1 St. Petersburg State University of Aerospace Instrumentation 2 JSC Information Satellite Systems named after acad. M.F. Reshetnyov
In article the STP-ISS new transport protocol for the onboard SpaceWire networks developed together with JSC Information Satellite Systems named after acad. M.F. Reshetnev for application in the Russian space industry is described. The review and the analysis of existing transport protocols functioning atop SpaceWire is provided and also necessary requirements to the transport protocol which will work over the SpaceWire network are formulated. The description of the main mechanisms of developed STP-ISS protocol of the first edition is submitted. Various imitating models which are also described were developed for carrying out verification, testing and research of mechanisms of the new protocol. On the basis of results received during modeling the first edition of the STP-ISS specification was let out.
Key words: transport protocol, STP-ISS, onboard networks, SpaceWire, modeling
Yuriy Sheinin, Doctor of Technical Sciences, Professor, Head of the Aerospace Computing and Software Systems Department. E-mail: sheynin@aanet.ru
Valentin Olenev, Candidate of Technical Sciences, Chief of the EmCoMobile Laboratory. E-mail: valentin.olenev@guap.ru Irina Lavrovskaya, Master Iliya Korobkov, Master
Sergey Kochura, Candidate of Technical Sciences, Associate Professor, Deputy General Designer for Electrical Engineering and Satellite Control Systems. E-mail: kochura@iss-reshetnev.ru Sergey Openko, Chief Designer for Electrical Engineering and Spacecrafts Testing. E-mail: openkosi@iss-reshetnev.ru Dmitriy Dymov, Chief of the 2202 Sector. E-mail: dymov@iss-reshetnev. ru
