ГОСТ Р 56096-2014. Национальный стандарт Российской Федерации. Система передачи космических данных и информации. Пакетная телеметрия

(утв. и введен в действие Приказом Росстандарта от 09.09.2014 № 1032-ст)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

СИСТЕМА ПЕРЕДАЧИ КОСМИЧЕСКИХ ДАННЫХ И ИНФОРМАЦИИ

ПАКЕТНАЯ ТЕЛЕМЕТРИЯ

System of transfer of the space data and the information. Package telemetry

ГОСТ Р 56096-2014

Предисловие

1. Разработан Открытым акционерным обществом «Научно-производственное объединение измерительной техники» (ОАО «НПО ИТ»).

2. Внесен Техническим комитетом по стандартизации ТК 321 «Ракетная и ракетно-космическая техника».

3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 9 сентября 2014 г. № 1032-ст.

4. Введен впервые.

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru).

1. Область применения

Настоящий стандарт устанавливает правила построения и организации информационных систем, использующих принципы пакетной передачи данных в измерительных системах на объектах и изделиях ракетно-космической техники и наземной космической инфраструктуры.

Настоящий стандарт может быть также применен при разработке стандартов организаций.

Для использования настоящего стандарта при организации информационных систем, использующих принципы пакетной передачи данных, рекомендуется указывать в соответствующей ссылке, в какой части настоящий стандарт следует применять в отношении стандартов данной организации.

Настоящий стандарт применяется при создании, производстве и эксплуатации изделий космической техники по международным договорам и в ходе реализации международных проектов и программ при условии согласия всех заинтересованных сторон, а также в случаях, когда его применение предписано требованиями технического задания на выполнение работ.

2. Термины, определения и сокращения

2.1 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

2.1.1. байт: Слово данных, состоящее из восьми одноразрядных двоичных символов (битов) с упорядоченной (по значимости разрядов) последовательностью при их передаче в последовательном виде.

2.1.2. неинформативные данные: Данные, не несущие полезной (содержательной) информации, передача которых необходима для работы системы синхронизации.

2.1.3. пакет источника, пакет: Структура данных источника информации, позволяющая однозначно идентифицировать источник данных и его содержание в рамках принятого алгоритма телеметрирования.

2.1.4. пакетная телеметрия: Стандартизованный способ передачи данных, включающий упорядоченные структуры данных и протоколы при их передаче через каналы связи, для достоверной расшифровки (декодирования) и доставки потребителю данных о телеметрируемых процессах.

2.1.5. кодирование телеметрического канала: Способ передачи данных по каналу связи с помехами, позволяющий безошибочно восстанавливать исходное сообщение (данные) на приемной стороне.

2.1.6. уровень прикладного процесса: Системный уровень совокупности преобразователей информационной системы: физическая величина — электрический сигнал.

2.1.7. номер пакета, счетчик пакетов: Четырнадцатиразрядное поле данных в структуре заголовка пакета, содержащее информацию о текущем порядковом номере передаваемого пакета данных.

2.1.8. длина пакета: Размер пакета в байтах, включая заголовок и поле данных пакета. Минимальное значение (включая заголовок) должно составлять 7 байт, максимальное — 65549 байт.

2.1.9. сегментация: Процесс разделения длинных пакетов данных от источников (более 1024 байта), при котором формируются пакеты данных фиксированной длины (256, 512 или 1024 байт).

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

2.1.10. сегмент: Структура данных фиксированной длины, полученная из длинных массивов данных источника, включающая заголовок сегмента и поле данных сегмента.

2.1.11. фрейм: Структура данных, предназначенная для передачи данных, сформированных в виде последовательности пакетов/сегментов.

2.1.12. мультиплексирование: Процесс передачи данных по одному каналу от нескольких источников данных с коммутацией входов источников по определенному алгоритму.

2.1.13. демультиплексирование: Процесс, обратный процессу мультиплексирования.

2.1.14. виртуальный канал: Информационный канал передачи, в котором реализуется мультиплексирование (демультиплексирование) источников прикладных процессов в потоки данных главного канала.

2.1.15. физический канал: Физическая среда для передачи кодированной пакетной информации.

2.1.16. поле управления последовательностью пакетов, сегментов: Шестнадцатиразрядное поле данных в структуре заголовка пакета, содержащее информацию о расположении и порядковом номере данной структуры в общем массиве данных от источника прикладного процесса.

2.1.17. кодирование данных (помехозащищенное): Способ преобразования данных, при котором внесением избыточности достигается увеличение вероятности обнаружения искажений как отдельных бит данных, так и их последовательностей при передаче по информационному каналу.

2.1.18. главный канал: Информационный канал передачи данных, в котором реализуется мультиплексирование (демультиплексирование) источников виртуальных каналов для кодирования (декодирования) данных и дальнейшей передачи информации через физический канал.

2.1.19. коды Рида — Соломона: Циклические коды, позволяющие исправлять ошибки в блоках данных.

2.1.20. сверточный код: Помехозащищенный код, позволяющий исправлять ошибки.

Примечание. Систематический сверточный код содержит в своей выходной последовательности кодовых символов породившую ее входную последовательность информационных символов.

2.1.21. заголовок пакета, сегмента, фрейма: Структура данных, содержащая идентификатор, поле управления и информацию о длине передаваемых в данной структуре данных и другую информацию.

2.1.22. холостой (неинформационный) пакет: Пакет, не содержащий полезной информации в поле данных пакета.

2.1.23. код времени: Структура данных, содержащаяся во втором заголовке пакета и сформированная для временной привязки измеряемых прикладных процессов к бортовой шкале времени.

2.2 Сокращения

В настоящем стандарте применены следующие сокращения:

• CCITT — международный консультативный комитет по телеграфии и телефонии (Consultative Committee on International Telegraphy & Telephony, CCITT);
• CCSDS — консультативный комитет по космическим системам передачи данных (Consultative Committee for Space Data Systems);
• ISO — международная организация по стандартизации (International Standards Organization);
• OSI — эталонная модель взаимодействия открытых систем (Open Systems Interconnect model).

3. Основные положения

3.1. Целевой задачей телеметрической системы, использующей принципы пакетной передачи данных, является надежная и достоверная доставка измерительной информации от удаленных бортовых источников информации к ее потребителям.

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

3.3. Понятие пакетной телеметрической системы, спроектированной в соответствии с рекомендациями CCSDS, должно включать две основных категории:

• пакетная передача телеметрических данных (пакетная телеметрия);
• кодирование телеметрического канала.

4. Структура информационной системы

4.1 Методическое обеспечение проектирования телеметрической системы

4.1.1. Процесс проектирования телеметрической системы должен содержать методику иерархического представления, позволяющую рассматривать систему как формализованный набор процедур в соответствии с рекомендациями [1].

4.1.2. Иерархическое представление в соответствии с эталонной моделью взаимодействия открытых систем OSI, ISO и CCITT должно логически группировать функции телеметрической системы в уровни и устанавливать связи между этими уровнями в соответствии с [2].

4.2 Порядок уровневого и межуровневого обменов данными

4.2.1. Обмен данными в пределах уровня должен происходить согласно установленным стандартным правилам или протоколам. При этом для каждого уровня должно быть определено ограниченное множество услуг, обеспечиваемых нижним по отношению к нему уровнем и, аналогично, определено множество услуг, предоставляемых данным уровнем верхнему по отношению к нему уровню.

4.2.2. Логика функционирования любого уровня может быть полностью изменена или исключена разработчиком в соответствии с требованиями пользователя при условии отсутствия нарушения целостности и функциональности системы.

4.3 Иерархическое представление систем

4.3.1. Иерархическое представление является инструментом разработки гибких структурированных систем, легко адаптируемых к изменяющимся требованиям или новым технологиям. Методика стандартизации телеметрических систем предполагает рекомендации в соответствии с [1]:

• инкапсуляцию данных источника и формирование в реальном масштабе времени автономного пакета информации;
• коммутирование независимых пакетов от различных источников данных в общую структуру для передачи на приемно-регистрирующую станцию по радиоканалу с помехами;
• доставку пользователю пакета источника.

4.3.2. Концепция иерархического представления должна обеспечивать следующие признаки функциональности систем в соответствии с рекомендациями [1]:

• наличие независимых автономных пакетов данных;
• фиксированные и стандартные протоколы обмена данными между источниками данных на борту и наземным пользователем;
• межведомственную совместимость;
• оптимальное распределение в реальном масштабе времени телеметрических каналов с использованием механизмов приоритетного коммутирования;
• практически безошибочный телеметрический канал, получаемый благодаря использованию помехоустойчивого кодирования.

4.3.3. Вариант построения семиуровневой иерархической модели телеметрической системы, использующей рекомендации CCSDS, приведен на рисунке 1.

Примечание. Рекомендации комитета CCSDS адресованы только пяти нижним уровням этой модели в соответствии с [1], [2], [3].

УСЛУГИ, обеспечиваемые

УРОВЕНЬ уровнем

1. Уровень прикладного процесса			данных
	\/ Физическая величина	/\ Преобразование физических величин
2. Системный уровень			в наборы телеметрических данных
	\/ Телеметрические данные	/\ Пакетирование телеметрических данных
3. Уровень пакетирования			для последующей доставки потребителям
	\/ Пакет	/\ Сегментация длинных пакетизированных
4. Уровень сегментации			наборов данных для мультиплексирования
	\/ Сегмент	/\ Мультиплексирование пакетов
5. Уровень передачи			и сегментов во фреймы для передачи по физическому каналу
	\/ Фрейм	/\ Кодирование фреймов для защиты
6. Уровень кодирования			от ошибок передачи по физическому каналу с ошибками
	Телеметрический битовый \/ поток	/\ Физическое соединение бортового
7. Физический уровень			радиопередатчика и наземной приемной аппаратуры
	\/ Радиосигнал	/\

4.3.3.1. Уровень прикладного процесса — уровень преобразования физических величин (температуры, вибрации, пульсации давления и т.п.) в электрические сигналы, пропорциональные шкале измеряемого сигнала.

4.3.3.2. Системный уровень определяет преобразование электрических величин (токи, напряжения, заряды) в наборы телеметрических данных, предназначенные для дальнейшего преобразования в структуры пакетизированных данных.

4.3.3.3. Уровень пакетирования — пакетирование телеметрических данных для последующей доставки потребителям. В рамках концепции пакетной телеметрии данные о процессах на борту телеметрируемого объекта формируются в блоки, определяемые как «исходный пакет», или «пакет источника».

Эти блоки должны содержать основной заголовок, включающий в себя следующие поля:

• поле идентификации пакета;
• поле контроля последовательности пакетов;
• поле для информации о длине данных пакета;
• поле контроля ошибок (допускается не использовать).

4.3.3.4. Уровень сегментации — сегментация длинных пакетизированных наборов данных для мультиплексирования.

Для управления потоком данных и их передачи по каналам связи должна быть предусмотрена возможность сегментации больших блоков данных в меньшие: пакеты источника (формат 1) или сегменты пакетов (формат 2). При этом размер поля данных пакета или сегмента определяется требованиями интерфейса нижнего уровня.

4.3.3.5. Уровень передачи — мультиплексирование пакетов и сегментов во фреймы для передачи по физическому каналу.

Допускается использование нескольких вариантов передачи данных:

• мультиплексирование фреймов в виртуальные каналы, где фрейм должен начинаться с синхромаркера и иметь основной заголовок, который должен содержать поля идентификации фрейма, номера фрейма и поле, описывающее состояние поля данных фрейма. Поле данных фрейма может завершаться необязательной областью, включающей поле операционного управления и поле контроля ошибок;
• поле операционного управления должно обеспечивать выполнение некоторых функций обмена данными (например, калибровки бортового времени, подтверждения приема команд и др.).
• поле контроля ошибок должно позволять обнаруживать и исправлять ошибки, которые могут появиться в процессе обработки и передачи данных.

4.3.3.6. Уровень кодирования — обеспечение безошибочной доставки данных (достоверность передачи) для их защиты от ошибок, вызванных шумами радиоканала. Для защиты данных от шумов физического канала битовый поток кодируется одним или одновременно двумя следующими рекомендуемыми кодами, исправляющими ошибки:

• блочный код Рида — Соломона (255, 223);
• сверточный код (7, 12).

Данные, связывающие уровень кодирования канала со следующим уровнем, — это канальные символы, выводимые кодером, то есть последовательность информационных битов (битовый поток), в виде которой представлены защищенные фреймы передачи.

4.3.3.7. Физический уровень — соединение бортового радиопередатчика и наземной приемной аппаратуры, где канальные символы, поступающие на физический уровень, в частности на уровень радиоканала, должны обеспечивать модуляцию радиосигнала. Ошибки, которые возникают в процессе распространения радиосигнала, могут быть обнаружены и исправлены получателем путем использования кодов, исправляющих ошибки.

4.3.3.8. Взаимное отображение различных структур телеметрических данных приведено на рисунке 2.

4.4 Механизм управления потоком данных

4.4.1. Ряд систем передачи данных имеет ограниченную пропускную способность и ширину полосы частот канала передачи, посредством которого бортовые системы наблюдаемых объектов соединяются с системами сбора данных, находящимися в космосе или на Земле. Когда многочисленные пользователи совместно используют один канал передачи данных, управление потоком данных становится процессом, определяющим производительность системы.

4.4.2. Телеметрическая система должна гарантировать своевременную доставку данных от всех источников, имеющих возможность достаточно часто получать доступ к этому общему ресурсу (каналу), и управление буферизацией данных источников.

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

4.4.4 Управление потоком данных должно быть выполнено одним из двух следующих способов:

Способ 1. Формирование виртуальных каналов — механизм, представляющий источнику или группе источников виртуально монопольный доступ к физическому каналу, ограничивая пропускную способность на уровне фреймов. Каждый фрейм может быть идентифицирован как принадлежащий одному из восьми виртуальных каналов. Разбиение физического канала на виртуальные каналы обычно используется для разделения источников или адресатов (получателей) с различными характеристиками. Например, если бортовая аппаратура содержит оборудование, генерирующее очень длинные пакеты, и ряд других источников, генерирующих пакеты меньшей длины, целесообразно выделить первому источнику отдельный виртуальный канал, а остальные мультиплексировать во второй виртуальный канал. Виртуальные каналы могут также использоваться для разделения пакетов, поступающих в реальном масштабе времени, и информации, поступающей с устройства записи, обеспечивая тем самым разделение потоков данных, предназначенных разным адресатам.

Способ 2. Сегментация пакетов источника, при которой очень длинные пакеты источника, генерируемые прикладными процессами, разделяются на борту на меньшие пакеты фиксированной длины — сегменты пакетов. Сегменты пакетов источника можно мультиплексировать с «короткими» пакетами источника в один виртуальный канал, обеспечив таким образом источникам данных непосредственный доступ к этому виртуальному каналу. Для последующего восстановления пакетов источника на Земле используется информация из заголовков фреймов и сегментов.

4.4.5. Пример потока телеметрических данных от различных бортовых источников, адресованных соответствующим получателям, приведен на рисунке 3. В верхней части рисунка 3 изображены источники, генерирующие пакеты источников и сегменты пакетов. Эти сегменты и пакеты мультиплексируются во фреймы виртуальных каналов.

4.4.6. Фреймы после помехоустойчивого кодирования должны передаваться на приемно-регистрирующую станцию для дальнейшего демультиплексирования в виртуальные каналы, из которых должны извлекаться сегменты пакетов и пакеты источника. Пакеты источника должны доставляться соответствующим получателям с использованием информации из поля идентификации заголовка пакета. Для доставки пакетов, время доставки которых ограничено, должна использоваться информация вторичного заголовка пакета.

5. Структура и содержание пакетов

5.1. Сущность концепции пакетной телеметрии состоит в том, что данные о многочисленных прикладных процессах, протекающих в системах, построенных по принципам пакетной телеметрии, должны быть объединены в блоки данных, соответствующие источникам, которые затем должны передаваться по каналу передачи так, чтобы принимающие средства с высокой надежностью могли восстановить эти блоки из общего потока с сохранением их исходной последовательности.

Для реализации этих функций в рамках пакетной телеметрии должны быть определены две структуры данных источников:

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

5.2. Формирование пакетов источника данных должно осуществляться в соответствии со структурой данных и логикой телеметрирования заданного процесса. Последовательность данных при этом может быть переменной или фиксированной длины.

5.3. Содержание пакета источника, за исключением заголовка, определяющего источник и характеристики пакета, полностью зависит от прикладного процесса и реализации процедуры его телеметрирования.

5.4. Формат пакета источника допускает оптимизацию размера и структуры набора данных каждого прикладного процесса определенного источника данных с минимумом ограничений, накладываемых системой передачи. Таким образом, возможна организация данных каждого источника независимо от других источников и адаптация к режимам работы телеметрируемых систем. Заголовок пакета источника должен содержать идентификатор прикладного процесса, необходимый для адресации пакета соответствующему получателю, и информацию о длине пакета, последовательности пакетов и о других характеристиках пакета. Необязательный вторичный заголовок должен быть предусмотрен для стандартизации передачи меток времени и вспомогательных данных.

Пакет источника должен объединять блок измерительных и вспомогательных данных бортового прикладного процесса и подлежит передаче от соответствующего источника одному или нескольким наземным потребителям.

Пакет источника должен состоять из следующих основных областей:

• 48-битовый основной заголовок пакета (обязателен);
• поле данных пакета переменной длины.

Минимальная длина пакета — 7 байт, максимальная — 65 549 байт.

Пакет, не несущий информации в поле данных, называется холостым пакетом. Ряд пакетов, последовательно сгенерированных по одному запросу (по команде), должен обозначаться как группа пакетов источника.

5.5 Основной заголовок пакета источника

5.5.1. Обязательный основной заголовок пакета должен состоять из четырех полей, расположенных в следующей последовательности в соответствии с рекомендациями [4]:

• номер версии пакета (3 бита);
• идентификатор пакета (13 бит);
• поле управления последовательностью пакетов (16 бит);
• длина пакета (16 бит).

5.5.2. Номер версии пакета должен содержаться в битах 0 — 2 заголовка. Это 3-разрядное поле идентифицирует пакет как пакет источника и должно иметь значение «000».

Номер версии необходим для идентификации пакетов как пакетов источника или сегментов пакета источника. Остальные возможные значения этого поля (001 ... 111) зарезервированы для новых (перспективных) типов данных.

5.5.3. Идентификатор пакета (биты 3 — 15 основного заголовка) должен содержать поле для идентификации пакета.

Это тринадцатиразрядное поле разделено на три части:

• индикатор типа (1 бит);
• флаг вторичного заголовка (1 бит);
• идентификатор прикладного процесса (11 битов).

5.5.3.1. Бит 3 основного заголовка должен содержать идентификатор типа и иметь значение «0». Идентификатор типа в заголовке пакета необходим для различия данных телеметрии (значение «0») и телеуправления (значение «1»).

5.5.3.2. Бит 4 основного заголовка должен содержать флаг вторичного заголовка, который должен указывать на его наличие или отсутствие в пакете. Наличие в структуре пакета вторичного заголовка индицируется значением «1» флага. Флаг вторичного заголовка должен оставаться статичным в течение фазы полета. Для холостых пакетов он должен иметь значение «0».

5.5.3.3. Биты 5 — 15 основного заголовка должны содержать идентификатор прикладного процесса. Он должен быть различен для разных процессов, телеметрируемых по одному главному каналу. Для холостых пакетов идентификатор должен иметь значение «все единицы».

5.5.4 Шестнадцатиразрядное поле контроля последовательности пакетов (биты 16 — 31) подразделяется на два подполя:

• флаги группирования (2 бита);
• счетчик пакетов источника (14 бит).

5.5.4.1 Флаги группирования должны быть установлены следующим образом:

• «01» — для первого пакета в группе;
• «00» — для промежуточного пакета, принадлежащего группе;
• «10» — для последнего пакета в группе;
• «11» — для пакета, не принадлежащего группе.

При сегментации пакетов источника флаги группирования используются как флаги сегментации (значения «11»). Группирование и сегментация пакетов источника взаимно исключают друг друга.

Длина пакетов источника в виртуальных каналах, по которым также передаются сегменты пакетов, не должна превышать 65549 байт.

5.5.4.2. Счетчик пакетов (биты 18 — 31) должен содержать счетчик следования последовательности пакетов, нумерующий каждый пакет источника конкретного процесса во всей последовательности его пакетов (пакетов, обозначенных одним идентификатором). Счет должен вестись непрерывно, и показания счетчика не должны сбрасываться до достижения максимального значения — «16384». Назначение счетчика — восстановление исходной последовательности пакетов источника в возможных случаях ее нарушения при передаче.

Счетчик должен использоваться вместе с кодом времени, так как его значение может быть недостаточно для однозначного определения исходного положения пакета в общем потоке пакетов одного источника. Разрешение (точность) кода времени должно быть достаточным, чтобы его использование было возможно вместе со счетчиком пакетов, то есть код времени должен увеличиваться хотя бы на единицу за один полный цикл счетчика пакетов.

Примечание. Если показания счетчика пакетов будут сброшены до достижения максимального значения и заново проинициализированы, правильно восстановить последовательность пакетов будет невозможно, что приведет к потере информации.

5.5.5. Длина поля данных пакета (биты 32 — 47) должна представлять 16-разрядное поле, которое должно содержать двоичное значение в диапазоне от 1 до 65536, равное числу байт в поле данных пакета. Другие ограничения по длине поля данных должны определяться длиной сегмента.

5.6 Поле данных пакета

5.6.1. Непосредственно за основным заголовком должно следовать обязательное поле данных пакета. Оно должно включать в себя по крайней мере одну из следующих областей:

• вторичный заголовок пакета (переменной длины);
• поле данных пакета источника (переменной длины).

5.6.2. Если присутствует вторичный заголовок, он должен быть расположен первым в поле данных. Если поле данных пакета источника отсутствует, вторичный заголовок обязателен. Наличие или отсутствие вторичного заголовка должно указываться наличием флага вторичного заголовка, поля идентификации пакета. Если вторичный заголовок присутствует, то он должен состоять из следующих подполей:

• подполе данных вторичного заголовка;
• подполе кода времени вторичного заголовка;
• подполе кода времени вторичного заголовка и поля данных вторичного заголовка.

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

5.6.4. Область кода времени вторичного заголовка должна состоять из целого числа байт и содержать код времени в формате, рекомендуемом CCSDS [5].

В соответствии с рекомендациями CCSDS [5] код времени должен состоять из необязательной преамбулы, идентифицирующей и характеризующей код, и обязательного поля данных о времени.

5.6.5. Формат представления кода времени должен быть неизменным на протяжении выполнения полетного задания. Если же допускается изменение характеристик прикладного процесса и, соответственно, формата представления кода времени, преамбула обязательно должна присутствовать. При наличии преамбулы за ней должно следовать поле данных о времени телеметрирования прикладного процесса.

5.6.6. Поле данных вторичного заголовка должно состоять из целого числа байт. Оно может содержать любые вспомогательные данные, необходимые для расшифровки или интерпретации информации поля данных пакета источника.

5.7 Поле данных пакета источника

5.7.1. Если поле данных пакета источника присутствует, оно должно следовать непосредственно за вторичным заголовком пакета (в случае его наличия) или за полем описания длины пакета. Поле данных пакета источника обязательно, если отсутствует вторичный заголовок пакета, и не обязательно, если вторичный заголовок присутствует. Длина поля данных пакета источника переменна и должна содержать целое число байт.

5.8 Сегмент пакета

5.8.1. Сегмент пакета — передача длинных пакетов источника в виде ряда более коротких сегментов пакета, что позволяет исключить «захват» информационного канала системы одним источником в соответствии с рекомендациями [2], [6].

5.8.2. Процесс сегментации должен применяться только к полю данных пакетов источника. Сегмент пакета должен содержать блоки данных из поля данных пакета источника. Для передачи пакета источника в виде сегментов необходимы два или более сегмента. Сегмент должен состоять из следующих полей:

• обязательный заголовок сегмента (6 байт);
• поле данных сегмента, содержащее:

а) сегменты пакета источника, за исключением последних проверочных битов;

б) остаток сегментированного пакета источника.

5.8.3. Длина поля данных сегмента должна состоять из 256, 512 или 1024 байт. Сегментация не применяется к пакетам источника, принадлежащим группе пакетов источника, и к холостым пакетам, т.е. длина неинформационного пакета не может превышать длины сегмента пакета.

5.8.4. Структура сегмента пакета и пример сегментации пакета по источникам данных приведены на рисунках 5 и 6.

1. Длина сегментов составляет 512 байт (для данного примера).

2. Длина последнего сегмента в последовательности составляет 68 байт.

5.8.5 Основной заголовок сегмента

5.8.5.1 Основной заголовок сегмента обязателен и должен состоять из трех полей:

• номер версии (3 бита);
• идентификатор сегментации (13 бит);
• поле контроля последовательности сегментов (32 бита).

Структура данных первичного заголовка сегмента соответствует структуре основного заголовка пакета источника (см. 5.5).

5.8.5.2. Номер версии должен содержаться в битах 0 — 2 заголовка и иметь значение «100».

5.8.5.3. Поле идентификации сегмента образуют биты 3 — 15 заголовка. Это поле должно быть идентично по форме и содержанию полю идентификации пакета источника (см. 6.1.2).

5.8.5.4. Тридцатидвухразрядное поле контроля последовательности сегментов (биты 16 — 47 заголовка) должно быть образовано тремя подполями:

• флаги сегментации (2 бита);
• счетчик сегментов (14 бит);
• поле остаточной длины пакета (16 бит).

Поле должно содержать информацию, необходимую для восстановления пакетов из сегментов пакетов.

5.8.5.5. Биты 16 и 17 заголовка представляют собой флаги сегментации. Комбинация этих битов интерпретируется следующим образом:

• «01» — сегмент, содержащий первый блок поля данных пакета источника;
• «00» — сегмент, содержащий промежуточный блок поля данных пакета источника;
• «10» — сегмент, содержащий последний блок (остаток) поля данных пакета источника.

5.8.5.6. Биты 18 — 31 заголовка должны содержать счетчик последовательности сегментов пакета источника. Их назначение соответствует одноименным битам заголовка пакета (см. 5.5.4.2).

5.8.5.7. Длина последнего сегмента пакета может быть неравной одному из значений 256, 512 или 1024 байт, поэтому биты 32 — 47 заголовка сегмента должны содержать информацию о количестве еще непереданных байт поля данных пакета источника минус единица. Эта информация должна соответствовать количеству байт, содержащихся в последнем передаваемом сегменте (без единицы), — остаточной длине сегмента.

5.8.5.8. Непосредственно за полем длины остатка пакета источника должно следовать поле данных сегмента, содержащее один из блоков поля данных пакета источника. Поле данных пакета источника должно быть разбито на блоки без пропусков данных, перекрытий блоков и заполнений другой информацией.

5.8.5.9. Длина поля данных должна иметь одно из значений равным 256, 512 или 1024 байт в зависимости от идентификатора длины сегмента в основном заголовке фрейма передачи, за исключением последнего сегмента, длина поля данных которого равна длине последнего блока данных поля данных пакета источника.

5.9. Кроме пакетов источника и сегментов пакетов непосредственно в поле данных пакета могут передаваться пакеты трех других типов в соответствии с рекомендациями [2], [7]:

• пакеты сетевого протокола CCSDS (NP);
• пакеты интернет-протокола (IPV4);
• пакеты инкапсуляции.

5.9.1. Пакеты сетевого протокола CCSDS и интернет-протокола IPV4 приведены на рисунке 7.

5.9.2. В заголовках пакетов сетевого протокола CCSDS и интернет-протокола должны содержаться номера версий, соответственно, со значениями «001» (биты 0, 1 и 2) и «0100» (биты 0, 1, 2 и 3).

5.9.3. Биты 3 — 15 пакета сетевого протокола и биты 4 — 16 интернет-протокола должны определять общую длину указанных пакетов.

5.9.4 Инкапсуляционный (вложенный) пакет приведен на рисунке 8.

5.9.5 Биты 0 — 2 должны содержать значения «111».

5.9.6. Биты 3 — 5, определяющие идентификатор протокола инкапсулированного пакета, должны содержать информацию о содержании блоков данных этого пакета:

• «000» — загрузка (инкапсулированные данные отсутствуют);
• «100» — блок данных протокола IPv6;
• «111» — произвольно соединенные октеты.

Примечание. Другие возможные значения поля (001, 010, 011, 101, 110) зарезервированы для будущих версий.

5.9.7. Биты 6 и 7 должны определять размер поля длины пакета, содержащего значение длины поля данных в байтах:

• «01» — 1 байт;
• «10» — 2 байта;
• «11» — 4 байта.

Два нулевых бита в этом поле означают:

• поле длины поля данных не существует;
• инкапсулированные данные отсутствуют;
• длина пакета инкапсуляции — один байт.

Такие однобайтные самоидентифицирующиеся пакеты должны использоваться для загрузки поля данных фрейма (так как фрейм — структура фиксированной длины) и являются неинформативными данными.

5.9.8. В поле данных инкапсуляционного пакета должны содержаться инкапсулированные данные.

5.10 Фрейм передачи

5.10.1. Фрейм передачи — структура, позволяющая передавать пакетизированные данные по зашумленному радиоканалу «Борт — Земля». Заголовок фрейма передачи несет информацию, необходимую наземной системе передачи данных для того, чтобы направить его соответствующему адресату. Длина фрейма передачи должна быть постоянной для всего времени выполнения полетного задания (целевой задачи).

5.10.2. Пакеты источника переменной длины, асинхронно генерируемые многочисленными прикладными процессами, протекающими на борту изделия, для надежной и достоверной передачи на Землю должны мультиплексироваться в соответствии с приоритетами источников в синхронный поток кодированных фреймов передачи.

5.10.3. Основной заголовок фрейма должен содержать поля, наличие которых позволяло бы мультиплексировать пакеты источника и/или сегменты пакетов переменной длины во фрейм фиксированной длины. Во фрейме может содержаться несколько коротких пакетов или сегментов или часть длинного пакета, передаваемого в двух или более фреймах. Все поле данных фрейма должно использоваться для передачи пакетов или сегментов.

5.10.4. Пакеты и сегменты могут начинаться и заканчиваться в любом месте поля данных фрейма. Для оперативной доставки данных с борта изделия нет необходимости подбирать размеры пакетов и порядок их следования для формирования фреймов передачи. В случаях когда для сохранения синхронизации между передающей и приемной сторонами при отсутствии данных источников необходимо передать фрейм, предусмотрен механизм холостых пакетов.

5.10.5. В заголовке фрейма должна содержаться информация, необходимая для извлечения пакетов стандартизованным и независимым от пакетов способом и для сборки пакетов из сегментов.

5.10.6. Кроме пакетов фрейм может нести информацию в двух необязательных полях: вторичном заголовке и поле операционного управления. Вторичный заголовок должен использоваться для передачи данных фиксированной длины, специфичных для конкретного объекта (изделия).

5.10.7 В соответствии с рекомендациями [4] фрейм обеспечивает передачу следующих структур данных:

• пакеты источника;
• сегменты пакетов источника;
• холостые пакеты.

5.10.8 Структура фрейма передачи приведена на рисунке 9.

5.10.9 Фрейм передачи должен содержать следующие поля:

• основной заголовок (48 бит);
• необязательный вторичный заголовок 16, 24, ..., 512 бит;
• поле данных (переменной длины);
• необязательное поле операционного управления;
• поле контроля ошибок (обязательное, если не применяется код Рида — Соломона).

5.10.10. Все фреймы с одним номером версии и идентификатором объекта, передающиеся по одному физическому каналу, составляют главный канал.

5.10.11. В большинстве случаев понятие «главный канал» идентично понятию «физический канал».

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

5.10.12 Основной заголовок фрейма передачи

5.10.12.1 Основной заголовок фрейма передачи должен состоять из пяти полей:

• номер версии фрейма (2 бита);
• идентификатор фрейма (14 бит);
• счетчик фреймов главного канала (8 бит);
• счетчик фреймов виртуального канала (8 бит);
• поле состояния поля данных фрейма (16 бит).

5.10.12.2. Несмотря на то что пакетные телеметрические системы подразумевают возможность защиты от ошибок на уровне пакетов источника или их сегментов, для достижения всей полноты их преимуществ необходим высококачественный канал передачи, сформированный таким образом, чтобы пакетированные данные могли быть адаптивно вставлены во фрейм.

5.10.12.3 Основной заголовок фрейма передачи включает в себя пять основных функций:

• идентификация блока данных поля фрейма передачи;
• идентификация объекта;
• мультиплексирование виртуальных каналов в главный канал;
• подсчет фреймов виртуальных каналов и главного канала;
• передача указательной и другой управляющей информации, необходимой для извлечения из поля данных фрейма пакетов и сегментов.

5.10.12.4. Двухразрядный номер версии фрейма должен содержаться в битах 0 и 1 основного заголовка фрейма. Это поле должно иметь значение «00», что и идентифицирует данный блок данных как фрейм.

Примечание. Другие возможные значения этого поля зарезервированы для будущих версий фреймов и в настоящее время не используются.

5.10.12.5 Четырнадцатиразрядный идентификатор фрейма (биты 2 — 15) делится на три подполя:

• идентификатор объекта;
• идентификатор виртуального канала;
• флаг поля операционного управления.

5.10.12.6. Это поле идентифицирует источник фреймов, принадлежащий ему виртуальный канал и содержит информацию о формате пакетов.

5.10.12.7. Идентификатор объекта (например, космического аппарата) должен содержаться в битах со 2-го по 11-й и быть согласован с секретариатом CCSDS. Идентификатор объекта обозначает космический аппарат, использующий при пакетной передаче данных фреймы. Одному аппарату может быть назначено несколько идентификаторов, соответствующих различным периодам эксплуатации (разработка объекта, предстартовые и подобные операции с использованием наземной сети передачи данных, передача моделируемых потоков данных, летная эксплуатация).

5.10.12.8. Биты идентифицируют каждый из восьми возможных виртуальных каналов. Порядок следования фреймов разных виртуальных каналов в главном канале может меняться.

5.10.12.9. Флаг поля операционного управления (15-й бит заголовка) должен указывать на наличие или отсутствие в структуре фрейма этого поля. Наличие этого поля идентифицируется значением «1» флага, отсутствие — значением «0».

Флаг поля операционного управления должен быть неизменен в течение фазы полета для главного или для виртуальных каналов.

5.10.12.10. Восьмиразрядное поле счетчика фреймов главного канала (биты 16 — 23) содержит двоичное значение порядкового номера фрейма в общем потоке фреймов. Счет ведется последовательно от 0 до 255. До достижения значения «255» показания счетчика не должны быть сброшены. Преждевременный сброс показаний счетчика приводит к потере информации.

5.10.12.11. Восьмиразрядное поле счетчика фреймов виртуального канала (биты 24 — 31 основного заголовка) служит для обозначения номера фрейма в последовательности фреймов виртуального канала. Его значение для виртуальных каналов аналогично значению основного счетчика фреймов для главного канала.

5.10.12.12 Шестнадцатиразрядное поле состояния поля данных (биты 32 — 47) должно состоять из пяти подполей:

• флаг вторичного заголовка (1 бит);
• флаг синхронизации (1 бит);
• флаг порядка пакетов (1 бит);
• идентификатор длины сегмента (2 бита);
• указатель заголовка первого пакета.

Это поле указывает на наличие вторичного заголовка и должно содержать информацию о типе данных, содержащихся во фрейме, и вместе со счетчиком фреймов виртуального канала информацию, необходимую для извлечения пакетов или сегментов из поля данных фрейма.

5.10.12.13. Флаг вторичного заголовка (32-й бит основного заголовка фрейма) указывает на наличие или отсутствие в структуре фрейма необязательного вторичного заголовка. Наличие вторичного заголовка индицируется значением «1» флага, отсутствие — значением «0». Для главного канала флаг вторичного заголовка должен оставаться статичным в течение всей фазы полета.

5.10.12.14. Флаг синхронизации (33-й бит заголовка) должен иметь значение «0», если в поле данных находятся пакеты источника, сегменты или неинформационные данные. При передаче во фрейме других данных (конфиденциальной информации) флаг должен иметь значение «1». Флаг не должен меняться для виртуального канала в течение всей фазы полета.

5.10.12.15. Исходные блоки данных пакетов или сегментов обычно вставляются в поле данных фрейма выровненными по границам байт. Начало пакета/сегмента может не совпадать с началом поля данных. Начало заголовка пакета/сегмента в поле данных фрейма должно указываться значением поля указателя первого заголовка. Если границы байт не выровнены с границами поля данных, то передаваемые в структуре фрейма данные должны рассматриваться как конфиденциальные.

5.10.12.16. Флаг порядка пакетов (34-й бит заголовка) при значении «0» флага синхронизации должен быть установлен на значение «0» и может принимать произвольное значение при значении «1» флага синхронизации. Данный бит зарезервирован для будущих версий форматов данных.

Примечание. Данный бит зарезервирован для будущих версий форматов данных.

5.10.12.17 Идентификатор длины сегмента (35-й и 36-й биты заголовка) должен содержать значение длины сегмента:

• «00» — 256 байт;
• «01» — 512 байт;
• «10» — 1024 байт.

Если в данном виртуальном канале передаются только несегментированные пакеты, поле должно содержать значение «11».

Последний сегмент в поле данных фрейма может быть короче чем 256, 512 или 1024 байта.

5.10.12.18. Указатель первого заголовка (биты 37 — 47) должен содержать двоичное значение номера первого байта в поле данных фрейма. Все байты поля данных фрейма должны быть последовательно пронумерованы, начиная с нуля. Положение в поле данных следующих пакетов или сегментов вычисляется с использованием информации об их длине, содержащейся в их заголовках. Данный указатель должен использоваться только при значении «0» флага синхронизации.

Если фрейм не содержит заголовков пакетов/сегментов, то данный указатель должен быть установлен на значение «11111111111», если во фрейме содержатся только неинформационные (холостые) пакеты — на значение «11111111110».

5.10.13 Вторичный заголовок фрейма

5.10.13.1. Необязательный вторичный заголовок фрейма передачи должен следовать непосредственно за основным заголовком. Его наличие определяется значением «1» флага вторичного заголовка (32-й бит основного заголовка). Вторичный заголовок должен состоять из двух подполей:

• поле идентификации вторичного заголовка (8 бит);
• поле данных вторичного заголовка (8, 16, ..., 504 бита).

5.10.13.2. Вторичный заголовок связан с виртуальным или главным каналом и должен иметь фиксированную длину в связанном канале.

5.10.13.3 Поле идентификации должно состоять из двух подполей:

• номер версии вторичного заголовка фрейма (2 бита);
• поле длины вторичного заголовка фрейма (6 бит).

5.10.13.4. Номер версии в настоящее время имеет значение «00», другие возможные значения зарезервированы на будущее.

5.10.13.5. Информация о длине поля данных вторичного заголовка необходима для определения начала поля данных фрейма.

5.10.13.6. Все вторичные данные заголовка должны содержаться в поле данных вторичного заголовка.

5.10.13.7. Длина вторичного заголовка должна быть неизменной для виртуального или главного канала на протяжении выполнения полетного задания.

5.10.14 Поле данных фрейма

5.10.14.1. Непосредственно за вторичным (если он присутствует) или основным заголовком должно следовать поле данных фрейма.

5.10.14.2. Пакеты и сегменты помещаются в поле данных без промежутков в прямом порядке их следования.

Если пакетов или сегментов недостаточно для заполнения всего поля данных, его заполняют холостыми пакетами.

5.10.15 Поле операционного управления

5.10.15.1. Необязательное поле операционного управления занимает 4 байта поля данных. Его наличие указывается значением «1» соответствующего флага (бит 15 основного заголовка фрейма).

5.10.15.2. Состояние поля операционного управления должно быть неизменным по отношению к данному виртуальному или главному каналу в течение всего времени выполнения полетного задания.

5.10.15.3 Первый бит — это флаг типа поля, принимающий следующие значения:

• «0», если поле операционного управления содержит данные «Тип 1», то есть слово управления командной линии;
• «1», если поле оперативного контроля содержит данные «Тип 2».

При значении «1» этого бита следующий бит должен быть установлен на значение «0», если содержание поля определяется разработчиком телеметрической системы. Значение «0» следующего бита зарезервировано для использования в будущем.

5.10.15.4. Поле предназначено для обеспечения некоторых оперативных функций телеуправления, таких как, например, проверка и калибровка бортового времени. В настоящее время рекомендации определяют только использование поля «Тип 1».

Библиография

1. Телеметрия. Концепция, термины и понятия. Рекомендация CCSDS 100.0-G-1. Выпуск 1. Зеленая книга. Консультативный комитет по космическим системам данных, декабрь 1987

2. Эталонная модель взаимодействия открытых систем, международная организация по стандартизации, проект международного стандарта DIS-7498, февраль 1982

3. Телекоманды. Общие концепция и обслуживание, Отчет CCSDS 200.0-G-6. Выпуск 6. Зеленая книга. Консультативный комитет по космическим системам данных, январь 1987

4. Пакетная телеметрия. Рекомендация CCSDS 102.0-B-5. Выпуск 5. Голубая книга. Консультативный комитет по космическим системам данных, ноябрь 2000

5. Форматы кодов времени. Рекомендация CCSDS 301.0-B-4. Выпуск 4. Голубая книга. Консультативный комитет по космическим системам данных, ноябрь 2010

6. Телекоманды. Часть 2.1. Сервис доставки данных. Спецификации построения архитектуры, Рекомендация CCSDS 202.0-B-3. Выпуск 3. Голубая книга. Консультативный комитет по космическим системам данных, июнь 2001

7. Протокол передачи пакетных данных в космических системах. Рекомендация CCSDS 133.0-B-1. Выпуск 1. Голубая книга. Консультативный комитет по космическим системам данных, июнь 2006

------------------------------------------------------------------