随着我国航天技术的不断革新,国产卫星遥感数据呈指数级增长,数据量在满足各行业务需求的同时,也对卫星数据处理提出了更大的挑战,传统单机作业模式已然不能满足目前的需求。在计算机、高速网络、大型存储技术快速发展的年代,卫星数据处理平台亟须向集群式自动化转变^[1]。

地理成像加速器(Geoimaging Accelerator,GXL)是加拿大PCI公司设计的新一代集群式遥感数据处理平台,可对航空、卫星遥感数据进行流程自动化生产,已大规模应用于国外卫星产品的生产中。在高分辨率卫星影像正射产品生产中,GXL依据控制资料对QuickBird,GeoEye,WorldView-1/2,TH01等航天卫星传感器数据进行分布式自动化处理,在产品精度满足生产要求的同时,大幅缩短生产周期,降低生产成本^{[2⇓⇓⇓⇓-7]}。针对国产卫星数据处理方面,张世群等^[8]利用PCI GXL在短时间纠正了包含资源三号(ZY-3)卫星在内的5 600景影像,成果精度满足地理国情监测项目要求,为地理国情后续工作提供了可靠的数据基础; 乔晓虹等^[9]在第一次地理国情普查中验证了结合资源一号02C(ZY1-02C)、高分一号(GF-1)、ZY-3国产卫星,运用 GXL 提供的影像配准影像模式可以较大程度上减小1∶50 000数字高程模型(digital elevation model,DEM)纠正时点核准正射影像与信息采集影像套合误差,为后续时点核查工作提供可靠的地理精度保障,GXL已经成为地理国情普查中主要的数据处理软件^[10-11]。

由于卫星数据源不断增加,数据处理的复杂度逐渐加大,仅利用GXL平台中固有功能模块很难满足新时期大数据模式下的卫星数据处理需求。虽然有学者结合其他卫星数据处理平台(如GeoWay CIPS和ERDAS等)开发新功能模块用以补充GXL不足^[12],或者基于GXL开发功能重新设计遥感影像生产管理系统^[13-14],并扩展新功能优化GXL,用以实现国产卫星数据便捷化处理,但这些均是建立新系统或者多个系统之间协同交互的基础上进行的,实现难度大,对于普通GXL使用者并不实用。

GXL平台的强大不仅在于其提供高效可靠的固有功能模块,还在于其具有高度灵活的可扩展性,可以和其他遥感数据处理软件无缝衔接使用^[15],而且其提供的二次开发接口可快速完成自建功能算法的流程化嵌入,扩展并优化数据处理流程。然而,基于此方面并应用于国产卫星流程化处理的研究相对较少,为此,本文重点研究利用GXL平台的二次开发功能,扩展优化国产卫星数据处理工作流,并有效提高国产卫星产品的生产效率和便捷化处理。

GXL软件是面向计算机集群的数据处理软件,是以网络为连接基础的,应用于分布式多机的超算平台。其主要功能组件由客户端、数据存储服务器、作业调度控制器、作业执行处理器4部分组成,如图1所示。数据处理流向描述如下: 客户端负责提交数据处理任务参数,涉及人工交互和作业状态显示,主要以B/S架构的浏览器端方式展现,用户在电脑端的浏览器上启动GXL软件,通过选择功能模块创建流程化作业即可提交数据处理任务。其次,作业控制器根据提交作业对其分析并结合网络寻找可用的处理服务器节点,将作业任务参数通过数据库链接传递于正常作业的处理服务器节点,同时启动和监控处理服务器的任务,完成分布式任务部署,此时多个任务服务器根据数据路径参数访问数据存储服务器,并对执行具体处理任务,完成数据的读写处理等相关操作,同时将状态反馈于作业控制器并传递于浏览器客户端,显示数据处理的日志信息。作业流首先按图1中实线箭头方向执行,然后再按虚线箭头方向反馈,完成一个作业周期。

数据处理任务流贯穿于GXL的4大功能部件块之间,且模块之间互不影响,从软件框架模式上分析,GXL软件整体上由3部分构成,是典型的MVC(Model View Controller)框架(图2)。其中模型层(Model)位于GXL软件框架底层,主要完成遥感数据存取、数据处理核心算法实现,通常部署于作业处理服务器中,是数据处理真正的执行者; 视图层(View)位于GXL软件最上层,通常部署于GXL客户端组件块中,面向使用者,通过浏览器与用户完成交互操作,具体实现GXL任务的参数输入、任务状态展示、日志信息输出等; 控制器层(Controller)则位于模型层与视图层之间,通常部署于GXL任务管理节点,利用数据库和网络调度算法,负责完成两者之间的信息传递、处理算法注册、作业调度管理,并于View端显示计算节点(模型运行环境)的资源负载状态等,三者通过网络以最低偶合度完成连接,将模型层与视图层最大化分离,具有部署快、灵活性强、高扩展性等优势。

以MVC模式为构建基础,GXL中所有任务流功能均满足这种模式,每个具体功能模块所需要的参数在视图端以网页形式显示与交互,在模型端(即后台)执行,同时受限于控制器的作业定制规则,从而以负载均衡的优配形式最大化利用集群服务器计算资源。所以,在MVC模式下的,针对GXL中的新增运算模块,需要分别对模型端、视图端、控制端3方面进行开发,最终完成功能扩展。

软件的二次开发是指在现有软件框架的基础上定制修改与功能扩展,实现满足自己业务等需要的功能。应用于GXL软件,即在功能模块中创建二次开发作业核心,扩展常规化GXL数据处理流,将新开发算法部署于GXL平台,综合利用GXL的集群调度平台,达到流程扩展和优化处理的目的。根据GXL软件框架构成可知,新增模块需要适配MVC框架,根据GXL平台程序接口规范,完成二次开发。

依据1.1小节可知,GXL的二次开发策略实际上是根据MVC这3个方面的接口规范分别实现功能扩展,具体策略如下:

1)首先在模型端。主要完成模型算法开发,是GXL二次开发的核心功能部分。在模型端GXL使用GDE(Geomatica’s Developer Environment)作为主要开发环境,使用Python语言编写执行角本。具体实现方式有3种情形: ①直接使用Python语言调用PCI Development tools,PCI Libraries中的PPFs(PCI Pluggable Functions),编写独立可执行的算法程序; ②针对现有的可执行程序,如Linux命令或者Windows下的exe程序,利用Python胶水语言的特性,完成封装调用; ③利用C/C++语言编写的核心算法库,使用Python脚本调用核心库完成功能实现。详细流程如图3所示。由于GXL的作业模式由主作业和子作业协同完成,主作业负责解析与划分整体作业精细粒度,而子作业具体负责完成作业内容,所以,在模型端运行的核心算法角本,应该需要包含主作业执行角本和子作业执行角本,并统一部署于${GXL_ROOT}/PGS目录下,这样才真正完成Model端的接口开发任务。

2)其次在视图端。GXL以网页形式提供参数输出,页面设置由GXL Web界面接口GUI PRM XML结构决定,主要参数类型如表1所示。根据表1指定类型为设计与布局输出界面参数,最终提交的视图端接口文件为XML类型文件,部署于GXL web服务中。图4描述了“正射纠正”模块在视图端中XML文件与web解析后的结果。经解析的XML文件为交互式界面,其中的每一选项均在XML文件中找到对应语句,即在视图的开发主要依赖于XML语言编写规范,依据GUI PRM结构接口要求完成。

3)最后在控制器端。控制器端的作用是将模型端算法与视图端界面联系起来,根据用户交互获取到的数据参数传递给模型端,并依据任务量大小对模型端作业和计算机资源进行调度管理。GXL在控制端将JPS(Job Processing System)服务和Postgresql数据库相结合,依据程序监控与操作数据库中的对应表,从而实现控制功能。在控制器端任务作业流如图5所示,主要分为算法注册、参数注册、对作业任务进行执行配置3个步骤。

同样以GXL系统自带模块“正射纠正”为例,其通过算法注册,对正射纠正中的主作业和子作业完成注册,界面参数的统一类型为PrmXmlType,视图端文件参数为OrthoParameters,模型端为MasterOrtho.pyc和Ortho.pyc,分别为主作业与子作业角本,执行优先级分别为50,所占资源,针对子作业为21,对应每个执行线程资源分配为21,即每次单节计算节点可运行100/21=4个任务。正射校正模块的算法注册代码为:

SELECT install_job (

\${GXL_ROOT}/PGS/Orthorectification/JPS/py/MasterOrtho.pyc, 1,

GXLMasterOrtho, 正射校正,

影像正射校正, 生成正射产品。,

50, GXLWorkflow, PrmXmlType, OrthoParameters,

正射校正主作业参数);

SELECT install_job (

\${GXL_ROOT}/PGS/Orthorectification/JPS/py/Ortho.pyc, 21,

GXLOrtho, 正射校正子作业,

对指定的影像正射校正,生成正射产品。,

50, GXLWorkflow, PrmXmlType, OrthoParameters,

正射校正子作业参数);

GXL二次开发功能不仅可以将新增算法完整加入数据处理流,完成定制流程化,而且可将新开发扩展算法快速应用于集群环境,最大化提高新算法运行效率。所以,GXL二次开发可以为常规数据流程进行2个方面的改进: ①流程优化; ②效率提升。本文以613景GF-1(322景)、GF-2(215景)和ZY1-02C(76景)的多源国产数据协同正射纠正处理为例,通过开发新模型,完成优化数据处理流与增强数据处理效率方面的改进与提升,进而验证GXL二次开发在国产卫星数据处理的应用。

众所周知,国产高空间分辨卫星遥感数据的GXL正射纠正处理流程如图6所示,主要包含原始数据(1级产品)导入、控制点采集、区域网平差、正射纠正4步。①完成多源影像格式转换,识别元数据信息; ②结合参考底图进行控制点采集与筛选; ③完成影像间连接点采集与筛选以及结合第二步的控制点联合区域网平差; ④结合高程数据完成全色多光谱影像配准和多源数据协同正射纠正。

2.1节所描述的功能模块均为GXL内嵌功能,这个流程在业务化运行时有一定的限制条件: ①数据导入必须为文件夹状态,不能为tar包; ②数据完整性必须良好,即一个任务批次中的原始数据必须存在全色和多光谱且一对一匹配; ③正射产品的文件名称为GXL内部文件系统所定义,与业务化成果数据库文件命名形式不匹配,不能直接归档可入库。在通常业务生产中,以上限制均可在人工交互辅助下克服,然而随着数据量的不断增长和卫星种类的日益繁多,人工干预的作业模式已不能满足业务需求。为此,针对以上3个条件分别开发新型模块,优化现有数据处理流程,释放人力资源。

首先,针对第一条件。由于为了保证卫星数据在传输过程的完全和效率问题,通过专线获取到的原始数据通常以*.tar.gz压缩包为主,这一数据源对于GXL的影像导入是不识别的,手动解压通常效率低下。因此利用GXL二次开发,设计“原始影像解压缩”功能来解决以上问题。依据1.2节所述,分别在模型端完成卫星数据解压缩核心功能; 在视图端设计输入输出路径(即,影像输出文件夹与解压结果文件夹选项框); 在控制器端完成算法注册,同时实现多节点并行运行,控制每个计算节点执行10个子任务,图7显示了“原始影像解压缩”功能模块开发在MCV模式下的开发情况。

其次,为了避免在业务化生产过程中由于原始数据不完整造成最后成果的不完整而导致大批量的返工操作,针对第二个条件,设计“影像完整性”二次开发模块完成现有国产卫星传感器在产品号相同的情况下缺失全色与多光谱配对的不完整数据,此功能在“影像导入”模块之前,在“原始影像解压缩”模块之后,流程为: 通过对卫星文件列表分析,依据原始数据产品ID进行关键字检索,并按表2中所描述的影像完整性进行分析差别,查找到缺失的原始数据。依据MVC设计开发原则,该功能在模型端进行实现,而在视图端设计文件夹输入和日志文件输出界面框,而在控制器端完成算法和界面代码的注册。具体流程如图8所示。

再次,针对GXL正射生产的成果,由于GXL系统不能满足业务需求,即: ①配套生产出影像产品的xml描述文件、影像产品的矢量范围(shapefile格式)、影像快视图、拇指图、产品检验报告文件(*.pdf); ②正射产品及其配套文件名需按照“产品等级_卫星名称_时相_产品号_传感器名称_量化等级_任务单号_标识号”重新命名,并以一景一个文件夹的结果整理。因此分别设计GXL二次开发5个功能模块(表3): “大范围基础数据快速索引和解析”、“成果元数据生成”、“质检报告生成”、“成果归档预处理”、“成果归档”。5个功能模块依次顺序执行,前3个负责完成生成正射产品的配套描述文件,后2个负责完成所有正射产品文件名的修改与整理。每个模块同样遵循MCV开发模式,详细开发思路不再赘述。

最后,通过GXL二次开发技术扩展系统内嵌国产卫星数据正射纠正处理流程,可以全程自动化处理,不再受限于上述3个限制条件,更好地满足实际业务化生产需求,优化后正射产品数据生产业务化流程如图9所示,其中红色为扩展的二次开发模块,常规GXL数据处理流程见图6。

为了有效地验证GXL二次开发的效能,针对同一业务批次的GF-1/GF-2/ZY1-02C的混合数据源,本文设计2个实验比对方案: 方案一为运行二次开发优化数据处理流程模式进行生产处理,并分别统计新增模块的运行时间; 方案二为除内嵌模块在GXL环境下运行外,新增优化处理模块使用单机运行或者人工交互完成,并统计运行时间。表4描述了“原始影像解压缩”模块在上述2个比对方案中运行的结果; 通过统计时间可知“原始影像解压缩”模块的平均运行时间在方案二中表现较好,但在整体任务中,方案一较方案二得到了较高的加速比(16.614),表5分别统计了“影像完整性分析”模块的运行时间和操作复杂度。而“完整性分析”模块在方案二表现较好,表明单次执行模块时,单机运行较快,而多任务处理时二次开发可以更好地利用集群化提高生产效率。

表6统计了“正射产品成果整理”一系列模块(其中,M1—M5分别代表成果整理二次开发的5个模块)在2个实验方案运行的结果,最终形成一整套遥感影像融合成果文件集: 包含具体的融合产品文件和质量生产检测报告、以及对应的地理范围矢量文件和缩略图,文件命名方式如2.2节中业务要求一致。

分析以上表格数据可得出如下结论: ①由于“影像完整性分析”模块只运行主作业模式,并没有并行执行,其工作效率低于直接在单机上运行该程序算法(表5),这是由于GXL集群式消息传递服务所致,即使只运行一个主节点作业,也避免不了各节点之间的通信与消息传递,从而降低了运行效率; ②二次开发模块在集群环境下运行效率高于单次执行(表4和表6),表明利用GXL二次开发功能可充分调用集群平台资源,将二次开发算法分布式部署,提高执行效率; ③二次开发模块可以和原GXL内嵌模块链式执行可定制流程设计,操作灵活,简便快捷,更适合大规模的数据处理。

为了统一比较,将二次开发模块所运行时间的总和统计于表7,图10为其可视化结果。图表表明,GXL二次开发虽然有部分模块会降低执行效率,但却增加了操作的简便性,使处理流程更加完整。而从整体来看,GXL的二次开发对国产卫星数据处理可充分发挥集群式电脑优势,执行效率得到了较好的优化(加速比16.48),同时结果和人工交互的一致。所以GXL二次开发对国产卫星数据处理流程不仅使用业务化流程更加优化,还可充分利用集群计算资源,提高数据处理效率。

本文通过从GXL软件架构框架MCV模式入手,重点分析基于MCV的二次开发方法,并结合国产卫星数据处理流程及其业务化运行中的受限条件,扩展性开发“原始影像解压缩”、“影像完整性分析”和“正射产品成果整理”功能模块,嵌入并改进现有数据处理流程,通过实验分别统计基于GXL二次开发改进的流程与原流程的运行效率。结果表明:

1)基于MCV模式的GXL二次开发可有效利用集群计算资源,充分提高了新开发功能模块的运行效率。

2)利用GXL二次开发优化后的国产卫星数据处理流程,不仅自动化程度高,而且在相同工作量的情况下,整个流程具有更高的处理效率。

本文研究的范围是基于MCV模式下的GXL二次开发方法,需要考虑3个层次的程序编写扩展,具有一定的复杂性。GXL是以作业为管理核心的调度平台,同时也开放了针对作业管理服务器JPS的调用接口,具有开发力度小、维护成本低等优势,未来可考虑两者结合式开发模式,预期既可以灵活扩展GXL功能,又可降低开发成本,更好地满足国产卫星数据处理的业务需求。