CC BY
130
УДК 004.051
ИССЛЕДОВАНИЕ СТАНДАРТА SPACEFIBRE ПРИ ПРИМЕНЕНИИ ТЕХНОЛОГИИ ВИРТУАЛЬНОГО ПРОТОТИПИРОВАНИЯ
© 2016 И.Л. Коробков, Е.А. Суворова, Н.А. Матвеева, Ю.Е. Шейнин Санкт-Петербургский государственный университет аэрокосмического приборостроения
Статья поступила в редакцию 25.03.2016
Статья посвящена актуальной задаче анализа эффективности применения стандарта SpaceFibre, а именно, механизмов обеспечения качества сервиса для передачи потоковых данных в бортовых вычислительных сетях, имеющих жесткие требования ко времени их доставки, что является критичным для жизнеспособности бортовых систем. Была разработана модель прототипа системы-на-кристалле (СнК) функционирующей с применением стандарта SpaceFibre - сетевого контроллера памяти - при помощи языков программирования, методологии и инструментов системного проектирования и виртуального прототипирования. Это такие языки как TLM 2.0 и SystemC, OVP технология и программные инструменты Virtual System Platform (VSP), предоставляемые компанией Cadence. Использование представленных средств позволило выполнить имитационное моделирование и провести анализ производительности контроллера. Полученные результаты помогли найти ограничения рассматриваемой архитектуры СнК. Программные утилиты Cadence и Imperas позволили сократить время проектирования. Использование представленных методологий помогло разработать и отладить тесты и встроенное программное обеспечение разрабатываемой СнК до выпуска изделия с фабрики.
Ключевые слова: SystemC, OVP, TLM (Transaction Level Modelirg), проектирование СнК, виртуальное прототипирование, SpaceFibre
В современном бортовом оборудовании летательных и космических аппаратов (КА) используются бортовые вычислительные сети (БВС) на основе таких стандартов передачи данных, как SpaceWire, ARINC-818-2, MIL-STD-1553B и др. БВС играют важную роль для корректного функционирования современных КА и входят в состав бортового комплекса управления (БКУ). К задачам БВС относится следующее: обеспечение взаимодействия со служебными системами, входящим в состав БКУ; организация управляющих и телеметрических интерфейсов с бортовыми системами и целевым оборудованием и др [1]. В данный момент разрабатывается новый стандарт SpaceFibre [2], который предоставляет различные механизмы обеспечения качества сервиса («Планирование», «Приоритеты» и др.), чего лишены другие стандарты. В БВС на основе SpaceFibre, как и в большинстве вычислительных сетей, возможны сетевые перегрузки коммутационного оборудования, возникающие вследствие значительных помех в каналах связи, сбоев в работе коммутаторов и др.
Цель работы: является исследование и анализ эффективности применения механизмов обеспечения качества сервиса стандарта SpaceFibre для передачи потоковых данных при различных сетевых условиях (интенсивность потока данных, пропускная способность каналов и др.).
В данной статье рассматривается применение SystemC/TLM-2.0 и технологии Virtual System Platform (VSP), предоставляемой компанией Cadence, для оценки эффективности применения стандарта SpaceFibre для передачи потоковых данных в бортовых вычислительных сетях. Далее представлено краткое описание использовавшихся для этого языков моделирования и
Коробков Илья Леонидович, младший научный сотрудник. E-mail: [email protected]
Суворова Елена Александровна, кандидат технических наук, заведующая лабораторией систем-на-крис-талле. E-mail: [email protected]
Матвеева Надежда Александровна, инженер. E-mail nadezhda. matveeva@guap. ru
Шейнин Юрий Евгеньевич, доктор технических наук, профессор, заведующий кафедрой Аэрокосмических компьютерных и программных систем. E-mail: [email protected]
технологий.
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). Стиль 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 позволяет уменьшить время проектирования СнК, помогает избежать широко таких широко распространённых ошибок, как несоответствие имен регистров, перекрытие регистров, незаконный доступ к регистрам со стороны программ-
ного обеспечения. Однако генератор ИМ поддерживает только один target-сокет на одно устройство.
кс- аа лгха size_m i
!* its'.?'.*: V
ACCESS ■ ГН?
EECmiTB • 32;
BE5EI ■ JiOOiO!
flELD [ JlC^SS - ra: i- AfXA SIZE_M (31:0];
EES 3pFwrC®I_a(!3EwTC_IlLEJHS j
/' Register description '/
ACCESS - jh;
ШИПИТ! - 32:
SESE7 - OlOOOD;
ПЕ1Э [ ACCESS - Щ J VC_LHOH [T:G]i
1Ш [ ACCESS - JB f VC_TEa-34GJ!?aT [IS:S];
FIELD [ ACCE55 - ¡y i vc_PRiOEiTi [1S:1H:
FIELD [ ACCESS - fji 1 TCJKHLPf [14:19];
FIDO [ ACCESS - J OBtajnORM (20:2«;
FIELI1 [ ACCESS - И 1 J ИШОТШЪМ 121:21];
Рис. 2. Описание некоторых регистров блока «DMA»
Анализ производительности СнК при помощи VSP Cadence. ПО VSP Cadence предоставляет аналитическую информацию на различных уровнях. На первом уровне представляется статическая информация.
Статическая информация о проекте формируется на этапе сборки проекта: количество объектов каждого типа, таких как sc_modules, tlm2_initiator_sockets, tlm2_target_sockets и др. На втором уровне представляется динамическая информация. Она содержит информацию, которая формируется в процессе моделирования и может быть использована для оценки узких мест с точки зрения производительности системы, настройки проекта для увеличения производительности моделирования. Информация о моделировании, такая как версия симулятора, использование ресурсов памяти и процессора выводится в самом начале. Информация, содержащаяся в профилированном файле отражает итоговое количество выполнений функций SystemC, т.е. в одной линии содержится информация в процентном соотношении и количестве порождений процесса (см. рис. 4). Пользователь Virtual System Platform получает информацию о моделировании проекта во время моделирования. Разработчик может использовать различные типы графиков, которые помогают анализировать какой объем данных был передан между сокетами и какое распределение переданных данных было между сокетами (см. рис. 5).
Рис. 3. Схема модели блока «DMA»
■ Oh'^ ©
i G) л IA 5 iir, в ;
wsi Active Nwkiiii ;
shits Hiics »:r >i imm
system su"ary <nunti (329 hits tfltil)
73.1 it <i tu С [t ж j ,i <>* t
1. I 75 scusertrKiSi '-. t&. 7 is '< I tr P Гв f r [n '<■ J дтгжхя :... 1J.9 -.O u f cK.'' I '
U.3 J" EiUEirProctjs ... CV. 1 gWMTKH _r _ ____
3.6 1.Э scuserirocess i [5e3ector_i_type] spf _рогт:_0.port_Mjtpm_0.s(
2.7 9 scocner (scKernel)
t>. i 1 KUfirprocm -p'i -.P«)!.'' H'.'T '
0. i 1 EiUEirPrflttiS fdH ; : -i. -.у if:,-,-:
P. i 1 scuserfrwiess иina]b2iifa_trrca<C7]
D.i 1 :' 1 > - f ess f [crtdlTblifi*r_trt»Jspt_perrл. pori_1ii(H4J5. с O.J 1 К t9 V РПМЫ t^- 't, . 5У5ТС.-С sta event (Р.И of IKll) irf 1 sccthef (iciierntl]
ipf_fr4Be4enerat&rcc tpf_fraftt6enera(torcc
' Г' Г I IV*-:. :r -:r -
bpF_fri«eiHriH-itDrCt ipf-friBrteneratsrcc
' .v > ' T1' * ~
5trt9a Tyj4 I, Cwnl? (WM hit» tVtjl>
Wilts rt4ts flnti fiat«
6 5JM [ 1 Duca»e «rtqint
Рис. 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] 1К 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), все данные передавались через порт #1. Сенсорные
14
Latency, гпз
данные были доставлены с недопустимой задержкой (рис. 7). Это происходило постоянно с периодом ~16,68 мс из-за того, что канал был занят передачей видеокадров по имеющего такой же приоритет, как и ^1. Другие данные были переданы с допустимой для них задержкой.
12
10
acccptitble litencv - S tris
packets
Рис. 7. Передача сенсорных данных с недопустимой задержкой
Такая ситуация может быть неприемлемой для бортовых систем КА. Нами были выявлены следующие причины доставки пакетов с недопустимой задержкой:
1. Возможна монополизация канала связи передачей данных по высокоприоритетным виртуальным каналам. Это происходит при следующих условиях:
• имеется 1 или более высокоприоритетный виртуальный канал;
• в буфере отправки высокоприоритетного канала всегда присутствуют данные для отправки;
• всегда есть свободное пространство в буфере приема высокоприоритетного канала на стороне получателя;
• время считывания полученных данных (длиной 256 N-Char или меньшей длины, но, в этом случае, данные должны быть ограничены символами EOP или EEP) из буфера приема и доставки управляющего слова FCT (кредита) до узла отправителя должно быть меньше времени доставки очередного кадра данных со стороны отправителя;
• предел кредита пропускной способности (Bandwidth Credit Limit) не был превышен передачей данных по высокоприоритетному каналу.
2. В соответствии с правилами механизма Medium Access Control (MAC) стандарта SpaceFibre [2] виртуальные
каналы должны соревноваться друг с другом за право передавать данные через канал. В результате сенсорные данные будут чередоваться с данными, поступающими через другие виртуальные каналы (например, управляющие данные, видеокадры).
Для решения данной проблемы предлагается использовать механизм «Планирования» стандарта SpaceFibre в дополнение к механизму «Приоритеты». Механизм «Планирование» позволяет сделать распределение ресурсов сети SpaceFibre полностью детерминированным. Это достигается тем, что время разделено на последовательности временных интервалов (тайм-слоты), во время которых виртуальный канал может быть запланирован на отправку данных. Если виртуальный канал запланирован на отправку в текущий тайм-слот, но у него нет данных для отправки или нет места в его входном буфере виртуального канала на удаленном конце соединения, другим виртуальным каналам, которым разрешено осуществлять передачу в текущий временной интервал, разрешено использовать неиспользуемую пропускную способность [2]. Все трафики были распределены между тайм-слотами. Для этого использовались все доступные для планирования тайм-слоты - 256. На рис. 8 продемонстрирован пример распределения видеокадров по тайм-слотам.
Слоты для передачи Слоты для
видеокадров др.трафиков
I 16.7 мс >
Время
Рис. 8. Пример применения механизма «Планирования» для передачи потокового видео
Необходимо отметить, что передача управ -ляющего трафика была запланирована на все тайм-слоты, потому что управляющий трафик - это критически важные данные для выполнения миссии КА (имеет наивысший приоритет в порту SpaceFibre) и данные такого трафика должны быть переданы как можно скорее. Расписание тайм-слотов было построено лишь с учетом допустимых задержек. В результате, механизм «Планирование» SpaceFibre обеспечил детерминизм в доставке данных: потоковые сенсорные данные были доставлены с допустимыми задержками <5 ms (рис. 9). Однако у механизма «Планирования» есть недостаток - простой канала связи SpaceFibre при передаче данных по виртуальному каналу (рис. 10). Это произошло поскольку суммарная длительность выделенных для передачи данных тайм-слотов превышала необходимое время для передачи видеокадра. Решением данной проблемы может быть планирование на неполностью загруженный тайм-слот передачи данных следующего по расписанию виртуального канала (рис. 11) - метод уплотнения расписания. Данный подход гарантированно решит эту проблему только в том, случае, если будет использоваться качество сервиса «Приоритеты» и у следующего виртуального канала приоритет будет ниже, чем у предыдущего канала. Иначе, виртуальные каналы будут соревноваться за право передавать данные в этот тайм-слот согласно спецификации SpaceFibre. В результате, возможна ситуация, представленная на рис. 12, когда видеокадр по VC1 будет передан с недопустимой задержкой из-за того, что VC5 было разрешено передавать сенсорные данные в тайм-слоте №186. Это приведет к тому, что видеокадры будет передан с недопустимой задержкой.
latency, гш
S .-
мм BCtjttMt '"""I ■. 5 I]
итчгчтччпчпг-йачоочкчтччлчпг-йачачо-*
1 ..........■ .. ........ ^ . ч
Рис. 9. Механизм «Планирования» позволил организовать передачу сенсорных данных с допустимыми задержками
.. pocVcts
Рис. 10. Пример простоя передачи данных по виртуальному каналу
УС5. приоритет = 14 УС1, приоритет = 15 (низший)
Потоковое видео Сенсорные данные 1 Сенсорные данные 2
Слот 1321 Слог ДО | СДОГ1841 Слот 1861 Слот 1961 Слот 1В71 Do 1881 Слог 139 I Слот 190 —i-г i ■■>
11ередача данных де^* трафиков запланирована на шин тайм-слот
Время
Рис. 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 OoS, SPO) и механизмов сервиса ADSS (динамические приоритеты (dynamic priorities, DP) и динамические тайм-слоты (dynamic time-slots, DT)) для передачи сенсорного трафика. Параметры потоковых трафиков были те же (см. табл. 1). Применение динамических тайм-слотов позволило увеличить количество доступных для планирования тайм-слотов с 256 до 512. Был подсчитан объем переданных сенсорных данных по виртуальному каналу. Затем мы сравнили полученный результат с планируемой передачей данных (рис. 13).
Рис. 13. Сравнение объемов переданных и запланированных для передачи сенсорных данных при использовании различных методов планирования при старых значениях
параметров сенсорного трафика
Из рис. 13 явно видно, что применение методов ADSS позволило увеличить объем переданных данных на 2,7% по отношению к методу SPO. При этом значительное количество сенсорных данных не было передано, поскольку расписание тайм-слотов было построено лишь с учетом допустимых задержек, значения которых были больше периода поступления потоковых данных. В итоге, сенсорные данные отбрасывались при переполнении выходного буфера виртуального канала. Уменьшив интенсивность поступления пакетов до 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.
СПИСОК ЛИТЕРАТУРЫ:
1. Mikrin, K.A.. Onboard Control Complexed of Spacecrafts. -Moscow, 2003. 336 р.
2. Parkes, S. SpaceFibre Specification / S. Parkes, A. Ferrer, A. Gonzalez, C. McClements // Draft F3, September 2013.
3. Open SystemC Initiative (OSCI), IEEE 1666™-2011 Standard for SystemC Language Reference Manual, 2011.
4. Open SystemC Initiative (OSCI), TLM-2.0 Language Reference Manual, 2009.
5. Virtual System Platform User Guide, Cadence Design Systems, 2014.
6. Open Virtual Platforms (OVP), Imperas. URL:
10.
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.
RESEARCH THE SPACEFIBRE STANDARD AT APPLICATION THE TECHNOLOGY OF VIRTUAL PROTOTYPING
© 2016 I.L. Korobkov, E.A. Suvorova, N.A. Matveeva, Yu.E. Sheynin Saint-Petersburg State University of Aerospace Instrumentation
Article is devoted to an actual problem task of the analysis of efficiency of application of the SpaceFibre standard, namely, mechanisms of ensuring the quality of service for transfer the stream data in the onboard computer networks having strict requirements by the time of their delivery that is critical for viability of onboard systems. The model of a prototype of system-on-crystal (SOC) functioning with application of the SpaceFibre standard - the network controller of memory - by means of programming languages, methodology and instruments of system design and virtual prototyping has been developed. These are such languages as TLM 2.0 and SystemC, OVP technology and the program Virtual System Platform (VSP) tools provided by the Cadence company. Use of the presented means has allowed to execute imitating modeling and to carry out the analysis of productivity of the controller. The received results have helped to find restrictions of the considered architecture of SNK. Program utilities of Cadence and Imperas have allowed to reduce design time. Use of the presented methodologies has helped to develop and debug tests and the built-in software of the developed SOC before release of a product from factory.
Key words: SystemC, OVP, TLM (Transaction Level Modeling), design of SOC, virtual prototyping, SpaceFibre
Ilya Korobkov, Minor Research Fellow. E-mail: [email protected]; Elena Suvorova, Candidate of Technical Sciences, Chief of the System-on-crystal Laboratory. E-mail: [email protected]; Nadezhda Matveeva, Engineer. E-mail: [email protected]; Yuriy Sheynin, Doctor of Technical Sciences, Professor, Head of the Aerospace Computer and Software Systems Department. E-mail: [email protected]
7.
8.
9.
