1. GEO Architecture and Data Committee Task AR-07-02 Architecture Implementation Pilot GEO Task AR-07-02 Team Representatives: - Doug Nebert, USA/FGDC - Larry McGovern, INCOSE/NGC - Herve´ Caumont, OGC/ERDAS - George Percivall, OGC ADC-7 May 2008

2. Task AR-07-02 Architecture Implementation Pilot (AIP) AIP Plan for IOC Phase – Doug Nebert –Developing AIP Call for Participation (CFP) –Plans for IOC Augmentation CFP Enterprise Models – Larry McGovern CFP Information Model – Herve´ Caumont

3. AIP IOC Phase Themes (1 of 2) Support GEOSS Common Infrastructure –IOC Phase planned for one-year duration. –AIP to augment the IOC baseline UIC/ADC collaboration –SBAs emphasis as initially identified in Cape Town –Operational SBA functionality to support persistence Emphasize operational persistence; "persistent exemplars" ; –Operational services linked using GEOSS Architecture –Cross-application services beyond their original purpose

4. AIP IOC Phase Themes (2 of 2) Build on accomplishments of 2007 –Begin by updating the CFP from 2007 –Architecture Implementation Report, Dec 2007 –GEOSS User and Architecture Workshop proceedings –ADC Architecture Workshop, Feb 2008 Open Development Process for AIP –Involve GEO tasks in using IOC and architecture –AIP process is iterative; Anyone can join at anytime –Structured within a phase; e.g. kickoff, integration

5. AI Pilot Development Approach DevelopmentActivities Kick-offWorkshop Call for Participation ConceptDevelopment PersistentOperations(AR-07-01) Participation ArchitectureDocumentation Updates for each step Baseline AR-07-02 Architecture Implementation Pilot Evolutionary Development Process Operational Baseline for next evolutionary spiral

6. CFP composed of three documents CFP Main Document –Master Schedule –Themes 2008 –How to respond to CFP Annex A: Development plan –Development phases; Communication Plan –Relationship to GCI task force Annex B: Architecture

7. CFP Annex B – Architecture Enterprise Viewpoint –Value of Earth Observations Information Viewpoint –Earth Observations schemas and encodings Computational Viewpoint –SOA services; broadcast; media distribution Engineering Viewpoint –Components types and interoperability arrangements Technology Viewpoint –Component Instances, Operational Criteria

8. Augmentations to IOC in the CFP SBA scenarios: collaboration of UIC and ADC Sensor Web services and components Build on Workflow and WPS from previous phase Intercalibration (TBD CEOS) Test Facility for Service Registration GEONetCast coordination Delivery of data without network or satellite links

9. CFP – Architecture – SBA SCENARIOS Disaster Response –Guy Sequin Air Quality –John White Biodiversity –Doug Muchoney Energy – Solar –Lionel Menard

10. GEO Web Site Client Tier Business Process Tier Access Tier GEOSS Web Portal GEOSS Registries Services Components Standards GEONETCast Other Services Data Access Services Model Access Services Community Portals Client Applications Requirements Community Catalogues Portrayal Services Workflow Management Processing Services Other Services GEOSS Clearinghouse Sensor Access Services CFP Architecture – Engineering Viewpoint

11. CFP Architecture – Operational Persistence Length of commitment –Upon registering a service, a service provider must specify the length of time for which the service will be offered (preferably ‘continuous operation’). –Consider multiple years Level of service –services are expected to be available at least 99% of the time, except when otherwise required by the nature of the service. –This allows for approximately 7 hours of down time a month –Being achieved regularly by servers, Biggest problem is network provider –Performance (perhaps by specifying number of simultaneous connections) Termination –GEO may “de-list” a server –non-functioning components of the Network will diminish the operational and marketing value of the Network in general for all participating organizations.

12. AIP – IOC Augmentation Phase Architecture WorkshopFebruary 2008 Call for Participation (CFP) –CFP Preparation Mar to May –CFP ReleaseJune –CFP Responses DueJuly Kickoff Workshop, 2 DaysSeptember –Hosted by USA - to be confirmed Deploy, Integrate, Test 4 mo.Sep ‘08 to Jan ‘09 GEO-V Plenary November 2008 Commit to Persistent OperationsFebruary 2009

13. User and Architecture Workshops for 2008 Accra, Ghana - 08 Water Security & Ecosystems Beijing, China-08 Air Quality & Health Kobe, Japan-08 Oceans & Water Quebec, Canada-08 Science Modeling & Data Policy Toronto, Canada-08 UIC workshop Boston, USA-08 Air Quality & coastal Ecosystems Spain-08 Architecture Of GEOSS Honolulu, Hawaii-08 Communications For disaster management

14. Coordinating Tasks

15. Global Earth Observation System of Systems (GEOSS) Architecture Development Using Viewpoint Specifications Lawrence McGovern, DSc International Council on Systems Engineering Lawrence.McGovern@NGC.com/ Lawrence.Mcgovern@incose.com/

16. Background Used UML standard for capturing architectural information as parts of viewpoint specifications 1 Developed viewpoint specifications as defined by RM_ODP standard 2 RM-ODP standard defines essential concepts required to define ODP systems in five viewpoints UML Standard provides framework for ODP systems (like GEOSS) using UML to depict five viewpoints 1 ISO/IEC 19793, 106 2 ISO/IEC 10746, 56

17. View Point Specifications Enterprise Specification - Specifies the roles played by an IT system in its organizational environment Information Specification - Specifies system behavior to meet its objectives abstracted from implementation Computational Specification - Specifies computational structure in terms of units of functionality and distribution and their interactions Engineering Specification - Specifies the mechanisms and services to provide the distribution transparencies and meet Quality of Service (QoS) constraints required by the system Technology Specification - Specifies the hardware and software pieces from which the system is built.

18. Viewpoint Language Each viewpoint is associated with a viewpoint language –Enterprise Language Modeled by one or more enterprise objects Models ODP system in context of business or organization in which it operates Model has one or more enterprise objects within communities of enterprise objects that model its environment Roles are used to model users, owners and providers of information

19. Oil Spill Scenario Context Diagram

20. GEOSS Oil Spill Scenario Enterprise Specification

21. UML Specification of Ground Station Community

22. UML Specification GEOSS Catalog Community

23. GEOSS Catalog Processes Activity Diagram

25. GEOSS Oil Spill Action Plan Activity Diagram

26. GEOSS Oil Spill Action Plan Iteration Diagram (UML Sequence Diagram)

27. Enterprise Objects – Reusable for all scenarios Enterprise objects, and relationships between them, that have roles (actor or artifact), In the GEOSS Clearinghouse community are shown above. These objects can be used to represent objects of all GEOSS scenarios

28. GEOSS Clearing House State Diagram

29. Key Findings UML standard provides an excellent framework for providing thorough characterization of the GEOSS ODP system concept Views other than Enterprise View specifications of GEOSS scenarios will require integration and correlation analysis to reflect complete views Policies for GEOSS have not yet been developed for the SOS and individual scenarios Roles will have to be standardized in GEOSS Additional information available in extended presentation: http://portal.opengeospatial.org/files/?artifact_id=28194

30. Task AR-07-02 CFP Information Model Hervé Caumont ERDAS member of OGC IP Team hc@ionicsoft.com

31. CFP – Architecture – Information Viewpoint Modeling Geospatial Information Geospatial information types for features, coverages, observations and maps Spatial referencing (new). Inter-calibration Registering geospatial information Metadata and Registry Information Models

32. Modeling Geospatial Information Map – picture of data Feature – discrete geometry, e.g., roads, boundaries Coverage – gridded data region, e.g., soil moisture, SST Observation – measurement at a location ISO 19100 feature modeling

33. Geospatial Information Types Features, coverages, observations and maps with data types may comply to some digital geographic product specifications Products specifications encompass scale, accuracy, quality, thematic content, encoding rules… Coordination with GEO Task DA-06-05 ISO TC211 19100 suite of standards provides normalization for these product aspects, e.g.: spatial schema, temporal schema, portrayal schema, coverage components and encodings…

34. Coordinate Reference Systems Terminology with spatial reference: –place names, spatial codes. –Valuable to have Gazetteer Coordinate Reference Systems –CRS consists of a coordinate system and a datum. –WGS84 commonly used –Registries for 1000s of CRS

35. Inter-calibration Why: to create the stable long-term data sets needed for monitoring climate change What: to inter-calibrate sensors on similar and different satellites. Also important is inter-calibration of satellite observations with in situ observations How: international efforts on relative calibration, channel validation, satellite radiances monitoring, absolute calibration… On-going : CEOS WGCV for GEOSS Data Quality Framework CEOS-GEO Cal/Val Portal: a Community Portal in AIP architecture

36. Registering geospatial information Registration of geospatial items offers the following benefits to the community: Wider use by providing international conformance recognition and public availability to potential users. Single mechanism to access information and manage temporal change (regular maintenance cycles, changes in technology), and maintain earlier versions of specified items. Standardized tags available for encoding of registered items in datasets, with support of multiple- languages.

37. Metadata and Registry Information Models Rising complexity of SOA deployments: –Dataset metadata (ISO 19115) –Service metadata (ISO 19119) –Feature catalogues, symbols, and many other types of artifacts (WSDL, XML Schema, BPEL, policies, XSLT, WSRP…) Need for governance of SOA artifacts –A single point of contact to enforce organizational policies –A Registry is a key service that enables SOA governance Many dependencies and relationships among artifacts: need a means for modeling a wide variety of metadata

38. Registry information models (ebRIM) OASIS Consortium defined the electronic business Registry Information Model (ebRIM) as a means to standardize the registration and management of distributed assets on a network : –The types of metadata and content that can be stored in an ebXML Registry. –The services and protocols for an ebXML Registry. Version 3.0 approved as OASIS standards May 2005 (ISO 15000 Standard, Part 3 and 4)

39. Registry information models (ebRIM)

40. GEO Architecture and Data Committee Task AR-07-02 Architecture Implementation Pilot GEO Task AR-07-02 Team Representatives: - Doug Nebert, USA/FGDC - Larry McGovern, INCOSE/NGC - Herve´ Caumont, OGC/ERDAS - George Percivall, OGC ADC-7 May 2008