Исследование стандарта SpaceFibre при применении технологии виртуального прототипирования

Автор: Коробков Илья Леонидович, Суворова Елена Александровна, Матвеева Надежда Александровна, Шейнин Юрий Евгеньевич

Журнал: Известия Самарского научного центра Российской академии наук @izvestiya-ssc

Рубрика: Информатика, вычислительная техника и управление

Статья в выпуске: 1-2 т.18, 2016 года.

Бесплатный доступ

Статья посвящена актуальной задаче анализа эффективности применения стандарта SpaceFibre, а именно, механизмов обеспечения качества сервиса для передачи потоковых данных в бортовых вычислительных сетях, имеющих жесткие требования ко времени их доставки, что является критичным для жизнеспособности бортовых систем. Была разработана модель прототипа системы-на-кристалле (СнК) функционирующей с применением стандарта SpaceFibre - сетевого контроллера памяти - при помощи языков программирования, методологии и инструментов системного проектирования и виртуального прототипирования. Это такие языки как TLM 2.0 и SystemC, OVP технология и программные инструменты Virtual System Platform (VSP), предоставляемые компанией Cadence. Использование представленных средств позволило выполнить имитационное моделирование и провести анализ производительности контроллера. Полученные результаты помогли найти ограничения рассматриваемой архитектуры СнК. Программные утилиты Cadence и Imperas позволили сократить время проектирования. Использование представленных методологий помогло разработать и отладить тесты и встроенное программное обеспечение разрабатываемой СнК до выпуска изделия с фабрики.

Еще

Проектирование снк, виртуальное прототипирование

Короткий адрес: https://sciup.org/148204402

IDR: 148204402

Текст научной статьи Исследование стандарта SpaceFibre при применении технологии виртуального прототипирования

технологий.

SystemC – это библиотека, представляющая собой расширение языка C++, разработанное для моделирования аппаратуры и программного обеспечения с использованием единого языка. В литературе встречается упоминание SystemC в качестве языка моделирования [3].

Transaction Level Modelling (TLM-2.0) – моделирование на уровне транзакций – стандарт (версия 2.0), позволяющий моделировать процессы на уровне транзакций [4]. TLM разработан на основе библиотеки SystemC и предоставляет множество SystemC модулей (т.е. C++ классов). В каждом модуле можно объявить и использовать один или более сокетов, с помощью которых модули SystemC могут осуществлять операции чтения и записи данных между собой. На TLM может быть описана модель какого-либо устройства, поведение которой соответствует функционированию такого устройства. Такая модель обычно состоит, в свою очередь, из двух моделей – функциональной и интерфейсной модели. Функциональная модель воплощает в себе полный набор поддерживаемых компонентом специальных функций – задач, которые устройство должно выполнять. Интерфейсная модель состоит из множества функций, объявленных в терминах операций над транзакциями, которые способствуют взаимодействию с TLM. Поведение каждого модуля обеспечивается за счет параллельных потоков. Поток – это функция C++ класса, которая взаимодействует с другими потоками в других модулях через передачу данных (чтения или записи) по сокетам. Эта связь именуется «транзакцией», а передаваемые данные – «полезной нагрузкой».

SystemC и TLM-2.0 могут быть использованы для разработки поведенческих имитационных моделей. Эти стандарты широко используются в программном обеспечении (ПО) VSP компании Cadence [5]. ПО VSP Cadence позволяет создавать виртуальные прототипы будущих вычислительных устройств – виртуальные платформы, которые могут состоять из процессоров, блоков памяти, коммутаторов/маршрутизаторов, шин и периферийных блоков, блоков, написанных на TLM-2.0 [5]. Также VSP предоставляет средства для отладки и анализа характеристик производительности системы, позволяющие проверить выполнение требований, предъявляемых к системе. Разработчик может подключить и использовать собственные модели блоков, блоки Fast Models компании ARM или каталог моделей компании Imperas [6]. Когда все компоненты определены, проектировщик системы должен объединить все блоки в одну подсистему или виртуальную платформу, затем следует выполнить отладку виртуальной платформы.

С применением выше описанных технологий была разработана модель СнК – сетевой контроллер памяти, функционирующий с применением стандарта SpaceFibre – для проведения оценки эффективности механизмов обеспечения качества сервиса SpaceFibre для передачи потоковых данных. Архитектура СнК приведена далее.

Архитектура СнК. Архитектура сетевого контроллера памяти (СКП) с встроенным процессором и коммутатором приведена на рРис. 1. СКП состоит из RISC ядра MIPS32, памяти, внешних входных и выходных портов. Порты функционируют в соответствии со стандартом SpaceFibre для бортовых систем космических аппаратов. СКП должен обеспечивать чтение данных от удаленных устройств и их запись в память. Также он поддерживает чтение данных из памяти в соответствии с запросами, принимаемыми от удаленных устройств. Обмен данными между сетевыми устройствами и СКП обеспечивается с помощью протокола Remote Memory Access Protocol (RMAP).Модель системного уровня СКП и последующие исследования велись с использованием программного обеспечения Cadence и Imperas. Модель СКП реализована с использованием TLM-2.0 с высокоуровневым подходом к моделированию цифровых систем, где информация о коммуникации между модулями отделена от деталей реализации функциональных единиц или коммуникационной архитектуры.

Отметим, что стандарт TLM-2.0 поддерживает несколько стилей программирования: Loosely-timed (LT) и Approximately-timed (AT). Cтиль LT использует блокирующий транспортный интерфейс, в котором каждая транзакция имеет две временные точки, обозначающих начало и конец транзакции. В свою очередь, стиль AT использует неблокирующий транспортный интерфейс. Для неблокирующего транспортного интерфейса каждая транзакция характеризуется множеством временных точек. Транзакция делится на несколько фаз с временными точками, отмечающими переход между фазами. Стиль LT поддерживает моделирование таймеров и прерываний, прямой доступ к памяти Direct memory interface (DMI). Стиль AT не поддерживает DMI. Стиль программирования Loosely-timed подходит к применению в случаях разработки программного обеспечения с использованием виртуальной мультипроцессорной платформы. Программное обеспечение может включать в себя операционные системы. Стиль программирования Approximately-timed подходит для случаев оценки архитектуры и анализа производительности [5]. В общем случае, время выполнения моделирования для LT моделей меньше, чем для AT моделей. Таким образом, при разработке СКП был выбран стиль программирования LT.

Для моделирования процессорного ядра использовалась модель процессора, поставляемого в рамках технологии Open Virtual Platform (OVP) компании Imperas [6]. В OVP входит библиотека моделей процессоров и различных периферийных блоков (память, шина, т.д.). Они предназначены для упрощения процесса моделирования многоядерных гетерогенных или гомогенных вычислительных платформ со сложной иерархией памяти и кэша. Технология OVP позволяет запустить модель процессора со скоростью более 100 миллионов операция в секунду. Функционирование моделей OVP осуществляется точностью до инструкций, но не до циклов.

Рис. 1. Структура Сетевого контроллера памяти

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

Генератор интерфейсов TLM Cadence. Программная утилита генерации интерфейсов TLM Cadence – tlmgen – использовалась для генерации множества шаблонов TLM модулей, описывающих блоки с регистрами. Входной формат данных для tlmgen может быть представлен в форме текстового файла, написанного в формате simple register definition language (simpleRDL). Достоинством данной утилиты является то, что правила её использования просты и понятны. Разработчик блоков может описать регистры вместе с их полями, и банком регистров. Пример входного файла в формате simpleRDL представлен на рис. 2 и представляет собой описание регистров и их полей. Рис. 2 представляет собой описание банка регистров и их адресное пространство. Утилита tlmgen упрощает создание пользовательских блоков в соответствии со стандартом TLM 2.0.

Пример модуля TLM – блок DMA – представлен на рис. 3. Использование tlmgen позволяет уменьшить время проектирования СнК, помогает избежать широко таких широко распространённых ошибок, как несоответствие имен регистров, перекрытие регистров, незаконный доступ к регистрам со стороны программ- ного обеспечения. Однако генератор TLM поддерживает только один target-сокет на одно устройство.

REG aOiRERSJZEJU I

/• Register description •/ access ■ ж?

REGWIDTH • 32;

RESET • 0x0000;

HELD ( ACCESS - «; ) DKA_AREA_SIZE_R4 (31:0]

REG SpF_PORT_MOX_VC_FARAMS {

/• Register description •/

ACCESS - »;

REGWIDTH - 32;

RESET - 0x0000;

FIELD ( ACCESS - $»; ) VC_LNUM (7:0];

FIELD ( ACCESS • Qf; ) VC_THROUGHPCT [15:8];

FIELD ( ACCESS • «; ) VC_PRIORITY [18:18];

FIELD ( ACCESS - q$; ) VC_WCRK_E2i [19:19];

HELD ( ACCESS - «; ) CREDIT_OVERfLOW (20:20]

HELD ( ACCESS • Qf: ) DATA_OVERFLOW [21:21];

Рис. 2. Описание некоторых регистров блока «DMA»

Анализ производительности СнК при помощи VSP Cadence. ПО VSP Cadence предоставляет аналитическую информацию на различных уровнях. На первом уровне представляется статическая информация.

Статическая информация о проекте формируется на этапе сборки проекта: количество объектов каждого типа, таких как sc_modules, tlm2_initiator_sockets, tlm2_target_sockets и др. На втором уровне представляется динамическая информация. Она содержит информацию, которая формируется в процессе моделирования и может быть использована для оценки узких мест с точки зрения производительности системы, настройки проекта для увеличения производительности моделирования. Информация о моделировании, такая как версия симулятора, использование ресурсов памяти и процессора выводится в самом начале. Информация, содержащаяся в профилированном файле отражает итоговое количество выполнений функций SystemC, т.е. в одной линии содержится информация в процентном соотношении и количестве порождений процесса (см. рис. 4). Пользователь Virtual System Platform получает информацию о моделировании проекта во время моделирования. Разработчик может использовать различные типы графиков, которые помогают анализировать какой объем данных был передан между сокетами и какое распределение переданных данных было между сокетами (см. рис. 5).

Рис. 3. Схема модели блока «DMA»

Рис. 4. Временное распределение между процессами

Результаты моделирования портов SpaceFibre. ПО VSP Cadence использовалось для оценки эффективности стандарта SpaceFibre для передачи потоковых данных оценивалась производительность портов SpaceFibre, являющиеся частью СКП (см. рис. 6). Необходимо отметить, что под эффективностью понимается то, что механизмы качества сервиса SpaceFibre позволяют доставлять чувствительные к задержкам потоковые данные с допустимыми для них задержками. Генераторы трафиков Traffic generators отвечали за генерацию различных потоковых трафиков: потоковая трансляция видео, аудио, сенсорные данные и др. (см. табл. 1).

Рис. 5. Графики с требуемыми параметрами

Использовались следующие параметры СКП: количество портов – 2; скорость SpaceFibre канала связи – 1.25 Гбит/сек; время моделирования – 500 мс. Потоковые трафики передавались через порты #1 и #2. Применялся механизм обеспечения качества сервиса «Приоритеты» стандарта SpaceFibre, поскольку к передаче трафиков предъявляются различные требования по задержкам. Наивысший приоритет равен 0, наименьший – 15. Детали конфигурации портов SpaceFibre представлены в табл. 2. Стоит отметить, что порт SpaceFibre состоит из виртуальных каналов (далее в тексте – VC, virtual channel), по которым осуществляется передача данных согласно стандарту SpaceFibre.

Рис. 6. Общая схема потоков данных при тестировании производительности SpaceFibre портов

Таблица 1. Параметры потоковых трафиков

Наименование трафика

Описание

Размер пакета, байты

Интенсивность поступления пакетов, пакет/мс

Допустимая задержка, мс

видео

потоковое интерактивное видео, крайне чувствительное к задержкам; SVGA 800*600; 60Гц; глубина цвета 24 бит [7]

1,42М

0,06

< 16,7

аудио

аудио коммуникация; Kodec G.711; 64Кбит/сек [8]

160

0,05

< 100

сенсорный

данные с датчиков (сенсоров) целовой бортовой аппаратуры КА [9]

50

< 5

управляющий

данные от управляющей аппаратуры КА, крайне чувсвтительные к задержкам и потерям данные [9]

260

0,02

< 0,1

фоновый

фоновый трафик

1K or 4K

25

не норм.

Таблица 2. Конфигурация портов SpaceFibre

Порт

Виртуальный канал

Трафик

Параметры SpaceFibre

при-ори-теты

Expected Bandwidth

Percentage [2]

1

VC 1

сенсорный

1

0,032768

1

VC 2

управляющий

0

0,0003328

1

VC 3

фоновый

3

0,16384

2

VC 4

аудио

2

0.0000512

2

VC 5

видео

1

0,55296

Когда порты исследуемого СКП были доступны для передачи данных, все трафики успешно передавались через два порта с допустимыми задержками. Задержка доставки видеокадров составляла ~11,4 мс. В случае, когда порт #2 был не доступен для передачи данных (вследствие сетевой перегрузки на порту #2), все данные передaвались через порт #1. Сенсорные данные были доставлены с недопустимой задержкой (рис. 7). Это происходило постоянно с периодом ~16,68 мс из-за того, что канал был занят передачей видеокадров по VC5, имеющего такой же приоритет, как и VC1. Другие данные были переданы с допустимой для них задержкой.

Рис. 7. Передача сенсорных данных с недопустимой задержкой

Такая ситуация может быть неприемлемой для бортовых систем КА. Нами были выявлены следующие причины доставки пакетов с недопустимой задержкой: 1. Возможна монополизация канала связи передачей данных по высокоприоритетным виртуальным каналам. Это происходит при следующих условиях:

  •    имеется 1 или более высокоприоритетный виртуальный канал;

  •    в буфере отправки высокоприоритетного канала всегда присутствуют данные для отправки;

  •    всегда есть свободное пространство в буфере приема высокоприоритетного канала на стороне получателя;

  •    время считывания полученных данных (длиной 256 N-Char или меньшей длины, но, в этом случае, данные должны быть ограничены символами EOP или EEP) из буфера приема и доставки управляющего слова FCT (кредита) до узла отправителя должно быть меньше времени доставки очередного кадра данных со стороны отправителя;

  •    предел кредита пропускной способности (Bandwidth Credit Limit) не был превышен передачей данных по высокоприоритетному каналу.

  • 2. В соответствии с правилами механизма Medium Access Control (MAC) стандарта SpaceFibre [2] виртуальные

  • 16.7 мс

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

Для решения данной проблемы предлагается использовать механизм «Планирования» стандарта SpaceFibre в дополнение к механизму «Приоритеты». Механизм «Планирование» позволяет сделать распределение ресурсов сети SpaceFibre полностью детерминированным. Это достигается тем, что время разделено на последовательности временных интервалов (тайм-слоты), во время которых виртуальный канал может быть запланирован на отправку данных. Если виртуальный канал запланирован на отправку в текущий тайм-слот, но у него нет данных для отправки или нет места в его входном буфере виртуального канала на удаленном конце соединения, другим виртуальным каналам, которым разрешено осуществлять передачу в текущий временной интервал, разрешено использовать неиспользуемую пропускную способность [2]. Все трафики были распределены между тайм-слотами. Для этого использовались все доступные для планирования тайм-слоты – 256. На рис. 8 продемонстрирован пример распределения видеокадров по тайм-слотам.

Видеокадр 1

Видеокадр 2

Слоты для передачи        Слоты для видеокадров          др.трафиков

Рис. 8. Пример применения механизма «Планирования» для передачи потокового видео

Время

Необходимо отметить, что передача управляющего трафика была запланирована на все таймслоты, потому что управляющий трафик – это критически важные данные для выполнения миссии КА (имеет наивысший приоритет в порту SpaceFibre) и данные такого трафика должны быть переданы как можно скорее. Расписание тайм-слотов было построено лишь с учетом допустимых задержек. В результате, механизм «Планирование» SpaceFibre обеспечил детерминизм в доставке данных: потоковые сенсорные данные были доставлены с допустимыми задержками <5 ms (рис. 9). Однако у механизма «Планирования» есть недостаток – простой канала связи SpaceFibre при передаче данных по виртуальному каналу (рис. 10). Это произошло поскольку суммарная длительность выделенных для передачи данных тайм-слотов превышала необходимое время для передачи видеокадра. Решением данной проблемы может быть планирование на неполностью загруженный тайм-слот передачи данных следующего по расписанию виртуального канала (рис. 11) – метод уплотнения расписания. Данный подход гарантированно решит эту проблему только в том, случае, если будет использоваться качество сервиса «Приоритеты» и у следующего виртуального канала приоритет будет ниже, чем у предыдущего канала. Иначе, виртуальные каналы будут соревноваться за право передавать данные в этот тайм-слот согласно спецификации SpaceFibre. В результате, возможна ситуация, представленная на рис. 12, когда видеокадр по VC1 будет передан с недопустимой задержкой из-за того, что VC5 было разрешено передавать сенсорные данные в тайм-слоте №186. Это приведет к тому, что видеокадры будет передан с недопустимой задержкой.

Latency, ms

Рис. 9. Механизм «Планирования» позволил организовать передачу сенсорных данных с допустимыми задержками

Размер видеокадра Время простоя

Потоковое видео

Стал 1821 Спя 1831 Спо 184 | Огл 1861 Слеп 186

Слоты, выделенные для передачи видеокадра по VC 5

Сенсорные данные 1

Сенсорные данные 2

Спот 1871 Слот 188

СлоП89|аюИ9О

Время

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

Рис. 11. Планирование передачи данных двух трафиков в одном тайм-слоте

Рис. 12. Пример неправильного планирования передачи видеокадров

Количество приоритетов в стандарте SpaceFibre также ограничено и равно 16. Следовательно, использование всех 16 приоритетов при передаче данных по расписанию приведет к тому, что для каждого виртуального канала c приоритетом 15 на последний таймслот нельзя запланировать передачу данных по следующему каналу, поскольку приоритет 15 является наименьшим из всех возможных. Кроме того, количество доступных для планирования тайм-слотов также ограничено и равно 256. В итоге, использование механизма качества сервиса «Приоритеты» и «Планирование» не может полностью решить проблему простаивания канала связи SpaceFibre при передаче чувствительных к задержкам данных по расписанию.

Одним из способов разрешения данных ограничений является применение метода адаптивного управления механизмами обеспечения качества сервиса (Adaptive Data Streaming Service, ADSS), впервые опубликованного в [10], по отношению к механизмам качества сервиса стандарта SpaceFibre. Например, ADSS может динамически изменять приоритеты виртуальных каналов (подход динамического изменения приоритетов). Это позволит избежать ограничения на количество используемых приоритетов при уплотнении расписания планирования. Другой возможный подход – динамически изменять значение времени в механизме «Планирования» (подход динамических тайм-слотов). Значение времени определяет текущий номер тайм-слота. Если ADSS изменит значение времени и спустя некоторое время вернет исходное значение, ограничение на количество доступных для планирования тайм-слотов будет снято, что приведет к возможности планирования передачи данных на большее количество тайм-слотов, чем 256. Таким образом, проблема простаивания канала связи может быть решена.

ПО VSP Cadence применялось для моделирования механизмов качества сервиса «Планирования» и «Приоритеты» стандарта SpaceFibre (Scheduled + Priority QoS, SPQ) и механизмов сервиса ADSS (динамические приоритеты (dynamic priorities, DP) и динамические тайм-слоты (dynamic time-slots, DT)) для передачи сенсорного трафика. Параметры потоковых трафиков были те же (см. табл. 1). Применение динамических тайм-слотов позволило увеличить количество доступных для планирования тайм-слотов с 256 до 512. Был подсчитан объем переданных сенсорных данных по виртуальному каналу. Затем мы сравнили полученный результат с планируемой передачей данных (рис. 13).

Рис. 13. Сравнение объемов переданных и запланированных для передачи сенсорных данных при использовании различных методов планирования при старых значениях параметров сенсорного трафика

Из рис. 13 явно видно, что применение методов ADSS позволило увеличить объем переданных данных на 2,7% по отношению к методу SPQ. При этом значительное количество сенсорных данных не было передано, поскольку расписание тайм-слотов было построено лишь с учетом допустимых задержек, значения которых были больше периода поступления потоковых данных. В итоге, сенсорные данные отбрасывались при переполнении выходного буфера виртуального канала. Уменьшив интенсивность поступления пакетов до 1.33 пакет/мс и размер пакета – 260 байт, были получены результаты, представленные на рис. 14. Как видно, все запланированные к передаче сенсорные данные были доставлены без потерь – 100%. В результате не было необходимости использовать совместно метод DP и DT. Применение метода ADDS позволило сократить потери на 10,5%. Можно сделать вывод, что метод адаптивного управления механизмами качества сервиса протоколов может успешно применяться для решения проблемы простаивания канала связи SpaceFibre при использовании механизмов «Планирования» и «Приоритеты».

Выводы: проведено исследование эффективности применения стандарта SpaceFibre, а именно, механизмов обеспечения качества сервиса, для передачи потоковых данных в бортовых вычислительных сетях. Исследования проводились при помощи разработанной имитационной модели системы-на-кристалле с поддержкой стандарта SpaceFibre. Модель построена при помощи технология виртуального прототипирования VSP Cadence, библиотек моделирования SystemC/TLM-2.0, OVP. Модель разработана с высокой степенью детализации и включает в себя модели процессора MIPS32 OVP, памяти, порты SpaceFibre и другие контроллеры и блоки, необходимые для корректного функционирования всей модели. Языки SystemC и TLM 2.0 используются для разработки виртуальных платформ при проектировании СнК. OVP предоставляет библиотеки поведенческих моделей процессоров и др. устройств (памяти, шины и т.д.), с помощью кото- рых легко можно собрать мультиядерную гетерогенную систему со сложной иерархичной структурой памяти. ПО Virtual System Platform Cadence предоставляет широкие возможности для моделирования и анализа производительности прототипов СнК.

Были получены важные результаты при исследовании стандарта SpaceFibre:

  • •    исследованы и определены условия возникновения монополизации канала связи SpaceFibre передачей данных по высокоприоритетным виртуальным каналам;

  • •    рассмотрены ограничения масштабируемости сети SpaceFibre. В стандарте SpaceFibre имеются ограничения в механизме «Планирования»: максимальное количество доступных для планирования тайм-слотов равно 256 и все тайм-слоты должны быть одинаковую длительность. В SpaceFibre также ограничивается количество приоритетов виртуальных каналов – их всего

  • 16. Эти ограничения накладывают рамки на масштабируемость сети SpaceFibre;

  • • изучена проблема простаивания канала связи при использовании механизмов «Планирования» и «Приоритеты» стандарта SpaceFibre для передачи требовательных к задержкам длинных сообщений, что ведет к уменьшению объема передаваемых данных и может быть расценено для непереданных чувствительных к задержкам данным, как их потеря. Предложены возможные решения. Применение метода уплотнения расписания совместно с методом адаптивного управления механизмами качества сервиса позволило увеличить объем переданных данных с 2,7% до 10,5% в зависимости от параметров трафика и схемы планирования.

Все полученные результаты могут быть представлены рабочей группе SpaceFibre для внесения изменений и улучшения текущей версии спецификации.

Рис. 14. Сравнение объемов переданных и запланированных для передачи сенсорных данных при использовании различных методов планирования при новых значениях параметров сенсорного трафика

Исследования выполнены при финансовой поддержке Министерства Образования и Науки РФ в рамках гранта RFMEFI57814X0022.

Список литературы Исследование стандарта SpaceFibre при применении технологии виртуального прототипирования

  • Mikrin, K.A. Onboard Control Complexed of Spacecrafts. -Moscow, 2003. 336 р.
  • Parkes, S. SpaceFibre Specification/S. Parkes, A. Ferrer, A. Gonzalez, C. McClements//Draft F3, September 2013.
  • Open SystemC Initiative (OSCI), IEEE 1666™-2011 Standard for SystemC Language Reference Manual, 2011.
  • Open SystemC Initiative (OSCI), TLM-2.0 Language Reference Manual, 2009.
  • Virtual System Platform User Guide, Cadence Design Systems, 2014.
  • Open Virtual Platforms (OVP), Imperas. URL: http://ovpworld.org
  • ARINC Inc., ARINC Specification 818-2 (ARINC 818 Supplement 2), 2013. URL: http://www.arinc818.com/arinc-818-specification.html
  • Олифер, В.Г. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 4-е изд./В.Г. Олифер, Н.А. Олифер. -СПб.: Питер, 2012, 944 с.
  • Grishin, V. D1.1 Consolidated set of Requirements for SpaceWire-RT, Version 2.0./V. Grishin, P. Rastetter, P. Eremeev, A. Lobanov. -2012, 46 p.
  • Korobkov, I. Adaptive Data Streaming Service for Onboard Spacecraft Networks”, in Proceedings of 17th Conference of Open Innovations Association Finnish-Russian University Cooperation in Telecommunications (FRUCT17). P.G. Demidov Yaroslavl State University. -Yaroslavl, 2015. P. 291-298.
Еще
Статья научная