1. Global Earth Observation System of Systems
By Lawrence McGovern, SCd
Northrop Grumman Electronic Systems
& International Council of System Engineers (INCOSE)
10/29/09
In the U.S. and globally, the emerging GEOSS system will focus on nine societal benefit areas:
Improve Weather Forecasting
Reduce Loss of Life and Property from Disasters
Protect and Monitor Our Ocean Resource
Understand, Assess, Predict, Mitigate and Adapt to Climate Variability and Change
Support Sustainable Agriculture and Forestry and Combat Land Degradation
Understand the Effect of Environmental Factors on Human Health and Well-Being
Develop the Capacity to Make Ecological Forecasts
Protect and Monitor Water Resources
Monitor and Manage Energy Resources
The benefits of building global observing architecture are enormous.

2. Global Earth Observation System of Systems (GEOSS) Description
Being built by Group on Earth Observations (GEO)
10 Year Implementation plan in execution ( )
Connect producers of environmental data and decision support tools with end users of products
Objective enhancing the relevance of Earth observations to global issues
Be a global public infrastructure that generates comprehensive, near-real-time environmental data, information and analyses for a wide range of users.
The Global Earth Observation System of Systems (GEOSS) is being built by the Group on Earth Observations (GEO) on the basis of a 10-Year Implementation Plan running from 2005 to 2015.[1]
GEOSS seeks to connect the producers of environmental data and decision-support tools with the end users of these products, with the aim of enhancing the relevance of Earth observations to global issues.
The end result is to be a global public infrastructure that generates comprehensive, near-real-time environmental data, information and analyses for a wide range of users.

3. GEOSS Implementation Consists of 70 Task Workplan
Each task supports nine Societal Based or Transverse Areas done by interested members, & participating Organizations. (International Council of System Engineers/Northrop Grumman Electronic Systems doing RM-ODP Architecture)
GEO is developing the GEOPortal as a single Internet gateway to the data produced by GEOSS.
The purpose of GEOPortal is to make it easier to integrate diverse data sets, identify relevant data and portals of contributing systems, and access models and other decision-support tools.
Developed for users without good access to high-speed internet,
As a networked system, GEOSS is owned by all of the GEO Members and Participating Organizations. Partners maintain full control of the components and activities that they contribute to the system of systems. [3] Implementation is being pursued through a Work Plan consisting of over 70 tasks. Each task supports one of the nine societal-benefit or four transverse areas and is carried out by interested Members and Participating Organizations. Governments and organizations have also advanced GEOSS by contributing a variety of “Early Achievements”; these “First 100 Steps to GEOSS” were presented to the 2007 Cape Town Ministerial Summit.
Interlinking observation systems requires common standards for architecture and data sharing. The architecture of an Earth observation system refers to the way in which its components are designed so that they function as a whole. Each GEOSS component must be included in the GEOSS registry and configured so that it can communicate with the other participating systems. In addition, each contributor to GEOSS must subscribe to the GEO data-sharing principles, which aim to ensure the full and open exchange of data, metadata and products. These issues are fundamental to the successful operation of GEOSS.
GEOSS will disseminate information and analyses directly to users. GEO is developing the GEOPortal as a single Internet gateway to the data produced by GEOSS.

4. GEOSS Implementation
GEO has established GEONETCast, a system of four communications satellites that transmit data to low-cost receiving stations maintained by the users.
The GEOSS Implementation Plan identifies nine distinct groups of users and uses, which it calls “Societal Benefit Areas”.
The nine areas are disasters, health, energy, climate, water, weather, ecosystems, agriculture and biodiversity.
Current and potential users include decision makers in the public and private sectors, resource managers, planners, emergency responders and scientists.
The purpose of GEOPortal is to make it easier to integrate diverse data sets, identify relevant data and portals of contributing systems, and access models and other decision-support tools. For users without good access to high-speed internet, GEO has established GEONETCast, a system of four communications satellites that transmit data to low-cost receiving stations maintained by the users. (User groups).
The growing demand for Earth observation data and information is the driving force behind GEOSS. The GEOSS Implementation Plan identifies nine distinct groups of users and uses, which it calls “Societal Benefit Areas”.
The nine areas are disasters, health, energy, climate, water, weather, ecosystems, agriculture and biodiversity. C
urrent and potential users include decision makers in the public and private sectors, resource managers, planners, emergency responders and scientists.

5. Reference Model of Open Distributed Processing (RM-ODP)
RM-ODP Description
Reference Model of Open Distributed Processing (RM-ODP)
is a Reference Model in computer science, which provides a coordinating framework for the standardization of open distributed processing (ODP).
It supports distribution, internet working, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems.
The three components of the enterprise architecture framework are:
Views : provide the mechanisms for communicating information about the relationships that are important in the architecture
Methods : provide the discipline to gather and organize the data and construct the views in a way that helps insure integrity, accuracy and completeness
Training/Experience : support the application of method and use of tools

6. RMP View Model Viewpoints addressed in Volume 3 of ISO/IEC 10746
RM-ODP Standards
RM-ODP, also named ITU-T Rec. X.901- X.904 and ISO/IEC 10746, is a joint effort by the International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC) and the Telecommunication Standardization Sector (ITU-T)
RMP View Model Viewpoints addressed in Volume 3 of ISO/IEC 10746
The rapid growth of distributed processing has led to the adoption of the Reference Model of Open Distributed Processing (RM-ODP), which provides a co-coordinating framework for the standardization of open distributed processing (ODP). RM-ODP creates an architecture which supports distribution, interworking, and portability and can be integrated.
This paper describes the architecture framework for the specification of ODP system. The views used in the framework are defined in ISO/IEC [1] and the UML Standard for the ODP is described in ISO/IEC [2]. The paper provides examples of all five views required by the RM-ODP for the Air Quality scenario of GEOSS it is one of eight Societal based Area scenarios of current GEOSS.

7. The ODP system specification Viewpoints
27/03/2017
The ODP system specification Viewpoints
Enterprise
- business aspects
- What for? Why? Who? When?
- information
- changes to information
- constraints
Information
- Object configuration
Interactions between
objects at interfaces
Computational
Engineering
- Mechanisms and services
for distribution trans-
parencies and QoS constraints.
RM-ODP framework provides five generic and complementary viewpoints on the system and its environment:
The enterprise viewpoint, which focuses on the purpose, scope and policies for the system. It describes the business requirements and how to meet them.
The information viewpoint, which focuses on the semantics of the information and the information processing performed. It describes the information managed by the system and the structure and content type of the supporting data.
The computational viewpoint, which enables distribution through functional decomposition on the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition.
The engineering viewpoint, which focuses on the mechanisms and functions required to support distributed interactions between objects in the system. It describes the distribution of processing performed by the system to manage the information and provide the functionality.
The technology viewpoint, which focuses on the choice of technology of the system. It describes the technologies chosen to provide the processing, functionality and presentation of information.
Hardware and software components implementing the system
Technology
- and correspondences between specifications

8. Viewpoints and Modeling
Enterprise Viewpoint - Focuses on the purpose, scope and policies of the system and describes business requirements and how they are met
Information Viewpoint - focuses on the semantics of the information and the information processing performed. It describes the information managed by the system and the structure and content type of the supporting data
Computational Viewpoint - enables distribution through functional decomposition on the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition
Engineering Viewpoint - which focuses on the mechanisms and functions required to support distributed interactions between objects in the system. It describes the distribution of processing performed by the system to manage the information and provide the functionality
Technology Viewpoint - which focuses on the choice of technology of the system. It describes the technologies chosen to provide the processing, functionality and presentation of information.
Viewpoint modeling has become an effective approach for dealing with the inherent complexity of large distributed systems. Current software architectural practices, as described in IEEE 1471, divide the design activity into several areas of concerns, each one focusing on a specific aspect of the system. Examples include the "4+1" view model, the Zachman Framework, TOGAF, DoDAF and, of course, RM-ODP.

9. RM_ODP and UML
ISO/IEC and the ITU-T started a joint project in 2004: "ITU-T Rec. X.906|ISO/IEC 19793: Information technology - Open distributed processing - Use of UML for ODP system specifications". This document (usually referred to as UML4ODP) defines use of the Unified Modeling Language 2 (UML 2; ISO/IEC 19505), for expressing the specifications of open distributed systems in terms of the viewpoint specifications defined by the RM-ODP
It defines a set of UML Profiles, one for each viewpoint language and one to express the correspondences between viewpoints, and an approach for structuring them according to the RM-ODP principles. The purpose of "UML4ODP" to allow ODP modelers to use the UML notation for expressing their ODP specifications in a standard graphical way; to allow UML modelers to use the RM-ODP concepts and mechanisms to structure their large UML system specifications according to a mature and standard proposal; and to allow UML tools to be used to process viewpoint specifications, thus facilitating the software design process and the enterprise architecture specification of large software systems.
In addition, ITU-T Rec. X.906 | ISO/IEC enables the seamless integration of the RM-ODP enterprise architecture framework with the Model-Driven Architecture (MDA) initiative from the OMG, and with the service-oriented architecture (SOA).

10. RM-ODP and SysML
The System Engineering Modeling Language (SysML) Is an extension of UML syntax
SysML Diagram Types were used to build Activity Diagrams , Block Diagrams and Internal Block Diagrams instead of UML Activity Diagrams, and Class Diagrams as specified in the UML Standard with permission of GEOSS Plenary

11. Enterprise View

12. UML Specification of GEOSS Community
the enterprise specification of the GEOSS example contains one community GEOSS . It is specified in a package, stereotyped as «EV_CommunityContract», containing a component, stereotyped as «EV_Community» (as well as other elements specifying other aspects of the community). Each of these components has a dependency, stereotyped as «EV_RefinesAsCommunity», from the relevant class stereotyped as «EVCommunityObject» GEOSS which expresses the community object that models the community when considered as a single object For convenience, the community object is included in a package named as Enterprise Objects (Global), which contains those enterprise objects that model entities whose scope is wider than the GEOSS itself. Examples of such enterprise objects are the Users with which the GEOSS System has to interact.
Policies have not been determined as yet

13. Use Cases: Air Quality & Health Specialized Use Cases:
Transverse Use Cases
Steps in use cases are defined by the Transverse workgroups. The Use Cases below are instances specific to the AQ WG.
Register Resources (see also CCRM transverse UC1) 
Deploy Component & Services (Access) 
Metadata via Clearinghouse (CCRM) 
Client Search of Metadata (Portal/Client)  
Services and Alert Presentation (Portal/Client)
Interact with Services (Access) 
Data Visualization & Analysis (Portal/Client)
Workflow (Workflow) 
Services Testing (Testing) 
Interoperability Arrangements (CCRM)  
This list of use cases represents activity / capability elements which should generally be common to most if not all of the community scenarios.See the status of the mapping between ... not all of the community scenarios.See the status of the mapping between those transverse technology Use Cases and the community scenarios.A Use Case Diagram showing relationships between the ...

14. Transverse Use cases
Role of the Transverse Technology Use Cases in GEOSS
As with the Internet, GEOSS is envisioned as a global and flexible network of content and service providers enabling decision makers to discover, access and integrate an extraordinary range of earth observing related information within their applications. To achieve this vision, the GEOSS architecture must provide an easy and reusable process to leverage the GEOSS Common Infrastructure (GCI) and components in support of many SBA communities. The AIP defined and piloted such a process for using and augmenting the GEOSS Common Infrastructure to meet SBA community needs. The process applies a system modeling methodology based on international standards tailored specifically to the GEOSS environment.
The reusable process is based on implementing community-defined scenarios using transverse technology use cases. The community scenarios are narrative descriptions of SBA community needs with minimal discussion of the implementation architecture. Community scenarios serve to provide an end user view of the value of GEOSS to specific community needs. The transverse technology use cases, on the other hand, describe reusable functionality of the GEOSS service oriented architecture implemented through Interoperability Arrangements.
This document describes in detail the ten generalized use cases identified in AIP-2. Each generalized use case encompasses a unit of useful functionality and describes a set of actions performed by various system actors in support of one or more actors or other stakeholders interacting with the system.
In AIP-2, the transverse technology use cases supporting the community scenarios were grouped in five categories, as shown in Figure 1. The grouping of the use cases was based on supporting the end-to-end GEOSS process from resource deployment (02), registration (01) and harvesting (03) to discovery (04), access (05, 06) and exploitation (07) of resources enabled by infrastructure-support functionality such as workflow construction/processing (08), service testing (09) and interoperability arrangements management (10).
The development of each category of use cases was lead by an AIP-2 transverse technology working group in a collaborative and iterative process. The development of each category was coordinated across technology working groups to maintain the integrity of the end-to-end process with participation from AIP-2 community working groups to ensure alignment with GEOSS SBA community needs.

15. GEOSS (E Spec)
the enterprise specification of GEOSS contains one community (the GEOSS). It is specified in a package, stereotyped as «EV_CommunityContract», containing a component, stereotyped as «EV_Community» The component has a dependency, stereotyped as «EV_RefinesAsCommunity», from the relevant class stereotyped as «EVCommunityObject» (GEOSS) which expresses the community object that models the community when considered as a single object. For convenience, the community objects are included in a package named as Enterprise Objects (Global), which contains the enterprise objects that model entities whose scope is wider than the GEOSS itself. Examples of such enterprise objects are GEOSS Portal,with which the GEOSS has to interact.

16. AQ Community Roles
From the textual description of GEOSS(and, in real life more importantly, from discussions, interviews and workshops with stakeholders of the SBAs) we can identify several roles in the AQ GEOSS community, in users with various privileges, Modelers, Manager Analysts, and the ODP system that supports the GEOSS Portal. Figure above shows these GEOSS AQ User roles within the package that contains the specification of the community, each with a realization link to the component that expresses the community
The behaviour identified by a role is expressed by the set of behavioral features of the class that expresses the role.The behavior of the role is specified in three opaque Behaviors, viz: RequestFireOccurancedata, Request ASmoke Forecast and a SmokeForecastReport, and one stateMachine.

17. Actor Role Fullfillment and Assignment Roles
Diagram depicts a Role hierarchy showing a generalization from a person to GEOSS user and then the association with AQ Quality Analysts, AQ Manager Analyst and Modeler Roles.

18. Enterprise View –AQ Use Case Diagram
The Enterprise View of the standard reflects the use of a Package of Processes.
We replaced this with Use case Diagrams.
This is the Air Quality Use Case Diagram. The individual processes have been replaced with Use Cases. Each use case is then associated with an activity diagram , sequence diagram and state diagram/machine.

19. Actors in the system - Descriptions
The UML standard did not include a list of actors and descriptions. So we added a table for this purpose. As well as a table of roles and a role hierarchy.

20. Enterprise View – SysML Activity Diagram
This activity diagram for “Forecast Smoke” includes the AQ Use Cases 1 through 6.
AQ01 A wildfire Occurs and an air quality analysts’ smoke forecasters and others seek fire occurrence , smoke and particulate matter data are derived
AQ 02 A modeler uses the fire locations to initialize smoke forecast models that are run to predict downwind impacts 1-3 days in the future which indicate a regional smoke pollution event
AQ03 Smoke forecast products are available to Manager /Analyst through OGC WCS or OGC SOS (Services)
AQ04 Multiple smoke observation products are available to the Air Quality manager/Analyst through OGC WCS or OGC SOS (Services)
AQ05 The Air quality manager/analyst uses spatial temporal comparison services to visualize difference and similarities in the smoke forecast products and publishes reports.
AQ06 The Air Quality manager/analyst uses the smoke forecasts to assess need for public health alerts

21. AQ Forecast Smoke Process State Diagram
State diagrams are used to describe the behavior of a system GEOSS.  State diagrams describe all of the possible states of an object as events occur.  Each diagram usually represents objects of a single class and track the different states of its objects through the system. The Class in this case is Forecast Data. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system.  Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case.  State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams.

22. AQ Forecast Smoke Sequence Diagram
Interaction diagrams model the behavior of  use cases by describing the way groups of objects interact to complete the task.  The two kinds of interaction diagrams are sequence and collaboration diagrams. This example is the behavior of the forecast Fire Occurrence and Smoke Forecast data Use Case Sequence Diagram.

23. GEOSS Information Specification
All three internal Packages summarized by Entity Relationship Diagram
The information viewpoint is concerned with information modeling. It focuses on the semantics of information and information processing in the ODP system. The individual components of a distributed system must share a common understanding of the information they communicate when they interact, or the system will not behave as expected. These items of information are handled, in one way or another, by one or more objects in the system. To ensure that the interpretation of these items is consistent, the information language defines concepts for the specification of the meaning of information stored within, and manipulated by, an ODP system (GEOSS Portal), independently of the way the information processing functions themselves are to be implemented.
Information object
Information held by the ODP system about entities in the real world, including the ODP system itself, is modeled in an information specification in terms of information objects, and their relationships and behavior.
Basic information elements are modeled by atomic information objects. More complex information is modeled as composite information objects modeling relationships over a set of constituent information objects. Information objects, as any other ODP object, exhibit behavior, state, identity, and encapsulation.

24. Information View – Entity Relationship Diagram
Information Object
Relationship
Attributes
Information view is constructed using UML Class Diagram. User Class attributes are User Name and ID number. Request Status Class attributes Requested, Accepted and Desired Status record indicators. Item status attributes record whether item has been provided, was not acceptable or being prepared. User status class attributes reflect whether User has applied, is eligible, refused, valid, deleted, or accepted. Requestor class attributes provide data on User Identifier, requested items and status on requestor status. Community catalog class attribute merely provides information as to availability of catalog for access. Policy Values for this Information View will be developed as part of AIP 3 later this calendar year. The Item class attributes provide and identifier of the item, data is was provided, producer of the item, status of item and Item Title. Abstracts of Item attributes include Correlation, Map and Report. Each of these have same attributes of ID, and status .

25. Computational View
Specifies computational structure of the system in terms of units of distribution and portability and the interactions between them
An object model of the system describing the structure of processing in terms of:
computational objects
Interfaces (of computational objects): identifying functions supported
Invocations (by computational objects): identifying functions invoked
activities: sequences of invocations
computational bindings: QoS constraints on invocations

26. Computational View – High Level Architecture Object Template (SysML Internal Block Diagram
Decomposition of the system functionality into computational objects that interact at interfaces provides the software architecture of the application. In UML, we express such architecture using a component diagram that describes the computational object templates and the computational interface templates at which these objects interact.
In the GEOSS SOS AQ example, the software architecture of the application is composed, at the highest level, of three main components: one that describes the basic functionality of the system (AQ system MainFunctionality), and other three (InterfaceToModeler, InterfaceToRegistry and InterfaceToManagerAnalyst) which specify the user interfaces that the application will offer to Manager Analysts,Modeler and Registry to interact with it, respectively.

27. Computational View –Detailed Architecture (SysML Internal Block Diagram)
Each computational object is expressed as a component. Object interfaces are expressed as component ports. Finally, interface signatures are expressed as interfaces. Thus, computational objects interact which each other at computational interfaces (port instances), which are instantiated from their corresponding interface templates (ports). Each port uses or implements some interfaces, which specify the corresponding interaction signatures.
The connections between the different components are shown using either the “ball-and-socket” notation that expresses implicit primitive bindings between the corresponding computational objects or some assembly connectors that express the explicit primitive bindings. We have also used some delegation connectors to map the external view of the component to its internal view, specifying how the services provided by an external port are in fact provided by a port of one of its internal components.

28. Computational View – Interaction Signatures (SysML Blocks)
We can see how each port is of a particular type (described in the InterfaceTemplate package) and implements and/or uses several interfaces (which express the corresponding interface signatures shown in Figure above).

29. Computational View – Data Types (SysML Data Types)
These data types have been derived from the corresponding information object types (which in turn came from the enterprise artifacts, roles and objects).

30. GEOSS Way Forward in AIP3
Develop Policies for each Societal Based Area Use Cases
Update Enterprise/Information and Computational Views as necessary
Develop Engineering View Diagrams
Develop Technical View Diagrams

31. Backup Slides

32. Specifies the mechanisms and services that provide the distribution transparencies and QoS constraints required by the system independent of platform
An object model of the system describing the infrastructure supporting the computational structure
basic engineering objects
(infrastructure) engineering objects
clusters, capsules, nodes
channels
functions

33. Engineering View – Basic Engineering Objects (BEOs)

34. Engineering view – Enterprise Server Internals – SysML Internal Block Diagram

35. Technology Viewpoint Deployment Diagram (SysML IBD)

36. Technology View – Node Structure –(SysML IBD)
Specifies the H/W and S/W pieces from which the system is built.
An object model of the system
defining the configuration of technology objects that comprise the ODP system, and the interfaces between them
identifying conformance points