ieee journal of selected topics in ... - sensor web groupswe.whu.edu.cn/cnc_web/paper/18.pdf ·...

IEEE JOURNAL OF SELECTED TOPICS IN APPLIED EARTH OBSERVATIONS AND REMOTE SENSING, VOL. 5, NO. 5, OCTOBER 2012 1519

A Sharable and Interoperable Meta-Model forAtmospheric Satellite Sensors and Observations

Nengcheng Chen and Chuli Hu

Abstract—How the heterogeneous and distributed atmosphericsatellite sensors can achieve precise discovery and collaborativeobservation is a big challenge. In this study, we propose an atmo-spheric satellite sensor observation system meta-model that reusesand extends the existing geospatial or sensor-related metadatastandards to enable the sharing and interoperability of atmo-spheric satellite sensors. The Open Geospatial Consortium SensorModel Language (SensorML) has a clear hierarchy in describingthe metadata framework, and it is adopted as the carrier toformalize our proposed meta-model into the Atmospheric Satel-lite Sensor Observation Information Model (A-SSOIM). Threedifferent types of atmospheric satellite sensors are used to testthe versatility of the proposed meta-model and the applicabilityof this formal expression of A-SSOIM. Results show that theproposed meta-model can be reused in all kinds of atmosphericsatellite sensors to enable the sharing of atmospheric satellitesensor information and potentially promoting the interoperabilityof these satellite sensors.

Index Terms—Atmospheric satellite sensor metadata, sensorinformation model, sensor interoperability, sensor management,sensor web.

I. INTRODUCTION

A TMOSPHERIC monitoring for environmental safety ne-cessitates the observation of trace gases, aerosols, clouds,

and physical parameters [1]. According to the NASA Sciencemissions, such observations cover hundreds of missions for at-mospheric remote sensing, and each mission is characterized bythe use of heterogeneous and distributed sensor systems. Giventhe growing number of atmospheric satellite sensor resources,improved sensor capability, and increased observational taskcomplexity, as well as the lack of mechanism to provide a uni-fied and standard description of an atmospheric satellite sensorobservation system and its associated metadata, the facilitationof precise discovery and collaborative observation for the avail-able resources has been a major problem.

Manuscript received December 30, 2011; revised March 20, 2012; acceptedApril 29, 2012. Date of publication June 19, 2012; date of current versionNovember 14, 2012. This work was supported in part by the National Basic Re-search program of China under Grant 2011CB707101, by the National NatureScience Foundation of China program under Grants 41023001, 41171315, and41021061, by the Program for New Century Excellent Talents in Universityunder Grant NCET-11-0394, and by the Fundamental Research Funds for theCentral Universities under Grant 201161902020004.The authors are with the State Key Lab for Information Engineering in

Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University,Wuhan 430079, China (corresponding author e-mail: [email protected]).Color versions of one or more of the figures in this paper are available online

at http://ieeexplore.ieee.org.Digital Object Identifier 10.1109/JSTARS.2012.2198616

The term “sensor web” was first proposed by the NASAwithin the definition [8]: “A Sensor Web is a system of intra-communication spatially distributed sensor pods that can bedeployed to monitor and explore new environments.” A web ofsensors can enable Earth Observation vision [10]. The SensorWeb Enablement (SWE) initiative of Open Geospatial Con-sortium (OGC) defines that a framework has the aim to allowan interoperable usage of sensor resources by enabling theirdiscovery, access, tasking, as well as eventing and alerting [9].Open, standardized sensor information model can help to

identify sensor inherent characteristics and capabilities, as wellas to identify current geolocation, observation valid time, etc.,of a sensor observation system [2]. The information provideddetermines which sensors can provide the needed observationfor a specific task or which centers allow certain tasks to besubmitted to specific sensors, etc. [28]. This means that theunified and standard sensor information model can be used todiscover the available sensors. Sensor Model Language (Sen-sorML) [7] is one of the SWE information model standards,which provides a flexible and general framework for describingsensor information used for discovering sensors, geolocatingsensor observations, and exploring a variety of propertiesassociated with the current tasks. We have reviewed somestandards for sensor information description [3]–[5], such asthe IEEE standard for smart transducer interfaces (IEEE 1451)[6], Energy Conservation and Homecare Network (ECHONET)[11], Device Kit [12], and Device Description Language (DDL)[13]. These four standards are described by proprietary lan-guage to be applied in domain-specific sensor informationmodels that share the feature of low versatility. Unlike thesefour standards, SensorML represents a standardized descriptivemeans for the sensors and observations. In the sensor webenvironment, SensorML has been used as a metadata encodingformat with a broad range of applications, such as Europeandirective INSPIRE (http://www.ec-gis.org/inspire/), SANY(http://sany-ip.eu), OSIRIS (http://www.osiris-fp6.eu), andOOSTethys (http://www.oostethys.org). The existing sensorinformation models have defined the standard metadata de-scribing formats by following the SensorML schema. However,they are all flawed in developing the unified metadata elementsthat satisfy the requirement of sensors for observation sharingand interoperation. That is, just defining the metadata encodingformat is not sufficient.Metadata about sensors, platforms, sensor data, and obser-

vation process is a critical aspect of Sensor Web infrastructures[20]. Di [17] analyzed the metadata requirements for emergingsensor webs, and noted that “Availability of metadata forthe Sensor Web can be very useful in discovery of the right

1939-1404/$31.00 © 2012 IEEE

1520 IEEE JOURNAL OF SELECTED TOPICS IN APPLIED EARTH OBSERVATIONS AND REMOTE SENSING, VOL. 5, NO. 5, OCTOBER 2012

sensor at right time and location with the right quality, andto achieve sensor interoperation.” However, the current meta-data cannot meet the requirements of sensor accessibility andinteroperability.This study discusses the composition of a unified meta-model

for atmospheric satellite sensor observation systems to promotethe sharing and interoperability of those heterogeneous and nu-merous sensors. The paper starts with the specific requirementanalysis of sharing and interoperability for atmospheric satellitesensors. Next, we make the comparison of a couple of maturegeospatial or sensor-related metadata standards to identify waysto better describe the atmospheric satellite sensors for sharingand interoperation. Then, the sensor observation system meta-model has been constructed to include non-functional metadatamodel and functional process model. After that, we formalizethe proposed meta-model by following the eXtensible MarkupLanguage (XML)-based SensorML description standard. In thismanner, the so-called Atmospheric Satellite Sensor ObservationInformation Model (A-SSOIM) was developed. At last, the ver-satility of the proposed meta-model is verified by using differenttypes of atmospheric satellite sensors, and the applicability ofthe A-SSOIM will be demonstrated. Overall, the objectives ofthe present work are twofold. First, we propose a meta-modelfor atmospheric satellite sensors and observations. Second, weverify the versatility of the proposed meta-model and the ap-plicability of A-SSOIM formalized from the meta-model as anaccessible and interoperable model.This paper contributes a proposal for the atmospheric satel-

lite sensor observation system meta-model based on specificrequirement of sensor web and its associated metadata [17].This meta-model attempts to merge the distributed and hetero-geneous sensors under a uniform metadata framework. TheA-SSOIM is the information model formed by adopting theSensorML metadata encoding standard to formalize our pro-posed meta-model. In A-SSOIM, the discovery of atmosphericsatellite sensors and observations is achieved and the interop-erability of sensor observation process is further promoted.

II. REQUIREMENTS

A. Types of Atmospheric Satellite Sensor Resources

When analyzing which types of atmospheric satellite sensorshave to be included in atmosphere monitoring, four types ofsensor resources were identified by the National Oceanic andAtmospheric Administration (NOAA) Atmospheric ChemicalApplication [18] and NASA Global Atmospheric CompositionMission [19]: sensor resources on changes in the ozone layer,air quality, climate change, and meteorological prediction.The first type of resource is used to probe the dynamics, ra-

diation, and chemistry of the stratosphere, especially in rela-tion to the ozone layer. The second resource focuses primarilyon tropospheric air quality measurements (CO, NO2, CH2O,SO2, aerosols, etc.). The third observes the global water andenergy cycles, climate variations and trends, and response ofthe climate system to increased greenhouse gases. The fourthserves the needs of nowcasting applications, such as numerical

weather prediction (temperature, moisture, wind, clouds, rain,snow, frost, dew, and lightning).

B. Addressing the Characteristics for Atmospheric SatelliteSensor Interoperability Under Sensor Web Environment

This section aims to identify what is needed for atmosphericsatellite sensor observing systems to realize sharing and inter-operability. Atmospheric satellite platforms are moving obser-vation systems where each platform is equipped with a varietyof sensors. One feature is that each sensor has different ob-servation objects and ranges, and different bands of the samesensor can be applied to different observation scenarios. An-other important feature is that all atmospheric compositions arein floating forms. Therefore, some physical properties, such asthe location and orientation of platforms and sensors, dynamicgeolocation system, etc., are dominant factors for the discoveryof remote movable sensors. The third feature is that many di-verse and complex atmospheric satellite sensors have not beenfully utilized; those knowable satellite sensors are often useddepending on the experience of experts. Although the satellitesensors cannot be dispatched directly, we should find a wayfor some complex observation tasks to collaborate those not-being-well-knowable satellite sensors, thereby reducing the ob-servation blind spots and improving the observation quality. Inconclusion, for the atmospheric satellite observation, it requiresaccurately finding the applicable sensors, quick tracking andgeopositioning of the monitoring object within the actual area,as well as the accessibility of useful information for planningand accessing.Under a sensor web environment, the purpose of a sensor dis-

covery mechanism is to identify an appropriate sensor at theright time and location with the right quality. The InternationalDirectory Network (IDN) of the Committee on Earth Observa-tion Satellite (CEOS) is an international gateway to the worldof Earth Science data. For finding earth observation platformsand sensors, the IDN team [17] recommends that five aspects beimproved: standard syntax for sensor description, sensor geolo-cation for dynamic tasking, applicability of sensor observations,sensor quality, and accessibility. Considering these recommen-dations and the specific characteristics of atmospheric satellitesensor observation, as well as the sensor identifications and clas-sifications that are common to sensor discovery, the followingcriteria are deemed necessary for the accessibility and interop-erability of atmospheric sensor resource:• formalization: allowing machine-to-machine interfaces forautomated exchange of the unified sensor metadata de-scription framework;

• capability: identifying the capability of the satellite sensorfor users to determine the capability of sensor observation;

• geolocation: geopositioning information for users to findall the available satellite sensors for a certain location witha dynamic observation system;

• quality: recording satellite sensor quality and the associ-ated observation accuracy for quality assurance of sensorand its observation application;

• interoperation service: defining the accessibility of sensorand its associated observations for determining whether thesensor observation can be available.

CHEN AND HU: A SHARABLE AND INTEROPERABLE META-MODEL FOR ATMOSPHERIC SATELLITE SENSORS AND OBSERVATIONS 1521

TABLE ITHE COMPARISON OF EXISTING METADATA STANDARDS

C. Considering Atmospheric Sensor Observation SystemMetadata

Metadata is closely related to sensor interoperability, and pro-vides sufficient information to enable appropriate sensor se-lection, dynamic access, and effective management. The ex-isting metadata standards developed by the ISO/TC 211, OGC,Federal Geographic Data Committee (FGDC) [20], and NASAGlobal Chang Master Directory (GCMD) [21] are used mainlyfor geospatial data. Geospatial data are directly related to thesensor observation system; thus, some of those metadata stan-dards inevitably involve a part of metadata description aboutthe sensors and platforms. As shown in Table I, nine geospatialor sensor-related metadata standards are considered. “NASAGCMD Keywords” is a set of keywords describing the data andservices of earth observations. The “NASA GCMD DirectoryInterchange Format (DIF)” [22] metadata model defines sen-sors around the instrument in terms of two Ancillary Descrip-tions (AD)—the instrument (AD-I) and the platform (AD-P);AD-I defines the instrument identification and its associated de-scription; AD-P defines the platform identification and its as-sociated description. The “FGDC-Remote Sensing Extension”[25] is extended from “FGDC Metadata Content Standard” tosupport the collection and processing of geospatial metadata de-rived from remote sensing. ISO 19115 [26] defines the funda-mental metadata for describing geographic data. ISO 19115-2extends ISO 19115, defining metadata for describing images.ISO 19115 and ISO 19115-2 [24] are based on the FGDC meta-data standards. Especially, most of ISO 19115-2 are based onthe “FGDC-Remote Sensing Extension”. ISO 19130 [23] liststhe metadata for remote sensor’s geoposition. SensorML fo-cuses on the representation of sensor observation system by fol-lowing XML schema. OGC Catalogue Services for Web (CSW)application profile for Earth Observation products [33] definesthe way Earth Observation products—and not direct sensor-ori-ented metadata elements—are organized and implemented inthe Catalogue for encoding, discovery, retrieval and manage-ment of sensor information.

Table I shows that all standards have different points onmain elements, application/focus, usage, and encoding schema.Nonetheless, they are all concentrated on information sharingand interoperability; some elements in the different metadatacontents overlap: “Instrument_Type” inside identification ofthe FGDC versus “Instrument Type” inside identification ofthe GCMD DIF; “Instrument_Short_Name” of the FGDCversus “Sensor_Short_Name” of the GCMD DIF; etc. Someunique elements also belong to proprietary standards, such asthe “GeopositionInfo” of ISO 19130. SensorML provides theXML-based metadata representation, while other standardsonly define the contents or data sets of metadata.Those metadata standards developed prior to the newly

emerged Sensor Web cannot meet the basic metadata require-ments of the Sensor Web. That is, none of above standardshas completely covered the metadata elements satisfying thecharacteristics of atmospheric satellite sensor sharing and in-teroperability. The solutions offered in the current research areto avoid the re-creation of metadata wherever possible, reusethe existing standards, as well as expand the new metadataelements by complying with the specific needs.

D. Hierarchy of Sharable and Interoperable A-SSOIM

Descriptive information of sensors is undoubtedly the mainsharable resource of A-SSOIM. Sensor interoperability is basedon the sharing of such information and enables collaborationbetween multisensors. However, the factor that determineswhich sensors can collaborate depends on whether these sen-sors can perform complementary observation. The A-SSOIMprocess model (e.g., geolocation model) is used to evaluate thecomplementary capability of the sensors. Therefore, sensor-de-scriptive information is the first hierarchy of A-SSOIM thatenables the sharing of sensor information resources; the processmodel, which defines the process name, method, and dataflow,is another hierarchy that aids complementary observationamong multisensors.


Fig. 1. Architecture of the sharable and interoperable system.

III. FRAMEWORK

A. Sharable and Interoperable Architecture and Sub-Models

The goal of the proposed method is to provide a sharable andinteroperable meta-model for atmospheric satellite sensors andobservations. This sharable and interoperable architecture mustbe standard, uniformly described, explicit, and comprehensive.The proposed meta-model and A-SSOIM act as an “interme-

diary broker” between users and atmospheric satellite sensor re-sources. Users can precisely discover the available atmosphericsatellite sensors and observations through the A-SSOIMmodel-based engine.As shown in Fig. 1 from the bottom up, the atmospheric satel-

lite sensors and their associated observation information can bedescribed by a variety of metadata [15], such as descriptive,structural, administrative and process metadata, etc. The atmo-spheric satellite sensor observation system meta-model is madeup of those metadata. Then, after formally expressing the pro-posed meta-model by following the XML-based SensorML de-scription standards, the A-SSOIM is established. The core ofthis architecture is its meta-model, which comprises the func-tional and non-functional modules.1) Non-Functional Meta-Model: The non-functional

meta-model facilitates the discovery of information relevantto the atmospheric satellite sensor. According to thespecific criteria analyzed in Section II, the non-functionalmeta-model of the atmospheric satellite sensor can bedecomposed into three segments: Sensor Tag, SensorObservation Capability Management, and SensorInteroperation Service (Fig. 2). Each segment contains its ownsensor information. In particular, those different sensorinformation can be formalized by different data types,which are defined as an eight-tuple, expressed as

Fig. 2. Non-functional meta-model structure.

,which represent “General”, “Properties”, “Space-TimeReference”, “GeoPosition”, “History”, “Contact”,“Constraints” and “Interface” information, respectively. Eachof the eight-tuple data types can be attributed to a specificmetadata type. Herein the non-functional meta-modelis composed of different kinds of metadata. Theconcrete mapping relationship of sensor information tospecific metadata encoding format will be described in“Formalization” section.Sensor Tag consists of sensor identification information,

which is used to describe the basic identification of the sensorand its platform, namely the minimum information for sensordiscovery. Sensor Observation Capability Management in-cludes sensor capability, sensor geolocation, and sensor qualityinformation. Sensor capability is primarily composed of thecapacity for temporal, spatial, and spectral resolution, as wellas sensor application capability. Sensor geolocation takes theinformation for satellite sensor dynamic geolocation into con-sideration. Sensor quality provides information on the qualityof the physical sensor itself and the observation accuracyof satellite sensors. With the identification and observationcapability of sensors assessed, the issue of availability oraccessibility of the sensor and its associated observation arises.Sensor Interoperation Service is intended to cope with aboveissue; for instance, the accessibility information of how toaccess the sensor, whether the user has sufficient privileges toget the sensor, who is the person in charge of this sensor, etc.,should be provided.2) Functional Meta-Model: The process model carries stan-

dard objects inherited from the abstract functional meta-model.The core of the process model lies in performing processoperations for sensor observation and its associated data. Theprocess dataflow (input and output) and process methods canbe described in process metadata (Fig. 3). The process modelcan be divided into two types: physical and non-physicalmodels. Our previous paper [30] described the details of thesetwo types of process model. The non-physical process modelcan be treated as merely a mathematical operation that trans-forms input to output. The physical process model describesa process that has some relationship to physical information,such as the position and orientation for geopositioning. That


Fig. 3. Functional meta-model structure.

is, the “Space-Time Reference” characteristic insidenon-functional meta-model should be mandatorily described infunctional meta-model, while for the functional process model,there is no mandatory requirement that the whole non-func-tional meta-model should be embedded inside the functionalmeta-model.The entire process of functional meta-model is a discovery-

oriented application, and the metadata description of non-func-tional meta-model can perform as the auxiliary information fordiscovery of sensor observation-related process. Therefore, asshown in Fig. 3, the non-functional meta-model can performas an optional component which can be referenced in the func-tional meta-model. The metadata information described in thenon-functional meta-model are not related to the implementa-tion of functional process model, but it plays a fundamental rolein facilitating the understanding and discovery of the sensor ob-servation-related processes.

B. Contents of the Proposed Meta-Model

This section aims to identify the specific contents of theproposed meta-model. Here, Atmospheric Satellite SensorMetadata (ASS_Metadata) represents the necessary contents ofthe meta-model uniformly in the Unified Modeling Language(UML). The ASS_Metadata can be divided into three classes:ASS_NonFunctional, ASS_Functional, and ASS_MetadataEx-tension. The ASS_NonFunctional class can be specializedinto ASS_Identification, ASS_ObservationCapability andASS_Accessibility subclasses. The ASS_Functional can bespecialized into ASS_Process.NASA GCMD Keywords can well describe the data and ser-

vices of Earth Observation [31]. GCMD DIF AD-I and AD-Pare specially used to describe the basic identification of instru-ment and platform. While most of existing metadata standards(part C of Section II) contain the identification information,CEOS IDN currently recommends the NASA GCMD DIF asthe directory for sharing among the platform/instrument nodes[17], [31]. Taking these into account, the concrete contentsof ASS_Identificaiton including keyword, ID, type, and nameof platform and sensor (Fig. 4) are referenced from NASAGCMD. For the ASS_Capability class, the temporal, spatial, andspectral resolution must be defined, and these elements have

been described in the GCMD DIF AD-I standard. However, forthe specific needs of atmospheric satellite sensor application,such as the “sensor_associated_bands” and “band_associ-ated_application” elements, none of the mentioned standardshave recorded them. Hence we cite the temporal, spatial, andspectral resolution fields from the GCMD DIF AD-I, andthe “sensor_associated_bands” and “band_associated_appli-cation” elements are defined as the new metadata elements.ASS_Quality class contents comprise the physical informationinherited in sensor, such as dimensions, mass, etc., and the ob-servation accuracy information, such as “geolocationQuality”and “radiationQuality”. The intrinsic sensor physical informa-tion can be reused from the GCMD DIF AD-I. The current ISO19130 model supports the geopositioning information for satel-lite sensor, and describes the geometric quality of the satellitesensor and its observations. Therefore, “geolocationQuality”element can be referenced from the ISO 19130. However, thereis no standard in defining a set of radiometric quality indicators[17]; thus, the “radiationQuality” element should be newlyadded to indicate observation accuracy. In addition, ISO 19130describes a physical sensor model to enable users to determinethe geographic location of the dynamic sensor observations;that is, the “SD_Geolocation Information” inside the ISO19130 used for geolocation can be completely transplantedto our ASS_Geolocation to satisfy the proposed atmosphericsensor geolocation needs. The ASS_Accessibility class servesfor sensor interoperation; it contains satellite sensor contactinformation, observation and planning service, the sharinglevel of sensor/user and constraints on the valid time of sensorobservations, etc. The security and legal constraint elementscan be reused from ISO 19115, while the metadata elementsincluding “sensorObser_ValidTime,” “responsibleCenter,”“access_associated_service,” and “SatelliteSensor/User_lev-elOfSharing” must be newly added. The ASS_Process is thenew content including “processID”, “processName”, “input”,“ouput”, and “processMethod”, which have not been defined inthe early metadata standards. In the development of this contentfor the proposed meta-model, we adopted a “hybrid” approachin aggregating and extending the existing standards. Therefore,the class of ASS_MetadataExtension is kept for extension tosatisfy future higher requirements.

C. Formalization

This section aims to transform the meta-model into theformal expression. Of the compared standards, the NASAGCMD DIF, ISO, and FGDC Remote Sensing Extension aremore oriented toward broadly identifying the metadata contentswhich focus primarily on data sets, whereas SensorML is moretargeted to formal descriptions of sensors and of observationprocessing. SensorML has a clear hierarchy in formalizing themeta-model. The metadata framework of SensorML includesidentifiers, classifiers, constraints, capabilities, characteristics,contacts, documentation, and history in addition to input,output, parameters, and system location, which can be used forthe discovery of sensor systems and observation processes, aswell as for deriving higher-level information from observation[7]. Therefore, the current work adopts it as the carrier to


Fig. 4. UML diagram for A-SSOIM metadata contents.

formalize the proposed meta-model to A-SSOIM. The formal-ization includes two parts: the non-functional metadata modeland functional process model.

As shown in Table II, we maintain a relationship mappingfrom the atmospheric satellite sensor meta-model to the Sen-sorML metadata framework. The information of atmospheric


TABLE IIMAPPING THE RELATIONSHIP BETWEEN ASS_METADATA CONTENTS AND SENSORML

satellite Sensor Tag (Fig. 2) can be described in the Sen-sorML metadata field, including “keywords,” “identification,”and “classification.” The Sensor Accessibility information isrelatively complex, and its observation constraint, such as “sen-sorObservation_ValidTime,” “Access_legalConstraints,” and“Access_SecurityConstraints,” are mapped into “validTime,”“securityConstraint,” and “legalConstraint” of SensorML,respectively. For the level of sharing information, this elementcan be viewed as the characteristic; thus “Sensor_levelOf-Sharing” and “User_levelOfSharing” can be embedded inSensorML “characteristics.” For a given satellite sensor, thecontact information such as sensor “responsibleCenter” and“primeContractor” should be filled in “contact.” The onlinesensor information element, “online resource,” can be mappedin “documentation.” “Access_associated_service,” includingsensor observation service and sensor planning service, can berecorded as a service in “serviceInterface.” In terms of sensorgeolocation, the “SD_GeolocationInformation” elements areall related to the sensor geolocation model to be described in“characteristics.” The sensor quality information reflects thecharacteristics of the sensor and its observation; thus, it shouldbe filled in “characteristics.” The type of sensor capability isintended for identifying the sensor and its associated processcapability, and its corresponding element should be mappedinto “Capabilities.” The dataflow of sensor process metadata ismainly reflected in “input,” “output,” and “processMethod.”After mapping the relationship between ASS-metadata

contents and SensorML framework, the next step is how torepresent those metadata contents. SensorML structure can beused to describe any of the above metadata contents, the essenceof which is supported by the SWE Common Data Model[34]. SWE Common Data Model consists of a bottom datasetswe:field, which includes a series of data type: swe:AnyScalar{swe:Count, swe:Quantity, swe:Time, swe:Boolean, swe:Text},swe:AnyRange, {swe:QuantityRange, swe:CountRange,

swe:TimeRange}, swe:DataRecord{swe:field}, swe:DataArray{swe:field}, swe:value, etc. Each data type has its ownstructure. For example, swe:DataRecord has a structurelike: <swe:DataRecord> <swe:field> <swe:Quantity><swe:value> <swe:value/> <swe:Quantity/> <swe:field/><swe:DataRecord/>. We can use the exampleddata structure to describe the content “power” inASS_Quality as: <swe:DataRecord> <swe:field name= “Power”> <swe:Quantity> <swe:uom code = “w”><swe:value>65<swe:value/> <swe:Quantity/> <swe:field/><swe:DataRecord/>. Similarly, we can use other data types toexpress other ASS_Metadata contents. The detailed instancewill be demonstrated in Section IV.

IV. INSTANCES AND APPLICATIONS

A. A-SSOIM Instances for Diverse Sensor Experiments

The prototype (SensorModel V1.0) has been developed bythe State Key Lab of Information Engineering in Surveying,Mapping and Remote Sensing (LIESMARS) of Wuhan Univer-sity in China. The core of the prototype is to rapidly establishthe A-SSOIM based on the proposed meta-model. On the basisof SensorModel prototype, we use three kinds of atmosphericsatellite sensors to demonstrate A-SSOIM.The Ozone Monitoring Instrument (OMI) is the key sensor

on the Earth Observing System (EOS) AURA satellite, whichalthough mainly designed to monitor ozone can be extendedto other atmospheric compositions including NO2 and SO2.Fig. 5 shows that the “band_associated_application” field ofsensor_Capability records different bands within different ap-plications. The “responsibleCenter” field shows that the Nether-lands Agency for Aerospace Programmes (NIVR) and FinnishMeteorological Institute (FMI) are the centers responsible forOMI. The complete A-SSOIM for OMI records can be viewedhere: http://swe.whu.edu.cn/OMI-A-SSOIM.xml.


Fig. 5. Sample of A-SSOIM for the ozone monitoring instrument.

Fig. 6 shows a MODIS sensor information model. TheMODIS aboard the Aqua satellites has a valid observationtime between “1999-01-01” and “2014-12-31.” The geolo-cation information of the Aqua-MODIS system containssix fields, namely “focalLength,” “pixelGridCharacteris-tics,” “principalPointCoordinated,” “affineDistortionCoef-ficients,” “radialDistortionCoefficients,” and “decentering-Coefficients.” All of these elements are referenced fromthe ISO 19130 geolocation metadata model. The completeA-SSOIM for the MODIS record can be viewed in this website:http://swe.whu.edu.cn/MODIS-A-SSOIM.xml.The above two examples are mainly used to show the

non-functional metadata model. In addition, the proposedA-SSOIM can also support sensor processes ranging fromlow-level sensor observation process to high-level data pro-cessing. Fig. 7 shows how the geolocation process modelof AVHRR aboard the NOAA series satellite is encodedin an A-SSOIM form. The input of the sensor raw attitudecomprises the “time,” “latitude,” “longitude,” “altitude,” “true-Heading,” “pitch,” and “roll” parameters. After referencingto the external process algorithm “urn:ogc:def:process:Raw-Postion_to_Prelocation,” the output can be yielded. Thisoutput includes the three-direction coordinates (xyz) ref-erenced from the WGS84 coordinate system. The de-tailed A-SSOIM for AVHRR records can be viewed here:http://swe.whu.edu.cn/AVHRR-A-SSOIM-Geolocation.xml.

Fig. 6. Sample of A-SSOIM for MODIS.

B. Applications in Registry and Discovery

The open sources Sensor Observation Service (SOS) [32]and Sensor Instance Registry (SIR) [27] initiated by the 52North (URL: http://52north.org/communities/sensorweb/) havebeen adopted to demonstrate the application of atmosphericsatellite sensor registry and discovery. RegisterSensor opera-tion inside the SOS and InsertSensorInfo inside the SIR areused to insert the SensorML-based information model, whichshould be validated against the SensorML profile for discovery[16]. Our proposed A-SSOIM is a domain-specific informationmodel where the inside metadata cannot be fully satisfied bySensorML profile. Therefore, we should do the secondarydevelopment on the functions of RegisterSensor operationinside the 52 north SOS and InsertSensorInfo operation insidethe 52 north SIR according to our proposed A-SSOIM, andguarantee that A-SSOIM can be integrated into SOS/SIR.We have deployed the SOS in our server (http://swe.whu.

edu.cn:9000/SOS). As a SOS producer, we publish thoseabove A-SSOIM instances as web resources through theRegisterSensor operation of SOS interface. In SOS database,each sensor instance of above three A-SSOIM is registered toa record within the unique SensorID: swe-OMI-sensorInfor,swe-AVHRR/3-sensorInfor, swe-MODIS-sensorInfor, respec-tively. The DescribeSensor operation of SOS allows the querylike “SensorID = swe-MODIS-sensorInfor” to retrieve the


Fig. 7. Sample of A-SSOIM for AVHRR.

satisfied sensor. Nonetheless, SOS interface only enables theretrieval of A-SSOIM by the search criteria of “SensorID”.We deploy the SIR implementation into our local server

(http://swe.whu.edu.cn:9000/SIR). SIR is a powerful web ser-vice interface used to manage the SensorML-based informationmodel; it allows a client to search for sensor instances bysearch criteria, such as observed phenomenon, observed data,temporal criteria, text fragments, unit of measure, sensorID andSWE service. Also, it is capable of automatically harvestingsensor metadata-based SensorML documents from a certainSWE service (e.g., http://swe.whu.edu.cn:9000/SOS/sos?) andinserting them into SIR database.Our deployed SIR portal (http://swe.whu.edu.cn:9000/

SIR/A-SSOIM-testclient.html) enables the atomic searchcriteria (SensorID_In_SIR, SWE_Service, Search_Text, Ob-servation_Phenomenon, BoundingBox, Temporal) and thecomposite search criteria (Search_Text& Observation_Phe-nomenon, Search_Text&BoundingBox, Search_Text&Tem-poral, BoundingBox&Temporal, BoundingBox& Observa-tion_Phenomenon, etc.) to discover the atmospheric satellitesensor. As shown in Fig. 8, we send a composite searchcriteria where “SearchText = ozone”, “PhenomenonName= urn:ogc:def:property:OGC::OzoneConcentration”, “begin-Position = 2000-01-27T09:07:39+0100” and “endPosition =2011-11-27T09:07:39+0100”.Fig. 9 illustrates the sensor discovery response. The contents

of the response are the A-SSOIM instance which meets the

above composite search criteria (Fig. 8). The yellow marks arethe places that exactly match with the query expression.

V. DISCUSSION

A. Versatility of the Meta-Model

As illustrated in Section IV, three different types of atmo-spheric satellite sensors, namely OMI onboard AURA formonitoring stratosphere ozone, MODIS onboard Aqua formonitoring tropospheric air quality measurements and AVHRRonboard NOAA series satellite for monitoring weather predic-tion, are formally described into the corresponding sensor in-formation model. By complying with the specific requirementsof atmospheric satellite sensors and observations, the proposedmeta-model has fully considered the aggregated information,including sensor identification, sensor observation capability,quality and geolocation, as well as sensor accessibility. That is,the current information model has comprehensively covered theinformation needed for sensor accessibility and interoperation.Therefore, the meta-model can be applied to describe differentatmospheric satellite sensors.

B. Accurately Accessing the Atmospheric Sensor Resource byUsing This Meta-Model-Based A-SSOIM

The proposed meta-model-based A-SSOIM is unlike theinformation model of public search engine sites (such asGoogle and Yahoo) or domain-specific search engine sites(NASA GCMD retrieval portal). For example, with thekeywords “water vapor” and “satellite sensor” entered assearch criteria in Google (http://www.google.com.hk/search?),463,000 entries are generated. In the NASA GCMD retrievalportal (http://gcmd.gsfc.nasa.gov/KeywordSearch/Home.do?Portal=GCMD&MetadataType=0), we refine the searchcriteria with “atmospheric instruments/sensors” and 10,111 en-tries are generated. We input “water vapor” as the second-levelsearch criteria, and 1,329 entries remain. These retrieval resultsshow that examining whether any desired information exists ac-cording to the suggested pages is tedious and time-consuming.Although the powerful SIR incorporates a SensorML discoveryprofile [16] that defines a minimum set of metadata supportingthe multiple search criteria, the insidemetadata can just meet thebasic mode of sensor discovery, which leads to search bias andconstraints. By contrast, the proposed A-SSOIM is formalizedfrom the meta-model consisting of a suite of clear hierarchymetadata. A-SSOIM is an XML-based description that enablesthe “text fragments” search operation of SIR; the “sensor_as-sociated_applications” and “band_associated_application”metadata elements of A-SSOIM can support the “ObservedPhenomenon” search operation of SIR; “sensorObserva-tion_validTime” can satisfy the “temporal criteria” operation ofSIR. That is, A-SSOIM can enable all the search criteria of SIR.Moreover, it can support the search criteria within more detailedand clear hierarchy, such as the “SensorType,” “SensorName”of sensor identification, “spatialResolution,” “temporalResoul-tion,” “bands_associated_application” of sensor capability and“responsibleCenter,” “sharingLevel_of_SatelliteSensor/users”of sensor accessibility, etc. For example, we conduct the more


Fig. 8. A composite search atmospheric satellite sensor request.

Fig. 9. Search atmospheric satellite sensor response.

precise and concrete query like “sensor_associated_platform= Terra” of sensor identification and “spectralResolution =600 nm–2000 nm,” “bands_associated_application = watervapor” of sensor capability, the search can be accurately lo-cated by contrasting with SIR where the main sensor searchesrely on fuzzy mode by the criteria of “text fragments”. There-fore, the future of developing this meta-model-based searchengine to identify atmospheric satellite sensors can provideusers more accurate and targeted results.

C. Use of Functional Process Model Inside A-SSOIM toFurther Promote Atmospheric Satellite Sensor CollaborativeObservation

Unlike other sensor information models, our A-SSOIM hasdescribed both non-functional metadata model and functionalprocess model. The A-SSOIM builds a synthetic sensor ob-servation system that can be used to support multisensoryinteroperability scenarios. The particularly important aspect


of sensor web is that the sensor data are rarely used as anend product; usually higher-level information is derived outof low-level observation data. The dynamic satellite sensorinevitably involves the dynamic geolocation which shouldbe modeled as a process where the process input can betransformed to output by executing the corresponding processmethod. The SIR implementation just supports the static ob-servation bounding area, while in the A-SSOIM the dynamicgeolocation process has been developed (Fig. 7). With regard toa specific atmospheric satellite observation task, we can utilizea specific engine interface based on A-SSOIM to calculatethe geoposition of the atmospheric satellites. Thereby, theinformation that sensors exist in a specific time of the specificarea can be identified. After that, the comparison among the“band_associated_application” of sensor capability insidedifferent A-SSOIM should be conducted to determine whetherthose satellite sensors have commonalities in observing thesame phenomena. At last, whether sensors that meet therequirements of the previous steps are available can be eval-uated by checking the contents of sensor accessibility insideA-SSOIM. In conclusion, the proposed A-SSOIM can play afundamental role in promoting the scenario where differentsensors within sufficient accessibility complement one anotherin specific observation tasks.

VI. CONCLUSION AND OUTLOOK

The sharing and interoperability of atmospheric satellite sen-sors under sensor web environments is a challenge; we foundthat the solution is to integrate the metadata into sensor informa-tion model. This work constructs the A-SSOIM. The method-ology for creating A-SSOIM is divided into two steps: the devel-opment of an atmospheric satellite sensor meta-model and theformalization of the proposed meta-model into the SensorML-based A-SSOIM. The proposed A-SSOIM is examined underdifferent types of atmospheric satellite sensors. The results con-firm that it performs not only as a non-functional descriptivemodel for sharing but also as a functional model that plays afoundation in aiding atmospheric satellite sensor collaboration.The proposed meta-model is expected to enable extension

under higher requirements. Strategies for providing an auto-mated mapping mechanism from the meta-model to the Sen-sorML description format and developing a standard proposedmeta-model-based service interface to support the observationprocess interoperability will be the subject of future investiga-tions. Besides, how to extend our proposed method to build theother thematic specific (e.g., hydrology) or observation prin-ciple specific (e.g., optic/microwave or passive/active) sensormeta-model by fully considering their special characteristicswill be a very interesting issue.

REFERENCES[1] M. Lee, C. Miller, A. Eldering, and Z. Qu, “Earth science mission con-

cept design system,” in 2007 IEEE Aerospace Conf., 2007, vol. 1–9,pp. 4448–4461.

[2] K. B. Lee and M. E. Reichardt, “Open standards for homeland securitysensor networks,” IEEE Instrum. Meas. Mag., vol. 8, pp. 14–21, Dec.2005.

[3] P. Z. Hu, R. Robinson, and J. Indulska, “Sensor standards: Overviewand experiences,” in Proc. 2007 Int. Conf. Intelligent Sensors, SensorNetworks and Information Processing, 2007, pp. 485–490.

[4] K. Lee, “Sensor standards harmonization—Path to achieving sensorinteroperability,” 2007 IEEE Autotestcon, vol. 1 and 2, pp. 381–388,2007.

[5] J. Graybeal, L. Bermudez, P. Bogden, S. Miller, and S. Watson,“Marine metadata interoperability project: Leading to collaboration,”Local to Global Data Interoperability—Challenges and Technologies,pp. 14–18, 2005.

[6] K. Lee, “IEEE 1451: A standard in support of smart transducer net-working,” in IMTC/2000: Proc. 17th IEEE Instrumentation and Mea-surement Technology Conf., 2000, pp. 525–528.

[7] OpenGIS® Sensor Model Language Implementation Specification(Version 1.0.0), OGC Standard, 180, 2007.

[8] K. A. Delin and S. P. Jackson, “The sensor web: A new instrumentconcept,” Functional Integration of Opto-Electro-Mechanical Devicesand Systems, vol. 4284, pp. 1–9, 2001.

[9] A. Broring, J. Echterhoff, S. Jirka, I. Simonis, T. Everding, C. Stasch,S. Liang, and R. Lemmens, “New generation sensor web enablement,”Sensors, vol. 11, pp. 2652–2699, Mar. 2011.

[10] E. Torres-Martinez, G. Paules, M. Schoeberl, and M. W. Kalb, “A webof sensors: Enabling the earth science vision,” Acta Astronautica, vol.53, pp. 423–428, Aug.–Nov. 2003.

[11] S. Matsumoto, “Echonet: A home network standard,” IEEE PervasiveComput., vol. 9, pp. 88–92, Jul.–Sep. 2010.

[12] C. Chen and S. Helal, “Sifting through the jungle of sensor standards,”IEEE Pervasive Comput., vol. 7, pp. 84–88, Oct.–Dec. 2008.

[13] C. Chen and A. Helal, “Device integration in SODA using the devicedescription language,” in Proc. 9th Annu. Int. Symp. Applications andthe Internet, 2009, pp. 100–106.

[14] OpenGeo SensorWeb Enablement (SWE) Suite, openGeo white paper,7, 2011.

[15] P. Fortier and K. Dasari, “Examining the role of metadata in testingIED detection systems,” Int. Test and Evaluation Assoc. J., vol. 30–3,pp. 421–433, 2009.

[16] OGC® OWS-6 SensorML Profile for Discovery Engineering Report(Version 0.3.0), OGC Discussion Paper, 25, 2009, .

[17] L. P. Di, K. L. Moe, and G. N. Yu, “Metadata requirements analysis forthe emerging sensor web,” Int. J. Digital Earth, vol. 2, pp. 3–17, 2009.

[18] Atmospheric Chemistry Modeling, NOAA Atmospheric ChemicalModeling Workshop, 2007 [Online]. Available: http://www.esrl.noaa.gov/outreach/events/chemworkshop/pdf/NOAAAtmosChemMod-eling.pdf, [Accessed 10 Sep. 2011]

[19] N. Livesey, M. Santee, P. Stek, J. Waters, P. Levelt, P. Veefkind, J.Kumer, and A. Roche, “A future “Global atmospheric compositionmission” (CACM) concept,” in Proc. 2008 IEEE Aerospace Conf.,2008, vol. 1–9, pp. 102–113.

[20] FGDC: Content Standard for Digital Geospatial Metadata: Extensionsfor Remote Sensing Metadata, Federal Geographic Data Committee,140, Reston, VA, 2002.

[21] NASA/GCMD: Ancillary Description Writer’s Guide, Global ChangeMaster Directory, 2011 [Online]. Available: http://gcmd.nasa.gov/User/suppguide/, [Accessed 10 Sep. 2011]

[22] NASA/GCMD: NASA’s Global Change Master Directory (GCMD),Directory Interchange Format (DIF) Writer’s Guide, 2011 [Online].Available: http://gcmd.nasa.gov/User/suppguide/, [Accessed 13 Sep.2011]

[23] ISO 19130: Geographic Information_Imagery Sensor Models forGeopositioning, ISO Standard, 156, 2008, .

[24] ISO19115-2: Geographic Information_Metadata_Part 2: Extensionsfor Imagery and Gridded Data, ISO Standard, 54, 2007.

[25] FGDC: Content Standard for Digital Geospatial Metadata: Extensionsfor Remote Sensing Metadata, FGDC Standard, 140, 2002.

[26] ISO 19115: Geographic Information_Metadata, ISO Standard, 140,2003.

[27] OGC® Sensor Instance Registry Discussion Paper OGC DiscussionPaper, 111, 2010.

[28] S. Jirka, A. Broring, and C. Stasch, “Discovery mechanisms for thesensor web,” Sensors, vol. 9, pp. 2661–2681, Apr. 2009.

[29] I. Simonis and J. Echterhoff, GEOSS and the SensorWeb,WS Geneva,2008.

[30] N. Chen, C. Hu, Y. Chen, C. Wang, and J. Gong, “Using SensorMLto construct a geoprocessing e-Science workflow model under a sensorweb environment,” in Computers & Geoscience, doi:10.1016/j.cageo.2011.11.027.

[31] L.M. Olsen, G.Major, K. Shein, J. Scialdone, R. Vogel, S. Leicester, H.Weir, S. Ritz, T. Stevens, M.Meaux, C. Solomon, R. Bilodeau, M. Hol-land, T. Northcutt, and R. A. Restrepo, NASA/Global Change MasterDirectory (GCMD) Earth Science Keywords. Version 6.0.0.0.0, 2007.


[32] N. Chen, L. Di, G. Yu, and M. Min, “A flexible geospatial sensor ob-servation service for diverse sensor data based on web service,” ISPRSJ. Photogramm. Remote Sens., vol. 64, pp. 234–242, 2009.

[33] OGC®Catalogue Services Standard 2.0 Extension Package for ebRIMApplication Profile: Earth Observation Products (Version 1.0.0), OGCApproved Standard, 146, 2010.

[34] OGC® SWE Common Data Model Encoding Standard (Version 2.0.0),OGC Approved Standard, 207, 2011.

Nengcheng Chen received the B.Sc. degree ingeodesy from Wuhan Technical University ofSurveying and Mapping, China, in 1997, the M.S.degree in geographical information systems fromWuhan University, China, in 2000, and the Ph.D.degree in photogrammetry and remote sensing fromWuhan University in 2003.He was a post-doctoral research associate in

Center for Spatial Information Science and Systems,George Mason University, Greenbelt, MD, from2006 to 2008. Currently, he is a Professor of geo-

graphic information science of the State Key Lab for Information Engineeringin Surveying, Mapping and Remote Sensing, Wuhan University, Wuhan, Hubei,China. His research interests include Smart Planet, Sensor Web, Semantic Web,Digital Antarctica, Smart City and Web GIS.Prof. Chen is a member of the International Association of Chinese Profes-

sionals in Geographic Information Sciences (CPGIS). He was the chair of 2010CPGIS Young Scholar Summer Workshop.

Chuli Hu received the B.Sc. degree in resourcesenvironment management from Anhui University ofArchitecture, China, in 2008, and the M.S. degree ingeographical information systems from Wuhan Uni-versity, China, in 2010. He is currently pursuing thePh.D. degree in LIESMARS at Wuhan University.

ieee journal of selected topics in ... - sensor web groupswe.whu.edu.cn/cnc_web/paper/18.pdf ·...

Documents