Способ и устройство сбора, записи и использования данных, снимаемых в летательном аппарате

Изобретение относится к способу и устройству сбора и записи данных, снимаемых в летательном аппарате, в частности, к установкам для летных испытаний, обеспечивающих запись и визуальное отображение видео-, аудио- и графических данных и, в целом, любых цифровых данных. Технический результат - получение оптимизированных данных "workflows" (на земле и в полете) с учетом требований для летных испытаний. Устройство сбора и записи данных, снимаемых в летательном аппарате, содержит: множество источников потоков данных, предназначенных для записи, по меньшей мере, один источник датированных значений параметров записи и средства записи данных, происходящих из потоков данных, и значений параметров, по меньшей мере, на одном энергонезависимом носителе информации. Средства записи выполнены с возможностью сохранения в отдельных файлах данных из различных потоков данных, объединенных с упомянутыми датированными значениями параметров записи. 2 н. и 21 з.п. ф-лы, 16 ил., 1 табл.

 

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

Установки для летных испытаний, как известно, предназначены для записи видеоисточников, например, SDI (сокращение “Serial Digital Interface” - последовательный цифровой интерфейс), в частности испытательных камер или видеокамер, входящих в состав систем самолета, и некоторых данных, характеризующих соответствующие параметры самолета. Системами записи являются собственные системы, которые потребовали адаптации к потребностям испытательных самолетов. Они сохраняют данные на кассетах с магнитной лентой. В зависимости от периода времени и от технологии, имевшейся в это время на рынке, использовались различные типы формата видеозаписи и записывающих устройств.

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

Как показано на фиг. 1, видеозапись получают при помощи датчиков-камер 105 и в дальнейшем обрабатывают при помощи средств 115 обработки. К ним добавляют GMT 110 (сокращение от “Greenwich mean time” - среднее время по Гринвичу), то есть часы-календарь, настроенные на универсальное время, позволяющие точно фиксировать процесс испытания и связать видео со всеми получаемыми параллельно остальными данными, в частности параметрами самолета 120. Для некоторых самолетов параметры самолета вычисляет бортовой компьютер (не показан), и они кодируются. Соответствующие данные ограничены по числу параметров и по частоте обновления. На выходе из средств 115 обработки сигнал передается, например, по стандарту SDI “SMPTE 259”. Пропускная способность такого соединения составляет 270 Мегабит/сек.

Сигнал отображается на экране 125 отображения непосредственно во время испытания. Следует отметить, что для отображения видеосигнала SDI необходимо наличие преобразователей форматов (не показаны). Кроме того, видеосигналы и метаданные, то есть параметры, идентифицирующие самолет, полет, используемое оборудование и время, записываются на кассеты 130 с целью их обработки, архивирования и/или сохранения наземными средствами 135. Используемый формат записи от используемого записывающего устройства. Этот формат предназначен только для профессионалов. Кроме того, добавляются данные о самолете (тип, номер и т.д.) для облегчения классификации и архивирования. Эти сведения добавляют на кассету. Таким образом, для каждой кассеты получают заголовок.

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

Как следует из вышеизложенного, современная бортовая архитектура видео IEV (УЛИ) (сокращение от «Установка для летных испытаний ») является относительно сложной по причине используемого носителя, то есть магнитных лент. Действительно, потоки информации (видео, аудио и параметры самолета) записаны на кассетах.

Это известное техническое решение имеет много недостатков:

- видеомагнитофон позволяет записывать только видеопотоки стандартного разрешения, называемые также “SD”. Чтобы записывать видеопотоки высокого разрешения, называемые также “HD”, необходимо использовать видеомагнитофоны типа HDCam, которые стоят намного дороже. Чтобы записывать графические страницы типа ASVI (сокращение от “Avionics Serial Video Interface” - последовательный бортовой видеоинтерфейс), относящиеся к приборам в кабине экипажа, или VGA (сокращение от «Video Graphics Array» - видеографическая матрица) следует добавлять модули, позволяющие преобразовать эти сигналы в видеосигнал SD или HD;

- датирование изображений на видеомагнитофоне происходит на основании временного кода, называемого “timecode”, получаемого через сигнал AES (сокращение от “Audio Engineering Society” - аудиоинженерное общество, - организация по стандартизации, которая определяет структуру цифрового сигнала для профессионального входа аудио). Следовательно, для датирования изображений на основании бортового времени необходимо специально разработать физический модуль, позволяющий конвертировать бортовое время во временной код AES; и

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

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

Настоящее изобретение призвано устранить все или часть этих недостатков. В частности, настоящее изобретение призвано решить все или часть нижеуказанных задач.

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

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

Третья задача состоит в обеспечении записи всех типов форматов. Действительно, появляются все более новые форматы, в частности, при высоком разрешении на выходе вычислителей, например, ARINC (сокращение от “Aeronautical Radio, Incorporated”, зарегистрированный товарный знак, - авиационная радиокомпания, стандарт 818 которой касается бортовой цифровой шины видео), VGA, данных, описывающих испытание, которые надо объединить, функций предварительного запуска и воспроизведения (на английском “play” или “replay”). Кроме того, появляются новые мощные алгоритмы сжатия и оборудование, обеспечивающее большую пропускную способность. Таким образом, изобретение ставит задачей определение бортовой системной архитектуры, не специфической для видео, а также формата файла, позволяющего собирать, сжимать, синхронизировать, сохранять, воспроизводить и использовать различные потоки данных, видеоинформацию, аудиоинформацию, параметры, графику, причем без количественного и качественного ограничения.

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

- множество источников потоков данных, предназначенных для записи,

- по меньшей мере, один источник датированных значений параметров записи, и

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

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

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

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

Благодаря этим признакам отпадает необходимость в синхронизации потоков во время сбора информации.

Запись потоков в нескольких разных файлах имеет следующие преимущества:

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

- на земле хранение разных потоков в отдельных файлах позволяет ограничить размер файлов и количество обрабатываемых данных в зависимости от запросов, и только файлы, содержащие запрашиваемые потоки, должны, например, помещаться “nearline”.

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

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

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

Конечной целью является получение оптимизированных “workflows” (на земле и в полете) с учетом требований для летных испытаний. Следует напомнить, что “workflow” является потоком информации внутри одной организации, например, таким как автоматическая передача документов между лицами. “Workflow” (в буквальном переводе «рабочий поток») называют компьютерное моделирование и информационное управление совокупностью выполняемых задач и различных участников, вовлеченных в осуществление рабочего процесса (называемого также производственным процессом или процедурой предприятия). Термин “workflow” можно перевести на французский язык как «электронное управление рабочими процессами». На практике “workflow” описывает схему подтверждения, выполняемые задачи между различными участниками процесса, сроки, режимы подтверждения и предоставляет каждому из участников информацию, необходимую для выполнения его задачи. В целом он обеспечивает отслеживание и идентифицирует участников, уточняя их функцию и наилучший способ ее реализации. Движком “workflow” является программное устройство, позволяющее реализовать одно или несколько определений “workflow”. Не вдаваясь в языковые тонкости, это программное устройство можно называть просто “workflow”.

Управление содержимым (данные, видеоинформация, аудиоинформация, графика) в компьютерной среде без кассет позволяет:

- ограничить расходы и

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

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

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

Согласно частным отличительным признакам средства записи выполнены с возможностью динамичной записи значений параметров, по меньшей мере, в один файл.

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

Например, данными, связанными с испытанием, являются тип испытания, номер испытания, тип самолета, номер самолета и номер полета.

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

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

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

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

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

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

Таким образом, датирование является очень точным.

Согласно частным отличительным признакам средства записи выполнены с возможностью формирования данных, происходящих из источников данных, в виде файлов в формате MXF (сокращение от “Material Exchange Format” - формат обмена материалами).

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

Этот формат обеспечивает механизмы, отвечающие условиям IEV (УЛИ), в частности:

- управление файловым режимом и различными потоковыми режимами,

- поддержка внешних ссылок,

- синхронизация произвольного числа потоков разных типов,

- родовой механизм для произвольного доступа, и

- самое развитое управление метаданными: управление статическими и динамическими метаданными, управление диапазоном метаданных, стандартизованные “frameworks” («каркасы») метаданных, покрывающие самые широкие потребности, возможность определения собственных “frameworks” метаданных.

Согласно частным отличительным признакам потоки данных датируются в момент их сбора с использованием внутренних часов, синхронизированных по часам летательного аппарата. Например, установку времени внутренних часов может производить внешний сервер NTP или преобразователь GMT/Timecode AES на основе ввода временного кода AES. В этом случае таблицы с индексами позволяют найти изображение, связанное с этим временным кодом. Этот механизм позволяет обеспечивать синхронное считывание потоков записанных данных, даже если они не используют одно и то же опорное время.

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

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

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

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

Таким образом, обеспечивают повременную реорганизацию параметров, чтобы их можно было хранить и использовать так же, как и поток аудио/видео.

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

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

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

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

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

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

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

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

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

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

Согласно частным отличительным признакам средства записи выполнены с возможностью определения дескриптивных метаданных, позволяющих дополнять каждый файл информацией, предназначенной для пользователя и организованной в виде “framework” («каркаса»).

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

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

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

отличающийся тем, что содержит:

- этап записи для сохранения данных различных потоков данных в отдельных файлах, и

- этап объединения записанных данных в каждом файле вместе с упомянутыми значениями параметров.

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

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

Фиг. 2 - логическая схема частного варианта выполнения устройства в соответствии с настоящим изобретением.

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

Фиг. 4, 5 и 6 - схематически представляют структуры записанных файлов согласно трем разным вариантам записи.

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

Фиг. 8 - схематически представляет “framework” («каркас»), применяемую в частном варианте реализации способа и устройства в соответствии с настоящим изобретением.

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

Фиг. 15 и 16 - представляют в виде логических схем частных вариантов реализации устройства в соответствии с настоящим изобретением.

В дальнейшем тексте описания термин «диск» относится как к жесткому диску, так и к компакт-дискам.

Как показано на фиг. 2, с точки зрения логики архитектура частного варианта выполнения устройства в соответствии с настоящим изобретением, основанного на центральном сервере 200, делится на четыре уровня. Слева на фиг. 2 показаны интерфейсные источники, дающие возможность сбора данных из любого типа источника. Как показано на фиг. 2, речь идет о входах рабочих данных и времени самолета 201, камер 202, графического источника 203, источника ASVI 204 и источника аудио 205.

На фиг. 2 показаны также системы, обеспечивающие маршрутизацию от источников к серверам сбора через сетку коммутации 206, содержащую, в случае необходимости, систему генерирования мозаики, предназначенную для объединения нескольких источников SD в изображение HD для формирования мозаики изображений, позволяющей экономить число каналов записи. В центре на фиг. 2 показаны системы сбора потоков аудио/видео и параметров самолета. Они предназначены для сбора сигналов, передаваемых различными источниками, и для их формирования в виде файлов в формате MXF (сокращение от “Material Exchange Format” - формат обмена материалами). Эти различные системы сбора могут работать независимо друг от друга (нет необходимости в их синхронизации). На фиг. 2 в этой части, кроме интерфейса «человек-машина» IHM 210, находятся модуль сбора видео 211, модуль сбора аудио 212 и модуль сбора метаданных (производственных данных и бортового времени) 213, обозначенный на фигурах “MTD”.

Наконец, на фиг. 2 показана система синтеза, сохранения и считывания 220, которая предназначена для сбора различных файлов в формате MXF, их сохранения на дисках 225 и их повторного считывания. Различные файлы могут быть записаны независимо друг от друга (нет необходимости в их синхронизации). Сводный файл создается и записывается последовательно, что позволяет синхронно повторно считывать файлы. Для этого система сохранения 220 содержит модуль 230 создания внешних ссылок, интегрируемых в сводный файл модулем 235 создания сводного файла.

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

Формат MXF является развивающимся. Чтобы соответствовать решению новых задач, созданы новые стандарты и рекомендации. Так, стандарт «422М» недавно был добавлен для описания контейнера “Jpeg2k”. Рекомендация “RP 2008” дополняет стандарт «381М» для «Н.264». В настоящее время создаются стандарты для “VC-1” и “VC-3”.

Формат MXF предоставляет все механизмы, отвечающие требованиям IEV, в частности:

- управление файловым режимом и различными потоковыми режимами,

- поддержка внешних ссылок,

- синхронизация произвольного числа различных потоков данных,

- родовой механизм для произвольного доступа, и

- развитое управление метаданными: управление статическими и динамическими метаданными, управление диапазоном метаданных, каркас “framework” стандартных метаданных, отвечающий широкому кругу потребностей, возможность определять “framework” для собственных метаданных.

Действительно, важным моментом изобретения является использование и определение собственного каркаса “framework”, адаптированной к потребностям IEV и авиации для более общих вариантов использования.

Следует напомнить, что “framework” является совокупностью библиотек, обеспечивающей быстрое развитие приложений. Она предоставляет достаточно программных блоков для создания завершенного приложения. Эти компоненты организуют таким образом, чтобы их можно было использовать во взаимодействии друг с другом, в частности, согласно так называемым технологиям «урбанизации».

Были сделаны попытки перевода термина на французский язык. Так иногда встречается термин “cadre d'application” (рамки приложений), предложенный Организацией французского языка Квебека, или “cadriciel” (рамки приложений).

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

Если использование термина «программная библиотека» ограничивается собственно библиотекой, то термин каркас “framework” можно применять расширительно, включая в него также программную архитектуру, рекомендованную для этой библиотеки (организация по слоям), а даже окружающую среду развития, даже если она может управлять разными “frameworks”.

Существуют различные типы “frameworks”:

- “framework” системной инфраструктуры: для разработки оперативных систем, графических интерфейсов, инструментов связи;

- “framework” межпрограммная интеграция: для объединения разнородных приложений. Для предоставления различных технологий в виде единого интерфейса;

- “framework” предприятия: для разработки приложений, специфических для определенного сектора деятельности предприятия; и

- ориентированные “frameworks” системы управления содержимым.

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

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

- источники SD: разрешение PAL и NTSC,

- источники HD: разрешения 1920×1080, 50 кадров в секунду и другие,

- источники ASVI (сокращение от “Avionic serial video interface” - авиационный последовательный видеоинтерфейс) или “Arinc818”: разрешения 1024×768, 60р, то есть 60 изображений в секунду в поступательном режиме,

- источники VGA, SVGA (сокращение от «super video graphics array» для супер видеографическая матрица) и XGA (сокращение от «extended graphics array» для расширенная графическая матрица): разрешения от 640×480 до 1280×1024 60р,

- источники аудио, аналоговые или цифровые,

- источник данных параметров самолета: примерно 50 параметров, частота, например, пять сборов данных в секунду с возможностью сбора гораздо большего количества данных и любого типа, и

- другие типы источников.

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

Факультативно сетка коммутации позволяет сгруппировать разветвления в одном месте и выбирать камеры, с которых необходимо вести запись (как правило, используют больше камер, чем число имеющихся каналов записи). Следует отметить, что необходима только одна сетка SD/HD-SDI. Она управляет несинхронными источниками и управляется интерфейсом управления IHM, который, например, является меню, выводимым на видеоэкран отображения.

Генераторы мозаики позволяют сгруппировать при помощи мозаики несколько камер на одном канале записи. Можно, например, сгруппировать несколько камер SD на одном канале HD без существенной потери качества.

Сбор аудио/видео потоков объединяет несколько этапов:

- собственно сбор потоков,

- сжатие этих потоков,

- датирование этих потоков, и

- упаковка сжатых и датированных потоков в файлы в формате MXF.

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

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

- на входе средств записи устанавливают преобразователь GMT/Timecode AES. Эти средства записи оборудованы входом временного кода AES, который позволяет датировать полученные изображения в зависимости от временного кода AES. Этот метод можно применять напрямую, так как датирование на основании временного кода AES присутствует на всех серверах сбора видеоинформации, имеющихся на рынке. Он основан исключительно на аппаратных средствах и, следовательно, является более точным. Вместе с тем, он требует разработки аппаратного преобразователя GMT/Timecode AES, который не обладает достаточной надежностью при неисправностях (датирование становится невозможным в случае неисправности преобразователя или проблемы в передаче сигнала AES);

- метод, основанный на внутренних часах серверов: внутренние часы серверов сбора синхронизированы по часам самолета при помощи тех же механизмов, что и на совокупности приборов сбора параметров самолета, или при помощи сервера NTP (сокращение от “Network Time Protocol” - протокол сетевого времени) бортового вычислителя. Например, установку времени внутренних часов можно произвести при помощи внешнего сервера NTP или преобразователя GMT/Timecode AES через вход временного кода AES.

Благодаря этим временным данным средства записи выполнены с возможностью выдавать записанные данные путем воспроизведения одного или нескольких синхронизированных потоков данных.

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

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

Каждый поток последовательно упаковывают в файл в элементарном формате MXF. Этот файл содержит статические метаданные, описывающие самолет, испытание и источник данных, дорожку аудио или видео, содержащую собранный поток, и динамическую дорожку временного кода или «timecode», содержащую даты каждого кадра. Этот файл следует структуре, выбранной для бортовых файлов, детально показанной на фиг. 7.

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

Сбор параметров самолета объединяет несколько этапов:

- установка соединения с системой передачи данных,

- сбор параметров (значения и даты сбора), предоставляемых системой передачи данных,

- сортировка этих параметров в зависимости от даты их сбора, и

- упаковка в файл в формате MXF.

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

Третий этап является специфическим для IEV видео. Она позволяет временно перегруппировать параметры таким образом, чтобы их можно было сохранить и использовать так же, как и аудио/видео поток. Действительно, аудио/видео поток разделен на сегменты фиксированной продолжительности, и эта продолжительность, как правило, соответствует, как правило, периоду или частоте кадров или «framerate» изображений, например, 40 мс для видео с 25 кадров/сек. Программное обеспечение сбора параметров делит время на сегменты фиксированной продолжительности (соответствующие необходимой частоте для параметров) и для каждого сегмента и каждого параметра сохраняет самое последнее значение параметра, полученное в этом временном сегменте (или последнее имеющееся значение, если в течение этого временного сегмента не было получено никакого значения).

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

Как и для аудио/видео потоков, в программное обеспечение сбора интегрируют функцию предварительной записи.

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

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

В нижеследующей таблице приведены примеры скорости передачи и объемов необходимых файлов:

	Скорость (Мбит/с)	Скорость (Мбайт/с)	Область 4ч (Гбайт)	Область 6ч (Гбайт)
1 камера SD	10	1,3	18	27
1 камера HD	40	5	72	108
1 прокси SD	1	0,1	1,8	2,7
Конфигурация 6 SD	70	8,8	126	189
Конфигурация 4 SD+2 HD	130	16	234	351

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

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

Во время летного испытания запись можно остановить, опять запустить или переконфигурировать. Предпочтительно для облегчения использования, как показано на фиг. 3, записи подразделяют на последовательности 305, 310, 315, 355, 360 и 365, сплошные, то есть без перерывов, и однородные, то есть без изменения конфигурации. Следовательно, создают новый каталог с новыми файлами для каждой новой последовательности каждый раз, когда запись возобновляют после перерыва 320 или производят переконфигурирование, независимо от причины (переключение камеры, смена диска, повторный запуск после аварии), а данном случае после коммутации 370.

Что касается интерфейса человек-машина (“IHM”), благодаря ему пользователь может изменить источники, которые он желает записать. Чтобы произвести переключение источников, не обращая внимание на то, что они не являются синхронными, предусматривают два решения:

- в первом варианте синхронизируют все источники SDI, чтобы избежать потери изображения: это решение предполагает установку оборудования синхронизации или коммутационной сетки, оснащенной функциями “relocking”,

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

Чтобы ограничить влияние «аварий» и сбоев, предусматривают:

- создание файлов в формате MXF в «потоковом» режиме, то есть непрерывно, что позволяет ограничить потери данных в случае аварии,

- функции перезапуска после ошибок: в случае ошибки перезапуск сбора данных происходит автоматически,

- функции диагностики, проверяющие состояние IEV видео перед испытанием,

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

Что касается выбираемого формата файла, файлы, используемые в рамках IEV видео, позволяют сохранять несколько типов видео и аудиопотоков: видео SD (форматы PAL и NTSC), видео HD (форматы типа 720р и 1080i), видеоинформацию из компьютеров (форматы типа VGA), видеоинформацию из кабины экипажа (форматы ASVI), аудиоинформацию, другие данные, которые могут понадобиться в будущем.

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

Файлы позволяют документировать эти аудио/видео потоки стандартных метаданных (права, название, участники,…). Файлы позволяют также сохранять производственные метаданные, которые применяют для всех потоков (описание самолета и полета,…) или только для некоторых потоков (описание камеры,…). Эти метаданные можно легко изменять и индексировать в базе данных.

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

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

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

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

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

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

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

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

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

- использовать в «потоковом» режиме: в этом случае файл передается пользователю через сеть, при этом пользователь не может копировать файл, и

- зашифровать, чтобы препятствовать его считыванию.

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

Что касается кодеков, описанная выше архитектура позволяет использовать одновременно разные кодеки, например, “Mpeg4 AVC (H.264)”, “VC-1”, “Jpeg2k”, “Mpeg2”, кодеки “Dirac” и “H.265”.

Что касается способа записи, формат файла MXF позволяет сохранять потоки в нескольких разных режимах:

- в «файловом» режиме, в котором файл делится на два или три блока, как показано на фиг. 4. Заголовок 405 (на английском языке “header”) и/или концевая шапка 410 (на английском языке “footer”) файла содержат информацию, позволяющую повторно считывать файл. Тело 415 файла содержит потоки. Этот режим используют, когда файлы хранятся на носителе, обеспечивающем произвольный доступ (диск или CD);

- в режиме «потокового сбора» (во французской терминологии «непрерывного сбора»), в котором файл делится на несколько разделов, как показано на фиг. 5. Каждый раздел содержит собранный поток 505 и 515, за которым следует блок информации 510 и 520, позволяющий повторно считывать эти потоки. Этот режим используют, когда файлы записывают на линейном носителе (лента) или когда сбор может неожиданно прерваться. Только потоки, находящиеся после последнего читаемого блока информации, не могут быть легко декодированы;

- в режиме «потокового считывания», в котором файл делится на несколько разделов, как показано на фиг. 6. Каждый раздел содержит собранный поток 610 и 620, которому предшествуют блок информации 605 и 615, позволяющий считывать эти потоки. Этот режим используют, когда файлы необходимо повторно считывать с линейного носителя (лента) или когда их необходимо передавать в сеть по проводам или при помощи волн. Только потоки, предшествующие первому читаемому блоку информации, не могут быть декодированы.

В рамках настоящего изобретения режимы «потокового сбора» и «файловый» режим применяют соответственно на борту и на земле.

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

Что касается внешних ссылок, формат MXF позволяет сохранять различные потоки, которые могут представлять собой последовательность аудио/видео в разных файлах, называемых «элементарными» файлами, и создавать файл, называемый «сводным файлом», который ссылается на файлы, содержащие предназначенные для повторного считывания потоки. Каждый поток сохраняется в отдельном файле. Сводный файл создают для каждой передачи. Он указывает, какие из потоков предназначены для передачи. Этот механизм позволяет записывать и использовать потоки в разных файлах.

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

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

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

- он позволяет применять контейнер, содержащий потоки в необработанном виде: аудио и/или видео потоки, динамические элементы (прерывистые временные коды и/или динамические метаданные). Как правило, эти потоки делят на куски, которые соответствуют фиксированной продолжительности, продолжительности изображения или GOP (сокращение от “group of pictures” - группа изображений), и в этом случае говорят о “frame-wrapping”. Потоки могут быть также упакованы в блок (который соответствует общей продолжительности последовательности), и в этом случае говорят о “clip-wrapping”.

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

Что касается управления метаданными, файлы в формате MXF используют только одну модель метаданных, которая позволяет определить одновременно структурные метаданные и дескриптивные метаданные. Структурные метаданные объединяют важную информацию, позволяющую описать логическую структуру файла, а также некоторую информацию, позволяющую отслеживать его создание и его изменение. Они являются обязательными и стандартизованными. Дескриптивные метаданные позволяют дополнить файл информацией, предназначенной для пользователя. Они являются факультативными. Они организованы в виде “framework”.

В настоящее время уже стандартизированы три “frameworks” под названием “DMS-1”, чтобы удовлетворять потребности в области аудиовизуального производства. Можно также определить и использовать “frameworks” собственных метаданных (в этом случае говорят о “Dark Metadata”). Некоторые программы, применяющие формат MXF, позволяют просматривать содержимое “frameworks” DMS-1 и позволяют их импортировать и экспортировать в виде файлов формата XML (сокращение от “extensible markup language” - расширяемый язык разметки). Но при этом они игнорируют “frameworks”, хотя их и не исключают.

Что касается механизмов датирования и синхронизации, формат MXF обеспечивает датирование и синхронизацию разных потоков. Каждая дорожка (аудио/видео поток или динамические метаданные) имеет свое собственное опорное время (“framerate”) и начало. Устройства считывания файлов в формате MXF обеспечивают произвольный доступ к данным на основании абсолютного времени при помощи следующего механизма: для каждой дорожки абсолютное время конвертируется во временной код в зависимости от опорного времени дорожки. В этом случае таблицы индексов позволяют найти изображение, связанное с этим временным кодом, даже в структуре GOP. Этот механизм обеспечивает синхронное считывание дорожек, даже если они не используют одно и то же опорное время.

Файлы в формате MXF позволяют управлять некоторыми более специфическими функциями, в частности:

- «Частичное восстановление»: речь идет о механизмах, позволяющих извлечь из файла в формате MXF потоки и метаданные в данном диапазоне времени и записать их в виде необработанных файлов или в другой файл формата MXF, и

- «Шифрование AES»: существенные данные в файлах формата MXF можно зашифровать с использованием алгоритма AES.

Чтобы избежать проблем взаимодействия, предпочтительно создают файлы, имеющие простую и распространенную структуру, например, типа “Op1a”, и строго соблюдающие стандарт (такие инструменты, как программа, применяющая формат MXF и называемая “analyser” или “analyzer” IRT (сокращение от “Institut für Rundfunktechnik”, зарегистрированные товарные знаки), позволяющая обнаруживать несовместимость файлов со стандартом).

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

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

- на земле сохранение разных потоков в отдельных файлах позволяет ограничить размер файлов и количество данных, обрабатываемых в зависимости от запросов, и только файлы, содержащие запрашиваемые потоки, должны, например, помещаться “nearline”. Следует напомнить, что “Nearline” означает систему быстрого доступа, которая, как и для носителя данных с произвольным доступом, позволяет быстро получить данные, архивированные на носителе с последовательным доступом.

В варианте выполнения применяют дробление потоков на элементарные и используют структуру файлов, показанную на фиг. 7.

Как показано на фиг. 7, используют два типа файлов:

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

- сводный файл 735, который ссылается на различные файлы 705-730, содержащие потоки. Уже сам сводный файл 735 позволяет получать всю информацию о летном испытании и различные потоки: сводный файл 735 статические метаданные, описывающие испытание (идентификатор самолета и полет), и статические метаданные, описывающие каждый из источников (идентификатор камеры, микрофона или описание параметров...). Сводный файл 735 позволяет также использовать разные потоки синхронно.

Что касается « frameworks метаданных», различные файлы в формате MXF содержат статические дескриптивные метаданные (права, идентификатор самолета…) и иногда динамические метаданные (параметры самолетов), отвечающие потребностям самолета, то есть потребности объединять некоторые измеренные параметры, такие как скорость или давление, в зависимости от испытания, производимого на самолете.

Следует заметить, что “framework” стандарта “DMS-1” можно использовать для стандартных статических метаданных, которые не являются конфиденциальными. Действительно, эти метаданные можно найти в некоторых программах, применяющих формат MXF. Например, используют «производственный framework» для указания правообладателя и его координат.

Можно также использовать “framework” DMS-1 опосредованно для сохранения статических производственных метаданных (идентификация самолета, полета, камеры и микрофонов, описание параметров). Можно, например, использовать «сцену» “framework” для идентификации самолета и камеры, что позволяет отображать их в большинстве программ, применяющих формат MXF.

В предпочтительных вариантах выполнения используют собственный каркас “framework” для этих статических производственных метаданных, так как он позволяет точно присвоить им необходимое наименование и тип и, таким образом, облегчает их визуальное отображение, их редактирование и индексацию.

Кроме того, этот собственный “framework” адаптирован для сохранения данных параметров самолетов, так как он позволяет значительно ограничить необходимое количество байтов для сохранения этих параметров (примерно 16 байт на параметр вместо нескольких сотен при опосредованном “framework” DMS-1).

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

В вариантах выполнения применяют “framework”, структура которого показана на фиг. 8. Такой “framework” 805 позволяет сохранять статические метаданные:

- тип самолета и идентификатор самолета, блок 810;

- тип полета (статическое испытание, летное испытание, коммерческий полет) и номер рейса, блок 815;

- идентификатор источников, например, тип, P/N (сокращение от “Part Number” - номер части), который индивидуально идентифицирует оборудование, S/N (сокращение от “Serial Number” - серийный номер), который идентифицирует серийный номер оборудования, заглавие и зарезервированное пространство, блок 820;

- дополнительные аннотации, относящиеся к источникам, блок 825, и

- диапазон времени в UTC (координированное универсальное время, при этом UTC является компромиссом между английским “CUT” от “Coordinated universal time” и французским “TUC”), для полета и для каждой записи, блок 830.

Кроме того, этот “framework” позволяет сохранять параметры самолетов и параметры, характерные для каждого источника, например, для EVS (сокращение от “Enhanced Vision System” - усовершенствованная система обзора): расчетное положение горизонта, значения коэффициента усиления, активация противообледенительной системы, режим, положение GPS (сокращение от “Global Positionning System” - система глобального позиционирования):

- описания каждого параметра сохраняются статично, и им присваивается UL (сокращение от “Universal Label” - универсальная метка), блок 835, и

- выборки параметров сохраняются динамично, блок 840. Эти выборки содержат только значение (без единицы измерения) и время GMT (дата сбора) каждого параметра, чтобы ограничить необходимое пространство. Эти выборки ссылаются на описатели, используя UL, что позволяет находить наименование и единицу измерения параметра.

Этот “framework” 805 разработан для удовлетворения нужд применения в авиации, отличных от летных испытаний, что будет пояснено ниже.

Что касается структуры аудио/видео файлов, каждый аудио или видеопоток сохраняется в отдельном файле 905, показанном на фиг. 9, который можно использовать изолированно в устройстве считывания или в программе монтажа, применяющей формат MXF.

Таким образом, эти файлы содержат только один «пакетный источник» 910, который содержит прерывистый аудио или видеопоток 915 и, в случае необходимости, прерывистую дорожку временного кода (не показана), и только одно «пакетное средство» 920, которое позволяет полностью воспроизвести этот поток. Пакетное средство 920 имеет на выходе требуемую форму, то есть форму, считываемую классическим видеоплейером. Элементы этой структуры устанавливают и соединяют с необработанными данными, «пакетный источник», при помощи “file package” (что может перевести на французский язык как «упаковочный файл»). Эта логическая схема является очень компактной: типичный “file package” соответствует примерно 1 кбайт, тогда как представляемая им сущность может иметь объем в несколько мегабайт, гигабайт или даже терабайт.

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

Эти файлы могут иметь две разные физические структуры:

- на борту, как показано на фиг. 10, файлы 105 собираются в режиме «потокового сбора», чтобы их можно было использовать, даже если они не были закрыты правильно. Она делятся на несколько разделов 1010, 1015 и 1020, которые соответствуют выбранной продолжительности. Таким образом, в случае аварии только потоки, находящиеся в последнем разделе 1020, не могут быть легко декодированы. Каждый раздел состоит из дерева 1025 метаданных и контейнера 1030 существенных данных. Каждое дерево 1025 метаданных содержит структурные метаданные (которые содержат логическую структуру файла) и статические дескриптивные метаданные (права, идентификатор самолета и полета, идентификатор камеры или микрофона). Каждый контейнер 1030 существенных данных упаковывает поток в режиме “frame-wrapping” по фиксированной продолжительности (изображение или GOP) с данными, которые позволяют правильно передать файл (например, информация о размере раздела, его положении в потоке…). На земле, как показано на фиг. 11, файлы конвертируют в «файловом режиме». Получаемые в результате файлы 1105 содержат только раздел заголовка 1110 и раздел концевой шапки 1115. Эти разделы содержат дерево 1120 метаданных, которое объединяет структурные метаданные и статические дескриптивные метаданные. Используют только один контейнер 1125 для упаковки потока (в случае необходимости, зашифрованного) в “clip-wrapping” в только один блок 1130. Автоматически добавляется таблица 1135 индексов, которая обеспечивает быстрый доступ к каждому изображению при помощи известных технологий.

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

Вместе с тем существуют некоторые различия по метаданным и упаковываемым потокам, пояснение которых следует ниже со ссылками на фиг. 12. Первое различие касается статических дескриптивных метаданных. Набор (на английском языке “set”) метаданных, идентифицирующих источник аудио/видео, заменен на совокупность или список наборов метаданных 1205-1220, описывающих параметры. Каждый набор описания параметра сохраняет наименование, описание и единицу измерения параметра, а также универсальную метку UL (Universal Label), идентификатор, который разный для каждого параметра.

Второе различие касается существенных данных. Аудио/видео поток заменен дорожкой динамических метаданных типа “timeline” 1225, при этом “timeline” является методом датирования данных, который содержит выборки параметров. Эти выборки сортируют и распределяют в сегментах фиксированной продолжительности (например, 200 мс при 5 pps (сокращение от «параметры на секунду») 1230 в зависимости от даты их сбора (а не в зависимости от даты получения сервером), и сохраняют одну выборку на параметр и на сегмент. Каждую выборку 1235 сохраняют вместе с соответствующим набором метаданных выборки параметра 1240, который содержит значение и дату сбора значения параметра и обозначает соответствующий набор описания параметра, используя его универсальную метку UL.

Что касается сводного файла, который ссылается на все другие файлы, чтобы их можно было считывать синхронно, он состоит из нескольких «пакетных источников» 1205, каждый из которых ссылается на файл, содержащий поток видео, аудио или параметры, и «пакетное средство» 1310, которое позволяет воспроизводить все потоки синхронно, как показано на фиг. 13. Структура типа “Op1b” позволяет управлять этой сложной системой. Таким образом, этот файл может легко стать взаимодействующим. Физическая структура этого файла, напротив, является очень простой, как показано на фиг. 14. Этот файл 1405 содержит только «раздел заголовка» 1410, «заголовок метаданных» 1420 и «раздел концевой шапки» 1415. Заголовок 1410 и концевая шапка 1415 содержат структурные метаданные, которые представляют логическую структуру файла, и статические метаданные, которые повторяют общие статические метаданные (идентификатор самолета и полета), и статические метаданные, присоединяемые к каждому потоку (идентификатор источников, список параметров).

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

- выбор сжатия, программного или аппаратного,

- выбор просмотра, и

- добавление модуля для функции воспроизведения.

Кроме того, для глобальной архитектуры возможны варианты. В первом варианте, показанном на фиг. 15, применяющем сеть 1505, предназначенную для видео, датчики напрямую передают данные в файловом формате в коммутатор (на английском “switch”) 1515, что предполагает определенный уровень сложности датчиков. Эта архитектура выдвигает проблему реального времени на уровне визуального отображения, управляемого сервером 1510. Качество сервиса и требуемое изображение учитываются для определения размеров сети 1505. Действительно, объемы, передаваемые датчиками, являются очень большими и требуют управления без потерь.

а) Во втором варианте, показанном на фиг. 16, применяют глобальную сеть 1605, не предназначенную для видео, в которой датчики видео 1610 находятся на том же уровне, что и любой другой датчик IEV 1615, 1620 или 1625. В этом случае после сбора данных на уровне датчика эти данные упаковывают с форматами, адаптированными для каждого приложения, и передают по той же сети через серверы 1630 и 1635 и коммутатор 1650. Эта архитектура тоже выдвигает проблему реального времени на уровне визуального отображения на экране 1645 отображения, используемом сервером 1640 отображения. Качество сервиса и требуемое изображение принимаются во внимание для определения размеров сети 1605. Действительно, объемы, передаваемые датчиками, являются очень большими и требуют управления без потерь.

В третьем варианте применяют комбинацию двух предыдущих вариантов.

1. Устройство сбора и записи данных, снимаемых в летательном аппарате, содержащее:
- множество источников (202-205) потоков данных, предназначенных для записи,
- по меньшей мере, один источник (201) датированных значений параметров записи, и
- средства (220, 230, 235) записи данных, происходящих из потоков данных, и значений параметров, по меньшей мере, на одном энергонезависимом носителе информации,
отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью сохранения в отдельных файлах данных из различных потоков данных, объединенных с упомянутыми датированными значениями параметров записи, при этом средства (220, 230, 235) записи выполнены с возможностью записи каждой единицы данных потока данных в сочетании с универсальным временем ее сбора.

2. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи содержат средство (230, 235) создания сводных файлов, создаваемых по мере записи характеристических файлов данных, поступающих из разных источников данных, при этом сводный файл позволяет ссылаться на и синхронно повторно считывать эти файлы и содержит внешние ссылки, указывающие на каждый из характеристических файлов данных, поступающих из источников данных.

3. Устройство по любому из пп.1 или 2, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью динамичной записи значений параметров, по меньшей мере, в один файл.

4. Устройство по п.3, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью записи дескрипторов параметров, а также данных, относящихся к испытанию, используя универсальную структуру данных.

5. Устройство по п.1, отличающееся тем, что содержит средство (220) считывания, выполненное с возможностью создания сводного файла, по меньшей мере, для одной передачи записанных данных, поступающих из потоков данных, при этом сводный файл позволяет ссылаться на и синхронно повторно считывать файлы, содержащие предназначенные для передачи данные, и содержит внешние ссылки, указывающие на каждый из характеристических файлов данных, предназначенных для передачи.

6. Устройство по п.1, отличающееся тем, что содержит средство (206) маршрутизации данных, происходящих из разных источников, в средства (220, 230, 235) записи, при этом средства записи содержат средство датирования, выполненное с возможностью компенсации задержек передачи, вызванных средством маршрутизации.

7. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью формирования данных, происходящих из источников данных, в виде файлов в формате MXF (сокращение от "Material eXchange Format" формат обмена материалами).

8. Устройство п.1, отличающееся тем, что, по меньшей мере, один источник (201) значения параметра содержит преобразователь универсального временного значения во временной код, относящийся к источнику данных потока.

9. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью датирования потоков данных в момент сбора с использованием внутренних часов, синхронизированных по часам летательного аппарата.

10. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи содержат средства упаковки каждого потока данных, поступающего от источника потока данных, в файл, который содержит статические метаданные, идентифицирующие летательный аппарат, летное испытание и упомянутый источник данных, данные потока данных и информацию, характеризующую момент съема упомянутых данных.

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

12. Устройство по п.1, отличающееся тем, что потоки данных, поступающих из источников потоков данных, делятся на временные сегменты фиксированной продолжительности, при этом средства (220, 230, 235) записи записывают для каждого временного сегмента и каждого параметра самое последнее значение параметра, имеющееся в распоряжении в течение этого временного сегмента.

13. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью записи файлов дескриптивных метаданных, содержащих значения параметров, распределенных в сегментах фиксированной продолжительности в зависимости от даты их сбора, при этом для каждого параметра и для каждого сегмента записывается только одно значение параметра.

14. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью разделения записей на последовательности, сплошные без перерывов и однородные без изменения конфигурации, при этом каждый раз, когда происходит повторный запуск или переконфигурирование записи, создается новый каталог, содержащий новые файлы для каждой новой последовательности.

15. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью сохранения одних и тех же данных с несколькими разными степенями и алгоритмами сжатия.

16. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью сохранения во время летного испытания данных в режиме «потокового сбора», в режиме записи, в котором файл делится на несколько разделов, содержащих данные, по меньшей мере, одного потока данных, за которыми следует блок информации, позволяющий повторно считывать упомянутые данные потока данных.

17. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью преобразования на земле записанных данных для их записи в «файловом» режиме, в котором файл делится на несколько блоков, при этом заголовок и/или концевая шапка файла содержат информацию, позволяющую повторно считывать файл, и тело файла содержит данные из потока данных.

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

19. Устройство по п.1, отличающееся тем, что (220, 230, 235) средства записи выполнены с возможностью сохранения, по меньшей мере, одного потока данных в его необработанном виде без сжатия.

20. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью определения дескриптивных метаданных, позволяющих дополнять каждый файл информацией, предназначенной для пользователя и организованной в виде каркаса framework.

21. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью записи файлов дескриптивных статических метаданных, содержащих списки наборов метаданных, описывающих значения параметров.

22. Устройство по п.1, отличающееся тем, что средства (220, 230, 235) записи выполнены с возможностью предоставления записанных данных в виде воспроизведения одного или нескольких синхронизированных потоков данных.

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