CC BY
151ПО МАТЕРИАЛАМ IV НАУЧНО-ПРАКТИЧЕСКОЙ КОНФЕРЕНЦИИ «ВЫЗОВЫ И ДОЛГОСРОЧНЫЕ ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ
КОСМИЧЕСКИХ СИСТЕМ»
УДК 629.783.051
РАЗРАБОТКА, АНАЛИЗ И ПРОЕКТИРОВАНИЕ ТРАНСПОРТНОГО ПРОТОКОЛА СТП-ИСС ДЛЯ БОРТОВЫХ КОСМИЧЕСКИХ СЕТЕЙ SPACEWIRE
Ю. Е. Шейнин1, В. Л. Оленев1, И. Я. Лавровская1,
Д. В. Дымов2, С. Г. Кочура2
1Санкт-Петербургский государственный университет аэрокосмического приборостроения,
г. Санкт-Петербург, Российская Федерация 2АО «Информационные спутниковые системы» имени академика М. Ф. Решетнёва», г. Железногорск, Красноярский край, Российская Федерация
В данной статье представлены результаты проекта по разработке нового транспортного протокола СТП-ИСС для бортовых космических сетей. Приведено краткое сравнение существующих транспортных протоколов для SpaceWire, которое обосновывает разработку нового протокола. Описаны все фазы разработки протокола СТП-ИСС начиная со сбора технических требований от представителей космической индустрии. После первой версии спецификации протокола, в которой описывались все его механизмы, было проведено моделирование, тестирование и верификация протокола СТП-ИСС по средствам трех разных реализаций: референсного кода на языке С++, ББЬ-модели протокола и сетевой SystemC модели, описывающей поведение устройств, работающих при помощи СТП-ИСС в сети. Следующим этапом работы была реализация №-ядра для СТП-ИСС и создание рабочего места для тестирования оборудования, работающего по разработанному протоколу. По результатам проекта в статье представлены две редакции протокола СТП-ИСС и приведено их краткое сравнение.
Ключевые слова: транспортный протокол, бортовые сети, SpaceWire, СТП-ИСС, тестирование, №-ядро, моделирование.
Введение
SpaceWire - это сетевая технология для космических аппаратов, совмещающая в себе простоту и низкую цену реализации наравне с высокой производительностью и гибкостью архитектуры [1]. Благодаря этому SpaceWire широко применяют мировые космические агентства и представители космической индустрии. Технология SpaceWire использовалась в более 30 миссиях и является доминирующей для бортовых систем малых космических аппаратов, посадочных модулей и т.п.
Длительное время основной технологией, применяемой в космическом и авиационном оборудовании, была коммуникационная шина MIL-STD 1553. Однако в условиях растущих требований MIL-STD 1553 уже не справляется с поставленными задачами, поскольку его средняя скорость передачи данных в 1 Мбит/с и шинная топология накладывают серьезные ограничения
© Шейнин Ю. Е., Оленев В. Л., Лавровская И. Я., Дымов Д. В., Кочура С. Г., 2016
[2-3]. Поэтому для передачи данных в бортовых сетях сейчас переходят на стандарт SpaceWire; необходимость в малых спутниках, посадочных модулях и т.п. резко подняла возможности его использования.
Применение SpaceWire в сочетании с транспортными протоколами, обеспечивающими различные качества сервиса, дает возможность удовлетворять требованиям авионики, а также значительно повысить надежность передачи данных на борту космических аппаратов.
Проект по разработке транспортного протокола СТП-ИСС стартовал в начале 2013 года. Первой поставленной задачей был сбор требований для транспортных протоколов от космической индустрии. Подробный обзор требований к транспортным протоколам представлен в [4]. В дополнение к требованиям был проведен обзор транспортных протоколов для различных типов сетей, а также механизмов, которые предоставляют различные типы качества сервиса на транспортном уровне.
Полученные требования и обзор протоколов были обработаны, и в результате была вы-
АЛ
Ж г
КО-
ГРАДА
22
пущена первая версия спецификации протокола СТП-ИСС. Эта версия была проверифицирована и промоделирована при помощи нескольких различных моделей. Эта часть работы подробно описана в [5].
Основная задача данной статьи состоит в том, чтобы описать весь процесс разработки протокола СТП-ИСС от сбора требований до реализации первой версии протокола в 1Р-ядре и создания рабочего места аппаратно-программной отработки СТП-ИСС. Также в статье представлена вторая, расширенная редакция транспортного протокола СТП-ИСС.
Современной космической индустрии необходим транспортный протокол, работающий поверх SpaceWire, который будет предоставлять надежность, гарантированную доставку данных и детерминизм. Протокол SpaceWire охватывает три нижних уровня модели OSI и не охватывает транспортный уровень [6]. На данный момент существует целый ряд транспортных протоколов, ориентированных на работу в сетях SpaceWire. Это такие протоколы, как ЯМАР, CCSDS, РТР, STUP, JRDDP и STP (см. рис. 1). Каждый из этих протоколов предназначен для решения конкретных узконаправленных задач, что неудобно, поскольку может возникнуть ситуация, когда необходимо использовать несколько транспортных протоколов на одном устройстве одновременно.
В табл. 1 представлено сравнение транспортных протоколов семейства SpaceWire, которое позволит проанализировать их на соответствие техническим требованиям.
Таблица 1
Сравнение транспортных протоколов
Свойство ЯМАР РТР STUP JRDDP STP SpW-D
Контроль потока - - - V V -
Гибкость конфигурации
Передача данных с установкой соединения - - - V V -
Проверка корректности данных V - V V V -
Проверка последовательности данных - - - V - -
Качество сервиса «С планированием» V
Качество сервиса «С приоритетом» - - - V - -
Повторная отправка данных - - - V - -
Подтверждение получения данных V - - V - -
Анализ транспортных протоколов SpaceWire показывает, что не существует транспортного протокола для SpaceWire, который обеспечивает надежность, гарантированную доставку данных, планирование [4] и гибкость конфигурации.
Транспортный протокол СТП-ИСС-13
Принимая во внимание технические требования от индустрии и обзор транспортных протоколов, разработали первую версию спецификации транспортного протокола СТП-ИСС, она получила название СТП-ИСС-13. В данном разделе приведены обзор и описание механизмов СТП-ИСС-13.
Бортовая сеть SpaceWire для малого космического аппарата (рис. 1) является одним из примеров применяемой топологии, но использование протокола СТП-ИСС планируется и в намного более сложных сетях. Максимальное количество узлов регламентируется технологией SpaceWire.
Более того, сеть может быть разбита на несколько регионов. Технология SpaceWire отвечает этим требованиям благодаря масштабируемости и возможности разбиения на регионы с использованием региональной логической адресации.
Общее описание СТП-ИСС-13. Протокол СТП-ИСС-13 выполняет функции транспортного уровня и определяет информационно-логическое взаимодействие, регламентирует форматы передаваемых данных и правила передачи сообщений между абонентами бортовой сети SpaceWire. При этом бортовое программное обеспечение космического аппарата может выполнять функции прикладного, представительского и сеансового уровней в соответствии с моделью OSI [14]. Место СТП-ИСС в семействе стандартов SpaceWire в соответствии с эталонной моделью OSI показано на рис. 2.
Интерфейсы СТП-ИСС-13. Для взаимодействия с прикладными процессами предусмотрены три интерфейса: интерфейс данных, конфигурационный интерфейс и интерфейс системных
Рис. 1. Пример топологии бортовой сети
Рис. 2. Соотнесение протокола СТП-ИСС с моделью ОБ1
кодов. Через интерфейс данных передаются команды управления и информационные сообщения.
Сообщения прикладных процессов и команды управления на удаленные узлы передаются в пакетах SpaceWire. Конфигурационный интерфейс служит для смены значений конфигурационных параметров СТП-ИСС-13, передачи статусной информации и команд сброса. В свою очередь, интерфейс системных кодов отвечает за распространение маркеров системного времени и системных прерываний во все узлы сети посредством технологии SpaceWire.
Для взаимодействия со SpaceWire - два интерфейса: интерфейс пакетов SpaceWire и интерфейс системных кодов (рис. 3).
Сообщения прикладных процессов СТП-ИСС. Одна из основных задач транспортного протокола СТП-ИСС - это обеспечение транспортировки сообщений прикладных процессов на удаленные узлы сети. Сообщение прикладного процесса - это блок данных, поступающий в СТП-ИСС от протокола прикладного уровня.
Рис. 3. Интерфейсы транспортного протокола СТП-ИСС-13
Рис. 4. Инкапсуляция сообщения в пакет SpaceWire в СТП-ИСС-13
Сообщения разделяются по типу в соответствии с их приоритетом: срочные (высокоприоритетные) и обычные (низкоприоритетные). Сообщения прикладных процессов на транспортном уровне должны быть помещены в пакеты SpaceWire и переданы на удаленный узел (рис. 4).
Блок данных СТП-ИСС-13 имеет ограниченную длину. Размер каждого сообщения прикладного процесса не должен превышать 2048 байт. Функция сегментации сообщений выполняется прикладным уровнем. Для этих целей вводится вторичный заголовок пакета СТП-ИСС-13, в котором прикладной процесс может передавать информацию, необходимую для сборки сообщений из сегментов.
СТП-ИСС-13 обеспечивает надежную передачу данных посредством защиты передаваемых данных и заголовка пакета контрольной суммой CRC-16, проверяемой на приемнике. CRC-16 охватывает поле заголовка пакета и поле данных, начиная с первого байта пакета и заканчивая последним байтом данных, не включая символ конца пакета ЕОР.
Таймеры жизни СТП-ИСС-13. В протоколе СТП-ИСС предусмотрен механизм таймера времени жизни пакетов, который отсчитывает время, пока пакет с данной информацией актуален для передачи по сети SpaceWire. Каждый пакет хранится в соответствующем буфере на передатчике в течение времени жизни, которое для него определено. Каждому типу пакетов соответствует отдельная величина таймера времени жизни.
Буферы повтора. На передающей стороне транспортного протокола предусмотрен отдельный логический буфер на каждый из приоритетов передаваемых данных: буфер команд управления; буфер срочных сообщений; буфер обычных сообщений. Размеры этих буферов задаются в соответствии с размером сообщения, которое будет использовать сетевой узел для обмена с другими узлами, а также в соответствии с типом устрой-
23
АЛ
Ж Г
КО-
ГРАДА
24
Рис. 5. Буферы повтора СТП-ИСС
ства. Организация буферов на передающей стороне изображена на рис. 5.
Если происходит переполнение буфера, то приложение должно ждать, пока появится свободное место для очередного сообщения.
Приемный буфер. На приемной стороне транспортного протокола СТП-ИСС-13 предусмотрен единый буфер на все типы информационных потоков. Буфер должен иметь возможность хранить минимум два пакета.
Если приемный буфер переполнен, то СТП-ИСС-13 должен об этом сообщить прикладному уровню.
Качество сервиса СТП-ИСС-13. Одним из преимуществ протокола СТП-ИСС-13 является обеспечение передачи сообщений и команд управления со следующими типами качества сервиса: «С приоритетом»; «Гарантированная доставка данных»; «Негарантированная доставка данных».
Качество сервиса «С приоритетом» является основным и должно поддерживаться всеми устройствами, на которых реализован транспортный протокол СТП-ИСС-13. Согласно данному типу качества сервиса данные с более высоким приоритетом должны быть переданы первыми. СТП-ИСС-13 поддерживает 7 уровней приоритетов.
СТП-ИСС-13 анализирует заявки на передачу пакетов во время арбитража. Пакет содержит специальный флаг «Тип пакета» и признак повторной отправки пакета. В зависимости от этого СТП-ИСС делает вывод, какой пакет должен быть отправлен первым.
Качество сервиса «Гарантированная доставка данных» обеспечивает подтверждение корректной доставки данных посредством отправки пакетов подтверждения, а также повторную пересылку данных источником в случае отсутствия подтверждения. Повторная отправка осуществляется на основе нумерации пакетов, которая выполняется на прикладном уровне. При отправке данных на сетевой уровень должен быть взведен таймер повтора. Он определяет временной интервал, по истечении которого считается, что пакет не был доставлен до адресата корректно либо был
потерян пакет подтверждения. По истечении таймера повтора пакет, соответствующий данному таймеру, повторно отправляется адресату.
Для того чтобы уведомить отправителя о корректном приеме пакета, используются пакеты подтверждения. Они отправляются, если отсутствует ошибка CRC, длина поля данных корректна или в заголовке пакета выставлен флаг «Требование подтверждения приема», определяющий для данного пакета качество сервиса «Гарантированная доставка данных».
При приеме пакета подтверждения пакет, соответствующий принятому номеру, должен быть удален из буфера повтора передатчика. Все таймеры, ассоциированные с номером этого пакета, должны быть остановлены и удалены.
Качество сервиса «Негарантированная доставка данных» обеспечивает передачу данных без подтверждений приема. Такие пакеты содержат в заголовке бит 'Требование подтверждения приема', установленный в 0, и для них не взводится таймер повтора. При приеме информационного пакета, не требующего подтверждения, приемник также проверяет CRC и корректность длины поля данных, но в случае обнаружения ошибки данные пакета все равно должны быть переданы на прикладной уровень с уведомлением об ошибке. Передатчик не хранит такой пакет в буфере, не ждет подтверждения и не пересылает пакет.
Конфигурационные параметры. Важной особенностью протокола СТП-ИСС-13 является его гибкость конфигурации. Протокол имеет ряд конфигурационных параметров, которые позволяют настраивать протокол в зависимости от требований к качеству предоставляемого сервиса и типа используемой аппаратуры. Конфигурация протокола СТП-ИСС-13 производится через конфигурационный интерфейс и выполняется в следующих случаях: включение устройства; перезагрузка устройства; переключение комплектов; восстановление из аварийного состояния.
В текущей версии протокола СТП-ИСС-13 определено 5 конфигурационных параметров:
- время жизни пакета команды управления;
- время жизни пакета срочного сообщения;
- время жизни пакета обычного сообщения;
- тайм-аут повтора (длительность таймера повтора);
- гарантированная или негарантированная доставка данных.
Сигналы Reset и Flush. Через конфигурационный интерфейс могут подаваться сигналы Reset и Flush. Команда Reset соответствует горячему сбросу, в то время как команда Flush используется для очищения буферов приемника и передатчика протокола СТП-ИСС. По приходе сигнала Reset буферы на передатчике и приемнике транспортного протокола очищаются, все тай-
меры, связанные с данными в буферах, должны быть сброшены, и конфигурационные параметры устанавливаются в значения по умолчанию. Если же в СТП-ИСС подается команда Flush, то также очищаются буферы и сбрасываются таймеры, но конфигурационные параметры остаются прежними.
Моделирование СТП-ИСС-13
После создания предварительной версии спецификации СТП-ИСС-13 необходимо было ее проверить, проанализировать и протестировать. Для проведения верификации и тестирования механизмов, предложенных в протоколе СТП-ИСС-13, были разработаны три модели: С++ референс-код; SDL модель; сетевая SystemC модель. На основании результатов анализа, тестирования и моделирования была создана финальная версия спецификации СТП-ИСС-13.
Под референс-кодом понимается программная реализация протокола транспортного уровня СТП-ИСС на языках С++ и С [15]. Эта реализация представляет собой программный код, наиболее точно соответствующий спецификации протокола. Он описывает логическую структуру протокола, его интерфейсы и внутренние механизмы, тестовое окружение, которое позволяет проверить функционирование протокола в различных условиях. В результате запуска сценариев генерируются файлы отчетов, содержащие информацию о возникающих в процессе работы протокола событиях.
Язык SDL [16] использовался для написания спецификации и моделирования СТП-ИСС. Разработанная SDL модель отражает структуру протокола СТП-ИСС и формально описывает все механизмы и функциональности, которые заявлены в спецификации СТП-ИСС. Тестовая система СТП-ИСС-13 представляет собой 2 узла, взаимодействующих через упрощенный канал SpaceWire. Настройка и генерация тестов выполняются посредством тестового окружения. Проведение такого рода моделирования позволило провести верификацию и тестирование всех внутренних механизмов, а также выполнить валидацию спецификации на логичность и связанность и проверить, выполняются ли функциональные требования, предъявляемые к протоколу.
Цель разработки сетевой модели СТП-ИСС-13 - имитация сетевого взаимодействия устройств (коммутаторов и узлов) через канал SpaceWire. Она разрабатывалась на языке SystemC [17-19]. Сетевая модель СТП-ИСС состоит из модели протокола SpaceWire (узлы, коммутаторы и каналы с помехами), модели СТП-ИСС-13 и генераторов различных тестовых последовательностей для тестирования СТП-ИСС-13 и сетевого взаимодействия устройств.
Проведенная работа по моделированию и тестированию помогла исправить некоторое количество алгоритмов и механизмов протокола, найти более удачные решения и протестировать СТП-ИСС-13 и взаимодействие по SpaceWire.
Разработка 1Р-ядра СТП-ИСС-13
Следующим этапом работы после моделирования и внесения изменений в спецификацию СТП-ИСС-13 была разработка 1Р-блока СТП-ИСС-13. 1Р-блок - это дизайн логического модуля, ячейки или чипа, который может быть использован много раз при производстве [20]. Чип был создан для проверки работоспособности механизмов протокола СТП-ИСС-13 при аппаратной реализации. Архитектура контроллера СТП-ИСС-13 показана на рис. 6.
1Р-блок СТП-ИСС-13 был разработан как конфигурируемое 1Р-ядро таким образом, чтобы была возможность исключать разные его компоненты. Компоненты, выделенные серым цветом на рис. 6, - это те компоненты, которые могут быть исключены для различных реализаций контроллера СТП-ИСС-13.
Рабочее место
аппаратно-программной отработки СТП-ИСС-13
Реализованный для СТП-ИСС-13 референс-код лег в основу рабочего места аппаратно-программной отработки СТП-ИСС-13 (РМ АПО-С). Эта референсная реализация протокола должна быть расположена на одной стороне соединения, а тестируемая программная или аппаратная реализация протокола - на другой. Референс-код может генерировать различные типы пакетов, и объект те-
25
Рис. 6. Архитектура контроллера СТП-ИСС-13
Hav
ж г
КО-
ГРАДА
стирования должен отвечать на них. В зависимости от результатов обмена данными мы можем сделать вывод, работает ли тестируемое устройство в соответствии со спецификацией СТП-ИСС или нет.
Общая архитектура аппаратно-программного тестера и пример использования аппаратно-программного тестера на базе ноутбука представлены на рис. 7. Программное обеспечение РМ АПО-С состоит из следующих элементов: тестовое окружение; референс-код; модуль генерации ошибок; драйвер к аппаратуре.
Программная часть РМ АПО-С должна 26 быть установлена на персональном компьютере. Текущая версия тестера работает под операционной системой Ubuntu. Для связи компьютера со SpaceWire устройством используется Star-Dundee SpaceWire Brick Mk2 [21].
Транспортный протокол СТП-ИСС-14
Первая версия протокола СТП-ИСС (СТП-ИСС-13) не реализует часть технических требований, которые были озвучены индустрией: это планирование, передача данных с установкой соединения, контроль потока и обнаружение повторных команд управления. Эти четыре пункта включены во вторую редакцию СТП-ИСС, которая названа СТП-ИСС-14. Каждый из этих механизмов будет описан в текущем разделе.
Качество сервиса «С планированием». Планирование подразумевает наличие единого расписания для всей сети SpaceWire. Это расписание дает возможность узлу отправлять данные только во время конкретных временных интервалов. Расписание, длительность временного интервала и длительность эпохи устанавливаются на этапе конфигурации протокола и хранятся в каждом узле. Эпоха содержит постоянное количество временных интервалов, описываемых в таблице расписания.
Таймер временных интервалов считает длительность текущего временного интервала для конкретного узла. Истечение таймера временного интервала для последнего временного интервала и получение метки времени сообщает о начале новой эпохи, в которой таймер снова будет считать с нуля. Начало новой эпохи соответствует факту получения метки времени. Есть две ситуации, которые могут возникнуть в сети: следующая метка времени получена перед или после срабатывания таймера эпохи. Для узла эти ситуации означают, что внутренний таймер временного интервала и мастер времени не синхронизированы, поэтому узел должен начать процедуру синхронизации. Синхронизация выполняется один раз в эпоху. Во время синхронизации узел должен вычислить новое значение для таймера временных интервалов. Новое значение должно быть применено для таймера во время следующего временного интервала. Новая эпоха начинается, когда получен новый тайм-код. В каждой эпохе есть К временных интервалов, в течение которых принятая метка времени считается актуальной - это «окно ожидания метки времени». Метка времени, принятая вне окна ожидания, считается неактуальной, и синхронизация в этом случае не выполняется (рис. 8).
Если срабатывание таймера временного интервала для последнего временного интервала и получение метки времени произошли одновременно, то корректировка длительности временного интервала производиться не должна.
СТП-ИСС-14 должен вести учет принятых неактуальных меток времени. Приём трёх неактуальных меток времени в трёх эпохах подряд означает значительную рассинхронизацию локального счётчика времени и мастера времени. Приём третьей неактуальной метки времени должен определять начало новой эпохи. Узел должен остановить таймер временного интервала и ожидать прием следующей метки времени. В этот период узел не должен отправлять данные до получения следующей
Рис. 7. Архитектура РМ АПО-С
К - размер окна ожидания метки времени
Рис. 8. Пример неактуального тайм-кода
27
метки времени. После этого узел должен обновить значение длины временного интервала и продолжить передачу данных в соответствии с расписанием. Детальное описание механизма планирования и его исследование описано в статье [23].
Передача данных с установкой соединения. Передача данных с установкой соединения дает возможность передавать большие объемы данных с минимальными накладными расходами. Только срочные пакеты и обычные пакеты данных могут передаваться по транспортному соединению. Максимальное количество транспортных соединений должно быть не более 8 в одном направлении. Каждое транспортное соединение является однонаправленным.
Максимальный объем пакета, передаваемого по транспортному соединению, составляет 64 Кбайта. Установка транспортного соединения должна быть инициирована приложением. Установка транспортного соединения выполняется посредством классического трехфазного протокола.
Во время установки транспортного соединения устанавливаются различные параметры соединения, такие как номер соединения, тип и направление передаваемых данных, качество сервиса и т.п. Удаленный узел проверяет, может ли он установить соединение с такими параметрами, и отвечает подтверждением или отказом. Для каждого транспортного соединения на приемной и передающей стороне есть таймер времени простоя, который считает время ожидания следующего пакета по текущему соединению. По истечении этого таймера транспортное соединение должно быть разорвано, а приложение уведомлено об этом.
Закрытие соединения инициируется приложением, которое было инициатором установки. Оно также производится посредством трехфазного протокола.
Механизм управления потоком. Управление потоком выполняется посредством отправки информации о количестве свободного места в буфе-
ре приемника. Этот механизм применяется только для транспортных соединений с гарантированной доставкой данных.
Принимающий узел во время установки транспортного соединения должен резервировать запрошенное буферное пространство и считать его. Каждое транспортное соединение имеет счетчик свободных кредитов и счетчик использованного пространства в буфере. Информация о свободном месте в буфере должна отправляться в пакете подтверждения. В случае если свободное пространство меняется после отправки пакета подтверждения (например, приложение считало данные из буфера), то приемник отправляет пакет подтверждения с особым флагом, который сообщает, что это не пакет подтверждения, а информация о новом значении счетчика кредитов. В свою очередь, передающий узел считает количество данных, которое может быть отправлено с использованием кредитов для каждого транспортного соединения. Оно должно быть равно зарезервированному месту в буфере приемника.
Потеря или повреждение пакета подтверждения с кредитами может повлечь за собой потерю информации о новых кредитах в приемнике. Чтобы избежать этого, СТП-ИСС-14 предоставляет механизм синхронизации кредитов. Передающий узел начинает синхронизацию кредитов после каждых 10 отправленных пакетов. Для этих целей передающий узел отправляет пакет запроса синхронизации кредитов. Принимающий узел получает его и отвечает пакетом с текущим значением кредитов в приемнике. Затем передатчик должен проверить, верно ли его локальное значение счетчика кредитов.
Качество сервиса «С приоритетом» в СТП-ИСС-14. Для качества сервиса с приоритетами было сделано несколько изменений для СТП-ИСС-14. Новая редакция поддерживает три новых типа пакетов, которые используются для режима с установкой соединения. СТП-ИСС-14 теперь поддерживает 9 уровней приоритетов.
АЛ
Ж Г
КО-
ГРАДА
28
Таблица 2
Сравнение редакций СТП-ИСС
Механизм СТП-ИСС-13 СТП-ИСС-14
Качество сервиса «С приоритетом» V V
Гарантированная доставка данных V V
Негарантированная доставка данных V V
Планирование — V
Передача данных без установки соединения V V
Передача данных с установкой соединения — V
CRC16 V V
Reset и Flush V V
Таймер времени жизни V V
Конфигурация протокола V V
Максимальная длина данных 2 Kb 64 Kb (для ТС)
Контроль потока — V
Обнаружение повторных КУ — V
Обнаружение дублирующих команд управления. Протокол СТП-ИСС-14 обеспечивает обнаружение повторных команд управления на приемнике. Повторная команда управления может возникнуть в случае потери пакета подтверждения и может быть обнаружена по комбинации логического адреса передатчика, номера приложения и номера команды управления. Эта комбинация однозначно идентифицирует каждую команду. Приемник должен хранить историю последних полученных команд управления. Информация о каждой команде управления должна сопровождаться таймером. По истечении таймера информация о команде управления удаляется из истории, хранящейся в приемнике.
Гибкость конфигурации СТП-ИСС-14. Гибкость при конфигурации дает возможность отключать или даже не реализовывать отдельные механизмы СТП-ИСС-14. Таким образом, СТП-ИСС-14 имеет много различных профилей реализации. Есть набор механизмов, обязательных к реализации: качество сервиса «С приоритетом»; негарантированная доставка данных; СЯС-16; буфер на передатчике (как минимум для одного типа данных); буфер на приемнике (как
минимум для одного типа данных). Другие механизмы рассматриваются как расширения протокола и могут быть реализованы опционально. В табл. 2 показано сравнение СТП-ИСС-13 и СТП-ИСС-14. Сохранена обратная совместимость этих редакций.
Заключение
В данной статье приведено описание нашего опыта в сфере разработки транспортного протокола для сетей SpaceWire. Работа над протоколом была начата со сбора технических требований от индустриального партнера, затем был проведен обзор существующих протоколов транспортного уровня для SpaceWire.
Краткое сравнение транспортных протоколов в сравнении с техническими требованиями показало, что не существует транспортных протоколов для сетей SpaceWire, которые предоставляют надежность, гарантированную доставку и планирование. По этой причине были предложены основные решения для некоторых механизмов протокола: форматы данных, CRC, буферизация на стороне передатчика, качество сервиса и конфигурирования. Эти предложения стали основой для нового транспортного протокола СТП-ИСС. Этот протокол описан в двух редакциях, которые описывают основные механизмы СТП-ИСС. СТП-ИСС-14 удовлетворяет техническим требованиям индустрии.
Более того, в статье описаны направления, в которых велась работа по разработке, верификации и тестированию СТП-ИСС: спецификация на языке SDL, разработка референс-кода и сетевое моделирование. Как результат, были исправлены несколько ошибок в спецификации и выпущена финальная версия СТП-ИСС. В текущей статье также дан обзор процесса разработки IP-ядра для первой редакции протокола, а также рабочего места аппаратно-программной отработки СТП-ИСС, предназначенного для тестирования готовых устройств, работающих с применением СТП-ИСС.
Первое аппаратно-программное тестирование протокола СТП-ИСС в составе функциональных узлов бортовой аппаратуры КА планируется провести в 2017-2018 годах.
Список литературы
1. Parkes S. SpaceWire-RT (SpWRT). Let's Embrace Space, Volume II. Luxembourg : Publications Office of the European Union, 2012.
2. AIM GMBh. MIL-STD-1553 Tutorial // AIM GMBh, 2010.
3. Condor Engineering, Inc. MIL-STD-1553 Tutorial // Condor Engineering, 2000.
4. Olenev V., Lavrovskaya I., Korobkov I., Dymov D. Analysis of the Transport Protocol Requirements for the SpaceWire On-board Networks of Spacecrafts // Proc. of 15th Seminar of Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program. Saint-Petersburg, SUAI university publisher house, 2014. P. 65-71.
Разработка, анализ и проектирование транспортного протокола СТП-ИСС
5. Sheynin Y., Olenev V, Lavrovskaya I., Korobkov I., Kochura S., Openko S., Dymov D. STP-ISS Transport Protocol Overview and Modeling // Proceedings of 16th Conference of Open Innovations Association Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program. Oulu : University of Oulu, 2014. P. 185-191.
6. ESA (European Space Agency). Standard ECSS-E-50-12C, Space engineering. SpaceWire - Links, nodes, routers and networks // European cooperation for space standardization. Noordwijk : ESA Publications Division ESTEC, 2008.
7. ESA (European Space Agency). Standard ECSS-E-ST-50-52C, Space engineering. SpaceWire - Remote memory access protocol // European cooperation for space standardization. Noordwijk : ESA Publications Division ESTEC, 2010.
8. ESA (European Space Agency). Standard ECSS-E-ST-50-53C, SpaceWire - CCSDS Packet Transfer Protocol // Noordwijk : Publications Division ESTEC, 2010.
9. EADS Astrium GmbH, ASE2. SMCS-ASTD-PS-001 1.1, STUP SpaceWire Protocol // Germany, EADS Astrium GmbH, 2009.
10. Sandia National Labortories. Joint Architecture System Reliable Data Delivery Protocol (JRDDP) // Albuquerque,
New Mexico, Sandia National Labortories, 2011. 29
11. Sheynin Y., Suvorova E., Schutenko F., Goussev V. Streaming Transport Protocols for SpaceWire Networks // International SpaceWire Conference. St. Petersburg : SUAI university publisher house, 2010.
12. Parkes S., Ferrer-Florit A. SpaceWire-D - Deterministic Control and Data Delivery Over SpaceWire Networks, Draft B. // International SpaceWire Conference. St. Petersburg : SUAI university publisher house, 2010.
13. Koblyakova L., Sheynin Y., Raszhivin D. Real-time signaling in networked embedded systems // International SpaceWire Conference. St. Petersburg : SUAI university publisher house, 2010. P. 385-388.
14. Tanenbaum A. Computer Networks, Fifth Edition // New Jersey : Prentice Hall, 2011.
15. Stroustrup B. The C++ Programming Language, 4th Edition // USA, Addison-Wesley, 2013.
16. International Telecommunication Union. Recommendation Z.100. Specification and Description Language (SDL) // Geneva, 2007.
17. Open SystemC Initiative (OSCI). IEEE 1666™-2011 Standard for SystemC [Электронный ресурс]. URL: http:// www.systemc.org (дата обращения: 09.11.2015).
18. Esperan. Introduction to the SystemC Tutorial [Электронный ресурс]. URL: http://homepages.cae.wisc.edu/~ece734/ SystemC/Esperan_SystemC_tutorial.pdf (дата обращения: 04.10.2016).
19. Black D., Donovan J., Bunton B., Keist A. SystemC: From the Ground Up // NY, Springer, 2010.
20. Ben Abdallah A. Multicore Systems On-Chip: Practical Software/Hardware Design. Second Edition. Atlantic Press.
21. Star-Dundee website, SpaceWire-USB Brick Mk2 [Электронный ресурс]. URL: https://www.star-dundee.com/prod-ucts/spacewire-usb-brick-mk2 (дата обращения: 04.10.2016).
22. Qtwebsite [Электронный ресурс]. URL: http://www.qt.io (дата обращения: 04.10.2016).
23. Olenev V., Podgornova E., Lavrovskaya I., Korobkov I., Matveeva N. Development of the transport layer scheduling mechanism for the оЛоаМ SрасеWirе networks // Proceedings of 16th Conference of Open Innovations Association Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program. Oulu : University of Oulu, 2014. P. 164-170.
DEVELOPMENT, ANALYSIS AND MODELING OF STP-ISS TRANSPORT PROTOCOL FOR SPACEWIRE ONBOARD
NETWORKS
Yu. E. Sheynin1, V. L. Olenev1, I. I. Lavrovskaya1, D. V. Dymov2,
S. G. Kochura2
1Saint Petersburg State University of Aerospace Instrumentation, Saint-Petersburg, Russian Federation 2JSC Academician M. F. Reshetnev Information Satellite Systems, Zheleznogorsk, Krasnoyarsk region, Russian Federation
The paper presents results of a projectfor development of a new transport protocol STP-ISSfor SpaceWire onboard networks. Authors shortly overview the existing transport protocols for SpaceWire and prove that development of a new protocol is reasonable. Then the paper describes all phases of the STP-ISS development. The development started from the gathering of technical requirements from the space industry. Then authors wrote the first version of the STP-ISS specification, wich describes its main mechanisms. After that authors performed modeling, testing and verification of a protocol by three different models: C++ reference code, SDL model and SystemC networking model, which describes the networking mechanisms of STP-ISS. The next step was the development of IP-core and implementation of a Workplace for the testing of a hardware, which works with STP-ISS usage. As a result, paper presents two revisions of STP-ISS transport protocol and shortly compares them.
Key words: transport protocol, onboard network, SpaceWire, STP-ISS, Tester, IP-core, modeling.
АЛ
Ж Г
КО-
ГРАДА
References
1. Parkes, S. SpaceWire-RT (SpWRT). Let's Embrace Space, Volume II. Luxembourg : Publications Office of the European Union, 2012.
2. AIM GMBh. MIL-STD-1553 Tutorial. AIM GMBh, 2010.
3. Condor Engineering, Inc. MIL-STD-1553 Tutorial. Condor Engineering, 2000.
4. Olenev V., Lavrovskaya I., Korobkov I., Dymov D. Analysis of the Transport Protocol Requirements for the SpaceWire On-board Networks of Spacecrafts, Proc. of 15th Seminar of Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program. Saint-Petersburg : SUAI university publisher house, 2014. Р. 65-71.
5. Sheynin Y., Olenev V., Lavrovskaya I., Korobkov I., Kochura S., Openko S., Dymov, D. STP-ISS Transport Protocol Overview and Modeling. Proceedings of 16th Conference of Open Innovations Association Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program. Oulu : University of Oulu, 2014. Р. 185-191.
3° 6. ESA (European Space Agency). Standard ECSS-E-50-12C, Space engineering. SpaceWire - Links, nodes, routers and networks. European cooperation for space standardization. Noordwijk : ESA Publications Division ESTEC, 2008.
7. ESA (European Space Agency). Standard ECSS-E-ST-50-52C, Space engineering. SpaceWire - Remote memory access protocol. European cooperation for space standardization. Noordwijk : ESA Publications Division ESTEC, 2010.
8. ESA (European Space Agency). Standard ECSS-E-ST-50-53C, SpaceWire - CCSDS Packet Transfer Protocol. Noordwijk : Publications Division ESTEC, 2010.
9. EADS Astrium GmbH, ASE2. SMCS-ASTD-PS-001 1.1, STUP SpaceWire Protocol. Germany, EADS Astrium GmbH, 2009.
10. Sandia National Labortories. Joint Architecture System Reliable Data Delivery Protocol (JRDDP). Albuquerque, New Mexico, Sandia National Labortories, 2011.
11. Sheynin Y., Suvorova E., Schutenko F., Goussev V. Streaming Transport Protocols for SpaceWire Networks. International SpaceWire Conference. St. Petersburg : SUAI university publisher house, 2010.
12. Parkes S., Ferrer-Florit A. SpaceWire-D - Deterministic Control and Data Delivery Over SpaceWire Networks, Draft B. International SpaceWire Conference. St. Petersburg : SUAI university publisher house, 2010.
13. Koblyakova L., Sheynin Y., Raszhivin D. Real-time signaling in networked embedded systems. International SpaceWire Conference. St. Petersburg : SUAI university publisher house, 2010. Р. 385-388.
14. Tanenbaum A. Computer Networks, Fifth Edition. New Jersey : Prentice Hall, 2011.
15. Stroustrup B. The C++ Programming Language, 4th Edition. USA, Addison-Wesley, 2013.
16. International Telecommunication Union. Recommendation Z.100. Specification and Description Language (SDL). Geneva, 2007.
17. Open SystemC Initiative (OSCI). IEEE 1666™-2011 Standard for SystemC, 2011. Available at: http://www.systemc. org (accessed 09.11.2015).
18. Esperan. Introduction to the SystemC Tutorial. 2005. Available at: http://homepages.cae.wisc.edu/~ece734/SystemC/ Esperan_SystemC_tutorial.pdf (accessed 04.10.2016).
19. Black D., Donovan J., Bunton B., Keist A. SystemC: From the Ground Up. NY : Springer, 2010.
20. Ben Abdallah A., Multicore Systems On-Chip: Practical Software/Hardware Design. Second Edition. Atlantic Press.
21. Star-Dundee website, SpaceWire-USB Brick Mk2. Available at: https://www.star-dundee.com/products/spacewire-usb-brick-mk2 (accessed 04.10.2016).
22. Qt website. Available at: http://www.qt.io (accessed 04.10.2016).
23. Olenev V., Podgornova E., Lavrovskaya I., Korobkov I., Matveeva N. Development of the transport layer scheduling mechanism for the оЛоаМ SрасеWirе networks. Proceedings of 16th Conference of Open Innovations Association Finnish-Russian University Cooperation in Telecommunications (FRUCT) Program. Oulu : University of Oulu, 2014. Р. 164-170.
