RU2651242C1 - Способ передачи данных - Google Patents
Способ передачи данных Download PDFInfo
- Publication number
- RU2651242C1 RU2651242C1 RU2017120283A RU2017120283A RU2651242C1 RU 2651242 C1 RU2651242 C1 RU 2651242C1 RU 2017120283 A RU2017120283 A RU 2017120283A RU 2017120283 A RU2017120283 A RU 2017120283A RU 2651242 C1 RU2651242 C1 RU 2651242C1
- Authority
- RU
- Russia
- Prior art keywords
- data
- packet
- confirmation
- information
- stp
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000012790 confirmation Methods 0.000 claims abstract description 42
- 239000000872 buffer Substances 0.000 claims abstract description 41
- 230000005540 biological transmission Effects 0.000 claims abstract description 26
- 238000012545 processing Methods 0.000 abstract description 2
- 239000000126 substance Substances 0.000 abstract 1
- 238000012546 transfer Methods 0.000 description 22
- 230000008569 process Effects 0.000 description 12
- 230000007246 mechanism Effects 0.000 description 7
- 238000012360 testing method Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 150000001875 compounds Chemical class 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
- H04L12/4675—Dynamic sharing of VLAN information amongst network nodes
- H04L12/4683—Dynamic sharing of VLAN information amongst network nodes characterized by the protocol used
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Изобретение относится к передаче данных, а именно к протоколам, используемым при передаче и приеме информационных данных. Технический результат – повышение надежности передачи информации. Способ передачи данных, заключающийся в использовании сетевого транспортного протокола (СТП); в обеспечении передачи команд управления, пакетов данных, маркеров времени SpaceWire, кодов прерываний SpaceWire и их подтверждения на все узлы сети; при этом передачу информационных сообщений и команд управления обеспечивают в соответствии с настраиваемыми в зависимости от требований качествами сервиса и перед отправкой каждый информационный пакет записывают в соответствующий по приоритетности логический буфер на передатчике; в обеспечение гарантированной доставки данных каждый пакет хранят в соответствующем буфере на передатчике в течение времени жизни, определяемом таймером, который отсчитывает время, пока пакет с данной информацией актуален для передачи по сети SpaceWire; в случае гарантированной доставки данных обеспечивают подтверждение корректной доставки данных посредством отправки пакетов подтверждения, а также повторную пересылку данных источником в случае отсутствия подтверждения; в случае негарантированной доставки данных не обеспечивают подтверждение корректной доставки данных; при приеме информационного пакета, не требующего подтверждения, данные проверяют и в случае обнаружения ошибки в принятом информационном пакете данные пакета передают на прикладной уровень с уведомлением об ошибке; на приемной стороне СТП все типы информационных пакетов записывают в единый буфер; обеспечивают настройку СТП при помощи конфигурационных параметров, обеспечивают сброс всех настроек СТП, очистку всех буферов СТП и сброс таймеров по специальным командам.
Description
Изобретение относится к способам передачи данных, в частности к протоколам, используемым при передаче и приеме информационных данных.
В настоящее время активно развивается сетевая технология SpaceWire, специально разработанная для космических аппаратов и совмещающая в себе простоту и низкую цену реализации наравне с высокой производительностью и гибкостью архитектуры. Длительное время основной технологией, применяемой в космическом и авиационном электронном оборудовании, была коммуникационная шина MIL-STD 1553. Однако в условиях растущих требований MIL-STD 1553 уже не справляется с поставленными задачами, поскольку ее средняя скорость передачи данных в 1 Мбит/с и шинная топология накладывают серьезные ограничения. Передача данных в бортовых сетях сейчас переходит на стандарт SpaceWire.
Протокол SpaceWire охватывает три нижних уровня модели OSI и не охватывает транспортный уровень. На данный момент существует целый ряд транспортных протоколов, ориентированных на работу в сетях SpaceWire.
Remote Memory Access Protocol
RMAP - протокол удаленного доступа к памяти. Он служит для поддержки широкого ряда приложений SpaceWire, может функционировать параллельно с другими протоколами передачи данных, запущенными поверх SpaceWire.
RMAP может быть использован: для конфигурирования коммутаторов SpaceWire и контроля их состояния (установки их рабочих параметров и записи информации в таблицу маршрутизации); для конфигурирования и считывания состояния узлов сети SpaceWire; для простых модулей SpaceWire без встроенного процессора - установка конфигурационных регистров приложений, чтения статусной информации или записи данных в память устройства; для интеллектуальных модулей SpaceWire - конфигурирование, сбор информации о состоянии, передача данных из памяти и в память или почтовый ящик. Почтовые ящики - это косвенные области памяти, на которые ссылаются с использованием адреса памяти.
Протокол RMAP оперирует понятиями команда, а не пакет, и определяет 3 вида команд: команда записи (команда записи считывает ноль или более байт данных из памяти другого устройства, могут подтверждаться или не подтверждаться узлом назначения при корректном получении), команды чтения (команда чтения считывает один или более байтов данных из указанной области памяти в узле адресата, прочитанные данные возвращаются в ответном пакете), команда чтение-модификация-запись (команда чтения-модификации-записи читает регистр (или память), возвращает его значение и затем записывает новое значение, определенное в команде, в регистр).
Протокол RMAP предоставляет качество сервиса негарантированная доставка в режиме без подтверждений и гарантированную доставку данных в режиме передачи данных с подтверждениями.
Недостатками протокола RMAP являются невозможность контроля информационного потока, проверки данных и повторной отправки данных, отсутствие качества сервиса «с приоритетом», невозможность гибкой конфигурации и передачи данных с установкой соединения.
CCSDS Packet Transfer Protocol
CCSDS РТР - протокол передачи пакетов, который служит для инкапсуляции космических пакетов в SpaceWire пакеты, передачи их от устройства источника к устройству назначения через SpaceWire сеть, извлечения CCSDS пакетов и передачи их приложению. Протокол разработан Международным Консультативным Комитетом по космическим системам передачи данных (Consultative Committee for Space Data Systems, CCSDS).
РТР обеспечивает однонаправленный сервис передачи данных от пользовательского приложения источника к приложению назначения через SpaceWire сеть.
Протокол РТР обладает следующими особенностями: протокол без установки соединения; пользователь может запрашивать передачу данных в любой момент времени; переменная или фиксированная длина пакетов (минимальный размер пакета 7 байт, максимальный - 65542 байт); односторонняя передача данных, без подтверждений; отсутствует повторная пересылка в случае потери данных; не поддерживает периодичность отправки данных; не отвечает за сборку пакета и его проверку на корректность (за это отвечает пользовательское приложение).
Недостатком протокола CCSDS РТР является то, что он предназначен для инкапсуляции космических пакетов в SpaceWire-пакеты для их передачи в сеть и их извлечения для передачи приложению, но не предоставляет каких-либо механизмов, гарантирующих качество сервиса.
Serial Transfer Universal Protocol
STUP - универсальный протокол последовательной передачи данных, который служит для организации передачи данных в сети SpaceWire. Ключевой особенностью STUP является его простота реализации.
Протокол STUP обладает следующими особенностями: протокол без установки соединения; определяет всего 2 вида команд: запись и чтение.
В командах протокола STUP предусмотрены поля для контрольной суммы, которые можно использовать для проверки корректности пришедшей команды.
Недостатком протокола STUP является то, что он не предоставляет каких-либо механизмов, гарантирующих качество сервиса.
Joint Architecture Standard Reliable Data Delivery Protocol
JRDDP - протокол надежной доставки данных, который служит для обеспечения сервиса надежной доставки данных к одному или многим высокоуровневым хост приложения, используя для этого канальный уровень SpaceWire.
Протокол JRDDP обладает следующими особенностями: протокол с установлением соединения; поддерживает множественные логические соединения; обеспечивает надежную доставку данных; обнаруживает потерянные, повторяющиеся пакеты; упорядочивает пакеты, пришедшие не по порядку; выполняет фрагментацию и повторную сборку пакетов.
Протокол JRDDP определяет следующие типы пакетов: данные приложения; подтверждение; открытие и реинициализация соединения; закрытие соединения; срочный пакет данных.
JRDDP протокол поддерживает качество сервиса с приоритетами и негарантированная доставка данных.
В спецификации протокола JRDDP определены следующие приоритеты отправки пакетов:
- пакеты подтверждения (отправляются в первую очередь);
- управляющие пакеты;
- срочные пакеты;
- повторно передаваемые пакеты;
- пакеты данных (отправляются последними).
Качество сервиса «Негарантированная доставка данных» используется (опционально) для доставки срочных сообщений, таких как широковещательные, сообщения с исключениями/контролем ошибок, метасообщения и др.
Для обнаружения ошибок и отказоустойчивости в пакетах протокола JRDDP предусмотрено CRC-поле, а также поле с порядковым номером пакета (размер поля 8 бит), отправка подтверждений об успешном получении пакетов. Более того, протокол JRDDP использует таймауты для обнаружения потерянных или повторяющихся пакетов.
Недостатком протокола JRDDP является отсутствие гибкости при конфигурировании.
Streaming Transport Protocol
STP - транспортный протокол потоковой передачи данных в сетях SpaceWire, в котором предусматривается также поддержка одновременной передачи множества когерентных информационных потоков.
Протокол STP ориентирован на асимметричную организацию транспортного соединения, с одной стороны которого находится ведущее устройство (хост, мастер) транспортного соединения, а с другой стороны - ведомое устройство. Инициатором организации сеанса обмена является ведущее устройство, которое осуществляет управление установкой соединения, настройкой его параметров и потоком пакетов-данных.
Протокол STP обладает следующими особенностями:
- протокол с установлением соединения;
- безопасное соединение (трехэтапное квитирование);
- ассиметричность (передача данных идет от ведомого устройства к ведущему);
- поддержка многопоточности (до 65535 отдельных соединений);
- порции данных фиксированной длины;
- периодическая через заданный интервал передача данных (по установленным параметрам на протяжении всего соединения);
- доставка данных без подтверждений, без повторной посылки;
- управление потоком данных.
Протокол STP оперирует понятиями пакет данных и команды.
Протокол STP разработан для передачи потоковых данных в сети SpaceWire. Устройство-получатель согласно спецификации STP не отправляет подтверждений о получении данных, тем самым обеспечивая качество сервиса с негарантированной доставкой данных.
В протоколе STP также предусмотрен механизм остановки/разрешения передачи данных по конкретному соединению, частоту отправки пакетов данных, что позволяет управлять потоком.
Недостатками протокола STP являются отсутствие гибкости при конфигурировании, качества сервиса «с приоритетом», подтверждений о получении данных, невозможность проверки и повторной отправки данных.
Задачей изобретения является разработка способа передачи информации, обеспечивающего надежность доставки, гибкость при конфигурировании.
Поставленная задача изобретения решается тем, что создают способ передачи данных с использованием сетевого транспортного протокола (СТП), реализованного программно и аппаратно в виде IP-блока; обеспечивают передачу команд управления, пакетов данных, маркеров времени SpaceWire, кодов прерываний SpaceWire и их подтверждения на все узлы сети; при этом передачу информационных сообщений и команд управления обеспечивают в соответствии с настраиваемыми в зависимости от требований качествами сервиса и перед отправкой каждый информационный пакет записывают в соответствующий по приоритетности логический буфер на передатчике; в обеспечение гарантированной доставки данных каждый пакет хранят в соответствующем буфере на передатчике в течение времени жизни, определяемом таймером, который отсчитывает время, пока пакет с данной информацией актуален для передачи по сети SpaceWire; в случае гарантированной доставки данных обеспечивают подтверждение корректной доставки данных посредством отправки пакетов подтверждения, а также повторную пересылку данных источником в случае отсутствия подтверждения; в случае негарантированной доставки данных не обеспечивают подтверждение корректной доставки данных; при приеме информационного пакета, не требующего подтверждения, данные проверяют и в случае обнаружения ошибки в принятом информационном пакете данные пакета передают на прикладной уровень с уведомлением об ошибке; на приемной стороне СТП все типы информационных пакетов записывают в единый буфер; обеспечивают настройку СТП при помощи конфигурационных параметров, обеспечивают сброс всех настроек СТП, очистку всех буферов СТП и сброс таймеров по специальным командам.
В сетевом транспортном протоколе для взаимодействия с прикладными процессами предусмотрены три интерфейса: интерфейс данных, конфигурационный интерфейс и интерфейс системных кодов. Через вышеописанные интерфейсы СТП обеспечивает передачу следующих основных типов данных:
- команды управления;
- пакеты данных;
- маркеры времени SpaceWire;
- коды прерываний SpaceWire и их подтверждения.
Через интерфейс данных передаются пакеты данных и команды управления. Сообщения прикладных процессов и команды управления на удаленные узлы передаются в пакетах SpaceWire. Конфигурационный интерфейс служит для смены значений конфигурационных параметров СТП, передачи статусной информации и команд сброса. В свою очередь, интерфейс системных кодов отвечает за распространение маркеров системного времени и системных прерываний во все узлы сети посредством технологии SpaceWire. Для взаимодействия со SpaceWire - два интерфейса: интерфейс пакетов SpaceWire и интерфейс системных кодов.
Одна из основных задач транспортного протокола СТП - это обеспечение транспортировки сообщений прикладных процессов на удаленные узлы сети. Сообщение прикладного процесса - это блок данных, поступающий в СТП от протокола прикладного уровня. Они разделяются по типу в соответствии с их приоритетом:
- срочные сообщения - высокоприоритетные;
- обычные сообщения - низкоприоритетные.
Блок данных СТП имеет ограниченную длину. Размер каждого сообщения прикладного процесса не должен превышать 2048 байт. Функция сегментации сообщений выполняется прикладным уровнем. Для этих целей вводится вторичный заголовок пакета СТП, в котором прикладной процесс может передавать информацию, необходимую для сборки сообщений из сегментов.
СТП обеспечивает надежную передачу данных посредством защиты передаваемых данных и заголовка пакета контрольной суммой CRC-16, проверяемой на приемнике. CRC-16 покрывает поле заголовка пакета и поле данных, начиная с первого байта пакета и заканчивая последним байтом данных, не включая символ конца пакета ЕОР.
В протоколе СТП предусмотрен механизм таймера времени жизни пакетов, который отсчитывает время, пока пакет с данной информацией актуален для передачи по сети SpaceWire. Каждый пакет хранится в соответствующем буфере на передатчике в течение времени жизни, которое для него определено. Величина таймера времени жизни пакета является конфигурационным параметром протокола СТП и может задаваться на этапе конфигурации. При этом каждому типу пакетов (пакет команды управления, срочного сообщения, обычного сообщения) соответствует отдельная величина таймера времени жизни. Таймер времени жизни взводится в момент записи пакета в буфер, а по истечении времени таймера соответствующий ему пакет из буфера удаляется.
На передающей стороне транспортного протокола предусмотрен отдельный логический буфер на каждый из приоритетов передаваемых данных:
- буфер команд управления;
- буфер срочных сообщений;
- буфер обычных сообщений.
Размеры этих буферов задаются в соответствии с размером сообщения, которое будет использовать сетевой узел для обмена с другими узлами, а также в соответствии с типом устройства, работающего по протоколу СТП. Однако, для каждого из буферов (на приемной или передающей части) рекомендуется задавать размер таким образом, чтобы он вмещал как минимум два пакета данных. Поле данных в пакете не должно быть пустым. Если такое происходит, то СТП должен отправить приложению уведомление о том, что пакет не отправлен. Пакет в буфере должен храниться до возникновения одного из следующих событий:
- получение пакета подтверждения на пакет, отправленный с гарантированным качеством сервиса;
- отправка пакета в сеть при негарантированной доставке данных;
- срабатывание таймера времени жизни данного пакета;
- команда reset или flush.
Если происходит переполнение буфера, то приложение должно ждать, пока появится свободное место для очередного сообщения.
На приемной стороне транспортного протокола предусмотрен единый буфер на все типы информационных потоков. Буфер должен иметь возможность хранить минимум два пакета.
Если приемный буфер переполнен, то СТП должен сгенерировать сообщение для уровня приложений.
Одним из преимуществ передачи данных предлагаемым способом является обеспечение передачи сообщений и команд управления со следующими типами качества сервиса:
- Качество сервиса «С приоритетом»;
- Качество сервиса «Гарантированная доставка данных»;
- Качество сервиса «Негарантированная доставка данных».
Тип качества сервиса «С приоритетом» является основным и должен поддерживаться всеми устройствами, на которых реализован транспортный протокол СТП. Согласно данному типу качества сервиса данные с более высоким приоритетом должны быть переданы первыми. СТП поддерживает 7 уровней приоритетов:
1. Пакеты подтверждения;
2. Пакеты команд управления;
3. Повторные пакеты команд управления;
4. Пакеты срочных сообщений;
5. Повторные пакеты срочных сообщений;
6. Повторные пакеты обычных сообщений;
7. Пакеты обычных данных.
СТП анализирует передачу пакетов во время арбитрирования. Пакет содержит специальный флаг «Типа Пакета» и признак повторной отправки пакета. В зависимости от этого, СТП делает вывод, какой пакет должен быть отправлен первым. Арбитрирование следующего пакета происходит только после отправки текущего.
Тип качества сервиса «Гарантированная доставка данных» обеспечивает подтверждение корректной доставки данных посредством отправки пакетов подтверждения, а также повторную пересылку данных источником в случае отсутствия подтверждения. Повторная отправка осуществляется на основе нумерации пакетов, которая осуществляется на прикладном уровне. Таким образом, комбинация идентификатора приложения и номера передаваемого сообщения однозначно идентифицирует каждый пакет. Для реализации качества сервиса «Гарантированная доставка данных» при отправке данных на сетевой уровень должен быть взведен таймер повтора. Он определяет временной интервал, по истечении которого считается, что пакет не был доставлен до адресата корректно либо был потерян пакет подтверждения. По истечению таймера повтора пакет, соответствующий данному таймеру, повторно отправляется адресату. Для того чтобы уведомить отправителя о корректном приеме пакета, используются пакеты подтверждения. Они отправляются, если:
- отсутствует ошибка CRC,
- длина поля данных корректна,
- в заголовке пакета выставлен флаг «Требование подтверждения приема», определяющий для данного пакета качество сервиса «Гарантированная доставка данных».
При приеме пакета подтверждения пакет, соответствующий принятому номеру, должен быть удален из буфера повтора передатчика. Все таймеры, ассоциированные с номером этого пакета, должны быть остановлены и удалены.
Тип качества сервиса «Негарантированная доставка данных» обеспечивает передачу данных без подтверждений приема. Такие пакеты содержат в заголовке бит ‘Требование подтверждения приема’, установленный в 0 и для них не взводится таймер повтора. При приеме информационного пакета, не требующего подтверждения, приемник также проверяет CRC и корректность длины поля данных, но в случае обнаружения ошибки в принятом информационном пакете и в случае, если пакет был завершен символом ЕЕР, данные пакета все равно должны быть переданы на прикладной уровень с уведомлением об ошибке. Передатчик не хранит такой пакет в буфере, не ждет подтверждения и не пересылает пакет.
Важной особенностью данного способа передачи является гибкость применяемого СТП. Протокол имеет ряд конфигурационных параметров, которые позволяют настраивать протокол в зависимости от требований к качеству предоставляемого сервиса и типа используемой аппаратуры. Конфигурация СТП производится через конфигурационный интерфейс и выполняется в следующих случаях:
- включение устройства;
- перезагрузка устройства;
- переключение комплектов;
- восстановление из аварийного состояния.
В первой редакции протокола СТП определено 5 конфигурационных параметров:
1. Время жизни пакета команды управления;
2. Время жизни пакета срочного сообщения;
3. Время жизни пакета обычного сообщения;
4. Таймаут повтора (длительность таймера повтора);
5. Гарантированная или негарантированная доставка данных.
Через конфигурационный интерфейс могут подаваться сигналы Reset и Flush. Команда Reset соответствует горячему сбросу, в то время как команда Flush используется для очищения буферов приемника и передатчика протокола СТП. По приходу сигнала Reset буферы на передатчике и приемнике транспортного протокола очищаются, все таймеры, связанные с данными в буферах, должны быть сброшены, счетчик порядковых номеров сбрасывается и конфигурационные параметры устанавливаются в значения по умолчанию. Если же в СТП подается команда Flush, то также очищаются буферы и сбрасываются таймеры, но счетчик порядковых номеров и конфигурационные параметры остаются прежними.
Таким образом, реализация способа передачи данных с помощью сетевого транспортного протокола СТП позволит передавать информационные потоки данных, обеспечивая надежность передачи данных, использовать различные типы качества сервиса, гарантированно доставлять данные и обеспечивать гибкость конфигурирования.
Способ осуществляют следующим образом
Сетевой транспортный протокол реализован программно, например, на языках С++ и С и аппаратно в виде IP-блока СТП.
Программная реализация представляет собой программный код, наиболее точно соответствующий спецификации протокола. Он описывает логическую структуру протокола, его интерфейсы и внутренние механизмы протокола. Референс-код содержит подробные комментарии, позволяющие лучше понять алгоритм функционирования СТП. Кроме того, программный код описывает тестовое окружение, которое позволяет запускать определенный набор тестовых сценариев работы протокола, что проверяет функционирование (конфигурация протокола, отправка данных, прием данных) протокола в различных условиях. В результате запуска сценариев генерируются файлы отчетов, содержащие информацию о возникающих в процессе работы протокола событиях. Параллельно в ходе работы тестового сценария ведется сбор статистической информации и фиксирование возникающих событий в системе, результатом которого является файл отчетов. Программный код используется для трансляции в другие языки программирования для создания бортового программного обеспечения, а также для тестирования программных моделей и аппаратных реализаций протокола.
Референс-код протокола СТП состоит из следующих компонент:
- компонент stp_testengine - приложение (тестовое окружение), предназначенное для генерации, приема и проверки тестовых данных;
- компонент stp_reference - протокол СТП, состоящий из передатчика, приемника и менеджера и выполняющий обработку тестовых данных;
- компонент spw_channel - канал SpaceWire, эмулирующий сетевой уровень SpaceWire, предназначенный для передачи поступающих данных на удаленную сторону.
Система состоит из заданного количества узлов. Каждый узел состоит из модели приложения и реализации протокола СТП. Узлы соединены моделью канала SpaceWire.
Система функционирует следующим образом.
При запуске модель приложения начинает генерировать данные, которые поступают в протокол СТП. Затем данные в виде пакетов SpaceWire поступают в канал SpaceWire, который передает их на удаленную сторону. Удаленная сторона принимает данные и выполняет их обработку с последующей передачей приложению. В случае использования гарантированной доставки данных удаленная сторона отправляет пакеты подтверждения об успешном приеме данных.
После инициализации внутренних механизмов (буферы, списки параметров, обработчики событий) выполняется конфигурация протокола. Затем передатчик начинает получать данные от модели приложения: сообщения, команды управления, time-коды. Далее передатчик обрабатывает полученные данные, создает пакеты СТП и выполняет их буферирование. В момент записи очередного пакета СТП в буфер передатчик взводит таймер времени жизни и далее специальный поток выполняет его мониторинг. В процессе арбитража на основе приоритетов передатчик определяет пакет, который должен быть отправлен первым. В случае использования гарантированной доставки данных после отправки пакета в SpaceWire канал выполняется установка таймера повтора с дальнейшим его мониторингом, который выполняет отдельный поток. В процессе функционирования передатчик также принимает запросы о подтверждении и удаляет данные из буферов. По специальному служебному сигналу передатчик завершает свою работу, останавливая потоки мониторинга всех таймеров. После завершения процесса передачи всех данных передатчик выдает накопленную статистику.
Аналогично передатчику в приемнике выполняется инициализация внутренних механизмов (буферы, списки параметров, обработчики событий). Затем приемник начинает принимать данные, проверять их корректность и буферировать. В случае корректности данных выполняется их отправка приложению. В случае необходимости отправки подтверждений приемник отправляет запрос на отправку подтверждения в передатчик. После завершения процесса передачи всех данных, приемник выдает накопленную статистику.
Менеджер принимает запросы на конфигурацию протокола и перенаправляет их в передатчик. Также в процессе работы менеджер принимает запросы на сброс протокола и на очистку буферов и перенаправляет их в передатчик и приемник. В случае переполнения буфера на приемной стороне менеджер принимает специальный примитив, который затем передается приложению.
В случае аппаратной реализации IP-блок СТП - контроллер СТП состоит из следующих основных блоков:
1. Контроллер передачи пакетов преобразует транзакции, которые приходят с уровня приложений в пакетах СТП и отправляет их в порт SpaceWire. Каждый типа пакетов СТП хранится в отдельном буферном блоке.
2. Контроллер приема пакетов принимает пакеты, приходящие из SpaceWire порта и проверяет их корректность. Пакеты подтверждения хранятся в Received АСК FIFO. Корректные обычные пакеты, срочные пакеты и команды управления хранятся в буфере.
3. Контроллер транзакций отправленных пакетов получает транзакции из уровня приложений, преобразует и передает в контроллер передачи пакетов.
4. Контроллер транзакций входящих пакетов преобразует корректные входящие обычные пакеты, срочные пакеты и команды отправления в транзакции для уровня приложений. Текущая реализация поддерживает только один формат транзакций, который соответствует команде записи.
5. Блок арбитрирования запросов выполняет арбитрирование запросов к АНВ контроллеру (master) из контроллера транзакций отправленных пакетов. Арбитрирование производится в соответствии со схемой с динамическими циклическими приоритетами.
6. Блок регистров режима/статуса состоит из массива регистров режима/статуса, контроллера регистра чтения и контроллера регистра записи. Чтение и запись выполняются из АНВ через АНВ контроллер (slave) и из функциональных блоков контроллера СТП.
IP-ядро является конфигурируемым, обеспечивая возможность исключать разные его компоненты.
При реализации сетевого транспортного протокола любым из вышеописанных способов (программно или аппаратно) обеспечивается высоконадежная транспортировка передаваемых данных по линиям связи сети SpaceWire для авиационной и космической отрасли.
Claims (1)
- Способ передачи данных, заключающийся в использовании сетевого транспортного протокола (СТП), реализованного программно и аппаратно в виде IP-блока; в обеспечении передачи команд управления, пакетов данных, маркеров времени SpaceWire, кодов прерываний SpaceWire и их подтверждения на все узлы сети; при этом передачу информационных сообщений и команд управления обеспечивают в соответствии с настраиваемыми в зависимости от требований качествами сервиса и перед отправкой каждый информационный пакет записывают в соответствующий по приоритетности логический буфер на передатчике; в обеспечение гарантированной доставки данных каждый пакет хранят в соответствующем буфере на передатчике в течение времени жизни, определяемом таймером, который отсчитывает время, пока пакет с данной информацией актуален для передачи по сети SpaceWire; в случае гарантированной доставки данных обеспечивают подтверждение корректной доставки данных посредством отправки пакетов подтверждения, а также повторную пересылку данных источником в случае отсутствия подтверждения; в случае негарантированной доставки данных не обеспечивают подтверждение корректной доставки данных; при приеме информационного пакета, не требующего подтверждения, данные проверяют и в случае обнаружения ошибки в принятом информационном пакете данные пакета передают на прикладной уровень с уведомлением об ошибке; на приемной стороне СТП все типы информационных пакетов записывают в единый буфер; обеспечивают настройку СТП при помощи конфигурационных параметров, обеспечивают сброс всех настроек СТП, очистку всех буферов СТП и сброс таймеров по специальным командам.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2017120283A RU2651242C1 (ru) | 2017-06-08 | 2017-06-08 | Способ передачи данных |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| RU2017120283A RU2651242C1 (ru) | 2017-06-08 | 2017-06-08 | Способ передачи данных |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| RU2651242C1 true RU2651242C1 (ru) | 2018-04-18 |
Family
ID=61976869
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| RU2017120283A RU2651242C1 (ru) | 2017-06-08 | 2017-06-08 | Способ передачи данных |
Country Status (1)
| Country | Link |
|---|---|
| RU (1) | RU2651242C1 (ru) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2703231C1 (ru) * | 2018-06-14 | 2019-10-15 | Российская Федерация, от имени которой выступает ФОНД ПЕРСПЕКТИВНЫХ ИССЛЕДОВАНИЙ | Пакетная сеть для мультипроцессорных систем и способ коммутации с использованием такой сети |
| RU2721230C1 (ru) * | 2019-10-16 | 2020-05-18 | Акционерное общество «Информационные спутниковые системы» имени академика М.Ф. Решетнёва» | Контроллер сетевого транспортного протокола |
| RU2758059C1 (ru) * | 2020-04-29 | 2021-10-26 | Акционерное общество «Информационные спутниковые системы» имени академика М.Ф. Решетнёва» | Способ передачи данных |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102624633A (zh) * | 2012-04-06 | 2012-08-01 | 航天东方红卫星有限公司 | 一种基于时间触发的SpaceWire网络通信方法 |
| CN102857295A (zh) * | 2012-06-15 | 2013-01-02 | 上海卫星工程研究所 | 基于虚拟信道的SpaceWire网络传输与处理 |
| RU126162U1 (ru) * | 2012-04-19 | 2013-03-20 | Закрытое акционерное общество Научно-производственный Центр "Микропроцессорные технологии" (ЗАО НПЦ МИТ) | УСТРОЙСТВО КОММУНИКАЦИОННОГО ИНТЕРФЕЙСА ДЛЯ СЕТИ Space Wire |
| RU130101U1 (ru) * | 2012-12-18 | 2013-07-10 | Общество с ограниченной ответственностью "Компекс-Т" | Локальное управляющее устройство автоматизированной резервированной системы управления стендом для испытаний ракетно-космической техники |
-
2017
- 2017-06-08 RU RU2017120283A patent/RU2651242C1/ru active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102624633A (zh) * | 2012-04-06 | 2012-08-01 | 航天东方红卫星有限公司 | 一种基于时间触发的SpaceWire网络通信方法 |
| RU126162U1 (ru) * | 2012-04-19 | 2013-03-20 | Закрытое акционерное общество Научно-производственный Центр "Микропроцессорные технологии" (ЗАО НПЦ МИТ) | УСТРОЙСТВО КОММУНИКАЦИОННОГО ИНТЕРФЕЙСА ДЛЯ СЕТИ Space Wire |
| CN102857295A (zh) * | 2012-06-15 | 2013-01-02 | 上海卫星工程研究所 | 基于虚拟信道的SpaceWire网络传输与处理 |
| RU130101U1 (ru) * | 2012-12-18 | 2013-07-10 | Общество с ограниченной ответственностью "Компекс-Т" | Локальное управляющее устройство автоматизированной резервированной системы управления стендом для испытаний ракетно-космической техники |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2703231C1 (ru) * | 2018-06-14 | 2019-10-15 | Российская Федерация, от имени которой выступает ФОНД ПЕРСПЕКТИВНЫХ ИССЛЕДОВАНИЙ | Пакетная сеть для мультипроцессорных систем и способ коммутации с использованием такой сети |
| RU2721230C1 (ru) * | 2019-10-16 | 2020-05-18 | Акционерное общество «Информационные спутниковые системы» имени академика М.Ф. Решетнёва» | Контроллер сетевого транспортного протокола |
| RU2758059C1 (ru) * | 2020-04-29 | 2021-10-26 | Акционерное общество «Информационные спутниковые системы» имени академика М.Ф. Решетнёва» | Способ передачи данных |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11757763B2 (en) | System and method for facilitating efficient host memory access from a network interface controller (NIC) | |
| US9503383B2 (en) | Flow control for reliable message passing | |
| CN102132535B (zh) | 在通信网中传输数据分组的方法和交换装置 | |
| EP0525985B1 (en) | High speed duplex data link interface | |
| US7653060B2 (en) | System and method for implementing ASI over long distances | |
| RU2651242C1 (ru) | Способ передачи данных | |
| CN103141050B (zh) | 快速通道互联系统中数据包重传方法、节点 | |
| CN104038322A (zh) | 中间节点、通信网络及其数据传输控制方法 | |
| Lavrovskaya et al. | Analysis of the transport protocol requirements for the SpaceWire on-board networks of spacecrafts | |
| JP2008113327A (ja) | ネットワークインターフェース装置 | |
| RU2758059C1 (ru) | Способ передачи данных | |
| US9621487B2 (en) | Method and apparatus for protection switching based on memory control in packet transport system | |
| US20120072520A1 (en) | System and Method for Establishing Reliable Communication in a Connection-Less Environment | |
| US20230403229A1 (en) | System and method for facilitating efficient host memory access from a network interface controller (nic) | |
| Wang et al. | An Optimized RDMA QP Communication Mechanism for Hyperscale AI Infrastructure | |
| CN116056042A (zh) | 一种列车通信方法、交换设备以及存储介质 | |
| Shihab | The Mechanism of Congestion between the Server and Clients in a Local Area Network Solutions | |
| WO2018131550A1 (ja) | コネクション管理ユニット、およびコネクション管理方法 | |
| WO2009138365A1 (en) | Method of communication between a source unit and a destination unit and communication node | |
| JP2002281034A (ja) | 情報転送装置 | |
| Suvorova et al. | SpaceWire control codes in SpaceWire, GigaSpaceWire and SpaceFibre networks | |
| JPH11298525A (ja) | ネットワークノード装置、端末装置及びゲートウェイ装置 |