Data Archive and Distribution Panel Report

Analysis of Current Systems

&

Conclusions and Recommendations

Purpose of document

Provide a reference model for archiving systems for the purpose of
analyzing current systems and framing recommendations

Allow us to define those areas of archiving and distribution where we
will recommend attributes and standards.

Identify those areas where the implementation is left up to the
individual implementers

Provide examples which can be generalized and directions for
standards/guidelines rather than be comprehensive in recommending a
complete suite of standards

Provide guidance to the current set of archiving systems as they make
modifications when they evolve and implement new systems

Scope of systems covered by this document

We are studying systems which are involved in archiving operational
data. This includes data at Levels 0 and 1 primarily.

-   Real time operations and storage of telemetry/payload data

-   Long term storage of this type of data

-   Distribution of data/data sets to projects and users

Even though systems discussed in this document do project specific
processing of data that is not covered under this study.

Models and Implementations of Archive Systems

The model we will use is for single systems. A model for collections of
individual systems is described briefly but is not needed for analysis
of current systems. It can, however, be used for making recommendations
for future systems.

Flow components of the single system model

In a single system data with different levels of processing may be
archived. For example Level 0 data is time ordered data as it came
directly from the science instrument or from engineering sensors, where
the effects of transmission have been removed. Level 1A data is
re-constructed instrument data that reflects the same temporal and
spatial resolution as it was observed, that is time-referenced and
annotated with ancillary information such as calibration coefficients
and platform ephemeris data, and any applied calibrations are only to
the extent that the original level 0 data could be reconstructed from
it. Level 1 B data, if it is produced, is instrument data that has been
processed to sensor units and may be re-sampled in such a way that the
original un-edited data can not be reconstructed from it. Level 2 data
consists of derived environmental variables at the same resolution and
location as thelevel 1 data.Systems may vary in how they handle the
archiving of different levels of data and this information needs to be
modeled.

Figure 1 is a conceptual data flow framework that enables the location
of various archive functions to be appreciated. The conceptual data
flows and interfaces are described to provide context. Actual
implementations may combine functions, thereby removing interfaces, or
may break functions into distributed parts with additional interfaces
needed. It is assumed that all functions identified may be distributed
to multiple platforms/sites.

![](media/image1.wmf){width="5.990277777777778in"
height="2.2604166666666665in"}

Figure 1: Data flow framework for archive systems

To make the framework more understandable, consider the following
scenarios. Assume that CCSDS frames/vcdu's and packets are captured (a
separate scenario is needed for receipt of 'files' from the S/C in
accordance with advanced file transfer communication capabilities) by
the ground station. The interface "1" will be some protocol that
supports the transmission of frames/packets to a Telemetry Buffer. The
telemetry buffer holds telemetry frames/packets for a short period
(possibly a few days) and it provides them, over some protocol, with
additional information about the capture (e.g., which S/C, time of
ground receipt, etc.). E.g., the JPL DSN does this using its compressed
SFDU form called "CHADOS". This is the interface "2". (Note to DADP
members: We should compare this with the SEWG services already
identified for this interface, and possibly including interface "1". I
believe that this is also the area that CCSDS Panel 3 is attempting to
standardize, and it is the area that will be defined by a joint NASA/ESA
effort to support the Integral satellite.)

The Level zero data processing function receives the frames/packets,
together with supporting information, and begins to form collections of
them according to project desires. Its primary function is to get rid of
duplicate packets and put the rest in time order. It goes back to the
Buffer to get missing packets assuming the Buffer holding time has not
been exceeded. It determines the time sequence of each packet from the
packet secondary header and the sequence counter in the transfer frame.
It may provide a number of services, such as forwarding each frame
directly (interface "5") to a type of Level 1A process doing quick look,
or it may collect frames and packets for a day's worth of some S/C's
telemetry, and then provide collections sorted by S/C ID and Packet APID
(designates an instrument mode) as well as time. The output is provided
using some protocol and it contains a package of one or more packets,
together with quality information, information on the type of service
being provided, and information on the requesting party. For example, it
may provide a set of health/safety packets (interface "4") to a process
that is monitoring this function. It may provide packets containing
instrument pointing information (interface "3") to the orbit/attitude
processing function. It may send the entire collection of a days S/C
packets to a Level zero archive (interface "6") using some protocol
which contains the packet collection package, together with an object
containing a set of attributes needed by the Level zero achive function
to do its ingest function. These attributes include (or point to)
information on the processing history to this point and pointers to
information on the meaning of the packet collection and packet contents.
The use of pointers allows this information to be updated over time
provided the pointers are universally recognized and the metadata is
maintained in permanent (archival) databases. This means that a quality
archival product does not have to be present at initial ingest to the
Level zero archive, and it allows the archival nature of the products to
be improved over time.

The level 1A science data processing function receives agreed
collections of packets, together with supporting quality information and
customer information, from either level zero processing (interface "5")
or level zero archiving (interface "9") (or possibly both). Its primary
function is to put the content, from one or more packets, together with
some ancillary information (e.g.,S/C name, time coverage), into a
science data object whose format typically conforms to some standard
formatting approach (e.g., FITS, PDS, CDF, HDF) This is done without
resampling the science data values so that, in prinicpal, level zero
data could be reconstituted. Any calibrations applied are reversable and
the science data are time referenced.

Although the level 1A science-data-object formats may conform to some
formatting system, there is still likely to be a wide variation in the
detailed structures and, of course, in the primitive data types found
therein.

The level 1A science data objects are sent, possibly with additional
information needed to facilitate archiving ingest, to a level 1A archive
using some protocol (interface "10"). They may also be sent (interface
"11") directly to a level 1B, or level 2, processing function.
Alternatively, this processing function may get them from the archive
(interface "12").

This general scenario repeats as the science data move to higher levels
of processing. Users of the data, other than the archives and processing
functions, may receive the science data objects from any of these
interfaces.

Functional components of the single system model

A more detailed model used for understanding the various functions
involved in archiving is given diagrammatically in Figure 2. This is
taken from the CCSDS and ISO "Reference Model for Open Archival
Information Systems (OAIS)" (Reference \# x).

. ![](media/image2.wmf){width="7.152777777777778in"
height="4.194444444444445in"}

Figure 2: Functional component model for archive systems

Briefly, information objects (which may be science or engineering data),
together with attributes needed for efficient ingest and for archival
preservation, are received from data Producers by the INGEST function
using a Submission Information Package. For example, as noted above for
"interface 6" of Figure 1, this may be a set of science packets together
with objects giving quality information and summary views of the
content. The INGEST function does validation, adds supporting
information as needed, and does any transformations needed to put the
information into archival storage forms. These transformations may
include reorganizing and reformatting to meet archival storage and
dissemination needs. The resulting Archival Information Packages are
sent to ARCHIVAL STORAGE using an Archival Information Package, and
information (e.g., Catalog data) used to support Consumer selection of
archived data is sent to DATA MANAGEMENT as Descriptor Information.

ARCHIVAL STORAGE accespts Archival Information Packages, stores and
manages them, and disseminates them in response to requests. It also
handles migrations of Archival Information Packages to new media.

ADMINISTRATION is responsible for coordinating daily operations of the
archive, and for addressing the implementations of policy issues which
impact multiple archival functions. In contrast, Management is a higher
level function that oversees archival operations as only one of it
responsiblities.

Consumers interact with the ACCESS function to find information objects
of interest. The finding aids used are supported by the catalog data
(Descriptor Information) held by DATA MANAGEMENT. Once a Consumer has
determined the information objects desired, the order goes to
DISSEMINATION for completion. Standing orders are processed
automatically as the information becomes available and meets
distribution requirements.

DISSEMINATION asks ARCHIVAL STORAGE for the Archival Information
Packages involved, and it performs whatever processing is needed to
complete the order. This may include additional subsetting and
transformations, as appropriate. DISSEMINATION provides the requested
information objects as Dissemination Information Packages to the
Consumer using some protocol (e.g, FTP, http).

Data components of the single system model

Of particular relevance for improving the cost-effectiveness of
information ingest into archives, and the ability of archive consumers
to cost-effectively find and use information held by archives, are the
archive's external interfaces with their respective data structures and
protocols. These also come into play for the transfer of information
from one archive to another. In Figure 2, these are the Producer-INGEST,
Consumer-ACCESS, and Consumer-DISSEMINATION interfaces.

These interfaces are affected by a number of factors operating on both
sides of the interface. On the Producer side, there is the range of
information object formats that need to be accommodated. For example,
referring again to "interface 6", a collection of packets may be
standardized by providing a standard packaging strucutre, but the packet
content formats of science and engineering data will vary depending on
the instument (and its modes) that produced them. On the INGEST side,
there is a strong desire to minimize the amount of INGEST processing
required (particularly involving human intervention) while
simultaneously obtaining sufficient supporting information so as to be
able to preserve the information objects over time and to provide
necessary Consumer ACCESS and DISSEMINATION services.

On the Consumer side, there are the varied requirements of different
types of Consumers and the heterogenity of their environments which must
be accommodated. On the ACCESS side there are the constraints of the
available information obtained during INGEST and kept in Data
Management, and a strong desire to minimize the need for acquiring
additional information to support ACCESS because this is likely to be
costly (manpower intensive) to obtain and integrate. On the
DISSEMINATION side, there are the cost-effective archival storage forms
which support information preservation (including possible migrations),
the need to provide timely responses to Consumer requests or standing
orders, and the strong desire to minimize special output processing when
it involves human intervention.

These factors need to be taken into account when developing or evolving
the interfaces. **We take it as an axiom that** **these interfaces
should assist archival operations** **and Customer usage** **to be as
automated** **as possible, which simultaneously** **minimizes the**
**average** **human intervention required over the long term.** This
follows from the continuing exponential growth in computational
capabilities and storage at reducing costs, while human costs remain
relatively fixed. It also means that, **to the maximum extent possible,
all information needed to manage archival operations and to support
Consumer** **usage of archival information should be the subject of
possible standardization** **and incorporation into data flows through
the external interfaces**.

A general model of archival information components is shown in Figure 3.

![](media/image3.wmf){width="5.992361111111111in"
height="3.2847222222222223in"}

Figure 3: Archival Information Package Components

The **Archival Information Package** (AIP) contains two primary
components that are identified as **Content Information** (CI) and
**Preservation Description Information** (PDI). The Content Information
is that information which is the primary information submitted for
preservation. The scope of what constitutes this information is agreed
to between the archive and the Producer. For example, for a level zero
archive it is likely to be a set of packets provided in some packaged
form and arriving via a network. To be complete, and preservable for the
long-term, this information must include the associated Representation
Information (or format information) that turns the Content Information
bits into meaningful information.

Once the Content Information has been determined, it is possible to ask
what constitutes the Preservation Description Information for that
particular Content Information. The PDI includes several types of
additional information that are needed to help preserve the Content
Information. These are:

o **Reference**: How consumers can uniquely identify the Content
Information from any other Content Information.

o **Provenance**: Who has had custody of the Content Information and
what was its source. This would include the processing that generated
it.

o **Context**: How the Content Information relates to other information
objects, such as why it was created and how it may be used with other
information objects.

o **Fixity**: Information and mechanisms used to protect the Content
Information from accidental change, this may consist of some directory
and file names, and their underlying implementations, on some medium. Or
it may consist of a tar file together with some information relating the
Content Information bits, its Representation Information, and Preserving
Description Information.

Also associated with the Archival Information Package is the Descriptor
Information. This is the information that is used to populate finding
aids and is typically thought of as the catalogue information. It is
this information that supports Consumer searches or that triggers the
dissemination of information in response to a standing order.

In support of the automation axiom given above, the Submission
Information Packages at the Producer-INGEST interface should be
standardized to make clear what is Content Information, what is
Preservation Description Information, what is Packaging Information, and
what is the Descriptor Information. The use of standard pointers to some
of this information already archived can be a useful approach to
avoiding extensive duplication when many similar Submission Information
Packages are to be received. For example, a data description language
expression of the format of a packet content (or higher level data
products to be archived) may be submitted and re-used for all packets of
that type. This also supports automated access to packet content for
validation and subsetting operations. There are some other categories of
information that may be included, and standardized, in a Submission
Information Package such as special INGEST processing instructions and
special DISSEMINATION processing instructions.

The Dissemination Information Package needs, in general, to be quite
flexible in order to respond to the variety of Consumer types and
environments, as well as to the variety of services the archive
provides. Typically it needs to support the dissemination of only part
of an Archival Information Package, together with optional Preservation
Description Information, in one or more package forms over a variety of
protocols or media. It will also need to support optional identification
of the Consumer and the request, or standing order, that led to its
preparation.

The data structures and protocols at the Consumer-ACCESS interface can
be quite varied. All archives will support WEB based discovery, and in
some cases retrieval, services. However, more precise searching services
are useful particularly when the need is to search across a number of
related archives, such as level zero archives or some science discipline
archives. These archives will adhere to some common standards describing
their holdings and thus more effective search protocols, such as those
based on Z39.50, can be applied. This also facilitates the ability of
applications to initiate the searches and increases the opportunity for
automation. For example, the adoption and re-use of common attributes
about data is faciliated by the registration of Data Entity
Dictionaries. The use of such dictionaries is becomming more common and
there are now international standards in this area. The ability to
provide a view on related data products, such as a science data product
and a related orbit/attitude data product, can also be supported through
the discovery process. Additional standards that express such
relationships explicitly are needed to improve automation in this area.

Current system descriptions

(I will format the various descriptions provided by the people)

A paragraph for each system will be included here.

A complete collection of current systems is presented in Appendix A.

Analysis of current systems

(Mike, you may want to take the lead here)

Matrix of features

Analysis of these features, illustrations of standards that are used,
measures of commonality among different systems

Models for federated systems

Users of multiple OAIS archives may have reasons to wish for some
uniformity or cooperation among them. For example, Consumers of several
OAIS archives may wish to have

\- a master catalog to aid in locating information over several OAIS
archives,

\- a common schema for access and dissemination, or

\- a single access site.

Producers may wish to have

\- a common schema for submission to different archives, or

\- a single depository for all their products.

Managers may wish to have means for

\- enforcing submissions, or

\- increasing the uniformity and quality of user interactions with the
OAIS.

Therefore, it may be advantageous for OAIS archives to cooperate to meet
these wishes. The motivation might come from the archives themselves, or
it may be imposed by an authority that has some influence over them. In
the former case, the archive might be motivated by the desire to keep
consumers happy with their products, or to keep users happy with their
quality of service, or simply by the need to compete with other archives
in order to survive or grow. Situations like this can and have motivated
agreements without the need for any explict federation establishing an
external authorty.

In cases where explict federation is established, the external authority
is represented in this Reference Model by Management. It is not the
purpose of this section to discuss the detailed organizational
architecture (or intrigue) of the Management interactions, since these
are outside the model, but rather to describe the OAIS external
interconnections that might allow the above wishes to be met.

At a rudimentary level of federation, **Figure B-1** represents a simple
mutual information exchange agreement between archives. (Note: In this
and the following figures, the OAIS is represented as a "five-port
device" following the arrangement of Figure 4-1. In each case, a
two-archive federation is shown for simplity, although the concept can
be extended indefinitely.) The essential requirement for this federation
is a set of mutual Submission Agreements, subscriptions, and user
interface standards to allow DIPs from one archive to be ingested as
SIPs by another. Therefore, it assumes that some pair-wise compatibility
has between established between the archives. This does not necessarily
require common access, dissemination and submission methods for all
participants, although that may be expected encourage more exchange.

![](media/image4.wmf){width="4.0in" height="1.7638888888888888in"}

######### Figure B-1. A Simple OAIS Federation for Mutual Data Exchange

**Figure B-2** is an example of OAIS archives that have standardized
their submission and dissemination methods for the benefit of users. No
special external element, other than management, is needed for this. Its
disadvantage is that there is no formal mechanism for exchange of
catalog information. Where does the consumer look for the desired
information? Perhaps the archives agree to exchange context and catalog
information, or perhaps one of the archives agrees to take on the role
for both.

![](media/image5.wmf){width="4.471527777777778in" height="2.375in"}

######### 

######### Figure B-2 An OAIS Federation with Standard Ingest and Dissemination Methods

**Figure B-3** shows a way to solve the catalog problem using an entity
eternal to the OAIS. Here, a pair of Producer-Consumers, each of whom
maintains his own OAIS archive, have joined together to share
information. The Common Catalog & Manager is the external binding
element that serves as a common access point for the information in both
archives. The Common Catalog may limit its activity to being a finding
aid, or it may provide full combined Acces service as shown in the
Figure. Optionally, it may include common Dissemination of products from
either or both arcihves.

This architecture closely matches that of NASA's TIMED (Thermosphere,
Mesosphere, Ionosphere Energetics and Dynamics) space mission, in which
four individual archives are operated by Principal Investigators. As
Producer, each principal Investigator is responsible for archiving his
own products. However, there are instances where the Producer
incorporates the products of other Principal investigators into his
product. In this application, the mission operator is the external
entity. The Common Catalog component provides a Dissemination service
which can assemble special products obtained from multiple archives, and
also accept subsciptions for them. Additionally, the Manager component
exploits its position to enforce the submission of data products by each
Principal Investigator to his own archive, according to the agreement
established for the mission.

![](media/image6.wmf){width="4.471527777777778in"
height="3.5416666666666665in"}

######### 

######### Figure B-3. An OAIS Federation Employing a Common Catalog

**Figure B-4** shows a federation with an external entity on the Ingest
side. As with the example of the Common Catalog, this entity permits
enforcement of broad submission agreements involving several producers
and archives. Here, the Common Ingest Staging entity can also take the
responsibility to route submissions to the appropriate archive.

![](media/image7.wmf){width="4.555555555555555in"
height="2.5833333333333335in"}

######### 

######### Figure B-4. An OAIS Federation with Common Ingest Staging

Of course, the arrangement of Figure B-4 is little help for the consumer
who does not know where to look for information. A more elaborate
arrangement than any of those shown above would include both a Common
Catalog and Common Ingest Staging, to provide an external appearance
similar to that of a single OAIS. Such a complete embedding of OAIS
archives may be thought to be less efficient than a single distributed
archive under one administration. However, it does allow for a
negotiated degree of autonomy for each archive.

It should be evident from the above examples that the OAIS model is
consistent with federation to accomplish specific objectives. However,
it should also be considered that some of these objectives may be
accomplished through voluntary action.

Conclusions

Explain the methods by which we arrived at these conclusions. Explain
that we have not system trades based on detailed analysis but have used
our expertise in archive systems. Where possible we will include
examples to support our recommendations.

You must do planning for long term archiving from the very beginning in
order to ensure that all the needed meta data will be there.

-   The concept of an archive quality product is the key concept we need
    to keep in mind. An archive quality product is one which can be
    productively used even after the current staff, software, and
    storage mechanisms are no longer available.

-   We recognize that there are short term data storage needs that are
    critical and these must be accommodated simultaneously

-   Planning for metadata should be done in conjunction with planning
    for the product itself

-   If this is not done then the ability to move from short term data
    storage to long term archives may be impossible (i. e., needed
    information is missing) or costly (i. e., transformation of data
    sets may be extremely complex and require special custom programs)

-   The driver for what we are doing is the ultimate preservation of all
    the needed data and we need to back up from this point to determine
    what we need to do in the intermediate time frames.

There needs to be system standards which accommodate a diverse set of
operational requirements. (Tom knows he needs to strengthen these
items.)

-   There are different levels of standards depending on the complexity
    and use/sharing of the system/data.

-   There can also be different levels of service provided by the
    various systems.

-   There needs to be a standard or a convention or an agreement within
    NASA or at least that portion of NASA that is covered by CSOC
    regarding the extent and character of data preservation/archiving
    functions.

There needs to be an architecture for the federation. Right now we
simply have a collection of individual systems without clearly defined
common ways of operating or interacting.

-   There is a need for a data architect and a data architecture (See
    paper by Dave Childs. An Acrobat 3.0 version of this paper is
    attached. It was written several years ago but the ideas are still
    relevant today.)

There is a need for a Project Data Management Plan and an Archive and
Transfer Plan.

-   The PDS model for this can be used.

-   The Project Data Management Plan is a document prepared by a
    project/mission which describes how all the data on the project will
    be handled. It is a high level document that is agreed to by
    engineering, science, operations, and management and sponsors.

-   The Archive and Transfer Plan is a more detailed document that
    describes the data that will be archived and the processes and
    standards that will be used to document the preparation of data and
    associated metadata for archiving and its transfer to an archive
    facility.

Responsibility for the definition, maintenance and preservation of every
data set should be assigned to one center or entity (Tom will work with
Leonard Halley to shape this section up better)

-   This entity (or supercenter for the dataset) should be the one whose
    mission is most closely allied with the data set. For example
    station playload data with EHS, station engineering data with ODRC.

-   Other sites may store the data and use the data. Thus we are really
    not addressing the issue of duplication of data.

-   The authoritative copy is at a supercenter

-   Responsibility for long term data preservation, metadata, and usage
    of data standards rests with the supercenter

-   It should be the responsibility of this center to translate the data
    from an implementation dependent state (e. g., this data can only be
    read by the XYZ system) into a form that can be read by any system
    able to interpret some well agreed upon standards.

Legacy systems will exist into the future and must be accommodated.

-   A solution can be to encapsulate these systems via wrapper
    technology which will allow them to be a standard part of a
    federated system

The standards which are recommended must evolve from the user
communities and the system developers. A strategy for standards
development must be produced. (Don - With your background in standards
construction, you may want to take a cut at this)

-   Flexibility of standards

-   Standards can be very specific (e. g., ASCII entries, tab delimited,
    column names in first row) or described via a limited set of
    alternative structures and definitions (the Planetary Data System
    uses the Object Description Language to describe numerous types of
    tabular data)

-   As the flexibility of the standards increases the complexity of the
    software to handle the data sets increases

-   Homebrewed standards are not inherently a problem. They could be a
    problem for

-   Maintainability - contractor goes away and who is there to maintain
    the software

-   Portability - Can't be readily used by another site

-   Compatibility and Shareability - Unless formats can be translated to
    a neutral form or directly transformed then data can't be easily
    shared.

-   Performance

-   Our initial system worked fine but it was not scaleable. That
    required a whole new design.

-   Product transformation/retrieval characteristics - The amount of
    data people were requesting was so large that translating from
    internal formats to external formats required considerable time

Recommendations

Initial set of recommendations to be carried out in the short term:

-   Form and empower a committee to guide and coordinate the technical
    development and evolution of archive and data distribution systems

-   Develop online database of metadata for all data available through
    selected archival systems in NASA

-   Develop common data dictionary and naming conventions

-   Develop wrappers for some current systems to enable common access -
    evaluate separation of common versus system/project specific
    implementations

Long term recommendations to be carried out after detailed engineering
analysis:

-   Adopt common web-based interface to data holdings at all sites.
    Build code underneath at each data center to communicate between
    local database and the common user interface. Phase out the custom
    interfaces at various data centers over a 1 year period.

-   Adopt a common data definition language at all data centers for
    electronically documenting data formats, contents and decommutation
    information.

-   Move from the current curatorial model for data centers to a
    publishing model (e. g., the Planetary Data System). Develop a
    standard volume architecture for raw data formats and guidelines so
    that each center provides consistently documented volumes.

-   Develop portable class libraries (in C++ or Java) of telemetry
    processing functions which will be provided to all data centers as
    they migrate to the new publishing-based architecture.

Appendix A

Current System Description:

Data Reduction Center (DRC) (Marshall Space Flight Center)

Overview

The MSFC Data Reduction Center (DRC) is considered a general purpose
computing facility. The DRC occupies approximately 12,000 square feet in
C-Wing of MSFC building 4663. Of this area approximately half is access
and environmentally controlled, with raised floor, and is dedicated to
computer system support. The remaining area provides office space for a
staff of approximately 60 people.

Power for building 4663 and the DRC is provided by the Tennessee Valley
Authority (TVA) and delivered via two redundant sources (sub-stations 12
& 16). In the event of failure of both transmissions sources, the DRC
computer systems and chilled air supplies are backed by Uninterruptible
Power Supplies (UPS) and generators.

The DRC utilizes 21 Automated Data Processing (ADP) systems, associated
peripheral devices, and front-end instrumentation to meet primary
mission objectives. Secondary objectives also require approximately 65
workstations.

The 21 ADP Systems include

-   Two Concurrent 5/6000s

-   Two Digital Equipment Corp. VAX 8650s

-   A Digital Equipment Corp. VAX 8800

-   A Digital Equipment Corp. VAX 6000-410

-   Three Digital Equipment Corp. VAX 4000-200

-   Four Silicon Graphics Inc. Challenge XL systems

-   Two Silicon Graphics Inc. Indigo Systems

-   Three Silicon Graphics Inc. Indigo II Systems

-   A SUN Microsystems 670MP

-   Two SUN Microsystems SPARCcenter 2000 systems

Significant Peripheral Devices include

-   Thirty Six Dual Channel Digital Telemetry Receive devices

-   Eight Dual Channel Telemetry Transmission devices

-   Three SONY 450 GB WORM Optical Storage Systems

-   Two HP 400 GB Write Many Read Many (WMRM) Optical Storage Systems

-   Two HP 600 GB WMRM Optical Storage Systems

-   Two 2.5 TB Digital Linear Tape (DLT) archives

-   One 13 TB DLT archive

-   GB of local Magnetic disk

-   A 400 GB shared Random Array of Inexpensive Disks (RAID) file server

-   Analog Tape Drives & High Speed Digital Drives (14 & 28 track, 1"
    tape)

-   Nine track, 8mm, 4mm, DAT, and QIC digital tape

-   Three single CD-ROM mastering units

-   Two 75 CD mastering systems

The DRC systems are networked internally by Ethernet and Fiber
Distributed Digital Interface (FDDI). External networks having
connectivity to DRC systems include: KMTS, NASCOM, PSCN, PSCNI, NSI, the
Internet, and FTS2000. These networks are used primarily for the
transmission of electronic data products and the exchange of raw
telemetry data.

The MSFC/DRC telemetry processing system is based on general purpose
"Open Systems" computing platforms equipped with serial interface
devices interfaced via industry standard busses, and integrated with a
POSIX compliant automated data reduction software system of modular
design. All development is done in standard computer languages,
primarily C/C++, facilitating upgrades and open procurement of hardware.
File and data structures utilized also are vendor independent. A small
suite of standard intermediate file formats are used within the DRC's
processing system from which custom output formats satisfying
requirements of individual users and user databases are produced.

The Technical Architecture of the DRC's primary processing systems is a
heterogeneous set of mini-computers, linked together by both FDDI and
Ethernet. The systems all run a variant of UNIX as their operating
system and share local disk resources amongst themselves using NFS over
FDDI. All the systems also share a common RAID pool and approximately 22
TB of mixed media on-line archive. These systems are utilized to run a
critical system of applications which is best described as an automated,
multi-node, distributed, event driven, pipelined digital data
acquisition, processing, archival, and delivery system. The software
system consists of multiple independent processing nodes. Each node is
capable of performing all tasks in the integrated system or
participating in the distributed execution of the system in a more
limited role. Digital data is first acquired in real-time through
special purpose interface devices. The data is then normalized for
acceptance by the rest of the processing system. Normalized data is then
merged with other sources and databased. These steps, acquisition,
normalization, merging and databasing constitute the four stages of the
front-end pipeline. The back end stages of the pipeline include
extraction from the database, product creation, and delivery.

Ingest

The DRC receives and processes digital and analog data from live and
pre-recorded sources. These sources include real-time and playback
orbiter and component downlink, and pre-flight ground tests.

Data sources

Data received and processed by the DRC may originate from a variety of
sources. Large volumes of data have traditionally been received from the
Space Shuttles and their cargo. The DRC will receive and process health,
status, and performance data from the orbiters and their various major
systems (i.e. Main Propulsion, External Tank, etc.). The facility also
receives and processes data originating from telemetry producing
payloads and experiments, including those aboard SpaceLab missions.

Quality Quantity and Continuity (QQC) Requirements

For all data sources and data products created, the DRC's mission is to
acquire all transmitted data to produce the best source maximum time
coverage output product. For cost and practicality reasons, this basic
mission requirement is often qualified in order to minimize demands on
resources outside the DRC. For instance, coverage gaps of two seconds or
less in SpaceLab experiment streams are acceptable vs. the cost of
investigating the availability of the data and its delivery to the DRC.

Replay capability

The DRC maintains the ability to replay all data sources which it can
acquire. This is accomplished through a system of computers with
telemetry transmission interfaces and wideband recording systems.

Decommutation

Many of the DRC's data products require decommutation of the received
telemetry frames. For instance, the primary data product produced in
support of the Space Shuttle Program is a large database which contains
all requested measurement samples decommutated and converted to
Engineering Units. In support of this requirements (and others like it)
the DRC maintains a Calibration Database System which includes a
decommutation map for all measurements and telemetry formats.

Throughput rates

The DRC digital telemetry processing system has 72 input channels, each
of which can support the acquisition of Pulse Code Modulated (PCM) data
at rates from 0 to 15 MHz. Other factors limit the overall throughput of
the system such that a sustained rate of 4 MHz per channel is
obtainable. Much higher rates are obtained through the network delivery
of packetized data.

Storage

Local storage format

Four primary local data storage formats are used. These formats are
optimized for the type of data they contain. All formats are software
interchangeable such that all data products and processing capabilities
are available to all types of stored data.

Archive size

The DRC online archive capacity is currently approximately 8 TB. This
will be expanded to 22 TB as a result of acquisitions in progress.

Retention periods

Data retention periods are variable based upon the program supported.
SpaceLab experiment data is retained for a minimum of two years. Data
archived in the STS Database is retained indefinitely.

Data Management

The DRC archive is a distributed system based upon a UNIX client server
model. The actual archive hardware is a multi-media approach which is
managed by a Hierarchical Storage Management (HSM) system called
OpenVision. Proprietary databases are currently being converted to
maximize the use of Oracle as the DBMS.

Administration

The Data Reduction Center is operated by Computer Sciences Corp. (CSC)
as part of the Program Information Systems Mission Services (PrISMS)
contract which is overseen by the Information Systems Services Office
(ISSO) of the MSFC I&PS directorate.

Management

The DRC is operated and managed by PrISMS Mission Services Department.
Oversight responsibility is divided into three sections: Operations,
Software Development, and Systems & Engineering.

Personnel

The DRC is operated by a staff of 50, approximately equally divided
between the sections named above.

Access

User community

The DRC user community consists primarily of NASA and contractor
engineers who support the STS, SpaceLab, Payload, and Propulsion Project
offices. Also, the private sector scientists whose experiments are flown
aboard SpaceLab missions.

Usage scenario

Typical usage of DRC services consist of either accessing the databases
constructed by the DRC and served via the STS Database System or
receiving electronically or via CD one of a suite of predefined data
products.

Types of requests

Requests can be divided into two categories: major/recurring and
minor/limited. Major or recurring requests for services are typically
made via NASA form 3559 which provides Project Office funding for a
specified service or set of services. For instance, a 3559 may request
the DRC to support all manifested shuttle missions by acquiring all
available main engine data, processing a specified list of measurements
and delivering them to the STS Database for user access. Minor or
limited requests may be issued via Data Request Form (DRF), which may
request that a specific set of measurements be acquired and processed
from a specified shuttle flight.

User Interface

The user interface for accessing DRC served data is typically associated
with access to the STS Database. Three types of interface are provided.
An API library is available for direct access to the database on the
database host (currently an IBM mainframe). A dumb terminal interface is
available for accessing the database and obtaining a number of data
plots or reports. Also, and X-Windows GUI is available for network
access to the database to obtain plots, reports, or to extract files of
data for network delivery.

Analysis Software

Files of data can be extracted from the database and converted into
formats appropriate for input into a number of available COTS analysis
packages. The DRC also provides a suite of applications for the creation
of standard vibro-acoustic analysis data products.

Dissemination

Data dissemination is accomplished through a range of output products.
The largest user contingent accesses data processed by the DRC by
accessing the STS Database. The database system provides the means for
hardcopy and network file delivery of a suite of standard products.

Other users, a significant group being the SpaceLab experiment
community, receives files of data direct from the DRC via electronic
transmission or CD-ROM. These files are a legacy SpaceLab standard
format for delivery.

A small set of users requests and receives custom data products.

Archive Classification

The following information is provided in order to assist in the
"classification" of the DRC in the company of other identified archive
systems. This information is based upon the categories outlined in
section 5 of the document describing the "Reference Model for an Open
Archival System". The information provided should in no way be
considered complete or conclusive regarding the DRC's capabilities.
Since the DRC is a multi-purpose archive facility, its classification
may change completely based upon the project, data, or mission context
in which it is viewed. Since the bulk of the DRC's archive requirements
are currently in support of the Space Transportation System (STS)
program and Shuttle Project Office, the classification information will
describe the STS Database archive.

1\. Acknowledged degree of permanence:

Classification criteria:

a\) Temporary archive: archive has a defined lifetime and is not
expected to exist beyond that time.

b\) Permanent archive: archive is defined as permanent, or the date at
which it may be terminated may be extended after additional review by
management.

The DRC's STS Database (STSDB) is a permanent archive.

2\. Digital Information preservation level:

Classification criteria:

a\) Bit Preserving: archive is responsible for preserving collections of
bits

b\) Information Preserving: archive is responsible for preserving bits
as well as what those bits mean.

(this does not address the physical media/samples issue)

In support of the STSDB, some data is preserved in its rawest bit-wise
form while the data stored in the actual database is retained in
time-stamped Engineering Units form.

3\. Degree of opaqueness of AIP

Classification criteria:

a\) Objects are completely opaque to the access function.

b\) Some information within an object is directly available to the
access function.

c\) Objects are available to the access function.

For the STSDB, objects are completely opaque to the access function.

4\. Dissemination methods

Classification criteria:

a\) Non-electronically readable media (paper, microfilm, etc\...).

b\) Electronically readable media.

c\) Electronic transmission (internet, modem, etc\...)

Data products are disseminated from the STSDB in both the traditional
hardcopy media form and the more modern electronic transmission of
extracted files.

5\. Active vs Final Archive

Classification criteria:

a\) Active archive

b\) Final archive

The STSDB exhibits some of the described characteristics of an active
archive, however, it's primary purpose is to be a Final Archive.

6\. Diversity of Collection

Classification criteria:

a\) Project

b\) Discipline

c\) General

The STSDB should be considered a Project based database.

7\. Institutional vs Non-Institutional archive:

Classification criteria:

a\) Institutional

b\) Non-institutional

The STSDB more closely approximates a non-institutional archive.
Although its funding comes from the Shuttle Project Office, it's purpose
is to serve a much wider user base of both NASA and contractor
composition.

8\. Archival storage types

Classification criteria:

a\) Physical: includes physical samples, hard copy, film, etc.

b\) Digital: Information archived is in digital forms

c\) Both: Some information archived is in digital and some is in
phyiscal forms

The STSDB is a Digital archive.

9\. Distributed vs Centralized

Classification criteria:

a\) Centralized

b\) Physically distributed, centralized administration/management

c\) Physically distributed, federated administration/management

The STSDB is currently a centralized database, but a project is under
way to re-host the database to a physically distributed/centralized
administration configuration.

Appendix B

Current System Description:

Enhanced Huntsville Operations Support Center (HOSC) System (EHS) Near
Realtime Retrieval (NRT) System (Marshall Space Flight Center)

Facility Summary

The EHS NRT system is a component of the overall EHS which provides for
acquisition, processing, recording, retrieval, and distribution of
spacecraft telemetry (TLM) data to programs and projects supported by
the generic EHS data system architecture \[ARCHIVAL STORAGE TYPE OF
DIGITAL\].

The architecture of the EHS (including the EHS NRT system) is designed
to be replicated at other locations other than the MSFC HOSC. These
locations include the Advanced X-Ray Astrophysics Facility (AXAF)
Operations Control Center (OCC) in Boston, MA in support of the AXAF
spacecraft; in addition to the Kennedy Space Center (KSC) and other
International Space Station (ISS) payload user facilities at other NASA
facilities (such as Lewis Research Center (LeRC)), etc.

Ingest

The EHS provides the capability to receive and process the following
different TYPES of telemetry data streams:

1\. Consultative Committee for Space Data Systems (CCSDS) Version 1
CCSDS Packet data

2\. Time Division Multiplexed (TDM) telemetry data streams

3\. NASA Communications (NASCOM) 4800 Bit Block (4800-BB) Native Packet
messages

The minimum EHS baseline requirement for the instantaneous DATA RATE
that must be supported in realtime is 4 megabits per second (Mbps) per
"TLM Server" (to be described later). The actual data rate that can be
supported is determined by the complexity of the data streams to be
processed, the loading placed upon the system by user data retrieval
activities, other realtime loading/processing conditions on the systems,
and finally the inherent capacity/performance of the server(s) and
storage subsystem supporting the activities.

The EHS provides the capability to receive raw (unprocessed) CCSDS
Version 1 Packet data via the industry standard User Datagram Protocol
(UDP) internet protocol via a standard Local Area Network (LAN)
interface using a messaging structure termed the EHS protocol. This EHS
protocol provides supplemental data quality and stream accounting
information in the message header of the transported/received data. A
front-end system is typically used to receive raw CCSDS Channel Access
Data Units (CADU's) and extract the required CCSDS Version 1 Packets for
transmission to the EHS NRT system (ex. for ISS this front-end system is
the EHS Payload Data Services System (PDSS) which provides for
reception, distribution, and storage/retrieval of raw user telemetry
data at rates up to 50 Mbps).

The EHS provides the capability to receive raw (unprocessed) TDM
telemetry data using a standard RS-422 serial clock and data interface.
Alternately, the EHS can receive TDM data encapsulated within the
UDP/EHS protocol via a standard network interface (ie. TDM data that has
been front-end processed by another data subsystem either local or
remote to the EHS system). Two special cases of TDM data processing are
also supported as follows (and are also referred to as TDM data
throughout the remainder of this writeup)

1\. The EHS has the capability to receive and process the Space Shuttle
Operational Downlink (OD) data stream and it's aggregate Operational
Instrumentation (OI), General Purpose Computer (GPC), and Payload Data
Interleaver (PDI) payload stream window components.

2\. The EHS provides the capability to process Standard Format Data Unit
(SFDU) telemetry data from the Deep Space Network (DSN). This SFDU data
includes raw AXAF CADU telemetry data.

The EHS provides the capability to receive raw (unprocessed) NASCOM
4800-BB Native Packet messages using a standard RS-422 serial clock and
data interface. Alternately, the EHS can receive the 4800-BB data
encapsulated within the UDP/EHS protocol via a standard network
interface. Data processed through this service includes:

1\. Any standard data message encapsulated within a single 4800-BB
message.

2\. TDRSS User Performance Data (UPD)

The EHS provides the capability to receive and process the following
DATA MODES for telemetry streams received:

1\. Realtime data streams (native data rate typical)

2\. Onboard Recorder Dump data streams (in the forward direction) at
rates typically other than the native data rate

3\. External playbacks of data at either the realtime native rate or at
a rate typically associated with an onboard recorder dump (or some other
logical data rate).

Telemetry streams that can be processed by the EHS should comply with
the EHS TELEMETRY FORMAT STANDARD (MSFC-STD-1274). Salient features of
the EHS TLM Standard includes:

1\. Support for multiple data rates and formats for each individual data
stream

2\. Support for multiple concurrent data commutation techniques

3\. Support for multiple concurrent standard native spacecraft data
format structures (ex. integer, floating point, ASCII, etc.)

4\. Support for multiple data conversion and calibration formats, etc.

On a case-by-case basic, the capability can be provided for the
acquisition and storage of other data streams to be processed that
either:

1\. Do not meet the EHS TLM format standard (where some
adaptation/expansion of the EHS TLM standard is required).

2\. LAN data received that is not in the EHS/UDP protocol (using
spacecraft unique front-end processing software on the TLM server).

3\. Non-standard serial clock and data RS-422 streams (using spacecraft
unique front-end processing software on the TLM server)

Storage

Telemetry data to be stored within the EHS can be setup as either a
TEMPORARY ARCHIVE and/or a PERMANENT ARCHIVE (DEGREE of PERMANENCE)
depending upon the needs of the program/project supported and the
specific operational support requirements.

It also obviously functions as an ACTIVE ARCHIVE due to the realtime
support nature of the system with a DIVERSITY OF COLLECTION typically
associated with a NON-INSTITUTIONAL PROJECT system.

For instance, EHS users such as AXAF will have all mission data
permanently archived for the life of the program; whereas ISS
simulation/test data will only be temporarily stored until some time
after the simulation/test activity is completed and a decision is made
to delete the data.

Capabilities are provided to an operator for: the setup of the data to
be stored; the manual deletion/removal of unwanted data after it is no
longer needed; and the automated deletion/removal of the oldest data
stored in the system (first in/first deleted round robin mechanism).

All data stored in the subsystem is in basically a raw (unprocessed)
format (i.e raw CCSDS Version 1 packets, frame-aligned and data quality
checked TDM major/minor frames, and/or 4800-BB messages) encapsulated in
the EHS protocol with it's associated data quality information. The
mission Telemetry Data Base (TDB) (which contains the reference
decommutation, conversion, and calibration information) is also stored
and available for retrieval/processing activities to allow access to
this raw data. As a result the DIGITAL INFORMATION PRESERVATION LEVEL is
INFORMATION PRESERVING. In the event of errors in the TDB, the TDB can
be replaced to correct the error and make the data retrievable by the
user.

Data is stored to a hierarchical mass storage sub-system (consisting of
both high-speed hard disks arrays (for cache) and one or more optical
jukeboxes with multiple read/write heads) on the TLM Server. The TLM
data is stored raw in binary files using the standard UNIX file system
mechanisms. All telemetry data is indexed/retrievable by Ground Receipt
Time (GRT), event Greenwich Mean Time (ex. simulation GMT), and/or
embedded spacecraft stream time.

The capability is provided for the operational removal and off-line
storage of optical platters from the system when/if the online capacity
is exceeded for a support activity (such as mission support) and there
is a project desire to retain the data. This data can be reloaded if
needed for retrieval of telemetry data.

In addition the capability is provided for the storage of Processed Data
that has been generated by the TLM server processing the Spacecraft
telemetry data as it is being received. This data is typically referred
to as Pseudo-TLM data. This data is also stored as CCSDS Version 1
packets and the retrieval/indexing of this data is identical to raw
CCSDS Version 1 Packet TLM data as mentioned previously.

Data Management

Architecturally, the EHS system components that provide for storage and
retrieval of the Telemetry data include the following:

1\. TLM Servers - One or more telemetry servers are provided for the
storage of Spacecraft data. TLM Servers are currently Silicon Graphics
Inc (SGI) Challenge L and/or XL class platforms. These servers are
scaleable from 2 to 32 CPU's. However the current TLM Servers to support
AXAF and ISS for mission support are only outfitted with 2 CPU's, 256 MB
memory, and a 40 GB disk cache. Therefore, the system architecture has
significant growth potential on each server (up to and exceeding a order
of magnitude in disk, memory, and CPU). Two TLM servers can work in
tandem for concurrent data receipt/storage if the spacecraft
availability/ reliability numbers necessitate a very high reliability
(ex. 99.99% to 99.999%). Each telemetry server currently supports up to
one spacecraft and one operational support mode (ex on-orbit operations)
concurrently. Multiple TLM servers can be used to support more than one
spacecraft and operational support activity simultaneously.

2\. Optical Jukeboxes - Optical Jukeboxes (from Vanguard Inc) are
provided on each TLM server. These Jukeboxes are OEM'd from various
manufacturers including Hewlett Packard, DISC, etc. With the hardware is
the AMASS Hierarchical storage software which allows the hard disk cache
subsystem and optical jukeboxes to function as a single logical UNIX
file system. Current capacities for ISS and AXAF optical jukeboxes range
from 187 GB to 650 GB; however from Vanguard optical jukebox systems can
be purchased in excess of 1.2 TB each, with multiple jukeboxes able to
be logically grouped together as a single UNIX file volume of a much
greater capacity. \[I have to check on this relative to Vanguard current
capabilities and SGI OS limits. We obviously have not tested our system
to these upper limits\]. These Optical Jukeboxes typically use
Magneto-Optical drives and media due to the rewrite nature of the media
and the higher sustained throughput rates; although other media/drives
are available from Vanguard.

3\. RS-422 Data Acquisition Interfaces - On the TLM servers are RS-422
serial clock and data interfaces from AVTEC Inc. These intelligent
devices provide for the frame synchronization, major/minor frame
alignment, and data quality scoring of received TDM and NASCOM 4800-BB
data using the onboard processor of the AVTEC board. Data is direct
memory access (DMA) transferred to the SGI server from the AVTEC. Each
AVTEC device has a raw capability for data acquisition of up to 11 Mbps
(which has been tested on the EHS SGI platforms). Multiple AVTEC boards
can be configured on each TLM server up to the hardware physical slot
limits of the SGI platform (currently up to 14 boards on an XL and up to
4 boards on an L class server respectively).

4\. Data Base (DB) Server - A Prime and Backup SGI server (Challenge L
class) is used to store the mission telemetry data base information. All
mission databases for all supported projects and support activities are
stored on the Primary DB Server and are available for use in the
retrieval of telemetry data from the TLM server. In case of a failure
the Backup DB server will mount a cross-strapped RAID disk drive
subsystem and continue to provide support for operations.

5\. System Monitor and Control (SMAC) Server and Workstations - A Prime
and Backup SGI server (Challenge L Class) and multiple SGI workstations
at operator consoles are used to control and monitor the TLM server, DB
server, and all the other components of the EHS architecture.

6\. Network Interfaces - As currently defined the EHS servers and
workstations are connected using Fiber Distributed Data Interface (FDDI)
network technology which provides for single fault tolerant network
operations. Other network technologies can be used if necessary.

The EHS architectually is defned as a PHYSICALLY DISTRIBUTED,
CENTRALIZED ADMISTRATION/MANAGEMENT configuration.

Administrative

Development of the core EHS design is supported through the funding of
the ISS and AXAF programs. Operationally the ISS program will provide
funding for the EHS systems operations and sustaining engineering
activities within the HOSC as part of the ISS Payload Operations
Integration Center (POIC). The AXAF program shall provide funding for
the operations and sustaining engineering of the EHS systems at the AXAF
OCC in Boston, MA.

Other EHS systems at LeRC, KSC, etc. will be funded for operations by
their sponsoring organizations (ie. ISS).

Configuration management (CM) of the EHS systems and software is
currently maintained by the HOSC contractor (Lockheed-Martin) as part of
the Utilization Mission Support (UMS) contract. This CM system provides
for the controlled release of application software and configuration
files to the production operational environment servers/workstations.

Additionally, the UMS contractor provides for the configuration
management of the mission telemetry databases used by the EHS systems.
Contractor developed application software is provide for the receipt and
conversion of spacecraft unique telemetry databases into the EHS-unique
telemetry database needed to support the EHS NRT system.

Access

User access to the EHS NRT systems is typically provided through a
graphical user interface (GUI) based upon the X-windows standard. This
GUI allows local and/or remote users to log into EHS workstations within
the host facility from which data can be selected for retrieval.
Follow-on activities are in works to determine if a WEB browser based
GUI will also be provided as a long-term remote user interface solution.
Additionally, an application program interface (API) is also provided
for the retrieval of data from the TLM servers.

From the GUI and API the capability is provided for a user/system to
request and retrieve the desired data. Within the design of the EHS the
DEGREE OF OPAQUENESS is identified as COMPLETELY OPAQUE TO THE ACCESS
FUNCTION. Three type of retrieval mechanisms are provided for user
access:

1\. NRT List Request - which allows a user to request for a given time
period a user defined set of telemetry measurements desired. The output
is provided by the system as a tab-delimited ASCII file containing the
time-ordered data. User selection criteria for the report includes:

• Selection of raw, converted, and or calibrated measurement data
processing

• Retrieval by ground receipt or onboard embedded time

• Selection of the output data representation (ex. decimal, hexadecimal,
octal, scientific notation, ASCII, time, etc.)

• Selection of any necessary data filter criteria (including
minimum/maximum/average, \<, \>, \<=, \>=, =, \<\>, \< or \>, \> and \<,
compressed, delta, etc.)

• Selection of the data sample rate per measurement (1 sample or all
samples)

• Selection of data quality indicator outputs to correspond to the
report data (ex. to indicate valid data, out of limits caution/warning
high, out of limits caution/warning low, etc.)

• Selection of the data modes desired (realtime, dump, and/or playback,
etc.)

• Desired output file name

2\. NRT Data Capture Request - which allows a user to request a specific
data stream (TDM, CCSDS packet, NASCOM 4800-BB, etc) over a user-desired
time period. The data is output as a single binary data file containing
the time-ordered raw data (encapsulated within the EHS protocol). User
selection criteria for the output file includes:

• Selection of the specific data stream desired

• Retrieval by ground receipt or onboard embedded time

• Selection of the data modes desired (realtime, dump, and/or playback,
etc.)

• Desired output file name

3\. NRT Snapshot Request - which allows a user to request a snapshot of
all telemetry measurements in the data base for a specific time instance
for a specific data stream. The data is output as a tab-delimited ASCII
file containing the desired data. User selection criteria for the report
includes:

• Selection of raw, converted, and or calibrated measurement data
processing

• Retrieval by ground receipt or onboard embedded time

• Selection of the output data representation (ex. decimal, hexadecimal,
octal, binary)

• Selection of the specific data stream desired

• Desired output file name

Additional user interfaces are provided to support the user in accessing
the telemetry information and performing normal operational activities
including:

1\. A user interface for the generation, saving, and retrieval of the
input data forms used for the NRT List Request, NRT Data Capture
Request, and NRT Snapshot Request operations.

2\. A directory listing of the telemetry data which is available in the
NRT system.

3\. Access to the telemetry data base to query/view the decommutation,
conversion, calibration, and limit sensing information related to the
telemetry items.

4\. A user interface to import the NRT List Request and NRT Snapshot
Request data outputs files into a UNIX EHS workstation spreadsheet
package for viewing, plotting, analysis, and printing \[DISSEMINATION
METHOD of NON-ELECTRONICALLY READABLE MEDIA\] of the data by the user.
The user can create any necessary macros within the spreadsheet package
to automate the processing of the input data.

5\. A user interface to allow for the transfer of the output user data
files generated using the Internet standard ftp protocol \[DISSEMINATION
METHOD of ELECTRONIC TRANSMISSION\]

The EHS provides the capability to output the resultant data files to
another system using the ftp protocol \[DISSEMINATION METHOD of
ELECTRONIC TRANSMISSION\]. On this system the user can:

1\. Analyze the NRT List Request and NRT Snapshot Request files using a
standard spreadsheet package (such as Excel, etc.) since the data file
is of a tab-delimited ASCII nature.

2\. Analyze a NRT Data Capture Request output using user developed
software, etc.

Finally, the capability is provided to playback data out of the NRT
system via the LAN interface. The output will be one or more data
streams (CCSDS packets, TDM data, NASCOM 4800-BB data) encapsulated
within the UDP/EHS protocol. This data can be made available to other
EHS workstations/servers or to user provided data systems
\[DISSEMINATION METHOD of ELECTRONIC TRANSMISSION\].

Appendix C

Current System Description:

Operational Data Reduction Complex (ODRC) (Johnson Space Center)

Facility Summary

The primary function of the Operational Data Reduction Complex (ODRC) is
to provide for archival and retrieval of Core Systems Data for Shuttle.
For the International Space Station (ISS) ODRC will archive both Core
System Data downlinked data and also uplinked commands.

ODRC provides both temporary and permanent archival of data. Most
mission data is permanently archived. Main Engine data is temporally
archived. Modular Auxiliary Data System (MADS) data from onboard
recorders is archived after landing. Voice and video data are not
archived by ODRC. Test and sim data are not generally permanently
archived.

Some payload or scientific data is archived but in general this data is
not archived by ODRC. Any data temporally archived by ODRC can be
permanently archived if requested. (See the tables in Response section
below. Currently ODRC has archived approximately 1.4 terabytes of
Shuttle data dating back to STS-1.

Ingestion

The vast majority of the data archived is Shuttle core telemetry
(mission and sim) that is processed by the Mission Control Center (MCC)
Front End Processor (FEP) and is available on the MCC common LAN along
with a large amount of other data. ODRC records only selected data
streams from the MCC common LAN. This is expected to be true of ISS data
also. Other archived data comes in over dedicated circuits.

The maximum data rate required for ingest is One (1) MBPS. This could
consist of the following three data streams - Shuttle in orbit, Shuttle
launch sim and ISS in orbit.

Shuttle in orbit

-   Realtime data

-   OI Operational Instrumentation

-   GPC General Purpose Computer

-   PDI Payload Data Interleaver

-   Dump data

-   OI

-   GPC

-   PDI

Shuttle launch sim

-   OI

-   GPC

-   PDI

ISS in orbit

-   USOS core telemetry

-   CMD History

-   CMD Status and uplink logs

-   ICM (Interim Control Module) Streams

-   OIU while Shuttle is docked

-   After Flight 5A there may be dump data (i. e., Zone of Exclusion
    (ZOE) data)

Other data will be recorded but usually not at same time.

Test data such as Shuttle Avionics Integration Laboratory (SAIL).

Privileged users may use ODRC to temporally (or permanently) store their
data. ODRC does not process this data but will retrieve it via name and
transmit it to the requester. This data is stored as a file or Binary
Large OBject (BLOB).

Storage

Data is stored in the as received format. The major indices is time
(GMT).

The ODRC system uses magnetic disk, tape cartridges and optical disks
for data storage.

Retrieval

Users use MEWS (Mission Evaluation Workstation Software) to request
data. Data can also be requested via the Internet if the IA (Interface
Agreement) is followed.

For Shuttle there are approximately 1,200 external users and 200
internal (i.e., MCC) users. ISS is expected to add to there number but
not to double them.

Security

ODRC is a Level II system. It is a tightly controlled Level II. A user
cannot upload or change any mission data. A user cannot upload any
software to ODRC. Users can submit a request for data and ODRC will
process the request and transmit the data to the requester. The request
is in a predefined format.

Some data, presently on a Measurement/Stimuli IDentification (MSID)
specific bases, is "protected" in that can be retrieved from only
specific locations. Currently this is medical data but that is an
administrative decision.

An anticipated requirement for ISS is that some data (such as the
Russian FGB) will be restricted to only a specific partner (i.e.
Russia). This will probably be by data stream instead of by Parameter
Unique Identifier (PUIs).

Recon

The recon data associated with the telemetry is also archived. This
includes the calibration as well as the decom information.

Some data is recorded as a BLOB. The recon for this type of data is
generally not archived by ODRC.

Response

ODRC is not "flight critical" which would require backup equipment,
however, it is "highly desirable". Which in practical terms means that
it will meet (or exceed) the RMA (Reliability, Maintainability,
Availability) requirements or the flight controllers (and management)
become very critical.

ODRC mission data is used for Near Real Time (NRT) flight control
decisions. The Level B Requirements are that realtime data is available
to the users within 5 minutes of being received by ODRC. The reality is
that the data is usually available almost immediately. This is more a
"quality of life" for the flight control team in that it makes their job
easier.

There are provision for prioritization of data retrieval based on user
and size of request.

  ----------------------- ----------------------- -----------------------
  DEFINITIONS FOR CLASSES                         
  OF ARCHIVED DATA                                

  DATA CLASS              SHUTTLE                 STATION

  CURRENT                 28 Days of mission      Current plus 15 days of
                          data. Current mission   data. (Ref. 5.1.2.1)
                          plus launch and landing 
                          of current vehicle's    
                          previous mission. (Ref. 
                          3.4.3.1)                

  ARCHIVED (ON-LINE)      On-line optical data    Data older than 15 days
                          storage. One hundred    but less than one year.
                          platters of mission     (Ref. 5.1.2.1)
                          data (1.2 Terrabytes of 
                          available online        
                          storage). (Ref.         
                          3.4.3.2)                

  ARCHIVED (OFF-LINE)     Platters of mission     Data older than one
                          data not currently      year to the life of the
                          loaded in optical       program. (Ref. 5.1.2.1)
                          storage.                
  ----------------------- ----------------------- -----------------------

  ------------- ----------- ------------- ----------- ------------ ------------
  PERFORMANCE                                                      
  FOR CLASSES                                                      
  OF ARCHIVED                                                      
  DATA                                                             

                SHUTTLE                   STATION                  

  DATA CLASS    AVAILABLE   RESPONSE      AVAILABLE   RESPONSE     CAPACITY

  CURRENT       ≤ 5 Min.    ≤ 30 Min      ≤ 5 Min.    ≤ 5 Min.     120
                after       after data is after       after data   Benchmarks
                receipt of  available for receipt of  is available per hour
                last data   a single      last data   for a single 
                element.\   benchmark.\   element.\   benchmark    
                (Ref 3.7.1) (Ref 3.7.1)   (Ref.                    
                                          5.2.1.1)                 

  ARCHIVED      Upon        ≤ 4 Hrs.      Upon        ≤ 30 Min.    For a single
  (ON-LINE)     request.                  Request\    after        request
                                          (Ref.       receipt of   
                                          5.2.1.1)    request      

  ARCHIVED      Upon        None          Upon        ≤ 24 Hrs.    For a single
  (OFF-LINE)    request.    specified.    Request     after        request
                            Requires an   Requires an receipt of   
                            operator to   operator to request      
                            mount a       mount a                  
                            platter.      platter.                 
  ------------- ----------- ------------- ----------- ------------ ------------

**1 SHUTTLE BENCHMARK =** 8.5 minutes of data at 3 samples/second for
200 MSIDs

**1 SPACE STATION BENCHMARK =** 30 minues of data at 1 sample/second for
40 PUIs

Ref. is SOC-RQ-603785 Operational Data Reduction Complex (ODRC) Upgrade
document

National Treasure

The US manned space flight data is designated as a National Treasure and
is therefore redundantly backed up. The over all system is 2 fault
tolerant, i.e. it will require 3 specific failures to totally lose a
piece of data. This is not to say that the recovery from a 2 failure is
a standard feature, it will require some work by competent personnel.

This is not an inherent part of the archival system but it is not
precluded and in fact it is facilitated by the design.

Computations

ODRC performs a number of computations (comps) upon request. When making
a comparison with other archival systems the comp cost and/or ksloc
should be removed or accounted for.

The comp function can be removed from ODRC and run in a separate server.
There were cost and operational savings to consolidating comps in ODRC.

Appendix D

Current System Description:

Data Distribution Facility (DDF) (Goddard Space Flight Center)

Facility Summary

The Data Distribution Facility provides long term storage and data
distribution via electronic form or physical media for Earth Science and
space science projects, including ISTP, HST, XTE, TRMM, and SOHO.
Agreements are made with projects for the types of products and their
frequency of distribution. As data are received, they are compared with
the known product types and other project criteria, and when all
criteria are satisfied the data are sent via network or media to the
identified customers. Multiple versions of the data are handled and data
are retained as long as the project provides funding.

Ingest

Types of submission information packages (telemetry sources) and rates

All data are received as a set of files together with an SFDU labeled
Data Availability Notice (DAN) file. The files may be in any format,
including a collection of packets or a standard format such as CDF. They
are primarily retrieved, by the DDF, via network, but may also come on
media as a backup. The primary data sources, currently, are ISTP CDHF
and Pacor II.

Metadata or ancilliary data sources

MOUs, meetings, and e-mail provide information on the definition of
product types and desired frequency of receipt. Customer account
information is also received this way.

Information modeling techniques and processing

Information is extracted from the DAN to populate the database tables
describing what is available. This includes name of mission, instrument,
and start/stop times of associated data files.

Ingest staging storage: 148 GB on-line used for staging on ingest.

Quality quantity and continuity (QQC) procedures

Data files are checked only to see if the appropriate number of bytes
are received. The DAN is checked for conformance to required format and
content.

Replay capability, frame synchronization, decommutation procedures

If the number of bytes is wrong, DDF will pull the files from the source
again. If there is still a problem, the source is notified. Pacor II
retains data for three days.

New versions are frequently made available by a source, and these
versions are retained by the DDF as long as the project provides support
or other funding is made available.

Throughput rates

TBD

Storage

Local storage formats (logical and physical)

Data files are stored in the format they were provided. Some of these
are SFDU labeled files.

The DAN file is not permanently stored as its information goes into the
database.

System storage procedures (packets stored by time, flat files of
parameter values, etc)

Files are stored as flat files, organized by mission. Organization of
files within mission is under storage system control and is not
controlled directly by DDF operations.

Current archive size

Long-term storage is 2.7 TB

Storage hardware and capacity (on-line, near-line, off-line)

Near-online storage: \~ 1 TB optical disk jukebox (SUN/Vanguard system).
Older Filetek optical disk system (810 GB in VAX Cluster) and VHS tape
storage system (48 GB) to be decommissioned this fall

Offline storage: Currently 1.5 TB on shelf as optical disks and VHF
tapes. Will eventually only be Vanguard re-writable optical platters
each holding 2.2 GB.

Retention periods

Customer negotiated up to life of mission or indefinitely beyond.

Data Management (supporting both metadata storage and system
information)

DBMS software

Oracle RDBMS used for holding the DAN information, consumer information,
and product definitions

Custom tools

SQL scripts, embedded SQL routines

Server hardware

SUN Workstation

Administration

System organization and architecture

Client Server architecture involving Vanguard Jukebox, about 10 SUNs,
VAX cluster composed of two 6410s, and 5 PCs. The jukebox and SUNs are
on a FDDI ring. There is also ethernet usage and internet connectivity.

Personnel

30 FTEs

Budget (development, operations, administration)

Development: 15 FTEs

Operations and maintenance: 13 FTEs

Administration: 2 FTEs

System documentation

-   User's Guide

-   Operator's Guide

-   Database Guide

-   Design Documentation

-   Requirements Documentation

Configuration management tools

PVCS (a COTS package) to manage software versions

System maintenance procedures.

Normal general system administration procedures such as backups; user
account updates; disk partition updates; porting software to new
systems; replacing hardware; upgrading of operating systems

Access

User community

-   Projects: ISTP, HST, XTE, TRMM, SOHO

-   PI's and their CO-I's

-   International access

-   The number of customer accounts is over 100

Usage scenario

For users not known to system: PI interacts with project which then
authorizes access. PI then makes requests online.

For users known to system: PI makes requests online for regular or for
one-time data requests. Users are notified when their products are
available for electronic data pull. Data can also be sent via media.
Sometimes users claim they did not receive data that was sent and the
data may need to be pulled from storage and sent/made available again.

Types of requests

Standing orders - set of products, frequence of delivery, and delivery
method

Special requests - send again, or send it to me early, etc.

User interface

Operators: GUI interface

PI's: WEB, GUI, e-mail interface

Analysis capabilities

None provided to customers

Dissemination

Order handling procedures

A check is made of the DAN and the database to determine if a product is
ready for delivery

For special requests, the database is updated with the type of product
requested and then handling procedes as for standing orders

Data delivery procedures

For media delievery, a CD-ROM is prepared and sent to the Tape Staging
and Storage Facility for mailing

For electronic delivery, a notice is sent to the customers that their
data are ready (or do you also push it to them, Jeannine?) for pickup
via FTP.

Product types

Electronic data distribution: files with a new DAN file are provided;
Approximately xxx file/year are distributed

Media data distribution (CD-ROM, 8mm \...): files with a new DAN file
are provided; Approximately 100,000 CD-ROMs/year are provided.

Archive Classifications

1\. Acknowledged degree of permanence:

Data files could be permanent or not, depending on project requirements

2\. Digital Information preservation level:

Data files are understood as bits only; The DAN information is fully
understood by the DDF.

3\. Degree of opaqueness of AIP

Data files are opaque

4\. Dissemination methods

Electronically readable media (CD-ROMs, 8mm)

Electronic transmission (Internet)

5\. Active vs Final Archive

Active archive because new versions of files are received, stored, and
disseminated.

6\. Diversity of Collection

Multi-discipline within the space domain

7\. Institutional vs Non-Institutional archive:

Institutional - supported by NASA to serve NASA customers

8\. Archival storage types

Digital: Information archived is in digital forms

9\. Distributed vs Centralized

Physically distributed (local networks), centralized
administration/management

Appendix E

Current System Description:

ISTP Central Data Handling Facility (Goddard Space Flight Center)

Facility Summary

The CDHF ingests level zero data for several ISTP missions (Geotail,
Wind, Polar, IMP-8 and SOHO) from the Data Capture Facility (DCF) (all
but SOHO, IMP-8, and Polar PWI data), from the Data Distribution
Facility (DDF) (IMP-8, Polar PWI) and from Pacor II (SOHO non-image
data - i.e. fields and particles). It also ingests other data products
needed in support of these missions. All the observation data are
organized by 'instrument' and put online for access by authorized ISTP
CDHF users. They are also sent to the DDF for archiving (a function to
be done in-house in the future) and for distribution via CD-ROM. The
CDHF also takes algorithms, provided by the PIs, and turns the
level-zero data into Key Parameter (KP) files with additional metadata.
These are also put online and provided to the DDF for CD-ROM
distribution to the investigators and their colleagues. Related data
products, including externally generated KP data from international
ground stations and other facilities are received. Spin phase and Polar
Platform despun attitude data are computed by the CDHF. These data,
including Command History, Level Zero quality data, and Orbit/Attitude
data are made available via network and CD-ROM. Officially this data is
retained for no more than 90 days and the archival services of the DDF
are used for longer term storage, but in practice some data is retained
much longer and in the future up to three years will be maintained
online within the CDHF. Data are also sent to NSSDC for permanent
archiving.

As an additional service, real time passes of Wind and Polar data are
decommutated for rapid distribution to NOAA and the Air Force to provide
real time monitoring. Also, some KP data are provided in near real time
(within a few minutes) for coordination of Rocket and Balloon launches
with optimum conditions. Finally, the CDHF supports some Inter-agency
Consultative Group (IACG) campaigns via special CD-ROM distributions.

Organizationally the CDHF is a part of the ISTP program in the Orbiting
Satellites Project (OSP) office under the Space Science Data Operations
Office (code 630).

Ingest

Types of submission information packages (telemetry sources) and rates

Level Zero data in Exchange Data Units (EDUs) are provided via BFX over
NASCOM network by the DCF (Geotail, Wind, Polar Level 0, Geotail
SIRIUS). These EDUs are CCSDS/ISO 12175 (SFDU) conforming packages which
contain two data objects. The first data object contains data management
attributes such as mission, instrument, and start/stop times. The second
data object contains the associated Level Zero data. The EDU
implementation option of using detached labels is employed for the
second data object resulting in a two-file EDU where the second file
only contains the Level Zero data. The format of this Level Zero data
object provides instrument data that is time indexed, quality assured,
byte counted, and organized by instrument type.

Level Zero IMP-8 and Polar PWI wideband data in EDUs are provided via
BFX over NASCOM network by the IMP 8 Unisys system and the Data Capture
Facility (PWI) through the DDF.

Level Zero SOHO particles/fields (non-image) data in EDUs are provided
via TCP/IP over NASCOM network from Pacor II via the DDF .

Externally generated Key Parameter data files in Common Data Format
(CDF) with ISTP conventions are provided in EDUs via Internet/NSI from
various external organizations.

Quick look Level Zero data in EDUs containing the first hour of a pass
are provided by the DCF within one or two hours of the end of a pass and
it is put online. Normally the investigators would have access to this
data oinly after 24 to 48 hours after the pass was taken.

Near Real Time (NRT) data as raw telemetry is received from the DCF, is
decommutated into Level Zero data, and is made available electronically
to investigators during RT spacecraft passes. It is also used by the
CDHF to produce KPs. The NRT KP CDF data is transferred to NOAA/AF and
is also available in support of rockets and balloons. The NRT KP data is
available via a Web browser
(http://www-istp.gsfc.nasa.gov/istp/whatsnew.html).

Metadata or ancilliary data sources

Orbit/Attitude files in CDF format from Flight Dynamics provided via
Internet/Center Network Environment (CNE) network

Orbit/Attitude files in CDF format from Japan provided via Internet/CNE
network

Housekeeping and Quality information in CDF format from DCF provided via
BFX network

Command history files in CDF format from Command Management System
provided via Internet/CNE network

Algorithms in software for VAX/VMS provided by PIs via Internet/CNE
network

(note: Internet could be commercial ISPs or the NASA Science Internet)

Information modeling techniques and processing

Each received (or converted) data file is associated with an attribute
object giving important management and access information such as
project names, spacecraft, and start/stop times. SFDU packaging is used
to create a 2 file logical (and detachable) unit for storage, management
and distribution. Such units are called Exchange Data Units (EDUs).

PI supplied algorithms are tested and moved into the production
processing

Level Zero data files are converted, using PI supplied algorithms, into
Key Parameter CDFs with ISTP conventions.

Quality quantity and continuity (QQC) procedures

Check for SFDU/EDU packaging

Check times for continuity and monotonicity

Replay capability, frame synchronization, decommutation procedures

Can ask JPL Deep Space Network (DSN) to replay through DCF or Pacor II
if data is not more that 30 days old.

Near real time KP data for NOAA and Air Force is decommutated from TLM
data into Level Zero form and then into KP form.

Throughput rates.

About 2 Gigabytes per day ingest rate (more detailed information
available)

Storage

Local storage formats (logical and physical)

SFDU/EDU packaged units consisting of two files, where one file starts
the SFDU package and includes the attributes associated with the second
file. The second file may be in CDF (key parameter file) or various
Level Zero formats.

Files are stored under a directory structure in VAX/VMS as binary files.

System storage procedures

EDU packages are stored by time under a directory structure reflecting
the spacecraft, instrument, and the time period covered.

Current archive size

300 Gigabytes, with the rest stored by the DDF

storage hardware and capacity (on-line, near-line, off-line)

300 Gigabytes online using Storage Works disks

Planning is for a Mass Storage Tower adding 1 Terabyte online with its
own management system

Retention periods

Level Zero - 7 days officially in CDHF but longer term in the DDF

Key parameter - 90 days officially in CDHF but typically 1.5 year
(except for image data which is kept for only 3 days because of its
large volume)

Ancillary data - 90 days officially, but typically 1 year

NRT data - 3 days

Data Management

DBMS software

Oracle database supporting storage as well as user access and other
administrative information

Custom tools

unknown

Server hardware

ALPHA

Administration

System organization and architecture

Inputs arrive onto an ISTP FDDI LAN and are accessed via two VAX
6000-410s. A DEChub with an internal FDDI links the VAX 6000s with
several DEC 3000s, two VAX 2100s and the two Storage Works devices. A
star coupler links the VAX 6000s with two HSC 79s supporting 9-track and
8-mm tape devices and the RA 73 storage device. In addition, two VAX
4000s tap into the ISTP LAN FDDI to provide near real time KPs while an
additional two are used for development. All the VAX's are also
connected via ethernet and this provides access to the NASA Science
Internet and GSFC networks. All the major platforms are paired to
provide redundancy and increase up-time.

Re-engineering effort plans to incorporate DDF functionality with NFS
mounting

Personnel

30 FTEs, possibly going to about 19 FTEs

Budget (development, operations, administration) \[may be sensitive
issue\]

(No information expected)

System documentation

-   CDR generated PDL like diagrams

-   Data Format Control Document

-   KPGS programmers guide - specifices a set of available system
    resource calls

-   User's guide to CDHF - Oracle forms described (WEB on the way)

-   CDHF Operator's Guide

-   Key Parameter Integration and Test Guide

Configuration management tools

Separation of Operations environment from Development environment and
Integration and Test environment (no specific tools identified)

System maintenance procedures

Reflects demonstration, test, and operations environments

Access

User community

PI's and their CO-I's and support people world wide, numbering about 200

About 35 investigations

Usage scenario

Standing requests - push the data to their site as it becomes available

Level zero, Key Parameters, and Ancillary are data online for access via
FTP until it is replaced by later data.

Reprocessing requests from PI's come via e-mail, but needs approval

Algorithms are provided by PI's who eventually promote them into the
operational system with the assistance of the CDHF Key Parameter
Integration Test Team

Specific user's can input 'quality flags' to be associated at
granularity of one day's worth of data and these are added to the Oracle
database

Specific user's must certify when data is ready to be sent to the DDF
for distribution via CD-ROMs.

Types of requests

Standing orders, delayed deliveries, and Ad Hoc FTP supported

User interface

Access restricted via name and password

Command line interface, but moving toward WEB interface

Analysis capabilities

PI provided algorithms for generating Key Parameter CDFs

Dissemination

Order handling procedures

Some standing orders require data to be pushed to an investigator\'s
site - e.g, every 24 hours. However, data can also be picked up when
they are online.

Data can be requested, which sends a request to the DDF who returns the
data to the CDHF.

Data delivery procedures

via postal mailing of CD-ROMs and electronic file transfers

Product types

Level Zero data on ISO-9660 CD-ROM (using the DDF) and via FTP Internet
networks

Key Parameter CDFs on ISO-9660 CD-ROM (using the DDF) and via FTP
Internet network

Quick look Level Zero data via FTP Internet network

Archive Classifications

1\. Acknowledged degree of permanence:

Temporary Archive handling 'permanent' information

2\. Digital Information preservation level:

level zero data understood as bits only, but some providence information
provided (instrument, time period covered, quality flags)

Key Parameter data understood as CDF format with some standard
attributes identified as defined in the ISTP conventions document.

CD-ROMs have a running index which lists all previous data packages by
instrument, data type, and time coverage

3\. Degree of opaqueness of AIP

Objects are completely opaque to the access function. Further processing
is done at the remote user sites.

4\. Dissemination methods

Traditionally, archives have delivered ordered products on media (paper,
magnetic tapes, CD-ROM, FTP sessions). With the growth of communications
bandwidth and Internet technologies there is a trend towards making
archive access and dissemination seem like a single interactive process.
This view can change the underlying architecture of the archive and
severely restrict the maximum size of DIPs.

Electronically readable media (CD-ROMs)

Electronic transmission (Internet)

5\. Active vs Final Archive

Active archive - involves production flows and reprocessing

6\. Diversity of Collection

Several Project Archive (Geotail, Wind, Polar, some SOHO), but is not
designed to be discipline wide support

7\. Institutional vs Non-Institutional archive:

Institutional- done for NASA organization with their support

8\. Archival storage types

Classification criteria:

Digital: Information archived is in digital forms

9\. Distributed vs Centralized

Physically distributed (local networks), centralized
administration/management