Module Decomposition View

The decomposition view consists of 14 view packets. View packet 1 shows the decomposition of the entire ECS system into a group of three segments, each of which is further decomposed into a number of subsystems. Subsequent view packets (214) show the further decomposition of each of the subsystems.

1.1 Module Decomposition View Packet 1: The ECS System

1.1.1 Primary Presentation[9]

[9] This is an example of a textual primary presentation. Text, such as a table or an outline, is sometimes superior to graphical presentations, which can easily become cluttered and difficult to lay out when the number of elements is large or when more than one level of decomposition is shown. A tabular primary presentation also can be combined with the element catalog in many cases, although that option is not exercised in this example.

System	Segment
ECS	Science Data Processing Segment (SDPS)
	Communications and System Management Segment (CSMS)
	Flight Operations Segment (FOS)

1.1.2 Element Catalog

1.1.2.1 Elements and Their Properties

Properties of ECS modules are

• Name, given in the following table
• Responsibility, given in the following table
• Visibility; all elements are visible across the entire system
• Implementation information: See the implementation view in Volume II, Chapter 9

Element Name	Element Responsibility
SDPS	The Science Data Processing Segment (SDPS) receives, processes, archives, and manages all data from EOS and other NASA Probe flight missions. It provides support to the user community in accessing the data and products resulting from research activities that use this data. SDPS also promotes, through advertisement services, the effective use and exchange of data within the user community. Finally, the SDPS plays a central role in providing the science community with the proper infrastructure for development, experimental use, and quality checking of new Earth science algorithms. SDPS is a distributed system, and its components are located at eight Distributed Active Archive Centers (DAACs).
CSMS	The Communications and System Management Segment (CSMS) focuses on the system components involved with the interconnection of user and service providers and with system management of the ECS components. The CSMS is composed of three major subsystems; here, they are introduced simply to explain the system configuration. They are the Communications Subsystem (CSS), the Internet-working Subsystem (ISS), and System Management Subsystem (MSS). The MSS, which includes several decentralized local system management capabilities at the DAAC sites and the mission operation center, provides system management services for the EOS ground system resources. The services provided by the MSS, even though they rely on the CSS-provided services, are largely allocable to the application domain.
FOS	The Flight Operations Segment (FOS) manages and controls the EOS spacecraft and instruments. The FOS is responsible for mission planning, scheduling, control, monitoring, and analysis in support of mission operations for U.S. EOS spacecraft and instruments. The FOS also provides investigator-site ECS software (the Instrument Support Terminal (IST) toolkit) to connect a Principal Investigator (PI) or Team Leader (TL) facility to the FOS in remote support of instrumental control and monitoring. PI/TL facilities are outside the FOS but connected to it by way of the EOSDIS Science Network (ESN). The FOS focuses on the command and control of the flight segment of EOS and the interaction it has with the ground operations of the ECS.

1.1.2.2 Relations and Their Properties

The relation type in this view is is-part-of. There are no exceptions or additions to the relations shown in the primary presentation.

1.1.2.3 Element Interfaces

Element interfaces for segments are given in subsequent decompositions.

1.1.2.4 Element Behavior

Not applicable.

1.1.3 Context Diagram

[omitted]

1.1.4 Variability Guide

None.

1.1.5 Architecture Background

1.1.5.1 Design Rationale

• Rationale for three segments: In the system design phase, broadly scoped decisions were made about the overall architecture of the ECS. Three major activities of the system were established and influenced by the system specification. These activities were Flight Operations, Science Data Processing, and Communications and Systems Management; each of these activities was allocated as the responsibility of a segment. During this activity, the ECS was organized into subsystems under each segment, based primarily on the analysis of ECS requirements. After taking into account the science and evolutionary requirements of the ECS, it should be noted that not all segment-designated requirements were allocated to the implied segment; rather, requirements were allocated to the design subsystems that logically would implement the designated functional and performance requirements.

[etc.]

1.1.5.2 Results of Analysis

• Change analysis: In June 2001, a change analysis was performed on the ECS architecture, using the Architecture Trade-off Analysis Method (ATAM). ATAM is a scenario-based method. Several scenarios dealt with likely changes and were applied to the module decomposition view. Results of the analysis can be found in the ATAM final report, available at http://www.ourinternalwebsite/ECS/documentation/architecture/atam_final_report.

[etc.]

1.1.5.3 Assumptions

• Future network upgrades will provide performance and bandwidth equal or superior to current capabilities. Given that, changes in system communication and management functions are unlikely to have any detrimental impact on the amount or type of science data processing that can be performed by ECS.
• Future needs for science data processing will require more, not less, capacity for computation, data storage, and communication.
• Communications and system management functions are independent of specific data processing algorithms used and data products produced by ECS.
• Communications and system management functions are independent of specific flight operation functions, such as planning and command transmission.

[etc.]

1.1.6 Other Information

[omitted]

1.1.7 Related View Packets

• Parent: None.
• Children

  - Module Decomposition View Packet 2: The Science Data Processing Segment (Volume II, Section 1.2, page 418)

  - Module Decomposition View Packet 10: The Communications and System Management Segment (CSMS), (Volume II, Section 1.10, page 422)

  - Module Decomposition View Packet 14: Flight Operations Segment (FOS), (Volume II, Section 1.14, page 424)

• Siblings: None in this view. View packets in other views that express the same scope as this onenamely, the whole systeminclude

  - Module Layered View Packet 1: The ECS System, (Volume II, Section 4.1, page 435)

  - C&C Pipe-and-Filter View Packet 1: The ECS System, (Volume II, Section 5.1, page 439)

  - Allocation Deployment View Packet 1: The ECS System, (Volume II, Section 8.1, page 457)

  - Allocation Implementation View Packet 1: The ECS System, (Volume II, Section 9.1, page 461)

  - Allocation Work Assignment View Packet 1: The ECS System, (Volume II, Section 10.1, page 464)

1.2 Module Decomposition View Packet 2: The Science Data Processing Segment

1.2.1 Primary Presentation

Segment	Subsystem
Science Data Processing Segment (SDPS)	Client
	Interoperability
	Ingest
	Data Management
	Data Processing
	Data Server
	Planning

1.2.2 Element Catalog

1.2.2.1 Elements and Their Properties

Properties of SDPS modules are

• Name, given in the following table
• Responsibility, given in the following table
• Visibility; all elements are visible across the entire system
• Implementation information: See the implementation view in Volume II, Chapter 9.

Element Name	Element Responsibility
Client	The SDPS Client subsystem provides a collection of components through which users access the services and data available in ECS and other systems interoperable with ECS. The Client subsystem also includes the services needed to interface an application, such as a science algorithm, with ECS for data access or to make use of ECS provided toolkits.
Interoperability	In general, support for the communication between SDPS clients and services is provided by CSMS, as described elsewhere. Any additional functions SDPS may require to support the interoperation of its components form part of the SDPS Interoperability subsystem and involve primarily the advertising service, which advertises service offerings.
Ingest	A provider site within EOSDIS will normally need to ingest a wide variety of data types to support the services it wishes to offer. This data may be delivered through a wide variety of interfacesnetwork file transfer, machine-to-machine transfer, media, hard copy, and so onwith a wide variety of management approaches to these interfaces. This interface heterogeneity and the need to support extendability and new data/interfaces as algorithms and provider functionality changes is handled within the Ingest subsystem.
Data Management	The Data Management subsystem is responsible for supporting the location, search, and access of data and service objects made available in the SDPS. The components of the subsystem decouple the location, search, and access functions from the components performing the data server and client interface functions, in order to accommodate the anticipated variety of users' search and access needs and to provide a growth path as capabilities evolve.
Data Processing	The Data Processing subsystem is responsible for managing, queuing, and executing processes on the processing resources at a provider site. Requests for processing are submitted from the Planning subsystem, which in turn have been triggered by data arrival or user request (Data Server) or through Planning itself, such as reprocessing.
Data Server	This subsystem has the responsibility for storing Earth science and related data in a persistent fashion, providing search and retrieval access to this data, and supporting the administration of the data and the supporting hardware devices and software products. As part of its retrieval function, the subsystem also provides for the distribution of data on physical media.
Planning	The Planning subsystem supports the operations staff in developing a production plan based on a locally defined strategy, reserving the resources to permit the plan to be achieved and the implementation of the plan as data and processing requests are received. It also allows the site operations staff to negotiate on a common basis with other provider sites and EOSDIS management, via MSS, if any change to their production plan causes conflict with other provider sites' plans, such as where dependencies between processing algorithms cannot be fulfilled.

1.2.2.2 Relations and Their Properties

The relation type of concern in this view is is-part-of. Every subsystem is part of exactly one segment, namely, the Science Data Processing Segment, as shown in the primary presentation.

1.2.2.3 Element Interfaces

[omitted][10]

[10] For examples of interface specifications, see Chapter 7.

1.2.2.4 Element Behavior

Not applicable.

1.2.3 Context Diagram

1.2.4 Variability Guide

None.

1.2.5 Architecture Background

[omitted]

1.2.6 Other Information

[omitted]

1.2.7 Related View Packets

• Parent: Module Decomposition View Packet 1: The ECS System (Volume II, Section 1.1, page 414)
• Children

  - Module Decomposition View Packet 3: The Client Subsystem (Volume II, Section 1.3, page 422)

  - Module Decomposition View Packet 4: The Interoperability Subsystem (Volume II, Section 1.4, page 422)

  - Module Decomposition View Packet 5: The Ingest Subsystem (Volume II, Section 1.5, page 422)

  - Module Decomposition View Packet 6: The Data Management Subsystem (Volume II, Section 1.6, page 422)

  - Module Decomposition View Packet 7: The Data Processing Subsystem (Volume II, Section 1.7, page 422)

  - Module Decomposition View Packet 8: The Data Server Subsystem (Volume II, Section 1.8, page 422)

  - Module Decomposition View Packet 9: The Planning Subsystem (Volume II, Section 1.9, page 422)

• Siblings

  - Module Decomposition View Packet 10: The Communications and System Management Segment (CSMS) (Volume II, Section 1.10, page 422)

  - Module Decomposition View Packet 14: Flight Operations Segment (FOS) (Volume II, Section 1.14, page 424)

[The following view packets are omitted from the example. Each of them would refer to Module Decomposition View Packet 2: The Science Data Processing Segment as their parent view packet and to one another as their sibling view packets. Finally, each could be further decomposed into finer-grained modules; in fact, for a system the size of ECS, this would be highly likely.]

1.3 Module Decomposition View Packet 3: The Client Subsystem

1.4 Module Decomposition View Packet 4: The Interoperability Subsystem

1.5 Module Decomposition View Packet 5: The Ingest Subsystem

1.6 Module Decomposition View Packet 6: The Data Management Subsystem

1.7 Module Decomposition View Packet 7: The Data Processing Subsystem

1.8 Module Decomposition View Packet 8: The Data Server Subsystem

1.9 Module Decomposition View Packet 9: The Planning Subsystem

1.10 Module Decomposition View Packet 10: The Communications and System Management Segment (CSMS)

1.10.1 Primary Presentation

Segment	Subsystem
Communications and System Management Segment (CSMS)	System Management
	Communications
	Internetworking

1.10.2 Element Catalog

1.10.2.1 Elements and Their Properties

Properties of CSMS modules are

• Name, given in the following table
• Responsibility, given in the following table
• Visibility; all elements are visible across the entire system
• Implementation information: For this information, see the implementation view in Volume II, Chapter 9.

Element Name	Element Responsibility
System Management	The System Management subsystem is made of two classes: the manager and the managed objects. The manager uses management applicationstypically, fault, performance, accounting, configuration, and security management; communications servicesagents that manage the communications traffic between the manager and the services; and an information model that defines the information flow between the manager and the managed objects. The manager also uses several applications to monitor and to configure system resources, or managed objects, as required.
Communications	The Communications subsystem consists of the session, presentation, and application layers from an open system interconnection-reference model perspective. The Communications subsystem provides support for peer-to-peer, advanced distributed, messaging, management, and event-handling communications facilities. The Communications subsystem is functionally dependent on the services provided by the Internetworking subsystem.
Internetworking	The Internetworking subsystem consists of the physical, data link, network, and transport layers, according to the open systems interconnection-reference model specified by ISO 7498:1994, Open System Interconnection. The Internetworking subsystem supports alternative transports between communicating end stations; alternative networking methods between end systems and intermediate systems; and alternative circuit, packet, or cell-based LAN and WAN distribution services.

[The remainder of this view packet is omitted from the example.]

1.11 Module Decomposition View Packet 11: The System Management Subsystem

[omitted]

1.12 Module Decomposition View Packet 12: The Communications Subsystem

[omitted]

1.13 Module Decomposition View Packet 13: The Internetworking Subsystem

[omitted]

1.14 Module Decomposition View Packet 14: Flight Operations Segment (FOS)

1.14.1 Primary Presentation

Segment	Subsystem
Flight Operations Segment (FOS)	Planning and Scheduling
	Data Management
	Command Management
	Commanding
	Resource Management
	Telemetry
	User Interface
	Analysis

1.14.2 Element Catalog

1.14.2.1 Elements and Their Properties

Properties of FOS modules are

• Name, given in the following table
• Responsibility, given in the following table
• Visibility: all elements are visible across the entire system
• Implementation information; See the implementation view in Volume II, Chapter 9.

Element Name	Responsibility
Planning and Scheduling	The Planning and Scheduling subsystem integrates plans and schedules for spacecraft, instrument, and ground operations and coordinates DARs for U.S. instruments and multi-instrument observations, if any. Planning and Scheduling provides the operational staff with a common set of capabilities to perform what-if analyses and to visualize plans and schedules.
Data Management	The Data Management subsystem is responsible for maintaining and updating the Project Database (PDB) and the FOS history log.
Command Management	The Command Management subsystem manages the preplanned command data for the spacecraft and instruments. Based on inputs received from Planning and Scheduling, Command Management collects and validates the commands, software memory loads, table loads, and instrument memory loads necessary to implement the instrument and spacecraft scheduled activities.
Commanding	The Commanding subsystem is responsible for transferring command datareal-time commands or command loadsto EDOS for uplink to the spacecraft during each real-time contact. Command data can be received in real time by the operational staff or as preplanned command groups generated by the Command Management subsystem. The Commanding subsystem is also responsible for verifying command execution on-board the spacecraft.
Resource Management	The Resource Management subsystem provides the capability to manage and monitor the configuration of the EOC: configuring EOC resources for multimission support, facilitating failure recovery during real-time contacts, and managing the real-time interface with the NCC.
Telemetry	The Telemetry subsystem receives and processes housekeeping telemetry in CCSDS packets from EDOS. After the packet decommutation, the telemetry data is converted to engineering units and checked against boundary limits.
User Interface	The User Interface subsystem provides character-based and graphical display interfaces for FOS operators interacting with all the previously described FOS subsystems.
Analysis	The Analysis subsystem is responsible for managing the on-board systems and for the overall mission monitoring. Its functions include performance analysis and trend analysis. It also cooperates with the Telemetry subsystem to support fault detection and isolation.

[The remainder of this view packet is omitted from the example. Subsequent view packets that further decompose this segment's eight subsystemsPlanning and Scheduling, Data Management, Command Management, Commanding, Resource Management, Telemetry, User Interface, and Analysisare also omitted.]