СОВРЕМЕННАЯ ЭЛЕКТРОНИКА №8/2014

СОВРЕМЕННЫЕ ТЕХНОЛОГИИ 21 WWW.SOEL.RU СОВРЕМЕННАЯ ЭЛЕКТРОНИКА ◆ № 8 2014 Кадр FC Поле «Начало кадра» Поле заголовка кадра FC Поле «полезного контента» Поле кода циклического контроля Поле «Конец кадра» Рис. 1. Структура ADVB-кадра (оптоволоконный канал (Fibre Channel, FC)). разрешением для системы наблюдения за целями в обширном районе (Wide Area Surveillance – WAS). О БЗОР ПРОТОКОЛА ARINC 818-1 Поскольку не все читатели знакомы со стандартом ARINC 818, ниже приво- дится краткое описание данного про- токола. Стандарт ARINC 818 основан на своём предшественнике – стандар- те «Оптоволоконный канал для аудио- и видеоинформации» (Fibre Channel Audio Video – FC-AV), который был упрощён и специально переработан с целью построения критически важ- ных видеосистем, которые должны иметь высокую пропускную способ- ность и малые задержки. Протокол ARINC 818 является про- токолом последовательной связи «точ- ка–точка» с кодированием по схеме 8b/10b для передачи видеоинформа- ции, аудиоинформации и данных. Он предусматривает работу с пакета- ми данных, но при этом специально ориентирован на видеоинформацию, и является очень гибким – поддержи- вает целый ряд сложных видеофунк- ций, включая мультиплексирование нескольких потоков видеоданных на одноканальную линию передачи или передачу одного потока данных по двухканальной линии. В протоко- ле определены четыре разных класса видеоинформации – от простой асин- хронной системы до точной синхро- низации на уровне растровых точек. С ТРУКТУРА ПАКЕТА ADVB Стандарт ARINC 818 ориентиро- ван на базовый (пакетный) механизм транспортировки данных – ADVB-кадр. Представляется важным именовать эти кадры именно «ADVB-кадрами», а не просто «кадрами» – с тем чтобы исклю- чить неправильное отождествление их с экранными видеокадрами. Как показано на рисунке 1, начало ADVB-кадра сигнализируется упорядо- ченным набором SOFx, а конец – упо- рядоченным набором EOFx. Каждый ADVB-кадр имеет заголовок, состоя- щий из шести 32-разрядных слов. Эти слова дают информацию относительно источника и планируемого получателя (адресата) данного ADVB-кадра, а также сведения о позиции кадров в передава- емой последовательности. Поле полез- ного контента содержит либо видео- данные, либо их параметры и вспомо- гательные данные. Размер поля может быть разным, но не более 2112 байтов. С целью контроля целостности переда- чи все ADVB-кадры содержат 32-разряд- ный код циклического контроля (CRC), вычисляемый по данным, находящим- ся в промежутке между SOFx и CRC. Для вычисления CRC применяется тот же самый 32-разрядный полиномиальный алгоритм, который описан в стандарте FC-AV (Fibre Channel Audio Video). Спецификация ARINC 818 (аналогич- но стандарту FC-AV) определяет поня- тие «контейнер» – набор ADVB-кадров, служащих для транспортировки видео. Другими словами, видеоизображение и данные инкапсулированы в кон- тейнер, который вмещает множество ADVB-кадров. В рамках понятия «кон- тейнер» стандарт ARINC 818 определя- ет объекты, каждый из которых содер- жит определённый тип данных. То есть, конкретные ADVB-кадры внут- ри контейнера представляют собой часть некоторого объекта. Как показа- но в таблице, в контейнере могут нахо- диться объекты четырёх типов. В большинстве случаев единичный контейнер отображает ровно один видеокадр. Однако вполне допустима транспортировка в одном контейне- ре только части видеокадра. Это воз- можно, например, в ситуации, когда есть необходимость обновлять курсор- ную информацию для дисплея с часто- той, превышающей частоту видеока- дров, или когда задаются интересую- щие пользователя области с высокой скоростью перемещения целей. В этом случае в контейнере может находиться некоторая часть кадра, поэтому появ- ление ADVB-кадров с объектами типа 0 происходит довольно часто. Данные о положении курсора могут быть загру- жены в ADVB-кадры с объектами типа 0, которые появляются в потоке доста- точно часто – возможно, и несколько раз при передаче одного видеокадра. Вспомогательные данные (объект типа 0) присутствуют и тогда, когда – наря- ду с видеокадрами – может переда- ваться информация, задаваемая поль- зователем. Например, в поле вспомо- гательных данных могут вводиться метаданные типа «ключ–длина–значе- ние» (Key-Length-Value, протокол KLV). Хорошей иллюстрацией вышеска- занного может служить пример-опи- сание того, как в соответствии с про- токолом ARINC 818 передаётся цвет- ной кадр формата XGA RGB. Такой кадр требует передачи данных со скоростью ∼ 141 Mбайт/с (1024 пикселя × 3 байта на пиксель × 768 строк × 60 Гц). Если доба- вить «накладные расходы» протокола и продолжительность гасящего сиг- нала, то требуется стандартная ско- рость передачи данных по каналу, рав- ная 2,125 Гбайт/с. Протокол ARINC 818 пакетирует видеоизображения в ADVB- кадры. Структура ADVB-кадра показа- на на рисунке 1, причём максимальная длина поля полезного контента состав- ляет 2112 байт. Каждый ADVB-кадр начинается с 4-байтового упорядочен- ного набора битов (поля), именуемо- го SOF (Start of Frame), и заканчивается полем EOF (End of Frame). Кроме того, в целях контроля целостности дан- ных при передаче в ADVB-кадр вклю- чается 4-байтовое поле кода цикличе- ского контроля CRC. Поле полезного контента первого ADVB-кадра после- довательности содержит встроенную заголовочную информацию, которой сопровождается каждый кадр видео- изображения. Каждая строка видеокадра XGA тре- бует 3072 байтов, что превышает мак- симально допустимую длину поля полезного контента FC-кадра. Поэто- му каждая такая строка распределяет- ся на два ADVB-кадра. Транспортиров- ка XGA-изображения «потребляет» объ- ём полезного контента, содержащийся в 1536 FC-кадрах. Кроме того, должен быть добавлен заголовок видеокадра. Четыре типа данных, находящихся в ADVB-кадрах и именуемых «объектами» Объект Данные 0 Вспомогательные 1 Аудио (не используется) 2 Видео: поля прогрессивной развёртки или нечётные поля чересстрочной развёртки 3 Видео: чётные поля чересстрочной развёртки © СТА-ПРЕСС