采集、 记录和使用航空器中已捕捉数据的设备和方法 技术领域 本发明涉及采集和记录航空器中已捕捉数据的设备和方法。 它特别是涉及允许记 录和可视化视频、 音频、 图形数据以及更普遍的任何类型数字数据的飞行测试设备。
背景技术 飞行测试设备， 以熟知的方式， 负责记录， 尤其是测试摄像机的视频数据源， 例如 SDI( 串行数据界面 “Serial Digital Interface” 的缩写 )， 或来自飞机系统的视频， 以及 表示相关飞机参数的某些数据。 记录系统是有必要调整以符合测试飞机的需求的所有权者 的系统。它们将数据存储在磁带盒上。根据所处时代及市场上可获得的技术， 不同类型的 视频记录格式及记录装置被使用。
图 1， 以示意图形式， 描绘现有技术的一连串视频测定功能块。 在这样一个系统中， 为飞机参数数据标注时间和将飞机参数数据与视频建立关联的需求以及记录尽可能多的 通道的需求， 促使通过尽可能改变某些功能和进行质量和数量的权衡以实现市场上可获得 的专业设备的适应调整。
正如我们在图 1 中所见的， 视频由摄像机传感器 105 获得并且随后由处理装置 115 进行处理。一个 GMT( 格林威治标准时间 “Greenwich Mean Time” 的缩写 )110， 换而言之 基于一个通用时间的一个实时计时， 采用该计时以便精确知道测试的进展并且将视频与并 行获得的其他所有数据， 尤其是飞机参数 120， 相关连。对于某些飞机， 飞机参数由机载计 算机 ( 未被表示出 ) 计算出并编码。相应数据在参数数量和刷新频率上被限制。在处理装 置输出 115 处， 信号例如根据 SDI“SMPTE 259” 标准被传输。这样一种连接的速率固定在 270Mbps( 兆位 / 秒 )。
信号在自身测试时在一个可视化显示屏 125 上被可视化。我们注意到格式转换器 ( 未被表示出 ) 对于视频信号 SDI 的可视化是必需的。此外， 视频和元数据， 换而言之即参 数， 飞机、 飞行、 所用材料和时间的识别码被记录在磁带 ( 录像带、 录音带 )130 上以便通过 地面装置 135 对它们整理、 归档和 / 或存储。所用记录格式由所用记录器指定。该格式专 属于专业设备。此外， 飞机数据 ( 类型， 编号 ......) 被添加以方便归类和归档。这些信息 在磁带上是完整的。我们因此为每一个磁带得到一个笺头。
在地面上， 所获得的磁带随后在一个处理工作台上由专家整理。磁带的处理用线 性方式进行， 磁带应被遍历以找到所需的顺序。而且， 飞机的参数以局部的方式被记录， 处 理工作台与数据库之间的连接是必需的。
正如我们在阅读前面文章所理解的那样， 目前的 IEV( “飞行测试设备” 的缩写 ) 视 频机载结构因此相对复杂， 出于所用载体的原因， 换而言之即磁带。 ( 飞机的视频、 音频和参 数 )( 数据 ) 流事实上被记录在磁带上。
现有技术显示出诸多不便 ：
- 一个磁带录像机仅允许记录标准清晰度， 也被称作 “SD” 的视频 ( 数据 ) 流。要 记录高清晰度， 也被称作 “HD” 的视频 ( 数据 ) 流， 应该要使用 HDCam 类磁带录像机， 其额
外成本是巨大的。为了记录涉及驾驶舱仪表的 ASVI( 航空电子串行视频接口 “Avionics SerialVideo Interface” 的缩写 ) 或 VGA( 视频图形阵列 “Video GraphicsArray” 的缩写 ) 类型的图形页面， 应该要添加允许将这些信号转换成一个 SD 或 HD 视频信号的模块 ；
- 为 磁 带 录 像 机 上 的 图 像 标 注 时 间 由 一 个 AES( 音 响 工 程 协 会 “Audio Engineering Society” 的缩写， 一个定义数字信号结构并使其进入专业音频领域的规范化 组织 ) 信号提供的、 被称作 “Timecode” 的时间码来完成。能够将飞机时间转换成 AES 时间 码的一个实体模块因此应该被特别开发以便能够从飞机时间出发为图像标注时间而且
- 在磁带录像机上没有预留任何系统用于记录动态参数。允许在一个声道上为飞 机参数编码的一个实体模块因此应被开发出来以便允许记录这些飞机参数。 另外一个实体 模块也应该被开发出来以便在地面上处理时读取这些参数。
- 磁带组成一个线性载体。 这意味着不同的 ( 音频、 视频数据和参数 ) 流在采集时 应被同步。由于这些不同 ( 数据 ) 流的传输时间， 因此造成问题。 发明内容 本发明力求解决所有或部分这些不便。特别是， 本发明旨在解决下述的所有或部 分问题。
第一个问题在于以简单而非限制的方式关联和同步元数据、 视频数据、 音频数据 及每个 ( 数据 ) 流的时间通道。视频 ( 数据 ) 流应在信息无损换而言之在原生分辨率和频 率的情况下采集， 并且以压缩或非压缩的方式记录起来。特别是， 它涉及到在同一载体， 实 际中至少是一个硬盘上， 但最好是在不同的文件中， 记录不同的 ( 数据 ) 流， 这体现一个好 处是不必在采集这些 ( 数据 ) 流时同步它们。
第二个问题涉及到至此还被使用的记录载体， 磁带、 以及记录和再次读取的设备 的即将过时。 问题是找到一个交换格式， 它不仅满足机载限制而且适应地面所遇到的限制， 尤其是采集数据的自动存档和简单快速处理。最好的情况是， 我们力求为视频和已记录在 硬盘上的飞机数据的存档架构统一化。
第三个问题在于允许记录所有类型的格式。事实上， 在计算机的输出端， 新的、 尤其是高清晰度的格式出现， 例如 ARINC 818( 航空无线电公司 “Aeronautical Radio， Incorporated” 的缩写， 注册商标， 其 818 标准涉及一个航空电子数字视频总线 )， VGA， 描述 相关联测试的数据， pre-trigger 功能， 换而言之即预触发功能， 回放功能 ( 英语为 “play” 或 “replay” )。而且， 强大的压缩新算法和设备允许大 ( 数据 ) 速率出现。本发明因此力 求确定一种非特定于视频的机载系统架构以及一种允许不受数量和质量限制， 采集、 压缩、 同步、 储存及重放及处理不同视频、 音频数据、 参数、 图形数据流的文件格式。
本发明特别力求解决所有或部分这些问题。 为此效果， 根据第一方面， 本发明力求 提供一种采集和记录在航空器中捕捉的数据的设备， 包含 ：
待记录数据流的多个源，
被标注时间的记录参数值的至少一个源， 以及
在至少一个非易失信息载体上记录来自数据流的数据和参数值的记录装置，
其特征在于所述记录装置适于在相互独立的文件中存储不同数据流的数据， 在每 个文件中记录的数据与所述参数值相关联。
本发明因此提供一个非特定于视频的机载系统架构以及一种允许不受数量和质 量限制， 采集、 压缩、 同步、 存储及重放和操作不同数据、 视频、 音频、 参数、 图形 ( 数据 ) 流的 文件格式。
而且， 所建议的架构是一个模块架构， 来自不同数据源的不同音频 / 视频 ( 数据 ) 流由多个不同的流程采集， 它允许根据记录通道的数量调整尺寸 ( 采集服务器及存储硬盘 的数量 ) 并便于添加新的功能。
得益于这些设备， 在采集时无需同步这些 ( 数据 ) 流。
把 ( 数据 ) 流记录在多个不同的文件中体现以下优势 ：
- 在机舱， 各文件是由多个不同的流程生成并且可被记录在多个不同的硬盘中而 且
- 在地面， 不同 ( 数据 ) 流在相互独立的文件中的存储允许限制文件的大小， 以及 根据需求限制待处理数据的数量， 只有包含所要求的 ( 数据 ) 流的文件例如应被置于 “近线 存储” 。
本发明提出一种围绕简单 ( 可作唯一的 ) 服务器而设计的设备架构， 它与一个适 合航天限制并且尤为特别的是飞行测试限制的文件格式相关联。 所提出的文件格式允许记录所有类型的数据， 并有可能将它们同步， 以及尤其是 通过从一个绝对时间开始通过数据库为便利搜索自动提供资料来随机访问数据， 以及通过 数据安全而便利操作，
而且， 所建议的架构是一个模块架构， 来自不同源的不同音频 / 视频 ( 数据 ) 流 由多个不同流程获得， 这允许根据记录通道的数量调整大小 ( 采集服务器及存储硬盘的数 量 ) 并便于添加新的功能。
最终目标是在考虑了飞行测试的职业限制的同时 ( 在地面和在飞行中 ) 获得优化 的 “工作流 (workflows)” 。在此， 一个 “工作流” 是一个组织内部的一个信息流， 象例如文 件在人群中自动传送一样。 “工作流” 是待完成任务以及在一个职业流程 ( 也被称作操作流 程或者是公司流程 ) 的实现过程中牵涉到的不同行动者的整体的信息模型化和管理。 “工 作流” 一词因此能够被翻译成法语为 “职业流程的电子管理” 。用更为实用的方式， “工作 流” 描述了验证的循环、 一道流程的不同行动者之间的待完成任务、 期限、 验证模式， 并向每 一位行动者提供实现他的任务所必需的信息。 它通常允许通过细述行动者角色和最好的完 成办法来跟踪并识别行动者。 “工作流” 的引擎是允许执行一个或多个 “工作流” 定义的软 件设备。由于语言的滥用， 可以简单地称呼这种软件设备为 “工作流” 。
在无磁带的信息化环境下 ( 数据、 视频、 音频、 图表 ) 内容管理允许 ：
- 控制成本以及
- 便利操作 ( 数据存档合理化， 数据轻松快捷的访问 )。
该解决方案由中央服务器四周的一种简单架构支持， 同时无论输入格式还是压缩 率都可适应。
根据特定的特征， 记录装置包含合成文件生成装置， 这些合成文件随着代表来自 不同数据源的数据的文件的记录而被生成， 合成文件使得能够以同步方式为这些文件设置 参考编号和再次读取这些文件， 并且包含指向代表来自数据源的数据的每一个文件的外部 参考编号。该合成文件通过将多个标注时间、 包含在几个文件中的 ( 数据 ) 流关联， 允许这
些文件同步重新读取。
根据特定的特征， 记录装置适于以动态方式在至少一个文件中记录参数值。
根据特定的特征， 记录装置适于用通用数据结构的斜体记录参数描述符以及关于 测试的数据。
例如， 关于测试的数据是测试类型、 测试号、 飞机类型、 飞机编号及飞行号。
根据特定的特征， 记录装置适于与数据流的采集的通用时间相关联地记录该每个 数据流数据。
因此允许记录所有类型的数据并有可能将它们同步， 并且， 尤其是基于一个通用 时间通过随机访问数据可便利操作。
得益于这些设备的每一个， 限制了数据存储所需的存储空间。
根据特定的特征， 本发明的设备， 如上面简要陈述的那样， 包括读取装置， 该读取 装置适于为至少一次来自数据流的记录数据的传播生成一个合成文件。 该合成文件使得能 够以同步方式为文件编制参考编号并再次读取该文件， 该文件包含待传播数据并包含指向 代表待传播数据的每个文件的外部参考编号。
该合成文件指明哪一个 ( 数据 ) 流应被发布。这一机制允许记录和处理不同文件 中的 ( 数据 ) 流。 根据特定特征， 本发明的设备如上面简要陈述的那样， 包括将来自各个源的数据 流向记录装置路由的路由装置， 记录装置包括适于补偿由路由装置产生的传输等待的时间 标注装置。
时间标注因此非常精确。
根据特定的特征， 记录装置适于把来自数据源的数据成形为 MXF( 素材交换格式 “Material eXchange Format” 的缩写 ) 格式文件形式。
关于 MXF 格式有关其逻辑结构的优势， 我们可以引用 MXF 格式文件的逻辑结构优 势， 它独立于其物理结构。因此在不同 ( 数据 ) 流和元数据之间进行组织和同步均有可能， 无论它们的类型和位置。
这一格式提供对应 IEV 限制条件的机制， 尤其是 ：
- 文件模式和不同流式模式的管理，
- 支持外部参考编号 ；
- 随机数量的不同类型 ( 数据 ) 流的同步
- 为随机访问而生成的机制， 以及
- 即时演化元数据的管理 ： 静态和动态元数据的管理， 元数据作用范围的管理， 回 应大范围需求的标准化元数据的 “构架” ， 定义所有权者 (propriétaire) 元数据 “构架” 的 可能性。
根据特定的特征， 数据流在采集时被用与航空器时钟同步的内部时钟标注时间。 例如， 内部时钟的时间校准可由外部 NTP 服务器， 或由一个 GMT/AES 时间码转换器从一个 AES 时间码输入开始完成。索引表则允许再次找到与该时间码相关联的图像。这一机制允 许保证所记录数据流的同步读取， 即便当它不使用同样的时基。
根据特定的特征， 记录装置包括将来自数据流源的每个数据流包装到一个包含标 识航空器、 飞行测试及所述数据源的静态元数据、 数据流数据及代表所述数据被捕捉时刻
的信息的文件中的装置。
根据特定的特征， 本发明的设备如上面简要陈述的那样， 包括缓冲存储器， 在该缓 冲存储器中， 当记录未被激活时， 数据流在一个预定时间段内被存储和保持， 而当记录被启 动时， 至少一部分暂存数据被记录。
根据特定的特征， 来自数据流数据源的数据流被分成固定时长的时间段， 记录装 置为每个时间段和每个参数记录该时间段期间可用参数的最新近值。
因此被生成的时间段， 逐渐地， 被包封在一个包含描述飞机和测试以及所采集的 不同参数的静态元数据、 存有为每一个时间段所保留的参数采集日期及数值的动态元数据 的文件中。
因此允许进行参数的时间重组， 以便可以用与音频 / 视频 ( 数据 ) 流相同的方式 存储和处理参数。
根据特定的特征， 记录装置适于记录包含根据它们的采集时间分配到固定时长时 间段的参数值的描述性元数据文件， 每个参数每个时间段仅存储唯一一个参数值。
根据特定的特征， 记录装置适于将记录分割成连续无中断、 且一致无配置改变的 序列， 一个包含用于每个新序列的多个新文件的新目录在每次记录、 重新启动或重新配置 时被生成。 根据特定的特征， 记录装置适于以多个不同的压缩率和算法存储同样的数据。
根据特定的特征， 本发明的设备如上面简要陈述的那样， 记录装置适于在飞行测 试时将数据存储为 “流式采集” 模式， 该记录模式其中文件被分成多个包含至少一个数据流 的数据并跟随有一个允许再次读取数据流的所述这些数据的信息块的分段。
当文件从一个线性载体 ( 带 ) 上采集， 或当采集有可能被突然打断时， 这一记录模 式被使用。 仅有位于最后一个可读取信息块之后的 ( 数据 ) 流不能被轻易地解码。 因此， 机 舱内， 文件是以 “流式采集” 模式采集的， 以便， 即便它们未被正确的关闭它们能够被使用。 他们被分割成对应于预定时长的几个部分。 因此， 在系统崩溃的情况下， 仅有位于最后部分 的 ( 数据 ) 流不能被轻易地解码。
根据特定的特征， 记录装置适于在地面上将已记录数据转换以便将其存储为 “文 件” 模式， 其中该文件被分割成多个块， 包含允许再次读取文件的信息的一个文件标题和 / 或一个文件页脚以及包含来自数据流的数据的一个文件本体。
该记录模式更适合存储在一个允许随机访问的载体 ( 硬盘或光盘 ) 上的文件。
根据特定的特征， 本发明的设备如上面简要陈述的那样， 包含适于生成一个指明 哪里可找到不同的记录图像的索引表的索引编制装置。
这一表因此允许随机存取关于一个 ( 数据 ) 流和一个给定的一个图像。
根据特定的特征， 记录装置适于以其原始的无压缩的形式保留至少一个数据流。
根据特定的特征， 记录装置适于定义允许用以 “构架” 的形式组织的专用于用户的 信息修饰每一个文件的描述性元数据。
根据特定的特征， 记录装置适于记录包含描述参数值的元数据组列表的静态描述 性元数据文件。
根据特定的特征， 记录装置适于以回放一个或多个同步数据流的形式提供已记录 的数据。
根据另一个方面， 本发明力求提供一种采集和记录在航空器中已捕捉数据的方 法， 包括待记录数据流的多个源， 被标注时间的记录参数值的至少一个源以及在至少一个 非易失信息载体上记录来自数据流和参数值的记录装置，
其特征在于包括 ：
- 记录步骤， 用于在独立文件中存储不同数据流的数据， 和
- 在每个文件中已记录数据与所述参数值相关联的关联步骤。 附图说明 本发明的其他优势、 目标及特征分列在随后的描述中， 参照附件图， 旨在说明并且 绝不局限于此， 其中 ：
- 图 1， 以功能示意图的形式， 表示现有技术的系统，
- 图 2， 以逻辑示意图的形式， 表示本发明设备的一种具体实现方式，
- 图 3， 以示意图的形式， 表示在本发明设备和方法的最佳实现方式下， 记录的文 件的一个组织结构，
- 图 4、 5 和 6， 以示意图的形式， 表示根据三种不同的记录模式所记录文件的结构，
- 图 7， 以示意图的形式， 表示在本发明设备和方法的一种具体实现方式下使用的 文件的结构，
- 图 8， 以示意图的形式， 表示在本发明设备和方法的一种具体实现方式下使用的 “架构” ，
- 图 9 至 14， 以示意图的形式， 表示在本发明设备和方法的具体实现方式下使用的 文件的结构以及
- 图 15 和 16， 以逻辑示意图的形式， 表示本发明设备的具体实现方式的变型。
具体实施方式
在所有描述中， “盘” 这一词既指代硬盘也指代光盘。
如图 2 所示， 从逻辑观点出发， 本发明设备的一种具体实现方式的架构， 基于一个 中央服务器 200， 分为四个层次。图 2 的左边， 表示了给与采集任何类型来源的数据的可能 性的接口源。 图 2， 涉及到职业 (métier) 数据和飞机时间 201、 摄像机 202、 图形源 203、 ASVI 源 204 和音频源 205 的输入。
我们随后发现， 图 2 中， 允许将数据源通过切换格栅 206 路由到采集服务器， 该切 换格栅 206 在必要时包括一个用于将多个 SD 源拼合到一个 HD 图像中， 以便构成一个能够 节约记录道数量的图嵌镶 (mosaique d’ images) 的嵌镶结构生成系统。在图 2 的中央可看 到音频 / 视频 ( 数据 ) 流和飞机参数的采集系统。它们职责在于收集由不同源发出的信号 并将其成形为 MXF( 素材交换文件格式 “MaterialeXchange Format” 的缩写 ) 格式的文件。 这些不同的采集系统可彼此独立运行 ( 无需将其同步 )。在图 2 中， 这一部分除人机接口 210 之外还包含一个视频采集模块 211， 一个音频采集模块 212 和一个在图中也被称为 MTD 的元数据 ( 职业数据和飞机时间 ) 采集模块 213。
最后， 在图 2 中具有一个合成、 存储和读取系统 220， 它负责取回不同的 MXF 格式 文件， 将其存储在盘 225 上并将其重新读取。不同的文件可被彼此独立写入 ( 无需将其同步 )。一个合成文件逐步被生成和记录， 以便允许再次同步读取这些文件。为此目的， 存储 系统 220 包含一个由合成文件生成模块 235 编入合成文件的外部编号生成模块 230。
最好是， 根据本发明， 通过选择适于 IEV 需求的该格式所提供的各种功能， 执行一 个 MXF 标准化文件格式。MXF 格式是一种标准化和独立格式 ( 因此是可持久的并可相互操 作的 )， 开放的并可发展的 ( 因此能够管理众多不同的视频格式和编码器 )， 并且越来越多 被采用。 它可被用作所有生产线上的交换格式， 从采集， 经过后生产、 索引编制和归档， 到发 布。
MXF 格式是可发展的。 新的标准和建议被写下来以便应对新的问题。 因此， “422M” 标准最近被加入用以描述容器 “Jpeg2k” 。 “RP2008” 建议将用于 “H.264” 的 “381M” 标准补 充完整。针对 “VC-1” 和 “VC-3” 的标准正在草拟中。
MXF 格式提供符合 IEV 限制的所有机制， 尤其是 ：
- 文件模式以及不同流模式的管理，
- 外部参考载体，
- 任意数量的不同类型 ( 数据 ) 流的同步，
- 用于随机接入的一般机制以及 - 实时演变的元数据管理 ： 静态和动态元数据管理， 元数据范围管理， 满足大范围 需求的标准化元数据 “架构” ， 定义主要元数据 “架构” 的可能性。
事实上， 本发明重要的一点是具有所有权者的元数据 “架构” 的使用和定义， 该 “架 构” 适于更为广泛的应用的 IEV 和航空航天需求。
这里， “架构” 是一套能够快速开发应用程序的库。它提供足够的软件砖石用于建 造一个成品应用程序。 这些元件被组织起来以可以相互之间互动， 特别是根据所述的 “都市 化” 技术。
术语法语化的尝试已被完成。我们因此有时发现由法语版魁北克 OFFICE 软件提 供的术语 “应用程序范围” ， 或 “cadriciel” 。
一个 “架构” 提供一套利于创造所有或一部分软件系统的功能， 以及一个将目标域 分成几个模块的结构向导。一个 “架构” 通常借助一个对象语言来实现， 虽然这并不是严格 必需的 ： 一个 “架构” 对象因此通过将目标域分类并且定义每一个的职责以及各类间的协作 关系来提供一个结构向导。这些类的子集允许是抽象的类。
若软件库术语的使用被局限于正确被称作的库， 术语 “架构” 可被扩展用于同样包 括被力荐给于该库的软件结构 ( 层式组织 )， 甚至是周围框架的开发环境， 即便它已能够胜 任管理不同的 “架构” 。
我们发现不同类型的 “架构” ：
- 基础设施系统的 “架构” ： 用于开发操作系统， 图形界面， 通信工具 ；
- 中间设备集成 “架构” ： 为了使非均匀应用程序建立联盟关系。用于把不同的技 术以唯一的接口形式就位 ；
- 企业 “架构” ： 用于开发专用于企业活跃部门的应用程序 ； 以及
- 面向内容管理系统的 “架构”
这些 “架构” 的主要优势是再次使用它们的代码， 软件生命周期标准化 ( 详细说 明、 开发、 维护、 进展 )， 它们允许形式化一个适合企业需求的结构。它们吸取以前开发的部
分经验。这些架构， 某种形式上， 是极端灵活和演进的软件程序包。
另一重要方面是所考虑的资源的多样性 ：
-SD 源 ： PAL 和 NTSC 分辨率，
-HD 源 ： 分辨率 1920×1080， 每秒 50 个图像， 以及其他，
-ASVI 源 ( “Avionics Serial Video Interface” 航空电子串行视频接口的缩写 ) 或 Arinc818 ： 分辨率 1024×768， 60p， 换而言之在渐进模式下每秒 60 个图像，
-VGA、 SVGA(“超级视频图形阵列” “Super video graphicsarray” 的缩写 ) 及 XGA(“扩 展 图 形 阵 列” “Extended graphics array”的 缩 写 ) 源， 分 辨 率 640×480 至 1280×1024， 60p，
- 模拟或数字音频源，
- 飞机参数数据源 ： 约 50 个参数， 频率例如每秒 5 个采集样本同时又可能得到更 大量任何类型的数据和
- 其他类型的源。
我们注意到不同的源不是同步的。
可供选择的情况是， 切换格栅允许在同一地点重新组合各分支并且选择我们希望 记录的摄像机 ( 通常都有比可用的记录通道更多的摄像机 )。我们注意到只有一个 SD/ HD-SDI 格栅是必需的。它管理同步资源并由指令 IHM 指挥， 而它是， 例如， 视频可视化显示 屏上所显示的菜单。 嵌镶结构生成器借助于嵌镶允许把多个摄像机重新组合到同一个记录通道内。 例 如能够在不明显损失质量的同时把几个 SD 摄像机重组到一个单独的 HD 通道。
音频 / 视频 ( 数据 ) 流的采集合并几个步骤 ：
- 所述 ( 数据 ) 流的采集，
- 这些 ( 数据 ) 流的压缩，
- 这些 ( 数据 ) 流的时间标注， 以及
- 已压缩并已标注时间的这些 ( 数据 ) 流被包装在 MXF 格式的文件中。
压缩根据其中一个确定的编解码器 ( 术语 “编码器” 和 “解码器” 的缩写 ) 完成。 第一次高品质压缩由采集服务器实时执行， 以便限制向存储模块传输的 ( 数据 ) 速率。 第二 次压缩， 用代理服务器质量， 若有可能， 同时被执行， 以避免地面上代理服务器的生成步骤。 根据来源和所需品质， 多个编解码器可在同一个服务器内部被使用。
不同的 ( 数据 ) 流在时间上被精确编码或 “被时间编码” ， 换而言之即根据它们被 采集的时刻标注时间， 并包含一个图像时长数量级的精确度。有几种方法被考虑到 ：
-GMT/AES 时间码转换器被放置在记录装置的上游。 这些记录装置配备一个 AES 时 间码输入， 它能够根据 AES 时间码为所采集的图像标注时间。这一方法可被直接采用， 因为 基于 AES 时间码的时间标注在所有商业视频采集服务器上都可用。它完全建立在设备的基 础上， 因此更为精细。与之对应的是， 它需要 GMT/AES 时间码切换器设备的开发， 并且它对 于故障并不耐抗 ( 在转换器故障或 AES 信号传输有问题的情况下时间标注变得不可能 )。
- 一种基于服务器内部时钟的方法 ： 通过使用与飞机参数采集机架上相同的机制 或使用机载计算机的 NTP( 网络时间协议 “NetworkTime Protocol” 的缩写 ) 服务器， 采集 服务器内部时钟可与飞机时钟进行同步。例如， 内部时钟的校准可由外部 NTP 服务器， 或一
个 GMT/AES 时间码转换器基于 AES 时间码输入来完成。
得益于这些时间数据， 记录装置适于以一个或多个同步数据 ( 数据 ) 流回放的形 式提供记录的数据。
商业采集卡使用它们自己的时钟来为获得的图像标注时间。 一个采集软件模块因 此应该被开发以用于在采集卡的时钟和服务器内部时钟之间建立对应联系并且因此根据 服务器内部时钟为视频标注时间。这一方法因此需要对采集软件的一个小小调整， 但相对 应地并不需要特定设备。它对于故障更耐抗 ( 在失去同步的情况下服务器内部时钟在几天 内持续可用并足够精确 )。
时间标注的方法考虑到由路由系统造成的在采集设备 ( 摄像机、 麦克风、 其 他 ......) 和采集服务器之间的传输等待。这一等待事实上在直接传输的情况下是可忽略 的， 但是当它通过一个嵌镶结构生成器造成时， 可以达到几个图像的差距。 这一等待已被认 知， 它由设备根据已知的技术予以补偿。
每一个 ( 数据 ) 流逐步被封装入 MXF 格式原子文件中。该文件包含描述飞机、 测 试及数据源的静态元数据， 包含采集的 ( 数据 ) 流的一个音频或视频轨道， 以及一个包含每 个图像时间日期的动态时间码或是 “timecode” 轨道。该文件遵循机载文件的结构， 详见图 7。 在一种变形中， 一个预记录功能可被集成到服务器中 ： 当记录未被激活时， 已压缩 并已标注时间的 ( 数据 ) 流被存储在一个临时空间内， 最好是在随机存取存储器内， 并且被 保留一段时间。当记录被启动， 它们被加入所生成的 MXF 格式文件中。
飞机参数的采集组合了以下步骤 ：
- 设置与数据发送器系统的连接，
- 采集由数据发送器系统提供的参数 ( 数值和采集日期 )，
- 根据它们的采集日期分拣这些参数， 并且
- 装入一个 MXF 格式文件。
前两个步骤对应于标准数据发送器系统客户端的实现。它允许预订一个参数列 表， 取回关于这些参数的普通信息 ( 名称、 单位 )， 随后， 按固定时间间隔取回带有参数采集 日期的这些参数的所有工业测量值， 换而言之即可直接使用的值。
第三个步骤为视频 IEV 专用的。它使得能够在时间上重新组织这些参数， 以便能 够以与音频 / 视频 ( 数据 ) 流同样的方式将参数存储和利用。一个音频 / 视频流事实上被 分成固定期间的段， 这一个期间通常对应图像帧的周期或频率， 或称之为 “帧率” ， 例如对于 一个 25 个图像 / 秒的视频为 40 毫秒。参数采集软件把时间分成固定时长片段 ( 它对应 各参数所需频率 )， 并且， 为每一片段和每一参数， 保留在该时间段中最近所采集的参数值 ( 或者如果在此时间段中没有获得任何数值则取最近的那个可用数值 )。
因此所生成的时间段逐步装入 MXF 格式原子文件中。该文件包含描述飞机及测试 的静态元数据以及不同的所采集的参数。 它还包含一个分成固定时长片段的动态元数据轨 道， 在这些片断中记录着每一时间段预定的参数的值和采集日期。该文件遵循机载文件的 预定结构， 详细结构参考图 7。
就如关于音频 / 视频 ( 数据 ) 流一样， 一个预记录功能被并入采集软件中。
关于序列的管理和存储， 来自不同采集方式的 MXF 格式文件被记录在至少一个存
储盘上。每个文件随着它的生成仅被存储在一个盘上。
最好的情况是， 每个盘记录所有文件的一个备份。然而， 若不同文件的累积流量 ( 速率 ) 远大于一张盘所能承载的流量， 将这些流量分配到几个盘上， 在一个盘上记录某些 文件， 在另一个盘上存储某些文件， 按需要多少个盘就使用多少个盘。
下表给出所需文件的流量 ( 速率 ) 和体积的例子 ：
速率 (Mb/ 秒 ) 1 个 SD 摄像机 1 个 HD 摄像机 1 个 SD 代理服务器 6 个 SD 配置 4 个 SD+2 个 HD 配置
速率 (Mo/ 秒 ) 1.3 5 0.1 8.8 164 小时空间 (Go) 18 72 1.8 126 2346 小时空间 (Go) 27 108 2.7 189 35110 40 1 70 130一个软件查看来自不同采集的文件并生成一个能够以同步方式给这些文件编制 参考编号和重新读取的 MXF 格式文件。此外这个文件包含指向每个所采集文件的外部参 考编号。它包含描述飞机和测试的静态元数据， 以及特定于每一个文件的静态元数据备份 ( 标识摄像机、 参数描述 )。该文件小但至关重要， 它以规则的时间间隔最好是在两张不同 的盘的两个不同位置上完全被重写。因此， 在两个存储系统有损坏的情况下一个正确的文 件总是可得的。
为了便利向地面的传输， 最好是同时记录所采集的文件到同一个目录中 ( 或者当 文件被分散到几个盘时存储到具有相同名称的各目录中 )。
在飞行测试期间， 记录可被中止、 重启或重新配置。最好是为了便利操作， 如图 3 所绘， 将记录细分成连续序列 305、 310、 315、 360 和 365， 换而言之即不中断且均一的， 换而 言之即不改变配置的。因此， 每当记录因无论任何原因 ( 摄像机切换， 盘的更换， 系统崩溃 后重启 )， 这里是由于切换 370， 在一次中断 320 之后重启或重新配置时， 用每一个新序列的 新文件来创建一个新的目录。
关于人机接口 (“IHM” )， 用户能够得益于它修改他希望记录的源。可采取两种解 决方案来执行源切换而不会受它们并非同步这一事实的影响 ：
- 在第一种变型中， 同步所有 SDI 源以避免图像损失 ： 这一解决方案涉及同步设备 或配备有 “重新计时” 功能的切换格栅的安装。
- 在第二种变型中， 在切换之前停止记录并且在切换之后重新开始。 这造成在被切 换通道上的一些图像的损失， 但无需进行设备调节。记录的停止和重启以对于用户透明的 方式由视频服务器自动执行。
为了限制 “系统崩溃” 和故障的影响， 规定 ：
- 生成以 “流” 模式， 即以连续模式的 MXF 格式文件， 这允许限制系统崩溃时数据的损失， - 错误恢复功能 ： 在错误时采集自动再次启动，
- 在测试前检验视频 IEV 状况的诊断功能，
- 测试时故障检测功能 ( 信号损失， 图像损失或冻结， 采集系统、 时间标注系统或 存储系统问题 )， 在必要时它产生警报并停止相关通道的数据采集。
关于选定文件的格式， 在视频 IEV 范围内所用文件可存储多种类型的视频和音频 流： SD 视频 (PAL 和 NTSC 格式 )， HD 视频 (720p 和 1080i 类型格式 )， 来自计算机的视频 (VGA 类型格式 )， 以及来自驾驶舱的视频 (ASVI 格式 )， 音频， 来自可能需求的其他数据。
这些流被压缩以限制传输它们所需的流量 ( 速率 ) 和存储它们所需的空间。使 用多种不同的编解码器， 以便在图像质量和文件大小之间得到良好的折中。这一折中可根 据文件处理模式而有不同， 并且有时候需要以几个不同压缩率存储同一个视频 ： 轻微压缩 ( 用于工作台上处理的高品质视频 ) 和 / 或高压缩 ( 用于个人工作站上处理的代理服务 器 )。
这些文件允许为这些标准元数据的音频 / 视频 ( 数据 ) 流提供资料 ( 规则、 题目、 参与者 ......)。这些文件也允许存储应用于所有 ( 数据 ) 流的职业元数据 ( 飞机和飞行 的描述， ......) 或仅仅是某些 ( 数据 ) 流的职业元数据 ( 摄像机的描述， ......)。这些 元数据很容易在数据库中被修改并编索引。
最后， 这些文件也被用于记录以动态元数据存储的参数流 ( 飞机参数 )。
来自不同源的不同音频 / 视频 ( 数据 ) 流由不同的程序 ( 甚至是不同的多台机 器 ) 获得。 将这些程序同步并把获得的不同的 ( 数据 ) 流重组到唯一一个文件中是困难的。 因此更愿意用异步方式获得不同的 ( 数据 ) 流并放在独立的文件中 ( 至少每个程序一个文 件 )。于是为每一个 ( 数据 ) 流精确地实时计时， 以便随后对其进行同步。
如前所述， 在机载架构中所用盘的速率 ( 流量 ) 有时不足以承载不同 ( 数据 ) 流 的累积速率 ( 流量 )， 在必要时我们将这些速率 ( 流量 ) 分配到几个盘上。
采集程序由于多种原因 ( 电源切断、 磁盘无空间、 硬件或软件问题 ......)， 可能 突然被中止。在此情况下， 这些文件可被使用， 即便它们没有被正确的关闭。这些文件因此 是以流模式获得， 换而言之即是有规律地写入使得可再次读取该文件的关键信息。
最后， 改变流的数量和源 ( 改变视频源 ) 是有可能的。这些改变通过这些文件中 的元数据被 “跟踪” 。这些文件被检验并且可在传输到地面时被再次成形。为此目的， 我们 具有检验和操纵这些文件的功能。
在目前技术中都不存在的实施本发明的一个重要优势是 ( 数据 ) 流可借助网络被 单独使用。最好是， 一个文件仅有一个 ( 数据 ) 流， 从而不会使网络过载。
这些 ( 数据 ) 流也允许被集体使用 ( 在操作台上 )， 如现有技术中的一样。选定文 件的格式允许关联、 编索引和同步包含在多个文件中的多个标注时间的 ( 数据 ) 流， 以便能 够完美同步地重新读取这些不同的 ( 数据 ) 流。
无论何种操作模式， 用户希望能够快速在视频中移动， 并快速进入记录的精确时 刻。选定的文件允许随机访问图像。
而且， 来自测试的视频构成一个敏感数据。 选定文件的格式可保证数据的机密性。 文件格式可以例如 ：
-以 “流” 模式被使用 ： 文件则通过网络被发布给用户， 而用户无法将其复制并且
- 被加密以便无法被读取。
用户在授权之后也可以提取一部分视频， 向其中嵌入数据并将其用于外部使用。 选定的文件的类型支持 “部分恢复” 机制、 给定时间范围内某些 ( 数据 ) 流的提取、 文本嵌 入、 解压缩 / 再压缩。
关于编解码器， 上面描述的架构允许同时使用不同的编解码器， 例如， “Mpeg4 AVC(H.264)” 、 “VC-1” 、 “Jpeg2k” 、 “Mpeg2” 、 “Dirac” 编解码器和 “H.265” 。
关于记录模式， MXF 文件格式可以在多个不同的模式存储 ( 数据 ) 流 ：
-“文件” 模式， 其中文件被分成两或三个块， 如图 4 所绘， 文件的标题 405( 英语 是 “Header” ) 和 / 或页脚 ( 英语是 “Footer” ) 包含允许再次读取文件的信息。文件的本 体 415 包含 ( 数据 ) 流。该模式被用于当这些文件被存储于一个允许随机存取的载体上时 ( 盘或 CD) ；
-“流式采集” ( 连续采集 ) 模式， 其中文件被分成几个分段， 如图 5 所绘。每个分 段包括所采集的流 505 和 515， 在之后是一个允许再次读取这些流的信息块 510 和 520。该 模式被用于当这些文件被采集到一个线性载体 ( 带 ) 上， 或当采集极可能被突然中断时。 只 有位于最后一个可读取信息块之后的流不能被轻易地解码 ； -“流式读取” 模式， 其中文件被分成几个分段， 如图 6 所绘。每个分段包括前面 为允许读取这些流的信息块 605 和 615 的所采集流 610 和 620。该模式被用于当这些文件 应从一个线性载体 ( 磁带 ) 被再次读取时或当它们应当通过线缆或通过微波在网络上发布 时。只有在第一个可读取信息模块之前的 ( 数据 ) 流不能被解码。
本发明的使用中， “流式采集” 模式和文件分别在飞机和地面上被实施。
关于同步机制 ： MXF 文件的格式提供允许同步随机数量的 ( 数据 ) 流的同步机制， 无论它们的类型和它们在文件中的布置。
关于外部参考 ( 编号 )， MXF 格式允许存储能够在被称为 “原子” 文件的不同文件 中构成一个音频 / 视频序列的不同 ( 数据 ) 流， 并允许构建一个被称为 “合成文件” 的文件， 它给包含应被再次读取的 ( 数据 ) 流的文件作参考编号。每个 ( 数据 ) 流被存储在一个独 立的文件中。对于每一次传播都构建一个合成文件。它指明哪一个 ( 数据 ) 流应被传播。 这一机制允许在不同文件中记录和使用 ( 数据 ) 流。
关于元数据的管理， MXF 格式允许管理标准元数据 ( 标题、 权限持有人 ) 及更具体 被称为 “所有权者” 的元数据 ( 飞机及测试的描述 )。而且， 在飞行测试中本发明应用程序 中所用文件包含仅应用于一个流 ( 源描述 ) 的元数据。最后， MXF 格式允许定义动态元数 据， 以存储飞机参数。
在与其物理结构有关的 MXF 格式优点中， 我们引述以下几点 ：
- 它允许使用一个指明哪里可找到记录于不同 ( 数据 ) 流中的不同图像的索引表。 它因此允许随机存取对于一个给定时刻和一个给定流的一个图像。
- 它允许使用一个本体容器， 它包含最初形式的 ( 数据 ) 流 ： 音频和 / 或视频流， 动态元素 ( 非持续性时间码和 / 或动态元数据 )。这些 ( 数据 ) 流通常被分割成对应固定 时长， 一个图像或一个 GOP( 图像组 “Group of Pictures” 的缩写 ) 的时长， 的几块， 而我们 称为 “帧包装” 。( 数据 ) 流也可以由一个块 ( 它对应序列的总时长 ) 包装起来， 称为 “别针
包装 (clip-wrapping)” 。
关于 MXF 格式与其逻辑结构有关的优势， 我们能够引述与他们的物理结构无关的 MXF 格式文件逻辑结构的优势。 因此无论它们的类型和它们的位置， 在它们之间组织和同步 不同 ( 数据 ) 流和元数据是可能的。
关于元数据的管理， MXF 格式文件仅使用一个元数据模型， 它允许同时定义结构性 元数据和描述性元数据。结构性元数据重组允许描述文件逻辑结构的重要信息， 以及允许 保管其创建和修改痕迹的某些信息。它们是必需和标准化的。描述性元数据允许使用专用 于用户的信息修饰文件。它们是随机的。它们以 “架构” 的形式被组织起来。
元数据的三个 “架构” 为满足视听需求已经以 “DMS-1” 的名义被标准化。我们也 能够定义和使用所有权者元数据 “架构” ( 我们则称为 “隐蔽元数据 (Dark Metadata)” )。 采用 MXF 格式的某些软件允许可视化 DMS-1“架构” 内容并允许以 XML( 可扩展标记语言 “Extensible Markup Language” 的缩写 ) 格式文件形式将其输入和输出。与之相对应的， 它们忽视所有权者 “架构” ， 然而并不将其取消。
关于时间标注及同步配置， MXF 格式允许不同 ( 数据 ) 流的时间标注和同步。 每个 ( 音频 / 视频 ( 数据 ) 流或动态元数据 ) 通道拥有自身固有的时基 ( 帧率 ) 和起点。MXF 格式文件读取器允许由以下机制从一个绝对时间开始随机访问数据 ： 对于每一个通道， 绝 对时间根据通道的帧率被转换成时间码。索引表则允许再找到与此时间码相关联的图像， 甚至在 GOP 结构中。这一机制允许保证各通道的同步读取， 即便它们没有使用相同的时基。 MXF 格式的文件允许管理更为具体的某些功能， 尤其是 ：
-“部分恢复” ： 它涉及一些机制， 这些机制允许基于一个 MXF 格式文件在一段指定 时间范围内提取元数据和 ( 数据 ) 流， 并将其以原始文件的形式记录， 或记录在另一个 MXF 格式的文件中， 并且
-“AES 加密” ： MXF 格式文件中的本体可通过使用 AES 算法进行加密。
为了避免协同操作的问题， 最好是产生具有一个简单而广泛流行结构的文件， 例 如 “Op1a” 类型， 而且它完全遵守 IRT(“Institut fürRundfunktechnik” 的缩写， 注册商 标 ) 规范 ( 命名为 “分析器” 或 “分析者” 的采用 MXF 格式的软件一样的工具 )， 允许检测文 件与标准的不兼容性。
最好是， 为了实施本发明， 我们把 ( 数据 ) 流记录在几个不同的文件中， 这体现以 下优势 ：
- 机舱中， 这些文件由几个不同程序生成并能够被记录到几个不同的盘上而且
- 地面上， 不同 ( 数据 ) 流在分离的文件中的存储， 允许根据需求限制这些文件的 大小， 以及待处理数据的数量， 只有包含所需 ( 数据 ) 流的文件例如应被置于近线。在此， “近线” 限定一个快速存取系统， 它使存档于一个序列存取载体上的数据可迅速获得， 如在 一个随机存取数据载体上一样。
在一种实现模式中， 施行一种 ( 数据 ) 流的原子化， 以及绘于图 7 中的文件结构的 使用。
正如我们参照图 7 所观察到的， 我们使用两种类型的文件 ：
- 原子文件 705 至 730， 它们每一个仅包含一个 ( 数据 ) 流 ( 高品质视频、 代理视 频、 音频或动态元数据 ) 及提供给测试的静态元数据 ( 飞机及飞行识别码 ) 及 ( 摄像机、 麦
克风识别码或参数描述 ) 流。原子文件 705 至 730 可被单独使用并且
- 为包含数据流的不同文件 705 至 730 设置参考编号的合成文件 735。合成文件 735， 允许自身， 获得飞行测试及不同 ( 数据 ) 流的所有信息 ： 合成文件 735 包含提供给测试 的静态元数据 ( 飞机及飞行识别码 ) 和提供给每个源的静态元数据 ( 摄像机、 麦克风识别 码、 或参数描述 ......)。合成文件 735 也允许以同步方式使用这些不同 ( 数据 ) 流。
关于 “元数据架构” ， MXF 格式的不同文件包含静态描述性元数据 ( 权限、 飞机识别 码， ......) 及有时， 根据飞机上所实现的测试类型， 回应飞机需求， 换而言之即关联譬如速 度或压力等某些测定参数的需求的动态元数据 ( 飞机参数 )。
可以观察到， 可以将一个 “DMS-1” 标准化 “架构” 用于非保密性的标准静态元数据。 这些元数据事实上可以在某些施行 MXF 格式的软件中被查看。例如将一个 “生产架构” 用 于指示权限所有人及其联系方式。
也可以以间接方式将一个 DMS-1“架构” 用于存储静态职业元数据 ( 飞机、 飞行、 摄像机及麦克风识别码、 参数描述 )。可以例如将一个 “场景架构” 用于识别飞机和摄像机， 并且因此允许它们在大部分 MXF 格式软件中的可视化。
在最佳实现模式下， 将一个所有权者 “架构” 用于这些静态职业元数据， 因为它允 许精确地给与它们名称和所需类型， 并且由此便于它们的可视化、 它们的编辑和它们的编 制索引。
而且， 这一所有权者 “架构” 适于飞机参数数据的存储， 因为它允许大力限制用于 存储这些参数所需字节的数量 ( 每个参数约 16 个八位字节而不是应用间接 DMS-1 架构时 的几百个 )。
所有权者 “架构” 的使用， 此外， 允许保证某些机密性。它所包含的元数据事实上 被施行于市场上的 MXF 格式的软件所忽略。只有一个借助于描述所有权者 “架构” 的方案 修改或配置过的软件可对其进行解释。
在这些实现模式中， 施行这样一个 “架构” ， 其结构被描绘在图 8 上。这样一个 “架 构” 805 允许存储静态元数据 ：
- 飞机类型和飞机识别码， 块 810 ；
- 飞行类型 ( 静态测试， 飞行测试， 商务飞行 ) 及飞行号， 块 815 ；
- 源识别码， 例如类型、 P/N( 部件编号 “Part Number” 的缩写 )， 它用唯一的方式 识别仪器， S/N( 序列号 “Serial Number” 的缩写 )， 它识别仪器的序列编号， 名称和预留空 间， 块 820 ；
- 关于源的补充注释， 块 825 和
- 对 于 飞 行 和 对 于 每 次 存 储 的 UTC 时 间 范 围 ( 协 调 世 界 时， UTC 是 英 语 CUT“Coordinated universal time” 和法语 TUC 的折中 )， 块 830。
这一 “架构” ， 此外， 允许存储飞机参数和每个源的专用参数， 例如 EVS( 增强视景 系统 “Enhanced Vision System” 的缩写 ) ： 水平计算位置、 增益值、 除冰激活、 模式、 GPS( 全 球定位系统 “GlobalPositionning System” 的缩写 ) 位置 ：
- 每一参数的描述以静态方式存储起来并配备一个 UL( 通用标签 “Universal Label” 的缩写 )， 块 835 以及
- 参数样本以动态方式被存储， 块 840。这些样本只包含每一参数的数值 ( 无单位 ) 和 GMT 时间 ( 采集日期 )， 这便于限制所需空间。这些样本通过斜体 UL 给参数描述符 编参考号， 以便再次查到该参数的名称和单位。
该 “架构” 为了满足航天应用程序以及飞行测试被设计出， 如下文所述。
关于音频 / 视频文件结构， 每个音频或视频 ( 数据 ) 流被存储在一个分离的文件 905 中， 如图 9 所绘， 它们可以被单独使用在一个采用 MXF 格式的读取器或安装软件中。
这些文件因此只包含唯一一个 “源代码包” 910， 它包含音频或视频流 915 和在必 要时一个非连续的时间码轨道 ( 未表示出 )， 以及唯一一个 “设备包” 920， 它允许在其完整 性上回放该流。设备包 920 在输出处具有所需形式， 换而言之即由一个传统视频读取器读 取的形式。这一结构的元素被设置并且通过 “文件包” 与原始数据 “源代码包” 相关连。这一 逻辑表示非常精炼 ： 一个典型的 “文件包” 对应约 1Ko 而它所代表的主体可能是几兆 (Mb)、 几千兆 (Gb) 或甚至是几个太拉 (Tb) 八位字节。
“Op1a” 结构更为理想， 因为它简单而范围广泛， 且允许保证良好的协同合作 ( 这 些文件在采用 MXF 格式的几乎全部读取器和安装软件上都可使用 )。 “Op0” 结构在标准化 过程中最终会有意义， 因为它会在记录时允许优化读取功能。
这些文件可有两种不同的物理结构 ：
- 机舱上， 如图 10 所绘， 文件 1005 以 “流式采集” 模式被采集， 以便它们可被使用， 即便它们没有被正确地关闭。它们被分割成几个分段 1010、 1015 和 1020， 这对应一个选定 时长。因此， 在系统崩溃的情况下仅有一些位于最后分段 1020 的 ( 数据 ) 流不能被轻易地 解码。每一分段由一个元数据树 1025 和一个本体容器 1030 构成。每一个元数据树 1025 包含结构性元数据 ( 它给出文件逻辑结构 ) 和静态描述性元数据 ( 权限、 飞机和飞行识别 码、 摄像机和麦克风的识别码 )。每一个本体容器 1030， 用允许正确将文件转移的数据 ( 例 如， 分段大小的信息、 ( 数据 ) 流中的位置 ......)， 将 ( 数据 ) 流在一个固定时长内 ( 一个 图像或一个 GOP) 包装成 “帧包装” 模式。地面上， 如图 11 所绘， 文件被转换成 “文件” 模式。 结果文件 1105 仅包含一个标题分段 1110 和一个页脚分段 1115。 这些分段包含一个元数据 树 1120， 它收集结构性元数据以及静态描述性元数据。 唯一一个本体容器 1125 被用于将数 据流 ( 必要时加密 ) 包装成 “别针包装” ， 成为单独一个块 1130。根据地面已知技术， 一个 索引表 1135 自动被加入以便允许对每个图像快速存取。
关于动态元数据文件， 包含飞机参数或其他相关联数据的该文件符合与包含音频 / 视频 ( 数据 ) 流的文件相同的逻辑和物理结构。
然而它在元数据和被包装的 ( 数据 ) 流方面存在几个不同， 这参照图 12 在此作出 解释。第一个不同关于静态描述性元数据。标识音频 / 视频源的元数据组由描述参数的一 套或一列表的元数据组 1205 至 1220 替代。每组参数描述符存储一个参数的名称、 描述和 单位， 以及一个 UL( 通用标签 )， 一个对于每个参数都不同的标识码。
第二个不同在于本体。音频 / 视频 ( 数据 ) 流被一个 “时间轴” 类 1225 动态元数 据轨道所代替， 时间轴是一个对数据进行时间标注的方法， 它包含参数样本。根据它们的 采集时间 ( 而不根据服务器接收时间 )， 这些被筛选并分配在固定时长的各个片段 1230 中 ( 例如， 若 5pps( 每秒参数的缩写 ) 则 200 毫秒 )， 并且每个参数每个片段只保管唯一一个样 本。每一个样本 1235 与一组参数样本元数据 1240 关联存储， 该一组参数样本元数据 1240 存储参数值采集时间和数值并用其斜体字 UL 为该组相应参数描述符编制参考编号。关于合成文件， 它给其他所有文件设置参考编号以便允许以同步方式再次读取， 它由几个 “源代码包” 1305 和一个 “设备包” 1310 组成， 每个 “源代码包” 为包含一个视频、 音频或参数 ( 数据 ) 流的一个文件编制参考编号， “设备包” 允许以同步方式重新呈现所有 这些 ( 数据 ) 流， 正如图 13 所绘。一个 “Op1b” 类型结构允许管理这一复杂性。这一文件 因此更不易于协同合作。该文件的物理结构， 与之相对地， 更为简单， 就如图 14 所绘。该文 件 1405 仅包含一个 “标题分段” 1410， 一个 “标题元数据” 1420 和一个 “页脚分段” 1415。标 题 1410 和页脚 1415 包含给出文件逻辑结构的结构性元数据， 和重取总体静态元数据 ( 飞 机和飞行识别码 ) 的静态元数据， 以及关联于每个 ( 数据 ) 流的静态元数据 ( 源识别码， 参 数列表 )。
从结构的角度来看， 几种技术选择是可能的， 例如 ：
- 软件或硬件压缩选择，
- 视觉化选择， 和
- 模块添加以实现重放功能。
而且对于总体结构而言几种变型是可能的。在第一个变型中， 如图 15 所绘， 采用 一个专用于视频的网络 1505， 传感器直接提供文件格式数据给一个切换器 ( 开关 )1515， 这 涉及一定程度的传感器复杂性。这一架构在由服务器 1510 管理的可视化方面造成实时的 问题。所需服务和图像质量被考虑到以定网络 1505 的尺寸。事实上， 由传感器生成的速率 ( 流量 ) 太大并应被无损管理。
a) 在第二个变型中， 如图 16 所绘， 采用一个不专用于视频的总体网络 1605， 该网 络其中视频传感器 1610 与其他任何 IEV 传感器 1615、 1620 或 1625 处于同一级别。在此情 况下， 在传感器捕捉数据之后， 这些数据与适于每个应用程序的格式包装在一起并借助于 服务器 1630 和 1635 以及切换器 1650 在同一网络上传输。这一架构也会在可视化服务器 1640 在可视化显示屏 1645 上施行可视化时造成实时的问题。所需服务和图像质量被考虑 到以定网络 1605 的尺寸。事实上， 由传感器生成的速率 ( 流量 ) 太大并应被无损管理。
在第三个变型中， 实施前面两个变型的组合。