As noted in Chapter 10 of the book, some projects maintain a single overall glossary and acronym list, which would include the terms and acronyms used throughout the architecture documentation and in other documentation. In that case, the architect's obligation for this part is discharged simply by pointing the reader to the overall project glossary acronym list.
asynchronous A format used in digital communication between computers with no timing requirements for transmission and with the start of each character individually signaled by the transmitting device.
attitude data Data representing spacecraft orientation and on-board pointing information: (1) sensor data to determine the pointing of the spacecraft axis, calibration and alignment data, Euler angles or quaternions, rates and biases, and associated parameters; (2) data generated on-board in quaternion or Euler angle form; (3) refined and routine production data related to the accuracy or knowledge of the attitude.
Communications Subsystem (CSS) The ECS subsystem for transferring ECS data between sites and within a single site, providing connections between ECS users and ECS service providers and providing requested services to support the System Management Subsystem operations. The CSS is composed of one CSCI, the Distributed Computing Configuration Item (DCCI), and one HWCI (a Sun workstation with an external disk.)
Computer Software Configuration Item (CSCI) An element in the module decomposition view. A CSCI is a subelement of a subsystem, implemented with COTS and custom-developed software to satisy a particular subset of subsystem-level software requirements.
Distributed Active Archive Center (DAAC) A facility that manages one or more data products and, possibly, the production of one or more products; archives are "active" in that their data holdings are always available.
data granule A file or file group containing science data and referenced as a single entity.
data product A class of similar data granules, usually produced by the same source.
Interoperability Subsystem (IOS) Allows ECS servers and non-ECS users to insert and subsequently search for Earth sciencerelated services, advertisement providers, and data. The IOS consists of the Advertising Service CSCI and the Interface Hardware CI. The Interface Hardware CI is shared with the Data Management subsystem
Level of data Categorization of ECS data into levels, depending on the amount of processing that has been performed.
Level 0 data is the raw, instrument telemetry data extracted from the spacecraft telemetry and has been time ordered, with duplicate and corrupted packets discarded. Level 0 gives the truest form of data produced by the instrument.
Levels 1a and 1b data is radiometrically (1a) calibrated and geometrically (1b) located to a reference surface. For each instrument, we maintain either the level 1a or the level 1b data. Older versions of level 1 data are discarded 6 months after reprocessing to a new version.
Level 2 data consists of geophysical data sets created by applying scientific algorithms developed by the instrument or science team investigators. Level 2 data sets retain the "full" resolution of the instrument or sensor: swath format for imaging sensors. Older versions of level 2 data sets are discarded 6 months after reprocessing.
Level 3 data consists of geophysical data sets averaged in space or time, using algorithms developed by the instrument or science team investigators. In most cases, level 3 data constitutes the "final" product for an investigation and is maintained in the archives for the extent of the mission or investigation. Older versions of level 3 data sets are discarded 6 months after reprocessing.
Level 4 data sets are value-added data sets, created through application of a model to the satellite data. Currently, ESE archives only a few standard level 4 data productsprimarily Data Assimilation Office productsand they are maintained for the extent of the mission or investigation:
message passing The peer-to-peer asynchronous communications service notifying processes of specific event triggers. This service is provided by the CSS within the ECS.
Mission to Planet Earth (MTPE) A NASA-initiated concept that uses space-, ground-, and aircraft-based measurement systems to provide the scientific basis for understanding the climate system and its variations. The science objectives address the fundamental physical, chemical, and biological phenomenon that govern and integrate the Earth system.
network ingest request An Ingest Request to automatically transfer data into the SDPS from an external data provider. The Network Ingest Request contains the following information: (a) external data provider, (b) date/time prior to which the data remains available, (c) requested ingest priority, (d) list of Data Type Identifiers, (e) for each Data Type Identifier, a list of file identifiers, (f) the corresponding file volumes.
on-board attitude data The attitude data generated by the spacecraft or its instruments.
science software A program used to generate data products.
Science Computing Facility (SCF) A facility that develops science software.
Science Data Processing Segment (SDPS) An ECS segment that provides the capabilities for science data processing and data product or data searching, ordering, archiving, and distribution.
Science Investigator-led Processing System (SIPS) A facility, external to ECS, that manages production of data products; products are stored in ECS.
scientist An individual with direct usage or support of the data collected and generated by, or the instruments contained within the EOSDIS. Included are principal investigators, coinvestigators, research facility team leaders and team members, interdisciplinary investigators, instrument investigators, non-EOS-affiliated science users, and other users of a diverse nature.
 The ECS project glossary is about 90 pages long and contains about 700 terms. A separate acronym list contains some 1,500 entries.
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints