nasa conference ublication 2196 officeofspaceand ...nasa conference publication 2196...
TRANSCRIPT
NASA Conference Publication 2196
OfficeofSpaceandTerrestrialApplications
(OSTA)/ApplicationsDataService[ADS)
DataSystemsStandards
NASA-CP-2196 19820007222 ] r ]_,] l_]f
_- -* ,- ,:i. " _..:-":.: " ":.. ...... ...-"--.-, LANGLEY RESEARCH CE,"4TE_"" '-'--_ LIBRARY., NASA
= __ H-_._,_PI-O 1"/,VIRGINIA.
Proceedings of a workshop held atGoddard Space Flight Center
Greenbelt, MarylandMay 27-29, 1981
NI_A
https://ntrs.nasa.gov/search.jsp?R=19820007222 2020-05-29T11:25:33+00:00Z
NASA Conference Publication 2196
OfficeofSpaceandTerrestrialApplications
(OSTA)/ApplicationsDataService(ADS)
DataSystemsStandards
Barbara A. Walton, EditorGoddard Space Flight Center
Greenbelt, Maryland
Proceedings of a workshop held atGoddard Space Flight Center
Greenbelt, MarylandMay 27-29, 1981
N_ANational Aeronautics
and Space Administration
ScientificandTechnicalInformation Branch
1981
CONTENTS
Page
Summa_j of Workshop Conclus!oL_s .................... vii
Workshop Summary ........................... S-I
1.0 Introduction ........................... I
2.0 Welcome
Paul Schneck ......................... I
3.0 Introduction to the WorkshopBarbara Walton ........................ I
4.0 OSTA Data Systems Planning Workshop RecommendationsRichard desJardins ...................... 5
5.0 The Role of Pilots
J. Patrick Gary ........................ II
6.0 The OSTA/ADS Standards Development ProcessBarbara Walton ........................ 19
7.0 Overview of the Current MITRE Effort
Terry Kuch/Rick Sakamo6o ................... 27
8.0 User Requirements for ADS Standards and Guidelines
Paul Clemens ............... ( .......... 30
9.0 ADS Pilot Methodologies as Candidates for ADS Standards
Paul Giragosian ....................... 32
I0.0 Panel Activities ......................... 35
II.0 Panel A Report: Standards Needed to Interconnect ADS Pilots for
Data Sharing for Catalogs, Directories, and Dictionaries . . 38
12.0 Panel B Report: Standards Needed to Intercon6ect ADS Pilots for
Data Sharing for User Interfaces ............... 45
13.0 Panel C Report: Standards Needed for the Use of ISO Open SystemsInterconnection - Basic Reference Model ......... . . . 55
14.0 Panel D Report: Standards Needed to Interconnect ADS Pilots for
Data Sharing in Data Formats and Descriptions . . . ...... 67
15.0 Workshop SummaryBarbara Walton ......................... 71
16.0 Action Items
John Kiebler ....... . ................. 71
iii
CONTENTS (continued)
Page
Glossary of Terms ................ ............ 73
Appendix A - Overview of the Current MITRE EffortPresentation Material ................... A-I
Appendix B - User Requirements for ADS StandardsPresentation Material ................... B-I
Appendix C - ADS Pilot Methodologies as Candidates for ADS StandardsPresentation Material ................... C-I
Appendix D - List of Reference Materials ................. D-I
Appendix E - Unpublished Preworkshop DocumentationInvitation E 1leeIIQoeiGeeQeQoe.iQe. IQ. m
Preworkshop Documentation Memo ............... E-3
Instructions to Panels ..... ........... . . . E-5
Appendix F - List of Attendees . ................ F-I
iv
LIST OF ILLUSTRATIONS
Figure Page
3-1 Objectives of the OSTA/ADS Data Systems Standards
Workshop ........................... 4
4-1 OSTA Data Systems Planning Workshop .............. 6
4-2 Integrated Discipline Requirements .............. 7
4-3 OSTA Data System Concept ................... 9
4-4 OSTA Overall Data System Concept and Recommendations ..... i0
5-1 Summary of Overall ADS Program ................ 12
5-2 Common Goals/Objectives of OSTA/ADS Pilots . . ....... 13
5-3 Promotion of ADS Concepts through Pilot Data SystemsActivities ......................... 14
5-4 Near-Term ADS Requirements ..... ............. 15
5-5 Relationship of OSTA/ADS Pilots to the Standards
Development Process .................... 16
5-6 ADS Program Review ........ • 18
6-1 OSTA/ADS Data Systems Standards and Guidelines ProgramOverview .......................... 20
6-2 OSTA Data and Data Systems Standards Requirements ........ 21
6-3 OSTA/ADS Data Systems Standards Program Working
Relationships ....................... 22
6-4 Approach to OSTA/ADS Data Systems Standards Program ...... 23
6-5 OSTA/ADS Data Systems Standards ProgramPhase I - ADS Focus .................... 24
6-6 OSTA/ADS Data Systems Standards ProgramPhase 2 - OSTA/Core ADS Focus ............... 25
6-7 OSTA/ADS Data Systems Standards ProgramPhase 3 - OSTA/Full ADS Focus ............... 26
i0-i Introduction to Panels .................... 36
10-2 Panel Assignments ....................... 37
v
ILLUSTRATIONS (continued)
Figure
ii-i ADS Directory/Catalog Architecture Model ........... 40
12-1 User View of Network Services ................ 46
12-2 User View of Network Topology ................ 48
12-3 Directory/Catalog User View .................. 50
13-1 Actual and Virtual Data Flow ................. 57
13-2 Near-Term Configuration ................... 61
13-3 Integrated Configuration Candidate .............. 64
LIST OF TABLES
Table Page
i-i OSTA/ADS Data Systems Standards Workshop Agenda ....... 2
12-1 Pilot Network Functional Requirements ............ 49
13-1 OSI Reference Model Layers ................... 56
13-2 Scenario ....................... .... 59
13-3 Protocols Required to Support Scenario ............ 60
15-1 Recommendation to OSTA on a Data Product PreparationStandard ......................... 72
vi
SUMMARY OF WORKSHOP CONCLUSIONS
The Office of Space and Terrestrial Applications (OSTA)/Applications Data
Service (ADS) Data Systems Standards Workshop was held at the Goddard Space
Flight Center in Greenbelt, Maryland on May 27-29, 1981. The purpose of
the workshop was to identify standards needed to interconnect ADS pilots
for data sharing; to assess current pilot methodologies; and to make
recommendations for future work. The theme of the four workshop panels was
"Standards Needed to Interconnect ADS Pilots for Data Sharing." Their
topics were: Catalogues, Directories, and Dictionaries; User Interfaces;
The Use of ISO Open Systems Interconnection - Basic Reference Model; and
Data Formats and Descriptions.
Panel A identified a preliminary set of requirements for guidelines and
standards for catalogues, directories, and dictionaries, which are found
in Section ii of this document. The panel found it necessary to identify
and define a structure for repository of information about data and defined
the following terms:
DIRECTORY Definition: High-level description of data sets available
to all ADS users. The directory is accessed by means of a standarduser interface.
LOCAL CATALOG Definition: Detailed description of data sets. The
local catalogs are maintained by the organization that is also re-
sponsible for maintaining those data sets.
The structure below the directory may contain intermediate levels ofdirectories which are both local- and network-implementation dependent.
Standards in the near term need only to be specified for the DIRECTORY.
Panel A recommended:
(I) A continuing Directory/Catalog Standards Working Group to advise
the ADS Standards Program on Directory/Catalog matters and to provide
advisory review of contractor products related to Directories and Catalogs
with membership from each of the pilots and the OSTA/ADS Standards Program.
(2) A Directory/Catalog Implementation Working Group to provide:
assessment of current ADS pilot methodologies, studies for alternative
implementation methods of the directory, detailed design of the directory,
determination of software functional requirements, design of interfacebetween directory and local catalogs of pilots, and consideration of
library and information science methodologies for its relevance.
(3) Policy be set concerning the release of information about datato ADS.
(4) Adoption or modifications of the WALLOPS definitions for datalevels.
(5) Continuing discipline user working groups be established.
vii
Panel B viewed the "user" as a discipline scientist at a terminal trying to
get data out of the network. It was assumed that the user is primarily
associated with one of the local systems, such as VAS or the Ocean Pilot.
In the short and intermediate term, users will connect to their "home"
system and obtain network services through it. Network services will be
visible to the user as separate from local system services. The panel
considered the requirements for standards and guidelines in the areas of
User Interfaces; their report is in Section 12.
Panel B recognized a need for a continuing oversight body for maintaining
and monitoring standards and guidelines. The panel recommended that there
be a continued panel existence more or less as a design review committee
to influence and monitor TAE, RSS, and allied efforts from the point of
view of user interface, with members represented from pilots, ADS Standards
Office, NASA Headquarters, other TAE users, and TAE developers. The panelalso recommended that a liaison be maintained with CODASYL and ANSI to
monitor work in command languages.
In order to determine the relevance of the OSI Reference Model for address-
ing ADS requirements, Panel C considered a scenario representing a broad
class of capabilities which were considered required to interconnect the
pilots for data sharing. The interconnection protocols needed to support
this scenario were then identified, and these protocols were then classified
in terms of standard layers within the OSI Reference Model. Panel C's
report is in Section 13.
Panel C considered three basic approaches which could be considered for
an integrated ADS pilot network system and the advantages and disadvantages
associated with each. The approach favored by the panel, to adopt existing
and emerging national and international telecommunication standards to the
greatest possible degree, involves the tentative acceptance of protocols
which are so new and unproven that they exist only as draft standards.
It is anticipated that, after an extensive review process, these protocols
will become FIPS and be required for future telecommunications support on
U.S. Government systems.
Panel C recommended that a working group be established to continue to
investigate identified issues and to track the progress toward a successful
interconnection of ADS pilots. Some specific topics for the Working Group
investigations recommended are:
(I) Review currently identified requirements versus other panels for
consistency and completeness.
(2) Develop functional specification of input parameters for each
application to be supported (input to layer 7).
(3) Develop design specifications of output stringspacketsmessage
blocks for each application to be supported (output "from 6 to 5").
(4) Evaluate existing layer 4 and 5 protocols, including the NBS
proposed standard, and recommend selection for pilot system and future
ADS use.
viii
(5) Perform a requirements analysis for the ADS at the combined
layers 1-3.
(6) Specify core requirements expected for each protocol layer for
pilots and future ADS use.
It was the consensus of Panel D that data exchange standards should be
developed to be of general future utility, though the near-term activityshould be constrained to focus on the problems of interconnecting the
ADS pilots. The panel report is in Section 14.i
Panel D recommended:
(i) ADS should establish a standard vocabulary of terms, units,
descriptions, and definitions.
(2) ADS should provide a machine-readable standard mechanism,which is medium and machine independent, for describing data content,
structures, numeric representations, and character codes.
(3) ADS should establish a set of preferred numeric representa-
tions, a preferred character code, preferred units, and preferred de-
scriptions.
(4) ADS should establish a permanent, dedicated team to pursue thiseffort further and recommended the following near-term outline.
a. The permanent team should begin by analyzing the data formats,codes and representations used in exisitng pilots.
b. The team should analyze existing and proposed data interchangestandards.
c. The team should adopt or create Strawman standards for review
by data base administrators for each pilot and associated NASAdata base.
d. The team should establish an ADS data standards administration
function to approve, disseminate, maintain and provide
visibility for these standards.
e. The team should provide top-level coordination for the
development of catalogs, in order to provide to the catalog
designers the mechanisms for describing data sets and to
evaluate the adequacy of the catalog structures to enableusers to access and select data.
Before adjourning, the workshop unanimously recommended the development of
a standard for data product preparation to ensure quality data sets. The
recommendation prepared by Richard desJardins, as given in Table 15-1, was
adopted. The workshop emphasized that there is a lot of work to be donein the standards area.
ix
WORKSHOP SUMMARY
I. INTRODUCTION
The Office of Space and Terrestrial Applications (OSTA)/Applications Data
Service (ADS) Data Systems Standards Workshop was held at the Goddard SpaceFlight Center in Greenbelt, Maryland on May 27-29, 1981. The purpose of
the workshop was to identify standards needed to interconnect ADS pilots
for data sharing, to assess current pilot methodologies, and to make
recommendations for future work. The theme of the four workshop panels was
"Standards Needed to Interconnect ADS Pilots for Data Sharing." Their
topics were: Catalogues, Directories, and Dictionaries; User Interfaces;The Use of ISO Open Systems Interconnection - Basic Reference Model; and
Data Formats and Descriptions.
Dr. Paul B. Schneck opened the workshop by welcoming the participants to
the Goddard Space Flight Center. He set the stage for the workshop by
stressing the importance of ADS in NASA's future.
Barbara Walton said that the near-term goal for 0STA/ADS is to provide the
capability for interconnecting the pilots for data sharing. There are
three major pilots within ADS at the present time: Oceans Pilot at JPL,
Earth Resources Pilot at Johnson Space Center, and the Atmospheres Pilot at
the Goddard Space Flight Center. The plan is to form a network
(interconnection) to share data between disciplines and users.
2. 0STA DATA SYSTEMS PLANNING WORKSHOP
Dick desJardins presented the 0STA Data Systems Planning Workshop recom-
mendations. The purpose of the OSTA Data Systems Planning Workshop, held
at Wallops Island on October 9-12, 1979, was to recommend a data system
concept and requirements to OSTA. A concept includes "a means for
identifying the work that has to be done, identifying the relationshipsbetween the people who have to do the work, and some kind of a
modularization scheme for the system." The purpose of flying spacecraft is
not to fly hardware but to build data sets from remote sensing. Panelswere composed of people who had problems and people who had solutions.
Disciplines represented were agriculture; land resources; hydrology;
geology and geodynamics; atmosphere; and oceans. There were also panels on
overall data systems; onboard data systems; data acquisition, distribution
and operations; information extraction and processing, and user facilities;
and data base storage and management.
The integrated discipline requirements identified by the 0STA Workshop
participants are:
(I) Quality data sets are needed which are clean, useful, and
rocessable. The project or discipline must produce parameter data setsof physical phenomena) which meet the program objectives. 0STA needs a
systematic treatment of problems with present data. Scientific data
management personnel should be responsible for the quality of the product,the planning of the product, and seeing that users get the data that they
want. The pedigree of the data is important. Sun angle, calibration,
algorithms for parameterizations, etc. are needed.
S-I
(2) OSTA needs a single integrated data catalog or "Master Directory."ADS should be one means to access the catalog to help the researcher find
out how to get the data and avoid wasting time doing it.
(3) OSTA needs continuity of data formats. A single format is notnecessary; there should be a few, fairly standardized formats. Data levelsshould be defined.
(4) OSTA needs to reference its data to a standard geographic and time
basis. Every piece of data should be marked with latitude, longitude,altitude and Universal Time.
(5) OSTA needs data delivery. Usually there is no need for immediate
access to data. What is needed is easy accessibility: ability to get data
by means of mail or electronic transmission. Each project has a"freshness" requirement.
(6) OSTA needs appropriate data archives to provide a place to store
data. There is a need for uniformity in policy for keeping, indexing, ormanaging that data. A policy of active archives is required. Scientificdata management should provide accessible data.
(7) Cooperation with user agencies is necessary for OSTA. USGS and
NOAA, as examples, have similar needs and problems, and NASA needs to be inharmony with operational data from other agencies.
Figure I shows the overall 0STA Data System Concept. Working storage is
provided for researchers. At the level shown in the figure, ADS tells us
what standards are necessary for making data available. ADS would provide
consultation and a Master Directory. The concept should be cost-
accountable; it should produce Level IA data sets. It could be phased overto commercial service. It was never a concept for electronic data
dissemination. The data have to cost-effectively satisfy multiple
objectives. The policy recommended was to store all the information that auser needs along with the raw measurement: sensor measurement data, sensor
ancillary data, calibration with instrument, etc. The data must be stored
in a form such that original data may be recovered. To do all this, OSTAmust implement research in data input and data dissemination to meet itsneeds.
3. THE ROLE OF THE ADS PILOTS
J. Patrick Gary addressed the role of pilots. This workshop is effectivelya working group for standards. We no__Ewneed more detailed specification ofhardware interfaces, communications protocols, data exchange services, etc.
This workshop should be viewed as a working group to define areas withinthe data systems concept where standards are required.
The overall goals of the ADS Program are to provide OSTA data users withtimely and effective access to needed data and information within and
outside of NASA and to provide standards/guidelines for future OSTA
programs to evolve data systems and data management towards compatibilitywhere appropriate. OSTA data users require timely and effective access to
needed data in a uniform way. We must not overstandardize. The pilots are
S-2
/ \ TOADS FLIGHT FEEDBACK
•STANDARDS\ PROJECTS REQU// • CONSULTATION _ DATA ACQUISITION
//= MASTER DIRECTORY'_
2+
u_ I LEVEL '_r" .... F -- " -- 2z I 2, 3, & WORKING
PROCESSING WORKING "X"
,v, DATA SETS STORAGE _ SYSTEM STORAGE USERS -I_n- LEVEL 1A -J [ A
DATA SETS _ IU'3
c_ z l " 1A, 1BI- '0 2+I u / LEVEL ...... P" DISCIPLINE "Y"
I 2,3,& I 2 INFORMATION i
_' I IDATASETS'WORKINGL'_ "il---'--I_ PROCESSING /WORKING)"Y"
I LJ STORAGE 3_ SYSTEM STORAGE USERS -t[ LEVEL1A
_ II .__._j DATA SETS
,_ _, OSTAI='_,
r , 2+ REAL-TIME i=I LEVEL I" ---- "_- -- -- USERSI 2,3,& I
[ i DATASETS , WORKING _ , OSTA
I I STORAGE NON.REAL.TIME _.LEVELIA F J I USERS
DATA SETS
NO ASA
NEW ARCHI ARCilIVES
OSTAARCIIIVE \
/ \
Figure I. OSTA Data System Concept
planned to evaluate the utilization of current techniques and technologies
in the use and exchange of data and to facilitate access to data (DBMS,Data Management, etc.).
The pilots are to provide demonstrations of the use of advanced
technologies, provide a test-bed environment for data handling technique
evaluation, evolve ADS requirements and capabilities (long-term goal), anddocument validated methodologies as standards and guidelines for OSTA data
system use. These objectives are carried out in order to apply technologyin a service capacity in support of the research programs of the
application disciplines. The three pilots, when they interconnect, have a
chance to "test bed" distributed processing and data sharing conceptsneeded to meet ADS near-term requirements. In time, they will come to test
concepts applicable to much of NASA. To interconnect the ADS pilots fordata sharing, two key functions are needed: I) Users must know what data
are available, and 2) data must be exchangeable among facilities.
The relationship of pilot program activities to the standards developmentprocess is shown in Figure 2. Inputs and evaluative criticism from the
users, pilots, and Headquarters are required in the standards development
process. The process starts with requirements for standards, but we must
not overstandardize. Standards are useful to describe: i) how to describe;2-7-how to build; and 3) how to apply. Should ADS find that the current
standards or methodologies are no___tadequate or applicable to its needs, the
pilots can test new methodologies or proposed standards and develop them.The establishment and dissemination of standards is a high level management
function. A result of this standards development process feeding back to
the pilots will be standards useful to the design and the specification ofnew systems.
Figure 3 shows the overall ADS development approach with its gradualexpansion of capabilities. The process is iterative; feedback to and from
working groups, such as a standards working group, is essential forprogress.
4. THE OSTA/ADS STANDARDS DEVELOPMENT PROCESS
Barbara Walton stated that the goals of the OSTA/ADS Data Systems Standards
Program Were formulated in response to the need for standards for sharing
data. The goal of the program is to provide effective data exchange and
data system interface, standards and guidelines for OSTA programs. Its
objectives are to: I) identify and recommend use of data system standards
and guidelines applicable to 0STA/ADS; 2) develop and maintain 8STA/ADS-unique data system standards and guidelines; and 3) coordinate with OSTA
programs, ADS pilots and pertinent standards activities within and outside
NASA. Applicable standards of the National Bureau of Standards and other
existing standards can be used, but ADS and OSTA have unique problems.NASA has already dealt with some of the unique problems, such as the
Landsat images CCT (Computer-Compatible Tape) standards; however, there areother development efforts that NASA will be dealina with in the nearfuture.
S-4
RELATIONSHIPOF OSTA/ADSPILOTSTO THE STANDARDSDEVELOPMENTPROCESS
STANDARDSOTHER SOURCES NEEDS OF PILOT PROJECTS
REQUIREMENTS
APPLICABLE
EXISTINGSTDS METHODOLOGIES OSTA/ADSPILOTS& GUIDELINES
DATA SYSTEMS/
TECHNIQUEDEVELOPMENT;TEST.
ANALYSIS AND EVALUATION' AND
EVALUATION
REQUEST FOR
OK NO TEST/DEVELOPMENT
YES
STANDARDS
ESTABLISHMENT
SPECIFICATIONS
IOSTA/ADSISTANDARDS& I
Figure 2
ADSPPOGRAMREVIEW,
.ADBDEVELOPI_EI_ITAPPROACII o
REQUIREMENTS:REFINED- QUAtITIFIED
C_ NEW Ii
CON WORKING BFOIIIRFMEI,IGROUPS
USERS / ///i "i ADS FY84DEVELOPERS
'PLANNINGXV " I o STANDARDS lJ PILOT I s _..] WORK ]TECII!TiLO5Y/ / j} .I AND i o CONSULTANTS TEST RFlilT _,,n_ IArlDSTDS'_/ / /
I I o,,u, /I F.vRn I ICOOP,DIIIATION BED EVALUATIONI / ..... [ /
o NASAI10 o USERS o WORKIIiGGROUPS IEXPArIDEDI /o GSFC o DEVELOPERSo R&DGROUPS PILOT Vo JPL o STAr:DARDS OPERATIOrlS
o JSC i ..IRESEARCHJ o flEl,lUSERS• o IHTERCO_IHECT
AND I NEW PILOTSCONCEP-ISJI7:'VFIrl>r.rrrr TECIfflnLOGY
o UNIVERSITIES APPLICATIONS ,Io DEVELOPERS
o CONSULTANTS
Figure 3
In 1980, a phased approach was developed for the program. FY81 Phase I
projects focused on ADS and included a standards survey, standards
requirements study, pilot methodology survey, and evaluation process andcriteria. "Candidate" standards will be produced and the results are due
to be published this year. This program builds on the results of the OSTAWorkshop and the feasibility study reported on by Dick desJardins. This
workshop will review, modify, and evaluate these processes so that those
standards which might be applicable to ADS may become candidate standardsfor ADS.
The following remains to be done: ADS planning, interim standards, a
concept for implementation of a "Core ADS," definition of OSTA data systems
policy, and full-capability ADS definition. Phase 2, in FY82 and FY83,expands the focus to OSTA datasystems and "Core ADS." Phase 3, focuses on
the future goal of a "full-capability ADS." Once a full set of standards
has been developed, a systematic review and periodic update will be needed.Standards will evolve as needs evolve.
5. THE CURRENT MITRE EFFORT
Terry Kuch and Rick Sakamoto presented an introduction to MITRE's supportof the 0STA/ADS standards and guidelines program. The three MITRE
presentations at the workshop concentrated on functions needed fornear-term data sharing among ADS member systems. Sharing of computational
facilities and software were considered to be longer-term ADS goals.
MITRE adopted a logical view of ADS as a distributed system, which
distinguishes among seven components of such a system: I) providers of
data; 2) providers of applications software; 3) providers of computational
facilities; 4) users of data, software, or computational facilities;
5) administrative services; 6) technical services such as documentation and
location support for data, software, and computational facilities; and
7) support for data communication. Based on this logical view, MITRE
developed a hierarchical classification scheme of ADS features at a levelof detail (70 nodes) appropriate to the level of detail addressed by most
Federal, national, and international information processing standards.This feature classification provided the framework for a preliminary
assessment of the applicability of Federal, national, and international
standards to ADS. These standards were gathered, screened, documented
briefly, and reported in NASA contractor report CR 166675.
Two key efforts were initiated to survey methodologies of the three ADS
pilots and to identify the requirements for standards of ADS members basedon a survey of the pilots and on representative potential future members.
Preliminary results of the requirements survey were used in the development
of a process and criteria for the evaluation of potential Standards forOSTA/ADS. An overview of the evaluation process was presented and examples
of standards passed through the process.
Paul Clemens presented the results of a survey Of ADS member requirements
for standards and guidelines. This survey was carried out in four steps:
I) identify a representative number of planned and prospective ADS members
from ADS pilots, key 0STA programs, and other sources; 2) survey the
S-7
identified members; 3) define and document members' needs for ADS systemcapabilities and services; and 4) derive ADS standards and guidelinesrequirements from this survey of members' needs.
The survey included the interpretation and analysis of functional
requirements from three sources: I) earlier OSTA/ADS data system studies,2) current ADS pilot activities, studies, and documentation, and 3) _prospective ADS members' activities and documentation. Requirements in
each case were then reviewed and modified as n_eded to reflect the overallscope of ADS.
The resultant requirements were then tabulated and mapped into the ADS
feature classification. The findings were analyzed for commonality of
purpose and function and, from this analysis, overall standardsrequirements determined.
Paul Giragosian presented the results of a survey of the methodologies
employed by the ADS pilot programs (Atmospheres, Oceanic, Earth Resources).At various stages in their development, the ADS pilots have implemented or
planned to adopt certain practices, procedures, standards, or conventions.
The collection of these practices as applied toward a specific developmentfunction or operational objective constitutes the notion of a
"methodology." The primary objective of the survey was to provide aninformation base for the evaluation of these methods and their
applicability to the future development of ADS standards and guidelines.
6. PANEL ACTIVITIES
Barbara Walton presented the following panel instructions: I) critique theMITRE representation of pilot methodologies for accuracy and completeness;
2) identify the requirements for standards and guidelines needed in yourpanel's area to interconnect the ADS pilots for data sharing; 3) make a
preliminary assessment of the adequacy of currently identified pilot
methodologies and external standards in meeting these requirements; 4)
identify any other methodologies you are aware of which may contribute tothe solution to Your panel's aspect of the problem; 5) make recommendations
for future work# providing descriptions and estimate of effort where
possible; and 6) provide the panel's consensus on the need for a continuing
working group in this area and suggest membershi p thereof.
She then introduced the following panel topics and assignments:
Standards Needed to Interconnect ADS Pilots for Data Sharingi
Panel A - Catalogues, Directories, and Dictionaries
Chairman: Jose Urena, JPL
Panel B - User Interfaces
Chairman: Jim Brown, JPL
Panel C - Use of ISO Open Systems Interconnection - Basic Reference Model
Chairman: Ed Greene, GSFC
S-8
Panel D - Data Formats and Descriptions
Chairman: Ed Greenberg, JPL
The panels convened briefly, then broke for dinner.
James Burrows, Director of the Institute for Computer Science and
Technology of the National Bureau of Standards, was the dinner speaker on
the first day of the workshop. He discussed the NBS Data Systems StandardsProgram and emphasized the communications protocol development program.
The panels continued their work on the following days with presentations bythe panel chairmen on the last day of the workshop. The full text of the
panel reports is contained in Sections 11 through 14 of the proceedings.
7. PANEL A: STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA SHARING
FOR CATALOGUES, DIRECTORIES, AND DICTIONARIES
Panel A identified a preliminary set of requirements for guidelines andstandards.
(I) The panel found it necessary to identify and define a top-level
repository of information about data in order to consider standardsrequirements. The term assigned to this "highest" level repository is"DIRECTORY."
DIRECTORY Definition: High'level description of data setsavailable to all ADS users. The directory is accessed by means
of a standard user interface.
The detailed information about data resides in the "lowest" level
repository. The term "LOCAL CATALOG" was assigned to it:
LOCAL CATALOG Definition: Detailed description of data
sets. The local catalogs are maintained by the organizationthat is also responsible for maintaining those data sets.
The structure below the directory may contain intermediate levels ofdirectories which are both local- and network-implementation dependent.
This potential requirement was not addressed by the panel.
The above definitions identify a structure with at least two levels.
Standards in the near-term need only to be specified for the top level
(DIRECTORY).
The ADS Directory/Catalog architectural model is depicted in Figure 4. The
user accesses the information in the directory by means of a standard user
interface, and logical links connect the directory with the local catalogsor with the intermediate level directories. The dashed lines show possible
future logical links between the user and the local catalogs, intermediatedirectories, and data sets, that would require new standard interfaces.
S-9
Figure 4. ADS Directory/Catalog Architecture Model
(2) A set of requirements for standards that were identified for the
directory by Panel A is listed in the panel report (Section 11.2.2).
(3) Definitions and conventions for terminology of directory
attributes are necessary.
(4) The panel identified a set of guidelines for the local catalogwhich are given in Section 11.2.4.
(5) A Directory User's Guide is required.
The panel recommended:
(I) A Continuing Directory/Catalog Standards Working Group
a. Functions of the working group would be to advise the ADS
Standards Program on Directory/Catalog matters and to provide
advisory review of contractor products related to Directoriesand Catalogs.
b. Membershipshould include at least one representative from
each one of the pilots and the 0STA/ADS Standards Program.
c. The group should consider of the need for a standard user
interface to local catalogs and intermediate directories and
investigate methods for incorporating terminology definitions
accepted by recognized discipline user bodies.
(2) A Directory/Catalog Implementation Working Group to provide: a)
assessment of current ADS pilot methodologies; b) studies for alternativeimplementation methods of the directory and selection of one; c) detailed
design of the directory; d) determination of software functional
requirements; e) design of interface between directory and local catalogs
of pilots; and f) consideration of library and information sciencemethodologies for its relevance. The directory could allow structured dataretrieval and retrieval of unstructured indexed textual information.
(3) Further Recommendations
a. Policy be set concerning the release of information about datato ADS.
b. Adoption or modifications of the WALLOPS definitions for datalevels (under area of work of Panel D on Data Formats and
Descriptions).
c. There is a need for continuing discipline user working groups.
d. Study alternatives to "in-person" meetings.
S-II
8. PANEL B: STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA SHARINGFOR USER INTERFACES
Panel B viewed the "user" as a discipline scientist at a terminal trying to
get data out of the network. It was assumed that the user is primarilyassociated with one of the local systems, such as VAS or the Ocean Pilot.
The panel discussed how the user views the network. Figure 5 shows some
possibilities of the user's concept of the network services. Illustration
(a) shows the user terminal connected to each local system with ADS
invisible as a networking function. After discussing this arrangement, the
panel decided that it was probably not realistic; the user would probablynot view the system that way. Representation (c) of the system is more inline with the long-term ADS picture. The users dial into a system called
ADS with its data system and information extraction services. However, in
the short term with the three pilots that we now have, that view is not
realistic. The resulting user view of the network systems is shown in view
(b). The user is aware of the ADS network added on to the local system.
Part of the user interface will be influenced by the network and part willnot. This view does take into account the actual network as it is likely
to exist with the three pilots.
In the short and intermediate term, users will connect to their "home"
system and obtain network services through it. Network services will be
visible to the user as separate from local system services. The interface
may have to be different, except where TAE or a similar "transportableexecutive" is used for both.
The panel recognized a need for a continuing oversight body for maintaining
and monitoring standards and guidelines. They considered the requirementfor standards and guidelines in the following areas:
(I) Dial-up Procedures. Users are connected to each local system and
know that each one of these local systems can connect in some way with anyother independent of location. With the exception of such things as
retrieval time and cost, it would not be apparent to the user if the
connection were by local or long-haul network. Since users will connect tolocal systems, no standard or guideline is needed.
(2) Terminals. A guideline or standard based on what is needed to
correctly support a Menu System (processor) in a user-friendly way is
required. This implies a minimum of 1200 baud "dumb" CRT; 300 baud
hardcopy is marginally acceptable.
(3) Common Capabilities. The panel developed a model of the user'sview of the catalogs and directories to use as a basis for a standard user
interface. This model shows the local catalog(s) as transparent to the
user. The user would deal with the high-level directory, standardized over
the network. The linkage between the directory and the actual data set
would be invisible. If the users have to see a local catalog or directory,that interface could not be standardized. ADS should seek to standardize
the user's view of the interface to a high-level directory.
S-12
F
\ . / \
" .//_ \\ / () \(a) (b) (c)
O USER TERMINAL
O LOCAL SYSTEM ORLOCAL NETWORK
Figure 5. User View of Network Services
The panel prioritized the functional requirements for the pilot network forwhich standard user interfaces would be needed. These requirements are
grouped in Table I based, not necessarily on functional importance, but onthe need for standard user interface. Clarification is needed for
functional requirements shown to accurately reflect the directory_catalog i
concept and criteria established by Panel A. This is an item for futurework.
The panel anticipates that the user will want sample data sets--the larger
the data set, the greater the need for a variety of different samples. The
user may want to look at smaller data sets quickly prior to operating on
larger data sets. (This is a strong requirement in the Oceans Pilot.) The
value of this function depends on the typical size of the data set vithwhich one is dealing. Theuser should be aware that sample data sets exist
and should be aware of how to get them even if the directory-pointing
mechanism is transparent. This requirement is shown in Group 3 to indicatethat it is a longer term effort.
(4) Language Interfaces. It is hoped that TAE and RSS will developinto the defacto standard for the three pilots, with possible modifications
based on current pilot methodologies and external standards.
(5) User Consultant. There should be a human user consultantavailable to be used for human-to-human assistance. Guidelines are needed
for a user consultant. The scope of the guidelines includes who, how many,
organization (local system, local network, ADS network), functions, and
expertise.
The panel recommended that there be a continued panel existence more oz_
less as a design review committee to influence and monitor TAE, RSS, and
allied efforts from the point of view of user interface, with membersrepresented from pilots, ADS Standards Office, NASA Headquarters, other TAE
users, and TAE developers.
There is a need to clarify TAE maintenance and control policy,organization, and authority of the review committee. The charter of the
TAE/RSS review committee should be to test and evaluate the software to _be
used; to recommend changes to be done; to review documentation.
The panel recommended that liaison be maintained with CODASYL and ANSI to
monitor work in command languages. The panel also recommended that there
be a study to understand user interface procedures of technology transfer
organizations, e.g., Eastern Regional Remote Sensing Applications Center(ERRSAC), etc. for both human training and computer methodologies.
9. PANEL C: STANDARDS NEEDED FOR THE USE OF ISO OPEN SYSTEMSINTERCONNECTION - BASIC REFERENCE MODEL
All three pilot programs were represented on Panel C. Given the diversebackground of the participants and the limited time available for
discussion, the panel was unable to explore the many detailed interface
considerations needed to thoroughly analyze the relevance of the OSI i
S-14
TABLE 1
PILOT NETWORK FUNCTIONAL REQUIREMENTS
GROUP 1 - MANDATORY
• COPY "FILE"• DISPLAY DIRECTORY CONTENTS
• DIRECTORY ATTRIBUTE SEARCH
• CREATE DIRECTORY ENTRY
• MODIFY DIRECTORY ENTRY (SOME ATTRIBUTES PROTECTED)
• DELETE DIRECTORY ENTRY (AND CORRESPONDING DATA SET)
• HELP• DISPLAY STATUS OF ANY OF THE ABOVE PROCESSES (IF APPRO-
PRIATE )
PRIORITYGROUP 2
• DISPLAY NETWORK STATUS/STATISTICS• SEND MESSAGE
- TO LOGGED-ON USER
- TO MAILBOX
PRIORITY GROUP 3
• PROVIDE SAMPLE DATA SETS
- PRE-CANNED
- FIRST N POINTS, RECORDS,...
[- SAMPLED, AVERAGED,. ••]• PROVIDE ESTIMATES OF "COST" BEFORE EXECUTING A NETWORK
OPERATION
- DATA SET SIZE
- ELAPSED TIME
- COST (IF USED)• BROWSE
• SEND MESSAGE TO BILLBOARD
GROUP 4*
• NETWORK LOG ON/OFF- TRANSPARENT TO USER
• ESTABLISH/REMOVE/MODIFY USER AUTHORIZATION
- NOT AVAILABLE TO USER
• RUN/CANCEL EXPLICIT PROCESS- FUNCTION NOT NEEDED IN SHORT TERM
• SEND BROADCAST MESSAGE- NOT AVAILABLE TO USER
• DIAL-UP, LOCAL SYSTEM LOG ON/OFF- CANNOT STANDARDIZE
*Functions may be required, but user interface standards/
guidelines are not required.
S-15
Reference Model to the ADS. Nevertheless, the panel concentrated its
efforts by performing a top-level mapping between the conjectured ADS
requirements and the identified layers within the 0SI Reference Model. Anumber of issues of a more detailed nature were identified for further
study.
The 0SI Reference Model represents a conceptual architecture fortelecommunication interconnections which consists of a hierarchical
structure composed of seven layers. The principal functions performed or
services rendered by each layer is shown in Table 2. At each level, thereis an illusion of a direct peer-to-peer protocol connecting the two
systems. However, in reality, the actual control and data communication isbetween adjacent layers. The N-th layer protocol performs identifiable
services to the (N+1)-st layer and, in turn, requests services from the
(N-1)-st layer. If the two systems are distinct, then the actual signal
communication is performed at the Physical Layer (layer I). The interface
to the applications process is at the Applications Layer (layer 7).
At the lowest three layers, there are existing protocols that conform
substantially with the OSI Reference Model. Beyond layer 3, there are no
nonproprietary general-purpose protocols which have been extensivelytested; however, this is a field of active research within both the U.S.
and European communities. Draft standards have been issued by the NationalBureau of Standards (NBS) for both a Transport Layer and a Session Layer
protocol. It is anticipated that these draft standards may emerge asmandatory Federal Information Processing Standards (FIPS) (for U.S.
government systems) after these protocols have been extensively reviewedand tested. Both IBM and Digital Equipment Corporation havetelecommunications software (SNA and DECNET, respectively) that provides
services at all layers for networking among compatible-computer systems.
Table 2
OSI Reference Model Layers
Layer Name Description
I Physical Physical signal interconnect from
point-to-point
2_ _ Link Control _ Data interconnect from
point-to-point
3 Network End-to-End data interconnect(Source DTE to Destination DTE)
4 Transport Host-to-Host data transfer
5 Session Dialogue synchronization betweenhosts
6 Presentation Data conversion services
7 Application Interface to application processes
S-16(
In order to determine the relevance of the 0SI Reference Model for
addressing ADS requirements, Panel C considered a scenario, described in
Section 13.3, representing a broad class of capabilities which were
considered required to interconnect the pilots for data sharing. The
interconnection protocols needed to support this scenario were thenidentified, and these protocols were then classified in terms of standard
layers within the OSI Reference Model.
The scenario consisted of a series of steps in which an investigator
utilizes a terminal to perform a search of a nonlocal data base, initiates
the execution of a process resident on a remote processor using the
selected data set as input data, copies the generated data set to a
different processor where it is added to the data base, the correspondingdirectories and catalogs are updated, and an electronic mail notification
of the new data set is given to selected colleagues.
To support this scenario, the protocols listed in Table 3 are required.
Items I, 2, 5, and 9 are essential layer 5 functions, and the remainingitems are combined layer 6 and layer 7 functions. Since nonlocal
intercomputer communication is required by this scenario, layer I, 2, 3,
and 4 protocols are required to support the higher layer protocols.
Other capabilities were discussed as appropriate for long-term ADS
consideration, but beyond the scope of that needed to interconnect ADS
pilots for data sharing, included distributed data bases, multiprocessorapplication processing, and generalized word processing (interoperability
among equipment from diverse manufacturers). Additional layer 5, 6, and 7
protocol services would be needed to support these functions.
Table 3
Protocols Required to Support Scenario
I. Terminal support
--Local
--Dial-in through network*
2. Automatic login/accounting to applications manager
3. Catalog manager command/response interaction, data base inquiryand response (command language, data descriptors)
4. File transferI
5. Applications executive interaction (suspend/resume, etc.)
6. Privacy/security services
7. Message to operator/mailboxes
8. JSC word processor access*
9. Automatic log off
*Additional near-term capability not directly derived from scenario
S-17
The Pilot Atmospheres Data System (PADS) at the Goddard Space Flight Centerand the Earth Resources Pilot System (ERPS) at the Lyndon B. Johnson Space
Center have developed and adapted telecommunications software to service
the needs of their individual pilot demonstrations. The computer systemfor the Oceans Pilot System (OPS) at the Jet Propulsion Laboratory will be
delivered this summer and is expected to utilize the DECNET software for
intrapilot networking. Figure 6 shows the initial telecommunicationssoftware that is being implemented for each pilot. The classification of
the software into OSI Reference Model layers is only approximate.
The panel considered three basic approaches which could be considered for
an integrated ADS pilot network system and the advantages and disadvantages
associated with each. The approach favored by the panel, to adopt existing
and emerging national and international telecommunication standards to the
greatest possible degree, involves the tentative acceptance of protocols
which are so new and unproven that they exist only as draft standards. The
NBS has issued specifications of a layer 4 (Transport) and layer 5
(Session) protocol which appear to be the leading contenders for standard
protocols at these levels. It is anticipated that, after an extensivereview process, these protocols will become FIPS and be required for future
telecommunications support on U.S. Government systems. The proposed draft
layer 4 protocol is intended to provide the proper interface to the majorexisting layer 3 protocol such as X.25 and X.21.
Above layer 5, the processing functions become so diverse that there
appears little hope for the development of a single standard protocol at
layer 6 or layer 7 in the near future. Instead, it is likely that a seriesof standard modules will be developed which perform certain well-defined
functions at layers 6/7 and which interface to the standard layer 5
protocol. One such module, the NBS File Transfer Protocol, is scheduled tobe released in draft form in early 1982. Other standard modules will
undoubtedly be developed but probably not on a timeframe that will benefitthe ADS.
The panel did not have the time to assess the adequacy of the NBS draft
protocols at layers 4 and 5. Nevertheless, the consensus of the panel was
that this approach deserves cautious support. _ While this approach islikely to be the most frustrating and difficult on a short-term basis, it
is the only approach which offers a potentially viable solution for the
effective networking among non-homogeneous systems._ Figure 7 illustratessome of the protocols that are needed for the candidate ADS configuration
and their relationship to the OSI Reference Model.
Panel C recommended that a working group be established to continue to
investigate these issues and to track the progress toward a successful
interconnection of ADS pilots. Listed below are some specific topics forthe Working Group investigations:
(I) Review currently identified requirements versus other panels for
consistency and completeness.
Panel C identified the need for protocols to support the functions
identified in Table 3. These requirements need be compared with the
requirements identified by other panels for consistency and completeness.
S-18
NEAR TERM CONFIGURATION
LAYER PADS ERPS OPS
7
6RSS TELEPORT
D5 E
CNET
4
RSCS_--- COMM (HASP)
2 BISYNC
m
1 II
Figure 6. Near-Term Configuration
S-19
INTEGRATED CONFIGURATION CANDIDATE
LAYER (TWO OR MORE YEARS IN FUTURE)
I
7
i
NBS DATAFILE ACCESS ?
TRANSFER PROTOCOLPROTOCOL (FUTURE)
6
:
m
5 NBSSESSION
4 NBSTRANSPORT
3
X. 21 • OTHERX. 25 OR OTHER (LOCAL AREA
2 SERVICE DEDICATED NET, SATELLITELINE TDMA, ETC.)
SERVICE
Figure 7. Integrated Configuration Candidate
S-20
The intent is to directattention to provide or plan protocols to meet any
extra requirements.
(2) Develop functional specification of input parameters for eachapplication to be supported (input to layer 7).
After the requirements of an ADS network have been identified, each
application must be isolated, and a functional or performance specification
must be described. Once this information is known, the functional
specification of the application can be broken down into subfunctional
groups that will describe the input parameters. These parameters are the
user interface between the application process and the protocol of the
application layer in the ISO model. The specification of the input
parameter functions can then be used to develop design specifications for
each parameter.
(3) Develop design specifications of output strings/packets/message
blocks 'for each application to be supported (output "from 6 to 5").
Pilot implementation of the identified application functions (e.g., remote
catalog manager request/response, file transfer, process initiation, and
user message exchange) requires detailed specification of the strings,
packets, and/or message blocks which will be output from one host system's
layer 6 protocol function for input to another host. Currently, with the
exception of file transfer, no federal standards exist to guide the designeffort needed by the ADS pilot system to provide mutually compatibleservices for these functions.
Detailed descriptions of the information content, format, and layout of the
message blocks to be exchanged and the encode/decode processing to be
applied to the message blocks must be specified.
(4) Evaluate existing layer 4 and 5 protocols, including the NBS
proposed standard, and recommend selection for pilot system and future ADSuse.
The purpose of this effort is to evaluate and recommend approach for the
implementation of the transport and session layers of the OSI. This will
be accomplished by a review of existing pilot system implementations,
proposed standards (e.g., NBS), and other existing protocols (e.g., SNA).Additional points of consideration include a cost analysis of "build versus
buy," that portion of the pilot systems' charter which effects the
exploration of new technologies, the possible addition of new nodes to theADS network, existing hardware and software in the centers involved, and
the facility with which a near-term implementation may evolve into a longerterm solution.
The output of this task should include recommendations of technologies and
methods for a near-term implementation and longer term analyses and studies
pointing toward a solution for future ADS system.
S-21
(5) Perform a requirements analysis for the ADS at the combined layers
I-3.
The service requirements for the interconnection of the pilots and for
future ADS capabilities will determine which services are best suited
(packet switched, dedicated line, other). No new standards are requiredfor these layers; ADS has to select those it needs. Traffic between nodeswill determine service required. X.25 is not cost-effective, under current
tariff structure, for use of more than 2 hours/day--dedicated line would be
cheaper. Satellite communication links have to be considered for high-datarates. The reliance on local area networks at the member nodes has, to be
considered for impact on the ADS network.
(6) Specify core requirements expected for each protocol layer for
pilots and future ADS use.
In general, standard protocols provide a large number of options and
services, not all of which are germane to a specific application. Because
of this, most implementations of protocols consist of a subset of the fullcapability defined by the standard. Incompatibilities arise when different
user systems adopt different subsets of the standards, and the logical
intersection of the various subsets are insufficient to provide the
necessary services. This task is concerned with developing guidelines for
each applicable protocol which identify the core functions and capabilities
expected from each user implementation to support the future ADSinterconnection uses.
10. PANEL D: STANDARDS NEEDED FOR DATA FORMATS AND DESCRIPTIONS TO
INTERCONNECT ADS PILOTS FOR DATA SHARING
It was the consensus of Panel D that data exchange standards should be
developed to be of general future utility, though the near-term activityshould be constrained to focus on the problems of interconnecting the ADS
Pilots. The intent is to use the three pilot nodes to evaluate the
generalized applications of the ADS. The panel agreed that the following
considerations were important when standards are designed:
a. DBMS catalogs should be accessible and understandable to remote
users (both humans and applications processors).
b. Formatting conventions should be constrained to have minimal
impact on existing archival data sets or on currently-generating datasources (e.g., Landsat), though they should be designed to provide guidance
for future DBMS developments.
c. Archival data records and their data descriptions should be
available in globally-identifiable, machine readable and interpretable form
so that users can automatically interact with variable, non-affiliated data
sets from remote DBMS nodes. The format of the records and descriptions
should be machine and medium independent.
d. Terminology must be scrupulously defined. Definitions, words,
units and general vocabulary should be standardized. Everyone should have
the same understanding of the same word or definition.
S-22
'e. Each DBM,B node should have the option to optimize its data formats
(at the discretio:n of the local authority) as long as minimal constraints
impos;ed by global standards are met.
Panel_ D recommended:
(I) ADS should establish a standard vocabulary of terms, units,
descr:iptions, mnd definitions. This must be accomplished in the immediate
future. Although the early versions of the vocabulary need not be
complete, they muslt provide the foundation for enabling the definitions ofrequfLrements and specifications to proceed.
_(2) ADS should! provide a machine-readable standard mechanism, which is
medium and machine!independent, for describing data content, structures,
nume:ric representations , and character codes. It is vital that these
definition mechanisms should be adopted as soon as possible in order to
faci_Litate the pilot interchange of data, and in order to provide guidance
for the future data sets which will be generated in coming years. The
mechanisms adopted MUST be adequately defined, with user guides and
examples, and MUST have expansion capabilities.
(3) ADS should establish a set of preferred numeric representations, a
preferred character code, preferred units, and preferred descriptions. The
ADS ;vocabulary should recognize and define ALL of the used or usable codes,
units, and descriptions which currently exist within the pilots, but asubset of these MUST be identified as the preferred set.
It :is highly desirable that each pilot node should perform conversions ofthose existing data e_ements that are not in the preferred form, thus
red,acing the number of conversions which must be performed by each userprocessor.
(4) The consensus of the panel was that the view of each of the panelparticipants was limited. The panel members felt that it is critical that
the ADS should establish a permanent, dedicated team to pursue these
rec:ommendations further. While impractical for the panel to recommend
detailed specific items for the team, it proposed that the followingnear-term outline be pursued:
a. The permanent team should begin by analyzing the data formats,
codes and_representations used in existing pilots.
b. The team s[hould analyze existing and proposed data interchangestandards.
c. The team should adopt or create Strawman standards for review
by data base administrators for each pilot and associated NASAdata base.
d. The team should establish an ADS data standards administration
function to _,approve, disseminate, maintain and providevisibility for these standards.
S-23
e. The team should provide top-level coordination for thedevelopment of catalogs, in order to provide to the catalogdesigners the mechanisms for describing data sets and to
evaluate the adequacy of the catalog structures to enableusers to access and select data.
11. WORKSHOP CLOSING
Before adjourning, the workshop unanimously recommended the developmenl i of
a standard for data product preparation to ensure quality data sets. The
recommendation prepared by Richard desJardins, as given i:_ Table 4, was
adopted.
The workshop emphasized that there is a lot of work to be done in the
standards area. The panels' detailed requirements and the recommendations
for future work are vital for the ADS program. Many of the workshop
attendees will be called upon in the future for participation in working
groups.
Critique of the MITRE presentation of the ADS pilot methodologies, one ofthe intents of the workshop, was deferred to the pilots for action and
reporting in a few weeks' time.
S-24
Table 4
Recommendation to OSTA on a Data Product Preparation Standard
Users of ADS may acquire some data only to find that crucial aspects of the
data are unknown or missing, e.g., the position and time of data taking,the processing steps performed, the calibration curves used. While these
aspects are of little consequence for systems interconnection protocols,they may be crucial for effective utilization of the data.
Therefore OSTA should develop a standard or guideline for Data Product
Preparation. The intent of this standard would be to provide to data
preparation personnel a checklist to assure the "quality" of the data as
defined by the 1979 OSTA Data Systems Planning Workshop. The term
"quality" was used at that workshop to signify the quality of the data
preparation process rather than the apriori intrinsic goodness of thesensor data.
The scope of the standard would include:
o data preparation practices (e.g., recommended quality assurance
practices, scientific data validation techniques)
o data labeling and annotation (e.g., source, indications of gaps,comments)
o ancillary data (e.g., position, time, solar aspect)
o "pedigree" of the data (e.g., calibrations performed, noise
removal technique used, algorithm applied)
o pointers of references (e.g., name and address of preparer,
identification of data control documentation, reference data and
software used including version numbers and algorithms)
S-25
1.0 INTRODUCTION
The Office of Space and Terrestrial Applications (OSTA)/Applications DataService (ADS) Data Systems Standards Workshop was held at the Goddard SpaceFlight Center in Greenbelt, Maryland on May 27-29, 1981. The purpose ofthe workshop was to identify standards needed to interconnect ADS pilotsfor data sharing; to assess current pilot methodologies; and to makerecommendations for future work. The agenda for the 3-day workshop appearsas Table 1-1. The theme of the four workshop panel groups was "StandardsNeeded to Interconnect ADS Pilots for Data Sharing," and their topics were:Catalogues, Directories, and Dictionaries; User Interfaces; The Use of ISOOpen Systems Interconnection - Basic Reference Model; and Data Formats andDescriptions.
This document contains reports from the panels; summaries of the talks anddiscussion presented, which are derived from transcripts and notes taken atthe workshop, and view graph presentation material. A list of workshopattendees is given in Appendix F.
2.0 WELCOME - Paul B. Schneck, GSFC
Dr. Paul B. Schneck opened the workshop by welcoming the participants tothe Goddard Space Flight Center. He set the stage for the workshop bystressing the importance of ADS in NASA's future. He emphasized that the"s" in ADS stands for service, not system, and that ADS must be responsiveto the user community. It must be seen as adding value to the data whichare processed. Finally, it was emphasized that standards must be appliedto ADS to heighten its usability and accessibility, and not to the user tobe able to adapt to ADS.
3.0 INTRODUCTION TO THE WORKSHOP - Barbara Walton, GSFC
The near-term goal for OSTA/ADSis to provide the capability forinterconnecting the pilots for data sharing (Figure 3-1). There are threemajor pilots within ADS at the present time: Oceans Pilot at JPL, EarthResources Pilot at Johnson Space Center, and the Atmospheres Pilot at theGoddard Space Flight Center. The plan is to form a network (interconnection) to share data between disciplines and users. The theme of thisworkshop is "Standards Needed to Interconnect ADS Pilots for Data Sharing."The first objective of this workshop is to establish the requirements forstandards in the areas of (a) Catalogues, directories, and dictionaries,(b) User interfaces, (c) Use of ISO reference model, and (d) Data formatsand descriptions. These topics are to be addressed by the four panels, andtheir members will be making recommendations at the close of the workshop.A second objective of the workshop is to review for accuracy andcompleteness the methodologies of the pilots as compiled to date and tomake preliminary assessment of their adequacy in meeting these standardsrequirements. The final and perhaps most important objective is to makerecommendations for future standards work and the need for continuingstandards working groups. These are the key results expected from themeeting.
Table I-I
Office of Space and Terrestrial Applications/
Applications Data Service (OSTA/ADS) Data Systems Standards Workshop
Theme: Standards Needed to Interconnect
ADS Pilots for Data Sharing
- AGENDA -
May 27-29, 1981Goddard Space Flight Center
Wednesday, May 27
8:30 am Registration
9:00 am Welcome Paul Schneck, GSFC
9:15 am Introduction to the Workshop Barbara Walton, GSFC
9:45 am Background- OSTA Data Systems Planning Workshop
Recommendations Dick desJardlns, CTA
- Role of Pilots Pat Gary, GSFC
10:30 am Coffee Break
10:45 am The OSTA/ADS Standards Development Process Barbara Walton, GSFC
II:00 am Overview of Current MITRE Effort Terry Kuch/Rick Sakamoto,MITRE
12:00 pm Lunch
1:15 pm User Requirements for ADS Standards Paul Clemens, MITRE
2:15 pm Refreshment Break
2:30 pm ADS Pilot Methodologies as Candidates Paul Giragoslan/Tom Burnsfor ADS Standards MITRE
3:45 pm Panel Assignments and Introduction Barbara Walton, GSFC
Subject: Standards Needed to InterconnectADS Pilots for Data Sharing
Panel A - Catalogues, Directories, and DictionariesPanel B - User Interfaces
Panel C - Use of ISO Open Systems Interconnectlon-Basic Reference Model
Panel D - Data Formats and Descriptions
Table i-I (continued)
4:00 pm Panels Convene
6:30 pm Dinner - Speaker: James Burrows, Director
Institute for Computer Science andTechnologyNational Bureau of Standards
Mr. Burrows will speak on the National Bureau of Standards Data SystemsStandards Program.
Thursday, May 28
9:00 am Panels Reconvene
10:30 am Coffee Break
12:00 pm Lunch
1:15 pm Panels Reconvene
3:00 pm Refreshment Break
3:15 pm Joint Discussion of Panels' Progress
4:00 pm Panels Reconvene
Friday_ May 29
9:00 am Panels Reconvene
I0:00 am Panel Reports and Joint Discussion
11:30 am Conclusions
- Workshop Summary Barbara Walton, GSFC
- Action Items John Kiebler, NASA HQ
12:00 pm Adjourn
NEAR-TERMGOALFOROSTA/ADS- PROVIDETHECAPABILI_FORINTERCONNECTING
THEPILOTSFORDATASHARING
OBJECTIVESOFTHEOSTA/ADSDATASYSTEMSSTANDARDSWORKSHOP- MAY1981
1, ESTABLISHREQUIREMENTSFORSTANDARDSINTHEFOLLOWINGAREAS
A - CATALOGUES,DIRECTORIES,ANDDICTIONARIES
B - USERINTERFACES
C - USEOF ISOREFERENCEMODEL
D - DATAFORMATSANDDESCRIPTIONS
2, REVIEWTHECOMPILEDMETHODOLOGIESOFTHEPILOTSFORACCURACYAND
COMPLETENESSANDMAKEPRELIMINARYASSESSMENTOFTHEIRADEQUACYIN
MEETINGTHESESTANDARDSREQUIREMENTS,
3, MAKERECOMMENDATIONSFORFUTURESTANDARDSWORKANDNEEDFOR
CONTINUINGSTANDARDSWORKINGGROUPS,
Figure 3-I
BAW5/12/81
4.0 OSTA DATA SYSTEMS PLANNING WORKSHOP RECOMMENDATIONS - Dick desJardins,CTA
The purpose of the OSTA Data Systems Planning Workshop held at WallopsIsland on October 9-12, 1979 was to recommend a data system concept and
requirements to OSTA. A great amount of time was spent trying to find out
"What is a data system concept?" A concept includes "a means foridentifying the work that has to be done, identifying the relationships
between the people who had to do the work, and some kind of a
modularization scheme for the system." The purpose of flying spacecraft isnot to fly hardware but to build data sets from remote sensing. Panels
were composed of people who had problems and people who had solutions; the
Data Systems Panel served as an integration function. All disciplines inthe OSTA were represented as shown in Figure 4-I.
Figure 4-2 summarizes the Integrated Discipline Requirements identified by
the OSTA Workshop participants as presented in the following paragraphs.
Quality data sets are needed which are clean, useful, and processable.Either the project or discipline must produce parameter data sets (of
physical phenomena) which meet the program objectives. There are problems
with data: OSTA needs a systematic treatment of problems with present
data. In the operations phase, scientific data management personnel shouldbe responsible for the quality of the product,'the planning of the product,
and seeing that users get the data that they want. The pedigree of the
data is important; data from a sensor are useless as is. Sun angle,calibration, algorithms for parameterizations, etc. are needed.
OSTA needs a single integrated data catalog or "Master Directory." ADS
should be one means to access the catalog to help the researcher find out
how to get the data and avoid wasting time doing it. Since most of the
data exist, it is estimated that these would solve over 50 percent of theproblem.
0STA needs continuity of data formats. A single format is not needed;there should be a few, fairly standardized formats. Data levels should be
defined. Users should be able to select the format they want. (There was
a divergence of opinion expressed by participants. Either the formats nowexisting could be translated for the user--a value-ad-_ service--or the
onus is on the user--he translates the data; ADS just gets the data.)
OSTA needs to reference its data to a standard geographic and time basis.
Every piece of data should be marked with latitude, longitude, and altitude
(georeference), Universal Time. The user must be provided with at least aspacecraft clock and swath which are fundamental elements. The user also
needs codes/algorithms, clock to UTC, geographic algorithms, etc.
OSTA needs data delivery. Usually there is no need for immediate access to
data. What is needed is easy accessibility: ability to get data by meansof mail or electronic transmission. Some projects (operational
demonstrations) have found that real-time information is useful; eachproject has a "freshness" requirement.
. WORKSHOPHELDOCT 9'12,1979,AT WALLOPS
. PURPOSE: IDENTIFYAND RECOMMENDTO OSTAAN OVERALLDATASYSTEMCONCEPT
FORPROVIDINGUSERSOF INFORMATIONFROMEARTH-WATCHINGSPACECRAFTWITHTIMELYAND READILYUSABLERESEARCHDATA
o 6 DISCIPLINEPANELS: AGRICULTURE;LANDRESOURCES;HYDROLOGY;
GEOLOGYAND GEODYNAMICS;ATMOSPHERE;OCEANS
o 5 DATASYSTEMSPANELS:.OVERALLDATASYSTEM;ONBOARDDATASYSTEMS;DATAACQUISITION,DISTRIBUTIONANDOPERATIONS:INFORMATIONEXTRACTIONANDPROCESSING,AND USERFACILITIES;DATABASESTORAGEANDMANAGEMENT
Figure 4-i
ii ii i i ii i i
i. QUALITYDATASETS
, PROJECTSDELIVERTIMELYQUALITYDATA SETSAS SUCCESSCRITERION
• DISCIPLINE"PROJECTS"PREPAREQUALITYPARAMETERDATASETS
. RECTIFYCRITICALEXISTINGPROBLEMS
. INVOLVESCIENTIFICDATAMANAGEMENT
, PROVIDEDETAILEDANNOTATIONS,"PEDIGREE",WITHDATA
2. DATA CATALOG(S)
3. DATA FORMATS
. SEVERALSTANDARDFORMATSAND LEVELS
. USERSELECTABLEFORMATSAND LEVELS
. REFERENCEDTO COMMONGEOGRAPHICAND TIMEBASES(LAT/LONGAND UT PREFERRED)
4. DATADELIVERY
5. ARCHIVE(S)
6. COOPERATIONWITH USERAGENCIES
7. ORDERLYEVOLUTION
Figure 4-2
OSTA needs appropriate data archives to provide a place to store data.There is a need for uniformity in policy for keeping, indexing, or managing
that data. A policy of active archives is required. Scientific data
management should provide accessible data.
Cooperation with user agencies is necessary for 0STA. USGS and NOAA, as
examples, have similar needs and problems, and NASA needs to be in harmony
with operational data from other agencies. Very few of NASA's Applications
Programs are able to function in isolation. 0STA must implement research
in data input and data dissemination to meet its needs.
Figure 4-3 shows the overall 0STA Data System Concept, a simple concept
whose requirements include production of Level IA data sets. Workingstorage is provided for researchers. At the level shown in the figure, ADS
tells us what standards are necessary for making data available. ADS would
provide consultation and a Master Directory; this workshop is an example ofconsultation. Researchers need to be able to "get to the root of the tree"
in ADS. For long-term planning, the concept should be based on data sets.
The overall data system concept and recommendations are shown in Figure
4-4. The concept should be cost-accountable; it should produce Level IA
data sets. It could be phased over to commercial service. It was never a
concept for electronic data dissemination. The concept included browse
data, then place order. There was a fundamental problem with Level I. Thedata have to cost-effectively satisfy multiple objectives. There was a
need for a general policy. The policy recommended was to store all the
information that a user needs along with the raw measurement: sensor
measurement data, sensor ancillary data, calibration with instrument, etc.The data must be stored in a form such that original data may be recovered.
To do all this, 0STA needs a research and technology thrust!
8
ADS _ TOFLIGHT FEEDBACK
/ • STANDARDS _ PROJECTS -4/ • CONSULTATION '_ DATA ACQUISITION REQUIREMENT,';
foMASTER DIRECTORY_
! DATA SETS ! WORKING _ INFORMATION ! ,PROCESSING "X"v j = STORAGE WORKING
<t:¢c _ SYSTEM STORAGE USERS--O -5_ LEVEL1A !-J I A
IDATASETS5
I-" _ , 2+ 1A, 1B-- " LEVEL _ m m P" DISCIPLINE "Y"
I 2, 3. & I 2 INFORMATION I
I i_ j STORAGE 31- SYSTEM \ STORAGE USERSLEVEL1A
,,.o _ _ DATA SETS • I
_ OSTAr I 2+ REAL-TIME •I LEVEL I- ---- "_ "- " USERSI 2.3,& II DATA SETS WOR KING _ _ OSTA
STORAGE NON-REAL-TIME •SYSTEM LEVEL1A
DATA SETS USERS
NEW ARCHIVES ; A UI1COSTA
ARCIIIVE
Figure 4-3. OSTA Data System Concept
_ _ Bi..,_.i OSTAOVERALLDATASYSTEMCONCEPTAND RECOMMENDATIONSl i l ii i i i
e OSTAOVERALLDATASYSTEMCONCEPT
--RECOMMENDEDAS LONGTERMPLANNINGBASIS
--BASEDON DATASETSAS INTERFACESBETWEENPROGRAMMATICACTIVITIES
--COSTACCOUNTABLEPROJECTORIENTEDDATASYSTEMSTO PRODUCELEVEL1A DATA
--DISCIPLINEORIENTEDDATASYSTEMSTO PERFORMHIGHERLEVELPROCESSING
--ARCHIVESTO RETAINDATASETSANDMAKETHEMREADILYAVAILABLE
--COMMONDATACATAI,OGINGANDDISSEMINATIONNETWORKSERVICEo
o LEVEl_1 DAIA
o FLIGHTPROJECTRESPONSIBILITY
o DISCIPLINEINFORMATIONPROCESSINGSYSTEMS
ARCHIVE(S)
a APPLICATIONSDATASERVICE(ADS)
ENDORSEMENTOF DISCIPLINEREQUIREMENTS
INFORMATIONSCIENCER&T
Figure 4-4
5.0 THE ROLE OF PILOTS - J. Patrick Gary, GSFC
This workshop is effectively considered a working group for standards. The
OSTA/ADS Data System Concept was described in broad terms by Richard
desJardins. We no____wneed more detailed specification of hardware
interfaces, communications protocols, data exchange services, etc. Hence,this workshop should be viewed less as a formal review committee but more
as a working group to define areas within the data systems concept wherestandards are required.
The overall goals of the ADS Program, as shown in Figure 5-I, are broad.
OSTA data users require timely and effective access to needed data in a
uniform way. We must not overstandardize. OSTA has sponsored and is
sponsoring three pilot programs deeply imbedded in the scientificdisciplines: at GSFC, the Atmospheres Pilot involved with severe storms
research, the VAS Demonstration project, and related atmospheres programsin weather and climate research; at JPL, the Oceans Pilot starting with an
interest centered around Seasat data; and at JSC, the Resources Pilot tiedstrongly with the AgRISTARS program.
These pilots are planned to evaluate the utilization of current techniquesand technologies in the use and exchange of data and to facilitate access
to data (DBMS, Data Management, etc.). Figure 5-2 shows the common goals
and objectives of pilots. Specifically, the pilots are to provide
demonstrations of the use of advanced technologies, provide a test-bedenvironment for data handling technique evaluation, evolve ADS requirements
and capabilities (long-term goal), and where applicable, document validated
methodologies as standards and guidelines for OSTA data systems planninguse. The pursuit of all of the above objectives is to be carried out under
the prime directive to apply technology in a service capacity in support of
the data handling research programs of theapplication disciplines. Thethree pilots, when they interconnect, have a chance to "test bed"
distributed processing anddata sharing concepts needed to meet ADS
near-term requirements. In time, they will come to test conceptsapplicable to much of NASA.
Figure 5-3 shows the Promotion of ADS Concepts through Pilot Data SystemsActivities. There must be feedback: Does the data handling concept serve
the data users' need? Four areas relating to the technical concepts are:I) User-oriented catalog system, _2) Data set management, 3) Networkcommunication system, and 4) User interface.
Figure 5-4 shows the near-term requirements to be accomplished by the ADSProgram. To interconnect the ADS pilots for data sharing, two keyfunctions are needed: I) Users must know what data are available, and 2)
Data must be exchaugeable among facilities. No utopian systems are plannedin the near-term, where processes or algorithms are exchanged or forms of
load leveling are attempted, but these concepts may need to be addressed inthe future.
The relationship of pilot program activities to the standards development
process is shown in Figure 5-5. Inputs and evaluative criticism from the
users, pilots, and Headquarters are required in the standards developmentprocess. The process starts with requirements for standards, but we must
11
SUMMARYOFOVERALLADSPROGRh_
GOAL
- PROVIDEOSTADATAUSERSWITHTIMELYANDEFFECTIVEACCESSTONEEDEDDATA
ANDINFORMATIONWITHINANDOUTSIDEOFNASA
- PROVIDESTANDARDS/GUIDELINESFORFUTUREOSTAPROGRAMSTOEVOLVEDATA
SYSTEMSANDDATAMANAGEMENTTOWARDSCOMPATIBILITYWHERE.APPROPRIATE
APPROACH
- EVOLUTIONARYDEVELOPMENTTHROUGHPILOTSTOMEETAPPLICATIONSUSERREQUIREMENTS
OSTA/ADSPILOTS RTOPMANAGEMENT
ATMOSPHERESPILOTSYSTEM GSFC
OCEANSPILOTSYSTEM JPL
RESOURCESPILOTSYSTEM JSC
CONCEPTS
- USERACCESSTOINFORMATIONABOUTDATAANDTOTHEDATAITSELFTHROUGH
o APPLICATIONOFDATACATALOGINGANDMANAGEMENTTECHNOLOGIESl
o INTERCONNECTIONOFAPPLICATIONSDATASYSTEMSTOFACILITATEDATAEXCHANGE
Figure 5-1
COMMONGOALS/OBJECTIVESOFOSTA/ADSPILOTS
o PROVIDEUSEFULDEMONSTRATIONSANDCAREFULEVALUATIONSOFCAPABILITIESTOLINKDATA
USERSANDPRODUCERSFORSELECTEDOSTAPROGRAMS
o PROVIDETESTBEDSTOEXPLORETECHNOLOGIESANDTECHNIQUESFORCATALOGS,DATAORDERING,
DATAEXCHANGE,ANDOTHERRELATEDADSCONCEPTS
o EVOLVEANDVERIFYTHEREQUIREMENTSANDSPECIFICATIONSFORAFUTUREFULLCAPABILITYADS
o DEVELOPSTANDARDSFOROSTADATASYSTEMSINCOOPERATIONWITHOTHERNASAPROGRAMOFFICES
ANDOTHERAGENCIES
Figure 5-2
PROMOTIONOF ADS CONCEPTS
THROUGHPILOT DATA SYSTEMSACTIVITIES
IDENTIFICATION PROTOTYPE OSTA/ADS
AND CAPABILITIES DATASYSTEM
ANALYSIS OF SPECIFICATIONS,l/
• REQUIRED IMPLEMENTATION STANDARDSAND
CAPABILITIES ._ GUIDELINES
• , sYsTE.DE.O,STRATIO.SIK
_. USEREVALUATIONS I "_ -I
ADS TECHNICALCONCEPTS
o USERORIENTEDCATALOGSYSTEM .= o NETWORKCOMMUNICATIONSYSTEM
- INFORMATIONCONTENT/ORGANIZATION - HIGH AND LOWSPEEDLINES- CREATE/UPDATECATALOGENTRIES - ISO LAYEREDDATA SYSTEMINTERFACES- INTERACTIVE CATALOG ACCESS - .USAGE STATISTICS MONITORING- CATALOGACCESSSECURITY - 'GATEWAYSTO OTHERNETS
o DATA SET MANAGEMENT o USER INTERFACE
- ON-LINE/OFF-LINE STORAGE - HELP FUNCTIONS- FILE PROTECTION/ACCESSPRIVILEGES - LOCAL/REMOTECATALOGQUERY- SELECTIVE DATA SUBSETTING - DATASET ACCESS/EXCHANGE- DATA EXCHANGEFORMATS - LOCAL/REMOTEPROCESSINITIATION
Figure 5-3
NEAR-TERMADSREQUIREMENTS
o INTERCONNECTADSPILOTSFORDATASHARING
-_PROVIDEUSERACCESSTO INFORMATIONABOUT
AVAILABLEDATA
- PROVIDEDATASETACCESS/EXCHANGE/DISSEMINATION
AMONGSYSTEMS
Figure 5-4
RELATIONSHIP OF OSTA/ADS PILOTS TO THE STANDARDS DEVELOPMENT PROCESS
OTHER SOURCES NEEDS OF PILOT PROJECTS
OSTA/ADS PILOTS
APPLICATIONS DATA SYSTEMS/TECHNIQUE DEVELOPMENT, TESTAND EVALUATION
METHODOLOGIES
REQUEST FORNO TEST/DEVELOPMENT
ANALYSISAND
EVALUATION
EX ISTI NG STDS&GUIDELINES ~~~---~------~
STANDARDSESTABLISHMENT
SPECIFICATIONS
OSTA/ADSSTANDARDS &GUIDELINES
Figure 5-5
not overstandardize. Standards are useful to describe I) How to describe;2-V-How to build; and 3) How to apply. Should ADS find that the currentstandards or methodologies are not adequate or applicable to its needs, thepilots can test new methodologies or proposed standards and develop them.The establishment and dissemination of standards is a high level managementfunction (0STA, NASA). A result of this standards development processfeeding back to the pilots will be standards useful to the design and thespecification of new systems.
Figure 5-6 shows the overall ADS development approach with its gradualexpansion of capabilities. The process is iterative; feedback to and fromworking groups, such as a standards development working group, is essentialfor progress. FY84 is planned as a target completion date for thedevelopment of an ADS working model.
17
ADSPROGRAMREVIE_'I
.ADSBEVELOPME_'ITAPPROACH
REQUIREMEIITS:REFINED- OUANTIFIED
C'_ I NEW Ti
CON WORKING RFOIHRFMFNGROUPS
o USERSDEVELOPERS
o TEST /I S!IOP A!;S / F_!
\/ o STANDARDS ' r', .....
PLANNING 1 PILOT 1 ' WORK ITECII''O'U'''/
ArID o CONSULTANTS P,F._tttT._I !ARIDST,_5_
COOI'alNATION BED IE',//!LHATlOr.I1 17 i:Y?-,O
o NASAIIQ ,_ o USERS o WORKIIIG5ROUPS [7.X_A[IDEDii/o GSFC o DEVELOPERSo R&DGROUPS Pil.nT
IV
o JPL o STANDARDS i°i_!-RATIP'flSo _EIIUSERS
o JSC .,,,IRESEARCH o IffTi-_',Cn_i_iECTAND NEW ?ILOTS
CO IIFVrw_.'rr'rr TECHNOLOGYo UNIVERSITIES APPLICATIn_'ISo DEVELOPERS
o CONSULTANTS
Figure 5-6
6.0 THE OSTA/ADS STANDARDS DEVELOPMENT PROCESS - Barbara Walton, GSFC
The goals of the OSTA/ADS Data Systems Standards Program were formulated inresponse to the need for standards for sharing data. The overview of the
program is shown in Figure 6-I. Applicable standards of the National
Bureau of Standards and other existing standards can be used, but ADS and
OSTA have unique problems. NASA has already dealt with some of the unique
problems, such as the Landsat images CCT (Computer-Compatible Tape)standards; however, there are other development efforts that NASA will be
dealing with in the near future. The coordination with the 0STA programs
and the pilots is an objective of the Program.
Figure 6-2, dated August 1979, lists the requirements for the OSTA data and
data systems standards at that time. In August of 1980, I began work on
ADS standards and developed a phased approach to the problem. In FY82 andFY83 the focus will expand to include all OSTA data systems. Hopefully, inFy84 and beyond there will be a "full" 0STA/ADS Standards and Guidelines
production.
Resources of the OSTA/ADS Data Systems Standards Program are shown in
Figure 6-3, which is an organization chart of parts of NASA. At Goddard we
have standards efforts in Cataloging, under Karen Posey; PADS is directed
by Pat Gary; Dave Howell is the head of TAE; and, the GSFC Aerospace Data
Systems Standards Program (not shown) is directed by Bill Poland.
The three phases of the Approach to OSTA/ADS Data Systems Standards Programare shown inFigure 6-4, What has been done? The standards survey, user
requirements, methodology survey, and evaluation criteria are all FY81
Phase I projects. "Candidate" standards will be produced and the results
are due to be published in August of this year. The following remains tobe done: ADS planning, interim standards, a concept for implementation of
a "Core ADS", definition of 0STA data systems policy, and full-capabilityADS definition.
Results are shown in the Phase I (Figure 6-5) chart. This is basically
this year's program which builds on the results of the OSTA Workshop and
the feasibility study reported on by Dick desJardins. Standards surveys,
examination of pilot methodologies, and criteria development have been
done. At the workshop today we hope to review/modify/evaluate these
processes so that those standards which might be applicable to ADS maybecome candidate standards for ADS.
Figure 6-6, Phase 2, shows the expanded focus on OSTA data systems and
"Core ADS_" Figure 6-7, Phase 3, focuses on the future goal of a
"full-capability ADS." Once we get a full set of standards, we will needto have a systematic review and periodic update. Standards will evolve as
needs evolve; the ADS effort will continue to grow.
19
O_STA/ADSDATASYSTEMS.STANDARDSANDGUIDELINESPROGRAMOVERVIEW
GOAL
• PROVIDEEFFECTIVEDATAEXCHANGEANDDATASYSTEMINTERFACE
STANDARDSANDGUIDELINESFOROSTAPROGRAMS
• IDENTIFYANDRECOMMENDUSEOFDATASYSTEMSTANDARDSAND
o GUIDELINESAPPLICABLETOOSTA/ADS
• DEVELOPANDMAINTAINOSTA/ADS- UNIQUEDATASYSTEM
STANDARDSANDGUIDELINES
. COORDINATEWITHOSTAPROGRAMS,ADSPILOTSANDPERTINENT
STANDARDSACTIVITIESWITHINANDOUTSIDENASA
Figure 6-I
BAW 1/13/81
DSTADATAANDDATASYSTEMSSTANDARDSREQUIREMENTS
, USERTERMINALS(INTERFACESANDVIRTUALTERMINALPROTOCOLS)
0 DATASYSTEMS(FILESTRUCTURE,DATAMANAGEMENT,ANDACCESSPROTOCOLS)
e FORMATS(DATAREFERENCEFRAMES--GEOGRAPHIC,TEMPORAL;DATAFORMATS,
CODESANDCONVENTIONSINCLUDINGGEOCODINGSTANDARDS)
e LANGUAGES(INTERACTIVEDATAQUERYLANGUAGE,DATADESCRIPTIONLANGUAGE--
DATADICTIONARY)
, DIRECTORIES/CATALOGS(PRODUCERANDUSERDATASOURCESANDPRODUCTLISTS
WITHLOCATIONSANDACCESSINGINFORMATION)
o INTERCONNECTION(NETWORKPROTOCOLS,INTERFACES,ANDGRADESOFSERVICE)
e DATAPREPARATION(STANDARDLEVELSOFVALIDATIONPERFORMEDANDCERTIFICATION
CRITERIA;STANDARDDEFINITIONSOF INFORMATIONLEVELS)
.o SOFTWARE(SOFTWAREENGINEERINGSTANDARDS,STANDARDSOFDOCUMENTATION) A
Figure 6-2 i00.7 8/13/79
OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM
WORKING RELATIONSHIPS
NASA
II I I I
I I I " "cIOSTA GSFC _C_NS1 rEART"RESOURCES1CODE E L PILOT J [ PILOT J
I '_(TO BE EXPANDED) /I IMISSION & DATA
COMMUNICATIONS APPLICATIONS OPERATIONS& INFORMATION DIRECTORATE DIRECTORATE
DIVISIONCODE 900 CODE 500
CODE EC-4 I IINFORMATIONI PROCESSING DIVISIONINFORMATIONP_ DATA SYSTEMS EXTRACTION CODE 560
BRANCH DIVISION FRANK KEIPERT. CHIEFCODE 930 JOHN SOS, ASST. CHIEF
CODE ECD-4 (DR. PAUL SCHNECK, . BOB NELSON)" ,(PETER BRACKEN, CHIEF) INEEDS PROGRAM
CHIEF) [
I I I I
I DATA SYSTEMS :
DEVELOPMENT _ INTERACTIVEJOHN KIEBLER INFORMATION SYSTEMSBILL SHAFFER MANAGEMENT BRANCH DEVELOPMENT
TONI VILLASENOR BRANCH CODE 934 | BRANCHAI FANG GERALD KNAUP, HEAD]
CODE 931 " (ADS MGRJ I CODE 933
PREPARATION I (BARBARA WALTON) GROUND SYSTEMS I APPLICATION I
SECTION. CODE 931.1 I r ADS STANDARDS ] DEVELOPMENT J SECTION, CODE 933.1
KAREN POSEY, HEAD} I [.& GUIDELINES MGRJ SECTION, CODE 934.1 II (DAVE HOWELL,rTAE] HEAD)]_NEEOSID_MS}I _PATGARV.HEAD_
L_DBMS J j [PADS]
.Figure 6-3
APPROACHTOOSTA/ADSDATASYSTEMSSTANDARDSPROGRAM
PHASE1 - FY81
FOCUSONADS
ASSESSREQUIREMENTS
SURVEYEXISTINGSTANDARDSANDGUIDELINES
EXAMINEPILOTMETHODOLOGIES
DEVELOPSTANDARDSEVALUATIONCRITERIA
PRODUCE."CANDIDATE"STANDARDSANDGUIDELINES
PHASE2 - FY82AND83
EXPANDFOCUSTOOSTA
DEVELOPIMPLEMENTATIONANDMAINTENANCEPROCEDURES
SPECIFYMAJORSTANDARDSDEVELOPMENTEFFORTSFORNEAR-TERMADSGOALS
PRODUCE"INTERIM"STANDARDSANDGUIDELINESFOR"COREADS"
PHASE 3 - FY84ANDBEYOND
CONTINUESTANDARDSREQUIREMENTSASSESSMENT
EVALUATESTANDARDSAS TESTEDIN PILOTS
PUT IN PLACEIMPLEMENTATIONAND MAINTENANCEPROCEDURES,REVIEWBOARDS
AND POLICY
PRODUCEOSTA/ADSDATASYSTEMSSTANDARDSAND GUIDELINESCAPABLEOF
SUPPORTING"FULL"CAPABILITYADS
Figure6-4 _AW4127181
OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM.
PHASE 1 - ADS FOCUS
REVIEW PRIOROSTA RESULTSRELATING TO
EXISTING
STANDARDS _ REVIEWPROCESSAND
DETERMINEADS _ RESULTSSTANDARDS _ __ •
REQUI REMENTS EXAMINEPILOT
METHODOLOGIES
MODIFY ASNEEDED
__ DEVELOP
EVALUATION CANDIDATECRITERIA EVALUATE ADS DATA
STANDARDSAND _ SYSTEMSSTANDARDS
METHODOLOGIES AND_._ GUIDELINES
Figure 6-5
OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM
PHASE 2 - OSTA/CORE ADS FOCUS
DETERMINE _ I W I_ _ IMPLEMENTATION L EVALUATEOSTA/ADS - _ CANDIDATE _ " OF PRIORITY _. _ EARLY _,
REQUIREMENTS _ ADSS&G _ /_ _ CANDIDATE S&G _ _ RESULTS I_
__ I _X_X_\\\\\\\\\\\\\_STANDOSTA/ADSETE DARMRINDSE SPECIFYDSTANDARDSEVOSTA/ADSELOPMEMAJORNT _ ____\\\\\\\\\\\_DEVELOP REOUIR EMENTS EF FORTSOSTA DATA INTERIM
SYSTEM CONCEPT OSTA/ADSDEFINING DATA SYSTEMS
ADS r STANDARDSINTERFACES AND
GUIDELINES
DEVELOPPROCEDURESFOR
DEVELOP DETERMINE MAINTENANCEADS SUBSET & IMPLEMENTATION
FUNCTIONAL FORDEFINITION CORE ADS "
RECOMMEND _ SPECIFY
STANDARDS STANDARDSPOLICY DATA BASE
Figure 6-6
.. OSTA/ADS DATA SYSTEMS STANDARDS PROGRAM
PHASE 3- OSTA/FULL ADS FOCUS
/ '="'=E""LS&G TO _ _ [_, I _ I_
F0 RM _ _\\\\\\_,\\\\_ I __--kk_ ENHANCE
/ COREADS I - __ _ CORE ADS I_\\_\\_\\\\\\_' _ EV...... _"_ I _. _,'_A LUATE _ _X_\\\\\\\\\\\\\_,"_
E_ *\\\\\\\\\\\\\\'_,\\\\\\\\\\\\\\'_ /COMPLETE ___ " /
_o _ OSTA/ADS _ • /o_ _ STANDARDS I_ /
DEVELOPMENT [_ /
/ EFFORTS / /___ " l
COMPLETE
OSTA/ADS I MAINTAIN
__ DATA SYSTEMS STANDARDS
IMPLEMENT STANDARDS _ ANDSTANDARDS AND GUIDELINESDATA BASE GUIDELINES
1
Figure 6-7
7.0 OVERVIEW OF THE CURRENT MITRE EFFORT - Terry Kuch/Rick Sakamoto, MITRE
Following is a summary of the first of three MITRE presentations at the
workshop. View graphs used in this presentation are reproduced inAppendix A.
Terry Kuch and Rick Sakamoto presented _n introduction to MITRE's supportof the OSTA/ADS standards and guidelines program. The three MITRE
presentations at the workshop dealt primarily with functions needed for
near-term data sharing among ADS member systems. Sharing of computationalfacilities and software were considered to be longer-term ADS goals.
MITRE adopted a logical view of ADS as a distributed system, which
distinguishes among seven components of such a system:
o Members
I) Providers of data
2) Providers of applications software
3) Providers of computational facilities
4) Users of data, software, or computational facilities
o Support services
5) Administrative services
6) Technical services such as documentation and location support
for data, software, and computational facilities
7) Support for data communication
Based on this logical view, MITRE developed a hierarchical classification
scheme of ADS features at a level of detail (70 nodes) appropriate to the
level of detail addressed by most Federal, national, and international
information processing standards.
This feature classification provided' the framework for a preliminary
assessment of the applicability of Federal, national, and internationalstandards to ADS. These standards were gathered, screened, and documented
briefly. Some 300 standards were examined, of which 187 were reported in
NASA contractor report CR 166675.
This survey of standards was enlarged to incorporate standards from NASA
Headquarters and centers. At the same time, two key efforts wereinitiated to:
o Survey methodologies of the three ADS pilots.
o Identify the requirements for standards of ADS members based on
a survey of the pilots and on representative potential futuremembers.
27
Preliminary results of the requirements survey were used in the developmentof criteria for the evaluationof candidate standards for 0STA/ADS. Anevaluation process was designed incorporating these criteria.
Anoverview of the evaluation process was presented in this session, and
examples of candidate standards were passed through the process_
7.1 GOALS OF THE SESSION
The goals of this session were to familiarize those attending the workshop
with MITRE's work in support of ADS, and to invite comment on this work,especially on:
o Applicable standards
o Evaluation process
o Evaluation criteria
7.2 PRESENTATION DISCUSSION
Dr. Adrian Hooke asked, "With reference to view graph 4, what happens whenyou do items 3 and 4 and find a requirement for standards that doesn't fitin item 5?" °
Terry Kuch replied that in this case a standard should be developed outsidethe flow shown in the diagram, perhaps under contract.
Richard desJardin commented that*the principal recommendation of the OSTA
Data Systems Planning Workshop is missing from the current standards effort :
- QUALITY DATA SETS. The main thing programmatically you have to tellpeople is what constitutes quality.
Quality is: Description
Annotation and_Pedigree
Certification andAlgorithms used to process the data
Where is the policy standard?
William Shaffer replied that it is a policy standard. There are two points
to be made here: First, it hasn't been done [in the pastS. Second,
Goddard has changed that and it is being done--for 3 months already.
Project Managers are responsible for their data--for quality data. BobLynn has solved this.
After further discussion, which pointed out that the current effort is on
ADS and that this is an OSTA problem, Richard desJardin agreed to draft a
recommendation for consideration by this workshop which was later adoptedin the closing session (see Section 15.O).
28
Anthony Villasenor commented that NASA Headquarters takes the position that
the purpose of this workshop is to evolve standards for ADS. The OPEN/UARSprograms point the way. There is a need for creating data and the
management of data--a realizable goal. We hope the workshop will give
input to which standards will be policy, which will be technical.
William Poland observed that the chart on characteristics is deficient and
needs augmenting.
Gerald Knaup commented on what is and is not a standard--we don't have a
standard catalog, rather we want to look at a number of technologies to
implement. We can then come up with areas and a cooperative agreement, not
a rigid standard.
Tony Villasenor said that for the full ADS, Headquarters needs and expectsa commercialized service. A specification on this service is needed for an
ADS interconnection. We will need it by Phase 3. The ultimate ADS will be
a commercial service, not government service.
29
8.0 USER REQUIREMENTS FOR ADS STANDARDS AND GUIDELINES - Paul Clemens,MITRE
Paul Clemens presented the results of a survey of ADS member requirements
for standards and guidelines; his view graphs are in Appendix B. Thissurvey was carried out in four steps:
o Identify a representative number of planned and prospective ADS
members from ADS pilots, key 0STA programs, and other sources.
o Survey the identified members.
o Define and document members' needs for ADS system capabilities andservices.
o Derive ADS standards and guidelines requirements from this surveyof members' needs.
The survey included the interpretation and analysis of functional
requirements from three sources: (I) earlier 0STA/ADS data system studies,(2) current ADS pilot activities, studies, and documentation, and (3)
prospective ADS members' activities and documentation. Requirements ineach case were then reviewed and modified as needed to reflect the overallscope of ADS.
The resultant requirements were then tabulated and mapped into the ADS
feature classification. The findings were analyzed for commonality of
purpose and function and, from this analysis, overall standards
requirements were determined.
This session prioritized requirements in the areas to be addressed by the
workshop panels: data catalogs, user interfaces, the IS0 model for opensystems interconnection, and data formats.
8.1 GOALS OF THE SESSION
The goals of the session were to elicit comments on the adequacy of MITRE'sfindings, especially as to:
I) Functional areas requiring standards,
2) Utility and applicability of the identified requirements forstandards,
3) Completeness of the survey as presented, and
4) Any misrepresentations in the survey and analysis.
8.2 PRESENTATION DISCUSSION
A question from the audience at the end of view graph 50: Is it more
fruitful to describe data formats and not data elements? One may argue the
point that some need data elements described, too. A solution might be to
say rather, that it is "sufficient for standardization requirements."
3O
Paul Clemens agreed that this is a good point.
Another question asked from the audience: If you know what to do, do you
carry it out in an optimum way--on the satellite, ground, or air?
Barbara Walton replied that ADS does not preclude doing sorting(for
example) on the spacecraft.
31
9.0 ADS PILOT METHODOLOGIES AS CANDIDATES FOR ADS STANDARDS - Paul
Giragosian, MITRE
The third MITRE presentation was made by Paul Giragosian; his view graphsare in Appendix C.
At various stages in their development, the ADS pilots have implemented orplanned to adopt certain practices, procedures, standards, or conventions.
The collection of these practices as applied toward a specific developmentfunction or operational objective constitutes the notion of a
"methodology."
This session presented the results of a survey of the methodologiesemployed by the ADS pilot programs (Atmospheres, Oceanic, Earth Resources).
MITRE surveyed, identified, and documented methodologies for each of the
ADS pilot systems. Major methodology categories include:
o Methods for system interconnection
o User interface
o System directory/catalog structure
o Data definition/structure
The primary objective of the survey was to provide an information base for
the evaluation of these methods and their applicability to the futuredevelopment of ADS standards and guidelines.
An illustrative example of Pilot communications methodologies follows:
The Pilot Atmospheres Data Systems (PADS) has been implemented on three
Digital Equipment Corporation (DEC) applications processors: two PDP
11/70 and a VAX 11/780 in a star configuration with a DEC PDP-11/34
functioning as the central communications processor. User terminals are
hardwired to the applications processors.
Communication is accomplished using the Remote Services Subsystem (RSS) and
a communications software package, COMM. These software packages were
developed specifically for PADS. On-site processor communication uses theDigital Data Communications Message Protocol (DDCMP) while off-sitecommunication will use a subset of the ANSI Advanced Data Communications
Control Procedure (ADCCP) protocol.
The Earth Resources Pilot uses the IBM bisynchronous protocol with the IBM
communications package, Remote Spooling and Communications Service (RSCS)to transmit and process data sets within the Earth Resources Data
Applications Network. The network is composed of two host processors: an
IBM 3031 with a front-end 3670 COMTEN communications processor at PurdueUniversity and an AS/3OO0 with a front-end 3650 COMTEN communications
processor at the Johnson Space Center. Two 9600-baud lines connect the
hosts. User communication is accomplished using 300-baud and 1200-baudlines asynchronously linked to either host.
32
The Oceanic Pilot System hardware configuration consists of a DEC VAX
11/780 with a PDP 11/44 serving as a front-end communication processor.
Users communicate via 300-bit/sec and 1200-bit/sec asynchronous lines. Thesystem will utilize Digital Equipment Corporation's DECNET communi_ationssoftware.
9.1 GOALS OF THE SESSION
The goal of the session was to obtain critical assessment of the
completeness and accuracy of the pilot methodology survey.
9.2 PRESENTATION DISCUSSION
Following view graph 8 on PADS, a member of the audience asked if the
Communications Package (COMM) of the Pilot Atmospheres Data Package (PADS)will be tied to commercial use.
Paul Giragosian replied that both COMM and RSS (Remote Services Subsystem)serve layers within the OSI model and will also be used as a basis forinterfacing with a commercial network.
Bill Shaffer asked how far along the PADS/System of Networked ApplicationsProcessors (SNAP)is.
Paul answered that it is now running in the current initial configuration.
Bill Shaffer asked about the need for standards for SNAP.
Pat Gary replied that dissimilar DBMS exchange has demonstrated that afile format structure standard was needed. The Pilot Climate Data Base
Management System (PCDBMS) will manage different information. This is also
a problem. So we really need standards now.
A member of the audience commented (after view graph 21 on PADS attribute
mapping) that the PADS "Superset" approach works for a smaller set and
asked, "What is now meant by a 'small' set? Big?"
Dr. Samuel Steppel replied that there are 200 bytes per slot. About 60
spare attributes now exist (some in 2, 4, 8-byte attributes). The
advantage is that each system worries only about its own attributes--no
translation. If we had lots of data though, it is no good.
Portia Bachman asked, in reference to view graphs 30 and 31, how the database for all of ERPS is accessed.
Paul answered that we use CMS to get the catalog. Then we use the catalogto search the entire data base.
Edward Greville asked (after view graph 37) if DECNET currently supportsPCL-11.
John Johnson answered that the present phase of it does.
33
Pat Gary (after view graph 40) commented: "You Eat OPS_ won't use it
ESFDU_ internally? Why abandon it?"
John Johnson replied that we will probably use what's already there becauseof convenience.
Dr. Dennis Fife, (after view graph 53) asked if there is any precedence or
prototype for this SFDU.
Dr. Edward Greenberg stated that we will steal from any standard that
exists. There is a draft in the NASA Office of Advanced Space Technology
(OAST).
Adrian Hooke commented that we are trying to draft this as a new standard.
Someone from the audience asked why this is highlighted if it is not being
used? How do you pace this development? Before JPL puts out standards, weshould take a breath.
Adrian commented that this [SFDU_ was mission unique but this uniqueness
will go away.
Ed Greenberg commented that this was to be used to use data; it is an
expandable set. You hope to have it in a good form for cataloging. We are
still in the process of understanding how to pick a version.
After the conclusion, someone in the audience asked how the strengths [of
the pilots] were developed, and was answered that the goals of the pilotsconditioned these. As an example, Dr. James W. Brown commented that the
thing that drove OPS was the idea of the pilot as a data archive _active),with active access to subsets. The idea of data management gives the
impression of a large number of small data sets ... whereas Oceans Pilot
has a small number of very large data sets. The pilots are just different.
Ed Greene stated that he has sympathy with the SFDU approach but the
concept is still immature. Trying to impose a structure now would stiflethe innovation. It's still developing.
34
10.O PANEL ACTIVITIES
Barbara Walton presented the introduction to the panels as shown in Figure10-I. She then gave the panel assignments as shown in Figure 10-2. Thepanels convened briefly before breaking for dinner.
James Burrows, Director of the Institute for Computer Science andTechnology of the National Bureau of Standards, was the dinner speaker onthe first day of the workshop. He discussed the NBS Data Systems StandardsProgram and emphasized the communications protocol development program.
He offered an inside view of the European Standards effort and noted thatU.S. companies use Europe as a forum due to anti-trust laws. He explainedthe National Telecommunication Information Administration (NTIA)/NationalBureau of Standards (NBS) relationship within the Department of Commerce.One comparative example illustrated that government communication services
such as telephone, telegram, and postal services are handled by onegovernment entity in most European countries, while in the United Statesstandards development for such services would go through the StateDepartment.
The panels continued their work on the following day with presentationsgiven by the panel chairmen on the last day of the workshop. The panelreports follow in Sections 11 through 14.
35
OSTA/ADSDATASYSTEMSSTANDARDSWORKSHOP
INTRODUCTIONTOPANELS
"STANDARDSNEEDEDTOINTERCONNECTADSPILOTSFORDATASHARING"
1_ CRITIQUETHEMITREREPRESENTATIONOFPILOTMETHODOLOGIESFORACCURACY
ANDCOMPLETENESS.D
2. IDENTIFYTHEREQUIREMENTSFORSTANDARDSANDGUIDELINESNEEDEDINYOUR
PANEL'SAREATOINTERCONNECTTHEADSPILOTSFORDATASHARING.
3. MAKEA PRELIMINARYASSESSMENTOFTHEADEQUACYOFCURRENTLYIDENTIFIEDPILOTMETHODOLOGIESANDEXTERNALSTANDARDSINMEETINGTHESEREQUIREMENTS.
4. IDENTIFYANYOTHERMETHODOLOGIESYOUAREAWAREOFWHICHMAYCONTRIBUTE
TOTHESOLUTIONTOYOURPANEL'SASPECTOFTHEPROBLEM.
5. MAKERECOMMENDATIONSFORFUTUREWORK,PROVIDINGDESCRIPTIONSANDESTIMATEi
OFEFFORTWHEREPOSSIBLE.'
6. PROVIDETHEPANEL'SCONSENSUSONTHENEEDFORA CONTINUINGWORKINGGROUP
INTHISAREAANDSUGGESTMEMBERSHIPTHEREOF.
Figure I0-i
STANDARDSNEEDEDTO INTERCONNECTADSPILOTSFORDATASHARING
PANELASSIGNMENTS
ROOM205FRONT PANELA - CATALOGUES,DIRECTORIES,ANDDICTIONARIES
CHAIRMAN.JOSEURENA,JPL- FTS792-3428
ROOM147 PANELB - USERINTERFACES
CHAIRMAN:JIMBROWN,JPL- FTS792-5109
ROOM200 PANELC - USEOF ISOOPENSYSTEMSINTERCONNECTION-
BASICREFERENCEMODEL
CHAIRMAN:EDGREENE,GSFC- 344-8685
ROOM205BACK PANELD - DATAFORMATSANDDESCRIPTIONS
CHAIRMAN:EDGREENBERG,JPL- FTS792-3387
Figure 10-2
11..O PANEL A REPORT: STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATA
SHARING FOR CATALOGUES, DIRECTORIES, AND DICTIONARIES
11.1 INTRODUCTION
One of the primary goals of the 0STA/ADS concept is to provide the user ofthe ADS service with coherent and comprehensive information about the data
that may be of interest to him. This information about the data (sometimescalled "metadata"), is usually made available in the form of electronic or
printed catalogs, dictionaries or directories. The objectives of this
panel were to specify the requirements for the minimum set of standardsthat are necessary for an effective sharing of information about data amongall the ADS member installations.
The meetings of the panel took place during the May 27-29, 1981 0STA/ADS
Data Systems Standards Workshop, and its membership consisted of the
following:
Jose Urena, JPL, Chairman Roy Saltman, NBS
Manju Bewtra, CSC Peter Smith, GSFC
Steve Haight, 0RI Ellen Stolarik, 0AO Corporation
Stan Klein, 0RI Frank Stone, 0A0 Corporation
Lou Kramer, LARS Barbara Walton, GSFC
Terry Kuch, MITRE Corp. James Wilkinson, Lockheed Corporation
11.2 REQUIREMENTS FOR GUIDELINES AND STANDARDS
The panel identified a preliminary set of requirements for guidelines andstandards that are described below. These requirements will be revised and
will eventually be used to develop guidelines and standards in subsequent
working sessions of the panel.
11.2.1 Layered Directory/Datalog Architecture and Definition of Terms
The panel found it necessary to identify and define a top-level repositoryof information about data upon which standards can be specified. The term
assigned to this "highest" level repository is "DIRECTORY."
DIRECTORY Definition: High-level description of data sets
available to all ADS users. The directory is accessed by meansof a standard user interface.
38
The detailed information about data resides in the "lowest" level
repository. The term "LOCAL CATALOG" was assigned to it:
LOCAL CATALOG Definition: Detailed description of data
sets. The local catalogs are maintained by the organization
that is also responsible for maintaining those data sets.
The structure below the directory may contain intermediate levels of
directories which are both local- and network-implementation dependent.
This potential requirement was not addressed by the panel.
The above definitions identify a structure with at least two levels.
Standards in the near-term need only to be specified for the top level(DIRECTORY).
The ADS Directory/Catalog architectural model is depicted in Figure 11-I.The user accesses the information in the directory by means of a standard
user interface, and logical links connect the directory with the local
catalogs or with the intermediate level directories. The dashed lines show
possible future logical links between the user and the local catalogs,
intermediate directories, and data sets, that would require new standardinterfaces. These interfaces are not being considered for ADS at the
present time, and they were not addressed by this panel.
Only those terms needed to support the model presented here have beendefined by the panel. The use of other terms such as inventory, or
terminology for intermediate directories is to be determined.
The use of terms presented here is compatible with the National Bureau ofStandards terminology, and it is consistent with some concepts used by the
International Standards Organization in the Reference Model for Open
Systems Interconnection.
The panel also agreed on the definition of the following term:
ATTRIBUTE Definition: A data element of a directory or a
catalog. _reference: FIPS PUB 20 for definition of the
data element. (I)I*
*(I) DATA ELEMENT: A basic unit of identifiable and definable information.
It has an identifying name and value or values for expressing a specificfact.
39
) _ REQUIREMENTS
ESTABLISHED
USERS _m REQUIREMENTSTO BE DETERMINED
"l" i
- ( ) --/ D,RECTOR_ _
c" _- / \ ,;__o I ' i_,DIRECTORY I I DIRECTORY I I
I ' [ j L ,, J, . I I
-c- i_c_l _c_oI I I t, I
L/'J/'j'DATA SETS DATA SETS DATA SETS
Figure ii-i. ADS Directory/Catalog Architecture Model
11.2.2 Standards Required for the DIRECTORY
The following is the set of requirements for standards that were identified
for the directory by Panel A:
a. Contents
I. Temporal and spatial coverage
2. Data type
3. Source
4. Responsible organization
a. Data generation
b. Data production
c. Data archival
5. Status (existing/planned)
6. Data level
7. Etc. (to possibly include an extensive list of additionalitems).
b. Structure
I. Standard format
2. Attribute representation
c. User Interface
I. Common query method
2. Interactive search of logical combinations of attributes andtheir values. All attributes are searchable.
d. Interface to lower levels
I. Short term: identification of local catalogs or intermediatelevel directories
2. Long term: transparent to user
41
e. Administrative responsibilities, policies andprocedures
I. Currency of directory
2. Quality assurance of directory
3. Access control
11.2.3 Definitions/Conventions for Terminology'of Directory Attributes
11.2.4 Guidelines for the Local Catalog
The diversity of implementations and the peculiarities of the localcatalogs used by the different ADS member organizations makes
standardization of the local catalogs unfeasible. The panel, however, has
identified a set of guidelines that can be specified for the local catalog:
a. Functions
I. Provide detailed description of data sets
2. Assist in obtaining access to the data
b. Document structure, access methods, etc.
c. Should provide definitions of terms used to describe the datasets.
d. Provide definitions/descriptions of data formats and cod_
conventions, etc. (see FIPS Pub. 20).
e. Contents should include an amplification of items I, 2, and 3under directory contents.
11.2.5 Directory User's Guide
11.3 RECOMMENDATIONS
11.3.1 Need for a Continuing Directory/Catalog Standards Working Group
a. Functions of the Directory/Catalog Standards Working Group:
I) Advise the ADS Standards Program on Directory/Catalogmatters.
2) Provide advisory review of contractor products related to
Directories and Catalogs.
b. Membership should include at least one representative from
each one of the pilots and the 0STA/ADS Standards Program.
c. The group should consider the need for a standard user interfaceto local catalogs and intermediate directories.
42
d. Investigate methods for incorporating terminology definitions
accepted by recognized discipline user bodies.
11.3.2 Need for a Directory/Catalog Implementation Working Group
a. Assessment of current ADS pilot methodologies to be done inthe future.
b. Studies for alternative implementation methods of the
directory. Selection of one.
c. Detailed design of the directory.
d. Determination of software functional requirements.
e. Design interface between directory and local catalogs of
pilots.
f. Consideration of library and information science methodologies
for its relevance. (See panel references.)
g. The directory could allow structured data retrieval andretrieval of unstructured indexed textual information.
e
11.3.3 Further Recommendations
a. Policy be set concerning the release of information about datato ADS.
b. Adoption or modifications of the WALLOPS definitions for data
levels (under area of work of Panel D on Data Formats and
Descriptions).
c. There is a need for continuing discipline user working groups.
d. Study alternatives to "in-person" meetings.
11.4 PANEL A PRESENTATION DISCUSSION
Pat Gary asked if it matters if the Directory is centralized.
Jose Urena answered that it is immaterial.
43
11.5 PANEL A REFERENCES
The following citations contain concepts relevant to the issues in the ADSdirectory system from a library and information science perspective.
I. Svenonuis, Elaine, "Directions of Research in Indexing, Classification,and Cataloging," Library Resources andTechnical Services, Jan./Mar.1981, pp. 88-103.
2. Foskett, Anthony C., The Subject Approach to Information, 3rd ed.,Hamden, Conn., 1977.
3. Lancaster, Frederick W., Vocabulary Control for Information Retrieval,Washington, D.C., 1972.
4. Thesauri and Thesauri Construction: ASLIB Bibliography No. 7, Compiledby Maxine MacCafferty, ASLIB London, 1977.
5. Kazlauskas, Edward J., "The Application of the Minicomputer toThesaurus Construction," Journal of the American Society forInformation Science, Sept. 1980, pp. 363-368.
6. "On Indexing, Retrieval and the Meaning of About," Journal of the
American Society for Information Science, Jan. 1977, pp. 38-43.
7. The Information Age in Perspective: Proceedings of the ASIS AnnualMeeting 1978, Vol. 15, 41st Annual Meeting.
8. Report on the Conference on Cataloguing and Information Services forMachine-Readable Data Files, Airlie House, Warrenton, VA, March 29-31,1978, Arlington, VA, Data Use and Access Laboratories, 1978.
NOTE: Citations I-7 were provided by Jody Engbretson, ORI.
44
12.0 PANEL B REPORT: STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR
DATA SHARING FOR USER INTERFACES
12.1 INTRODUCTION
Some key elements recommended prior to the workshop for the _anei's
consideration were: (I) Dial-up procedures, (2)Terminals (minimum,desirable, extended capability), _3) Common capabilities, (4) Language
interfaces (query, command, menu), and (5) Display capabilities. It was
the group's goal to identify the requirements for standards and guidelineswith regard to user interfaces for the near-term interconnection of the
pilots, bearing in mind that it must not cause any long-term problems. The
key elements listed were considered though not always as separatelyidentified topics.
The meetings of the panel were held on May 27-29, 1981 at the Goddard Space
Flight Center OSTA/ADS Data Systems Standards Workshop, and its membershipconsisted of the following:
James W. Brown, JPL, Chairman
Portia Bachman, GSFC
William Benton, Lockheed Corporation
Paul Giragosian, MITRE Corporation
Ronald Glaser, CSC
David Howell, GSFC
Richard Sakamoto, MITRE Corporation
William Shaffer, NASA Headquarters
David Stowell, 0A0 Corporation
12.2 DEFINITION OF USER
The "user," as defined for the purposes of this panel, though not
necessarily for the purpose of the whole workshop, is viewed as a
discipline scientist at a terminal trying to get data out of the network.
It is assumed that the user is primarily associated with one of the localsystems, such as VAS or the Ocean Pilot.
12.3 USER VIEW OF PILOT NETWORK
The panel discussed how the user views the network. Figure 12-I shows somepossibilities of the user's concept of the network services. Illustration
(a) shows the user terminal connected to each local system with ADS
invisible as a networking function. After discussing this arrangement, the
45
/
/ //O \,,./
(a} (b) (c)
O USER TERMINAL
O LOCAL SYSTEM ORLOCAL NETWORK
Figure 12-1. User View of Network Services
panel decided that it was probably not realistic; the user would probably
not view the system that way. Representation (c) of the system is more in
line with the long-term ADS picture. The users dial into a system called
ADS with its data system and information extraction services. However, in
the short term with the three pilots that we now have, that view is not
realistic. The resulting user view of the network systems is shown in view
(b). The user is aware of the ADS network added on the local system. Part
of the user interface will be influenced by the network and part will not.
This view does take into account the actual network as it is likely to
exist wit_ the three pilots.
In the short and intermediate term, users will connect to their "home"
system and obtain network services through it. Network services will be
visible to the user as separate from local system services. The interface
may have to be different, except where TAE or a similar "transportableexecutive" is used for both.
12.4 REQUIREMENTS FOR STANDARDS AND GUIDELINES
There is a need for a continuing oversight body for maintaining and
monitoring standards and guidelines. Standards should be self-enforcing;
guidelines not necessarily so--they must be monitored to see compliance.
There is a need for maintenance, and there should be some way to getfeedback as to whether guideines are Of any use or validity.
12.4.1 Dial-up Procedures
Figure 12-2 (a) shows that for a near-term view the network should not be
considered as transparent. This would reflect GSFC users connected to the
"GSFC network" and JPL users connected to the "JPL network"; this is not
realistic in the near term. Users connected to each local system and the
user view that each one of these local systems can connect in some way with
any other, independent of location, as shown in (b), is more realistic.
With the exception of such things as retrieval time and cost, it would not
be apparent to the user if the connection were by local or long-haul
network. Since users will connect to local systems, no standard or
guideline is needed.
12.4.2 Terminals
The basic network functions defined in Table 12-I don't need more than
basic (300 baud hardcopy) ASCII capability, but menu support may need suchadditional functions as screen clear, cursor addressing, scrolling, and a
higher data rate. A guideline or standard based on what is needed to
correctly support a Menu System (processor) in a user-friendly way isrequired. This implies a minimum of 1200 baud "dumb" CRT; 300 baud
hardcopy is marginally acceptable.
12.4.3 Common Capabilities
Figure 12-3 is the panel's model of the user's view of the catalogs and
directories. The panel developed this model as a basis for a standard user
interface. This model shows the local catalog(s) as transparent to the
user. The user would deal with the high-level directory, standardized over
47
//
/(a)
Figure 12-2. User View of Network Topology
• USER TERMINAL
LOCAL SYSTEM
LOCAL NETWORK
TABLE 12-1
PILOT NETWORK FUNCTIONAL REQUIREMENTS
GROUP 1 - MANDATORY
• COPY "FILE"• DISPLAY DIRECTORY CONTENTS
• DIRECTORY ATTRIBUTE SEARCH
• CREATE DIRECTORY ENTRY
• MODIFY DIRECTORY ENTRY (SOME ATTRIBUTES PROTECTED)• DELETE DIRECTORY ENTRY (AND CORRESPONDING DATA SET)
• HELP
• DISPLAY STATUS OF ANY OF THE ABOVE PROCESSES (IF APPRO-PRIATE )
PRIORITY GROUP 2
• DISPLAY NETWORK STATUS/STATISTICS• SEND MESSAGE
- TO LOGGED-ON USER
- TO MAILBOX
PRIORITY GROUP 3
• PROVIDE SAMPLE DATA SETS
- PRE-CANNED
- FIRST N POINTS, RECORDS,...[- SAMPLED, AVERAGED,...]
• PROVIDE ESTIMATES OF "COST" BEFORE EXECUTING A NETWORK
OPERATION
- DATA SET SIZE
- ELAPSED TIME
- COST (IF USED)• BROWSE
• SEND MESSAGE TO BILLBOARD
GROUP 4*
• NETWORK LOG ON/OFF- TRANSPARENT TO USER
• ESTABLISH/REMOVE/MODIFY USER AUTHORIZATION
- NOT AVAILABLE TO USER
• RUN/CANCEL EXPLICIT PROCESS- FUNCTION NOT NEEDED IN SHORT TERM
• SEND BROADCAST MESSAGE- NOT AVAILABLE TO USER
• DIAL-UP, LOCAL SYSTEM LOG ON/OFF- CANNOT STANDARDIZE
*Functions may be required, but user interface standards/
guidelines are not required.
49
DIRECTORY
O
SAMPLE DATA SET(S) DATA SET
Figure 12-3. Directory/Catalog User View
the network. The linkage between the directory and the actual data set
would be invisible. If the users have to see a local catalog or directory,that interface could not be standardized. ADS should seek to standardize
the user's view of the interface to a high-level directory.
The panel prioritized the functional requirements for the pilot network for
which standard user interfaces would be needed. These requirements are
grouped in Table 12-I based not necessarily on functional importance but onthe need for standard user interface. Clarification is needed for
functional requirements shown to accurately reflect the directory/catalog
concept and criteria established by Panel A. This is an item for futurework.
The panel anticipates that the user will want sample data sets--the larger
the data set, the greater the need for a variety of different samples. The
user may want to look at smaller data sets quickly prior to operating on
larger data sets. (This is a strong requirement in the Oceans Pilot.) Thevalue of this function depends on the typical size of the data set with
which one is dealing. The user should be aware that sample data sets exist
and should be aware of how to get them even if the directory-pointing
mechanism is transparent. This requirement is shown in Group 3 to indicatethat it is a longer term effort_
12.4.4 Language Interfaces
It is hoped that TAE and RSS will develop into the defacto standard for the
three pilots. This may be modified by current pilot methodologies andexternal standards.
12.4.5 User Consultant
There should be a human user consultant available to be used for
human-to-human assistance. Guidelines are needed for a user consultant.
The scope of the guidelines includes who, how many, organization (local
system, local network, ADS network), functions, and expertise.
12.5 RECOMMENDATIONS FOR FUTURE WORK
12.5_I It is recommended that there be a continued panel existence more orless as a design review committee to influence and monitor TAE, RSS, and
allied efforts from thepoint of view of user interface, with membersrepresented from: .
o Pilots
o ADS Standards Office
o NASA Headquarters
o Other TAE users
o TAE developers
51
There is a need to clarify TAE maintenance and control policy,organization, and authority of the review committee. The charter of theTAE/RSS review committee should be:
o To test and evaluate the software to be used;
o To recommen_ changes to be done;
o To review documentation.
This will consume resources and time; a minimum estimate is I/4 person per
pilot. It should not be necessary for this committee to meet frequently.Most of its work can be done by mail, with occasional teleconferences.
12.5.2 Liaison should be maintained with CODASYL and ANSI to monitor work
in command languages, using mechanisms available to influence both in the
public sector by:
o Including ADS standards people and TAE developers on mailinglists;
o Contacting Capt. Bruce Hogman and William LaPlant (Pentagon, DODsoftware standards) who might provide current status of ANSI/X3HI
and CODASYL COSCL to D.C. area people.
12.5.3 There should be a study to understand user interface procedures oftechnology transfer organizations, e.g., Eastern Regional Remote Sensing
Applications Center (ERRSAC), etc. for both human training and computermethodologies.
12.6 ADDITIONAL COMMENTS
a. Critique of MITRE methodologies must be done by each pilot, not in
this panel.
b. In Priority Group 3 (Table 12-I), the functions represented in the
first two bullets may be interpreted by others as ADS value-added
functions and therefore inappropriate for an early ADS, or even aninterim ADS.
c. The CSC-distributed document available at the workshop seems toimply from the start an attempt at an ADS central facility. Thiswould be a policy decision, and is not yet firm.
d. There is at least a partial impression that the viewpoint inFigure 12-I of the "User View" and our definition of "user" does
not agree with the Panel D viewpoint. This must be reconciledbefore candidate standards can be written or tested.
52
12.7 PANEL B PRESENTATION DISCUSSION
Pat Gary asked if Panel B's concept of the directory is consistent with
that of Panel A's description, and if there exists a single standardized
directory at the top.
Jim Brown answered that he didn't say that there was a single one. In the
long term it is desirable that the user view of ADS is a single, top-level
directory that is global. It isn't known if it will be practical in the
future, but it is not now. The panel didn't discuss how to deal with it,
but it is something to work on with regard to interconnecting these pilots.
He expects that the likely case for the top-level directories is that they
will be physically distributed but will be logically centralized.
Pat Gary commented that when the user realizes that the data set he isseeking is not to be found locally, then he is going to make further
queries through that user interface at a remote site. Pat asked if that
interface will vary depending on location. Is it acceptable or desirable
on the short term that the user have a specific, non-standard interface foreach local catalog?
Jim answered that it is desirable that the user not even be aware that
there is a local catalog. Given current implementations, that probably is
not practical in the short term. The Ocean Pilot is consistent with this
model - the local catalog is invisible to the user, but it isn't known if
it is true for the other pilots. For the panel's purpose, they assumed
that is was not true in general and that there are some local catalogs.
Even though it's desirable to standardize them, in the short term they do
not hope to standardize local detailed interfaces. It is desirable but not
practical.
Someone from the audience asked what the difference is between the
broadcast message (Group 4 - Table 12-I) and the billboard
"teleconferencing" (Group 3).
Jim answered that broadcast is something that you get on your terminal
whether or not you want it, and billboard is read-at-discretion.
Another member of the audience commented on User Commands, Priority GroupI, that maintenance of the directory would be done off line and not by
users, and that there is no command for interfacing with lower level
catalogs.
Jim answered that the assumption for directory maintenance is that, as in
RSS, a file copy operation would create a user-owned file and correspondingdirectory entry. If this is the case, then the user needs directory
manipulation facilities. This is a policy issue that needs to be worked.
The three pilots agree substantially on what users are allowed to modify.
Commands for interfacing with lower level catalogs could not be
standardized due to lack of information regarding local catalogs; prefer atransport interface.
53
Barbara Walton commented that there is a question of long and short term
and transparency rather than functionality. Panel A didn't see the link as
transparent in the short term; they had a problem with that. Panel B's
view _as that the local user saw the directory and not the local catalog;
in Panel A they saw that as desirable in the long term but not possible in •the short term.
There was agreement with Barbara's comment.
Ed Schlosser asked if the panel had determined if user interface isconversational and stated that conversational interaction has some
( problems.
Jim answered that it is implicit that the interface is basically
interactive and that it is explicit that no operation will tie up theterminal. The implication is that status posting is required for any
process which cannot be completed within a few seconds.
Dave Stowell commented regarding user requirements that "human/human
consultancy" should be flagged as existing. It is an important item.
54
13.0 PANEL C REPORT: STANDARDS NEEDED FOR THE USE OF ISO OPEN SYSTEMSINTERCONNECTION - BASIC REFERENCE MODEL
13.1 INTRODUCTION
Panel C of the Application Data Service (ADS) Data Systems Standards
Workshop met to discuss the recently developed International Standards
Organization (ISO) Open System Interconnection (OSI) Reference Model (I)
and to explore its relevance to interconnecting the ADS pilots for data
sharing. All three pilot programs were represented on this panel as well
as participants with broadly based experience in related fields. Given the
diverse background of the participants and the limited time available for
discussion, the panel was unable to explore the many detailed interface
considerations needed to thoroughly analyze the relevance of the OSI
Reference Model to the ADS. Nevertheless, the panel concentrated its
efforts by performing a top-level mapping between the conjectured ADSrequirements and the identified layers within the OSI Reference Model. Anumber of issues of a more detailed nature were identified for further
study. Panel C attendees are as follows:
Richard Berman, CSC Edward Greene, GSFC, Chairman
Joseph L. Bishop, NASA HQ. Adrian J. Hooke, JPL
William Bisignani, MITRE John Johnson, JPL
Albert Bowers, MITRE John Kiebler, NASA HQ
Gary Brammer, LARS James Moulton, NBS
Paul Clemens, MITRE William Poland, Jr., GSFC
Richard desJardins, CTA A1 Skopetz, GSFC
David Freeman, LARS Robert Stephens, NASA HQ
J. Patrick Gary, GSFC Phil Y_, GSFC
55
13.2 OVERVIEW OF OSI REFERENCE MODEL
The OSI Reference Model represents a conceptual architecture fortelecommunication interconnections which consists of a hierarchical
structure composed of seven layers. The principal functions performed or
services rendered by each layer is shown in Table 13-I. Figure 13-Iillustrates the actual data flow (dotted line) and the virtual data flow
(solid lines) between two application processes running in systems that
are, in general, distinct and geographically separated. At each level,
there is an illusion of a direct peer-to-peer protocol connecting the twosystems. However, in reality, the actual control and data communication is
between adjacent layers. The N-th layer protocol performs identifiable
services to the (N+1)-st layer and, in turn, requests services from the
(N-1)-st layer. If the two systems are distinct, then the actual signalcommunication is performed at the Physical Layer (layer I). The interface
to the applications process is at the Applications Layer (layer 7).
Table 13-I
OSI Reference Model Layers
Laye_____Er Name Description
I Physical Physical signal interconnect from
point-to-point
2 Link Control Data interconnect from
point-to-point
3 Network End-to-End data interconnect
(Source DTE to Destination DTE)
4 Transport Host-to-Host data transfer
5 Session Dialogue synchronization betweenhosts
6 Presentation Data conversion services
7 Application Interface to application processes
56
OPEN SYSTEMS
i._ INTERCONNECTION ENVIRONMENT ....,.I1 1
APPLICATION-PROTOCOL _I_PLICATION -"_APPLICATION /'_PPIICATION _ _
PRESENTATION _ I PRESENTATION-PROTOCOLLAYER , : : I.SESSION I- '_ ; ! II : SESSION - PROTOCOL : i iLAYER I :"_ _ : I:_
TRANSPORT I : TRANSPORT -- PROTOCOL : II • "'_ ' _"" • I
LAYER I : "' 4, INETWORK r : NETWORK - PROTOCOL : i
I :._ , , _ : t'k.,rt
-4 LAYER l : ; t• "" !
DATA LINK u : .DATA - LINK - PROTOCOL . : tI . ..,,_ ' _: I
LAYER 0 : : IPHYSICAL _ -I : PHYSICAL - PROTOCOL : ,
OPEN SYSTEM A iLAYER ................ .:: ..................... : OPEN SYSTEM B
F oil• • ooe • • o. oil, .go• le••oo• ooo • .ao• o. • • •• dPHYSICAL MEDIA OF OPEN SYSTEMS INTERCONNECTION
• tI'1Figure 13-1. Actual and Virtual Data Flow /_
At the lowest three layers, there are existing protocols that conform
substantially with the 0SI Reference Model. Some of the possible choicesare:
Layer Name Examples
I Physical EIA RS-232-C, RS-422-A, RS-423-A
CCITT V.28, V.35MIL STD-188C
2 Data Link Binary Synchronous Communication
(Bi-Sync)
ADCCP, SDLC, HDLC
3 Network X.21, X.22, X.25, X.75
Beyond layer 3, there are no nonproprietary general-purpose protocols which
have been extensively tested; however, this is a field of active research
within both the U.S. and European communities. Draft standards have been
issued by the National Bureau of Standards (NBS) for both a Transport Layerand a Session Layer protocol. It is anticipated that these draft standards
may emerge as mandatory Federal Information Processing Standards (FIPS)
(for U.S. government systems) after these protocols have been extensively
reviewed and tested. Both IBM and Digital Equipment Corporation have
telecommunications software (SNA and DECNET, respectively) that provides
services at all layers for networking among compatible-computer systems.
13.3 ADS REQUIREMENTS IDENTIFICATION
In order to determine the relevance of the OSI Reference Model for
addressing ADS requirements, the Panel considered a scenario representing a
broad class of capabilities which were considered required to interconnect
the pilots for data sharing. The interconnection protocols needed to
support this scenario were then identified, and these protocols were thenclassified in terms of standard layers within the OSI Reference Model.
The scenario consisted of a series of steps described in Table 13-2. In
essence, an investigator utilizes a terminal to perform a search of a
nonlocal data base, initiates the execution of a process resident oh a
remote processor using the selected dataset as input data, copies the
generated data set to a different processor where it is added to the data
base, the corresponding directories and catalogs are updated, and an
electronic mail notification of the new data set is given to selectedcolleagues.
58
Table 13-2Scenario
Research user sits down at alphanumeric terminal and performs the followingfunctions:
I. Attaches to local host
2. Remote data base inquiry
o Accesses root of directory in local host
o Linked to remote host for secondary directory services
o Submit request for information about data of interest
o Receives data descriptors/pointer
o Iterates process to locate data set of interest
3. Request remote processing of data set. Activate resource
estimation/accounting function
4. Copy generated data set to local or remote data base and add to
catalog
5. Notify colleagues of new data set by electronic mail
6. Terminate link/logoff
To support this scenario, the protocols listed in Table 13-3 are required.
Items I, 2, 5, and 9 are essential layer 5 functions, and the remaining
items are combined layer 6 and layer 7 functions. Since nonlocalintercomputer communications is required by this scenario, layer I, 2, 3,
and 4 p_otocols are required to support the higher layer protocols.
Other capabilities discussed as appropriate for long-term ADS
consideration, but beyond the scope of that needed to interconnect ADS
pilots for data sharing included:w
a. distributed data bases,
b. multiprocessor application processing, and
c. generalized word processing (int_roperability among equipment from
diverse manufacturers). Additional layer 5, 6, and 7 protocol
_services would be needed to support these functions.
59
Table 13-3
Protocols Required to Support Scenario
I. Terminal support
--Local
--Dial-in through network*
2. Automatic login/accounting to applications manager
3. Catalog manager command/response interaction, data base inquiry
and response (command language, data descriptors)
4. File transfer
5. Applications executive interaction (suspend/resume, etc.)
6. Privacy/security services
7. Message to operator/mailboxes
8. JSC word processor access*
9. Automatic log off
*Additional near-term capability not directly derived from scenario
13.4 NEAR-TERM TELECOMMUNICATION SUPPORT METHODOLOGY IN ADS PILOTS
The Pilot Atmospheres Data System (PADS) at the Goddard Space Flight Centerand the Earth Resources Pilot System (ERPS) at the Lynd0n B. Johnson Space
Center have developed and adapted telecommunications software to service
the needs of their individual pilot demonstration. The computer system for
the Oceanic Pilot System (OPS) at the Jet Propulsion Laboratory will bedelivered this summer and is expected to utilize the DECNET software for
intrapilot networking. Figure 13-2 shows the initial telecommunications
software that is being implemented for each pilot. The classification of
the software into OSI Reference Model layers is only approximate.
13.5 INTEGRATED TELECOMMUNICATIONS CANDIDATE
The following are three basic approaches which could be considered for an
integrated ADS pilot network system:
Approach I: modify the software of the near-term configuration(Figure 13-2) to permit interpilottelecommunications,
Approach 2: adopt a computer manufacturer sponsoredtelecommunications package such as SNA or DECNET,
Approach 3: adopt existing and emerging national and international
telecommunication standards to the greatest possible degree.
6O
I[
II
Ii
II_
_d
m
oq (.o
I •_
0_
'_
__
Z m mI
3O
"_
_03
_m
•I-=o
r_m
0_.
r__
m_
_Z
0Z
"0_
0_
--
h_
._
_Z
0_
m_
_-_
mz_
m_
_
There are advantages and disadvantages associated with each of these
approaches.
Approach I offers the advantage of providing the potentially easiest means
of transferring bits between two computers. With a minimum of effort, itis anticipated that software modifications could be made so that the raw
bit streams representing data and control messages could be interchanged
among the three pilots. However, it is not enough to reliably transfer a
sequence of bits; we need to be able to exchange information. This is a
great deal harder to do via approach I, since the command language
structure and codes are not uniform among the three pilots. This lack of
uniformity in command language structure and data structures is likely toresult in a very awkward telecommunications capability. Either some very
"kludgy" software would have to be written to translate between the native
codes of the three pilots, or the user would have to employ differentconventions and utilize different command languages, depending on the host
computer to which the user was attached. Either alternative is considered
very undesirable and the panel rejected this approach.
Since two of the pilot systems (PADS and OPS) are oriented towards the DEC
computers and the ERPS is oriented toward IBM or IBM lookalike computers,
approach 2 considers the adoption of DECNET or SNA as the ADS
telecommunications system. Both DECNET and SNA provide a rich variety of
file transfer and data base services; however, they are parochially adapted
to the hardware and software system supplied by the respectivemanufacturer. This is not to say that it is impossible to use the DECNET
structure on a non-DEC system or the SNA structure on a non-IBM system;
however, the non-native equipment would tend to experience inferior
performance if it could not exactly emulate the system for which the
proprietary software was designed. Hence, the adoption of a proprietarytelecommunication system would tend to give a specific manufacturer a
significant advantage over its competition. For this reason, the panelchooses not to recommend approach 2.
The third approach involves the tentative acceptance of protocols which areso new and unproven that they exist only as draft standards. The NBS has
issued specifications (2,3) of a layer 4 (Transport) and layer 5 (Session)
protocol which appear to be the leading contenders for standard protocols
at these levels. It is anticipated that, after an extensive review
process, these protocols will become FIPS and be required for future
telecommunications support on U.S. Government systems. The proposed draft
layer 4 protocol is intended to provide the proper interface to the majorexisting layer 3 protocol such as X.25 and X.21.
Above layer 5, the processing functions become so diverse that there
appears little hope for the development of a single standard protocol at
layer 6 or layer 7 in the near future. Instead, it is likely that a series
of standard modules will be developed which perform certain well-defined
functions at layers 6/7 and which interface to the standard layer 5protocol. One such module, the NBS File Transfer Protocol, is scheduled to
be released in draft form in early 1982. Other standard modules will
undoubtedly be developed but probably not on a timeframe that will benefit
the ADS. Approach 3 involves making a tentative commitment to use the NBSproposed layer 4 and 5 protocols and the File Transfer Protocol (layer 6/7)
62
when available. Other essential layer 6/7 functions needed by the ADS
would have to be specially developed for the ADS and should interface to
the standard layer 5 protocol.
The panel did not have the time to assess the adequacy of the NBS draft
protocols at layers 4 and 5. Nevertheless, after rejecting approach I and
2, the consensus of the panel was that approach 3 deserves cautious
support. While this approach is likely to be the most frustrating anddifficult on a short-term basis, it is the only approach which offers a
potentially viable solution for the effective networking among
non-homogeneous systems. Figure 13-3 illustrates some of the protocols
that are needed for the candidate ADS configuration and their relationshipto the OSI Reference Model.
13.6 CONCLUSIONS
Considering the diversity of experience among Panel C attendees, the
breadth of the topic to examine, and the very limited time available for
deliberation and discussion, the panel could only provide tentative advice
regarding the choice of protocols for an integrated ADS network
demonstration. The recommended approach discussed in the preceding section
is fraught with many uncertainties. Nevertheless, it is the consensus of
the panel that the OSI Reference Model represents an orderly architecture
for the ADS networking planning and that the standard protocols beingdeveloped by the NBS offer the best available implementation approach.
13.7 RECOMMENDATIONS
The issues considered by this panel cannot be satisfactorily resolved by a
diverse group during a 2-day workshop. It is the panel's recommendation
that a working group be established to continue to investigate these issues
and to track the progress toward a successful interconnection of ADS
pilots. Listed below are some specific topics for the Working Group
investigations:
13.7.1 Review currently identified requirements versus other panels forconsistency and completeness.
Panel C identified the need for protocols to support the functions
identified in Table 13-3. These requirements need be compared with the
requirements identified by other panels for consistency and completeness.
The intent is to direct attention to provide or plan protocols to meet anyextra requirements.
13.7.2 Develop functional specification of input parameters for each
application to be supported (input to layer 7).
After the requirements of an ADS network have been identified, each
application must be isolated, and a functional or performance specificationmust be described. Once this information is known, the functional
specification of the application can be broken down into subfunctional
groups that will describe the input parameters. These parameters are the
user interface between the application process and the protocol of the
application layer in the ISO model. The specification of the input
63
INTEGRATED CONFIGURATION CANDIDATE
LAYER (TWO OR MORE YEARS IN FUTURE)
7
NBS DATAFILE ACCESS
TRANSFER PROTOCOL 7PROTOCOL (FUTURE)
6
5 NBSSESSION
4 NBSTRANSPORT
m
X. 21 OTHERX. 25 OR OTHER (LOCAL AREA
2 SERVICE DEDICATED NET, SATELLITELINE TDMA, ETC.)SERVICE
m
Figure 13-3. Integrated Configuration Candidate
64
parameter functions can then be used to develop design specifications foreach parameter.
13.7.3 Develop design specifications of output strings/packets/messageblocks for each application to be supported (output "from 6 to 5").
Pilot implementation of the identified application functions (e.g., remote
catalog manager request/response, file transfer, process initiation, and
user message exchange) requires detailed specification of the strings,
packets, and/or message blocks which will be output from one host system's
layer 6 protocol function for input to another host. Currently, with the
exception of file transfer, no federal standards exist to guide the design
effort needed by the ADS pilot system to provide mutually compatibleservices for these functions.
Detailed descriptions of the information content, format, and layout of the
message blocks to be exchanged and the encode/decode processing to beapplied to the message blocks must be specified.
13.7.4 Evaluate existing layer 4 and 5 protocols, including the NBS
proposed standard, and recommend selection for pilot system and future ADSuse.
The purpose of this effort is to evaluate and recommend approach for theimplementation of the transport and session layers of the OSI. This will
be accomplished by a review of existing pilot system implementations,
proposed standards (e.g., NBS), and other existing protocols (e.g., SNA).Additional points of consideration include:
a. a cost analysis of "build versus buy,"
b. that portion of the pilot systems' charter which effects the
exploration of new technologies,
c. the possible addition of new nodes to the ADS network,
d. existing hardware and software in the centers involved, and
e. facility with which a near-term implementation may evolve into alonger term solution.
The output of this task should include the following recommendations:
a. technologies and methods for a near-term implementation, and
b. longer term analyses and studies pointing toward a solution forfuture ADS system.
13.7.5 Perform a requirements analysis for the ADS at the combined layers I-3.
The service requirements for the interconnection of the pilots and forfuture ADS capabilities will determine which services are best suited
(packet switched, dedicated line, other).
65
o No new standards required for these layers; ADS just has to selectthose it needs.
o Traffic between nodes will determine service required.
o X.25 not cost-effective, under current tariff structure, for use
of more than 2 hours/day--dedicated line would be cheaper.
o Satellite communication links have to be considered for high-data
rates.
o The reliance on local area networks at the member nodes has to be
considered for impact on the ADS network.
13.7.6 Specify core requirements expected for each protocol layer forpilots and future ADS use.
In general, standard protocols provide a large number of options and
services, not all of which are germane to a specific application. Because
of this, most implementations of protocols consist of a subset of the full
capability defined by the standard. Incompatibilities arise when different
user systems adopt different subsets of the standards, and the logicalintersection of the various subsets are insufficient to provide the
necessary services. This task is concerned with developing guidelines for
each applicable protocol which identify the core functions and capabilities
expected from each user implementation to support the future ADSinterconnection uses.
13.8 PANEL C PRESENTATION DISCUSSION
Tom Burns asked if the panel had a chance to look at tradeoffs between
packet switching and datagram connection.
Ed Greene replied that it might be approved for both but that it is an
economics decision and should go into the "further-work category."
Someone from the audience stated that a phone call or telegram is a
connectionless concept in the model and asked if there is a requirement.
Ed answered that it is not considered in this model; it is an anticipated
interactive requirement.
66
14.0 PANEL D REPORT: STANDARDS NEEDED TO INTERCONNECT ADS PILOTS FOR DATASHARING IN DATA FORMATS AND DESCRIPTIONS
14.1 BACKGROUND
At this point in the development of information and communications systems
technology in general, and the growing multitude of space-related databases in particular, it is appropriate that data interchange between
distributed, non-affiliated (foreign) data bases be pursued by NASA in
order to gain experience with such systems and nurture a future user
community. The ADS Standards activity has thus been formed to provide forthe creation of data interchange rules and protocols, and to serve as a
"brass board" for the generation of long term techniques and standards forthis far reaching technology.
The universal need for access to CATALOG data from non-affiliated data
bases is repeatedly expressed in ADS workshop reports. This reflects a
real user requirement to be able to interrogate various data bases to seewhat products are archived. The demand for networked access to
multi-source data products from multiple data bases is less clearlydefined; this is probably a result of justifiable caution within the user
community, who are wary of grandiose systems which promise wonderful thingsbut do not deliver. The challenge of the ADS pilots is therefore to
demonstrate that such systems can in fact be made to work, and to develop
the framework for future operational systems.
The charter of the Data Formats and Descriptions Panel was to identify the
scope of data specification standards that need to be adopted in order to
facilitate the interchange of information between the archival pilotsnodes. A list of panel participants follows.
Thomas Burns, MITRE
Dennis Fife, NBS
Edward Greenberg, JPL, Chairman
Edgar M. Greville, CSC
Larry Herath, GSFC
Merv MacMedan, JPL
Ed Schlosser, Lockheed
Valerie L. Thomas, GSFC
67
14.2 SUMMARY OF PANEL DISCUSSIONS
It was the consensus of the panel that data exchange standards should be
developed to be of general future utility, though the near-term activity
should be constrained to focus on the problems of interconnecting the ADS
Pilots. The intent is to use the three pilot nodes to evaluate the
generalized applications of the ADS. The panel agreed that the following
considerations were important when standards are designed:
a. DBMS catalogs should be accessible and understandable to remote
users (both humans and applications processors).
b. Formatting conventions should be constrained to have minimal
impact on existing archival data sets or on currently-generating data
sources (e.g., Landsat), though they should be designed to provide guidance
for future DBMS developments.
c. Archival data records and their data descriptions should be
available in globally-identifiable, machine readable and interpretable form
so that users can automatically interact with variable, non-affiliated data
sets from remote DBMS nodes. The format of the records and descriptions
should be machine and medium independent.
d. Terminology must be scrupulously defined. Definitions, words,
units and general vocabulary should be standardized. Everyone should havethe same understanding of the same word or definition.
e. Each DBMS node should have the option to optimize its data formats
(at the discretion of the local authority) as long as minimal constraints
imposed by global standards are met.
14.3 PANEL RECOMMENDATIONS
The specific recommendations that this panel extends are as follows:
14.3.1 The ADS should establish a standard vocabulary of terms, units,
descriptions, and definitions. This must be accomplished in the immediate
future. Although the early versions of the vocabulary need not be
complete, they must provide the foundation for enabling the definitions of
requirements and specifications to proceed.
14.3.2 The ADS should provide a machine-readable standard mechanism, which•is medium and machine independent, for describing data content, structures,
numeric representations, and character codes. It is vital that these
definition mechanisms should be adopted as soon as possible in order to
facilitate the pilot interchange of data, and in order to provide guidance
for the future data sets which will be generated in coming years. The
mechanisms adopted MUST be adequately defined, with user guides andexamples, and MUST have expansion capabilities.
68
14.3.3 The ADS should establish a set of preferred numeric
representations, a preferred character code, preferred units, and preferreddescriptions. The ADS vocabulary should recognize and define ALL of the
used or usable codes, units, and descriptions which currently exist within
the pilots, but a subset of these MUST be identified as the preferred set.It is highly desirable that each pilot node should perform conversions of
those existing data elements that are not in the preferred form, thus
reducing the number of conversions which must be performed by each userprocessor.
14.3.4 The consensus of the panel was that the view of each of the panelparticipants was limited. The panel members felt that it is critical that
the ADS should establish a permanent, dedicated team to pursue these
recommendations further. While it is impractical for the panel to
recommend detailed specific items for the team, we propose that thefollowing near-term outline be pursued:
a. The permanent team should begin by analyzing the data formats,
codes and representations used in existing pilots.
b. The team should analyze existing and proposed data interchangestandards.
c. The team should adopt or create Strawman standards for review bydata base administrators for each pilot and associated NASA data base.
d. The team should establish an ADS data standards administration
function to approve, disseminate, maintain and provide visibility for thesestandards.
e. The team should provide top-level coordination for the developmentof catalogs, in order to:
i) Provide to the catalog designers the mechanisms for describingdata sets.
ii) Evaluate the adequacy of the catalog structures to enableusers to access and select data.
FOOTNOTE:
Owing to the shortness of time allowed, the MITRE presentation on pilotstandards methodologies was not critiqued by the panel. We would howeverlike to commend the MITRE assessment of the standards that need to be
developed to support Pilot Data interchange: this presentation showedsubstantial technical insight.
14.4 PANEL D PRESENTATION DISCUSSION
Pat Gary asked if the panel hopes for short- or long-term activity.
Ed Greenberg answered that the panel didn't address time; they addressedurgency. Data must be described in a standard way and it must be done now.
69
Tom Burns commented that the standard visibility requirement (see 14.3.4)
must be emphasized.
Ed Greenberg said that we need electronic access to what people are doing.
Pat Gary stated that it would be a good thing if we built an on-line database.
John Kiebler asked where specific formats went which were there at thestart but are not there now.
Ed Greenberg replied that the panel did not have all of the details of theother formats.
7O
15.O WORKSHOP SUMMARY - Barbara Walton, GSFC
The workshop unanimously recommended the development of a standard for data
product preparation to ensure quality data sets. The recommendation
prepared by Richard desJardins, as given in Table 15-I, was adopted.
There is a lot of work to be done in the standards area. The panels'
detailed requirements and the recommendations for future work are vital forthe ADS program. Many of the workshop attendees will be called upon in the
future for participation in working groups.
A document with the proceedings of the workshop, including theparticipants' addresses, will be distributed to all of the attendees of the
workshop.
15.1 WORKSHOP SUMMARY DISCUSSION
Ed Greene agreed with Richard desJardins' recommendation to OSTA and
commented that it presumes quite a sophisticated data configurationmanagement, under strict control.
Richard desJardins said that it might be considered a goal, an ideal, but
it may never be implemented.
Jim Brown commented that it has been done (for instance, with the Seasat
Altimeter).
16.O ACTION ITEMS - John Kiebler, NASA Headquarters
Draft panel reports are due to Barbara Walton in two weeks with a finalversion due in one month.
The panels didn't do much critiquing of the MITRE representation of the ADS
pilot methodologies, which was one of the intents of the workshop, so it isup to the pilots to review the methodologies and report in a few weeks'time.
A meeting of the Steering Group will be held in room 206 at 2 p.m., to
which panel chairmen are invited.
John thanked the participants and said that he thought the workshop had
proven productive.
71
Table 15-IRecommendation to OSTA on a Data Product Preparation Standard
Users of ADS may acquire some data only to find that crucial aspects of thedata are unknown or missing, e.g., the position and time of data taking,the processing steps performed, the calibration curves used. While theseaspects are of little consequence for systems interconnection protocols,they may be crucial for effective utilization of the data.
Therefore OSTA should develop a standard or guideline for Data ProductPreparation. The intent of this standard would be to provide to datapreparation personnel a checklist to assure the "quality" of the data asdefined by the 1979 OSTA Data Systems Planning Workshop. The term"quality" was used at that workshop to signify the quality of the datapreparation process rather than the apriori intrinsic goodness of thesensor data.
The scope of the standard would include:
o data preparation praotices (e.g., recommended quality assurancepractices, scientific data validation techniques)
o data labeling and annotation (e.g,, source, indications of gaps,comments)
o ancillary data (e.g., position, time, solar aspect)
o "pedigree" of the data (e.g., calibrations performed, noiseremoval technique used, algorithm applied)
o pointers of references (e.g., name and address of preparer,identification of data control documentation, reference data andsoftware used including version numbers and algorithms)
72
Glossary of Terms
ADCCP Advanced Data Communications Control Procedure
ADS Applications Data ServiceANSI American National Standards Institute
CCT Computer-Compatible Tape
CODASYL Conference on Data Systems Languages
COSCL Common Operating System Command Language
CMS Command Management System
DBMS Data Base Management System
DDCMP Digital Data Communlcatlons. Message Protocol
DEC Digital Equipment CorporationDOD Department of Defense
ERPS Earth Resources Pilot System
ERRSAC Eastern Regional Remote Sensing Applications Center
FIPS Federal Information Processing Standardsl
GSFC Goddard Space Flight Center
IDBMS Integrated Data Base Management System
IPS Information Processing System
ISO International Standards Organization
JPL Jet Propulsion Laboratory
JSC Johnson_Space Center
NASA National Aeronautics and Space AdministrationNBS National Bureau of Standards
NEEDS NASA End-to-End Data System
NOAA National Oceanic and Atmospheric AdministrationNTIA National Telecommunication Information Administration
OAST Office of Advanced Space Technology
OPS Oceanic Pilot System
OSI Open System Interconnection
OSTA Office of Space and TerrestrlalAppllcations
PADS Pilot Atmospheres Data System
PCDBMS Pilot Climate Data Base Management System
R&D Research and Development
R&T Research and Technology
RSCS Remote Spooling and Communications Service
RSS Remote Services Subsystem
RTOP Research and Technology Objectives and Plans
73
S&G Standards and Guidelines
SFDU Standard Format Data Unit
SNA Systems Network ArchitectureSNAP System of Networked Applications Processors
TAE Transportable Applications Executive
TDMA Time Division Multiple Access
USGS United States Geological Survey
VAS VISSR Atmospheric Sounder
VISSR Visible Infrared Spin Scan Radiometer
74
APPENDIXA
OSTAIADSDATASYSTEMSSTANDARDSANDGUIDELINESDEVELOPMENTPROGRAM
OVERVIEWOF THECURRENTMITREEFFORT
TERRY KUCH 0STA/ADS DATA SYSTEMS
RICK SAKAMOTO STANDARDS WORKSHOP "
THE MITRE CORPORATION MAY 27, 1981
MCLEAN, VIRGINIA
THEOSTA/ADSDATA SYSTEMS STANDARDSAND GUIDELINES DEVELOPMENTPROGRAMIS A
COLLABORATIVE ACTIVITY, THIS WORKSHOPPROVIDES THE OPPORTUNITY FOR ENHANCE-
MENT OF ADS STANDARDSAND GUIDELINES THROUGHINTERACTION WITH WORKSHOP
PARTI C I PANTS,
PURPOSE OF THIS PRESENTATION
0 PRESENT AN OVERVIEW OF THE CURRENT EFFORT,=D_
0 PRESENT A TERMINOLOGY AND CONCEPTUALIZATION _OF ADS FOR STANDARDS DEVELOPMENT
PURPOSES
0 PROVIDE A CONTEXT FOR THE NEXT TWO PRESENTATIONS
- USER REQUIREMENTS
- PILOT METHODOLOGIES
OUTLINE OF BRIEFING
0 OVERVIEW OF CURRENT.MITRE ACTIVITIES
o ADSTERMINOLOGY
o ADSAS A DISTRIBUTED SYSTEM,_.
0 A FUNCTIONAL CLASSIFICATION OF ADSFEATURES
0 A STANDARDS EVALUATION PROCESS FOR ADS
MITREACTIVITIES:....OVERVIEW
i, DEVELOP NASA-DEFINED APPROACH TO 0STAIADS DATA SYSTEMS STANDARDS AND
GUIDELINES,
2, EXTEND KNOWLEDGE OF DATA SYSTEMS STANDARDS AND GUIDELINES ORGANIZATIONS
AND PROCESSES,
3, DETERMINE ADS MEMBERS' REQUIREMENTS FOR STANDARDS AND GUIDELINES,} FOLLOWING4, SURVEY AND ANALYZE METHODOLOGIES OF PILOTS, PRESENTATIONSI
5, SURVEY EXISTING DATA SYSTEMS STANDARDS AND GUIDELINES,
6, COMPILE A PRELIMINARY CANDIDATE SET OF 0STA/ADS STANDARDS AND GUIDELINES,
7, DEVELOP 0STA/ADSSTANDARDSAND GUIDELINES EVALUATION PROCESS AND CRITERIA,
8, EVALUATE PRELIMINARY CANDIDATE STANDARDS AND GUIDELINES,
9, DEVELOP CANDIDATE STANDARDS AND GUIDELINES REPORT,
MAJOR PRODUCTS :
, MITRE SURVEY REPORT MTR-81W5 (MARCH 1981)
, ADS CANDIDATE STANDARDS AND GUIDELINES REPORT (AUGUST 1981)
MITREACTIVITIES:i
DEVELOP NASA-DEFINED APPROACH TO OSTA/ADS DATA
SYSTEMS STANDARDS & GUIDELINES,
0 EXAMINE NASAAND CONTRACTOR DOCUMENTATION.
o DiscussADS CONCEPTS WITH GSFCAND CONTRACTOR PERSONNEL.
0 ESTABLISH CONSISTENT USE OF TERMS,
0 DEVELOP LOGICAL VIEW OF ADSFOR A STANDARDS DEVELOPMENT
EFFORT,
0 DEVELOP OSTA/ADS FUNCTIONAL CLASSIFICATION SCHEME,
TERMINOLOGYFORTIIEADSSTANDARDSPROGRAM
o STANDARD
o GUIDELINE
o METHODOLOGY
o DISCIPLINEUSERC_
o MEMBER
o CENTRALSYSTEMFUNCTION
GENERAL CHARACTERISTICS OF STANDARDS, GUIDELINES, AND HETNODOLOGIES
Standard Guideline Methodology
Administratively compelling Advisory Informational(required at some admin-
istrative level)
Exhaustive (complete within Exhaustive or selective, Selectiveits scope) as required
Detailed Not necessarily detailed; Detailed; based on actual
may be used to set bound- implementationaries within which stand-
ards may he defined
Adopted formally by key Agreeable to key organ- May be unique to one or
organizations izatlons, not necessar- a_few organizationsily adopted formally
Broad scope of appll- Broad scope of appllea- Limited scope of appli-cation to many systems tlon cation
and organizations
Product-orlented Actlvity-orlented Product-orlented oroutcome-orlented
Compatible with other Compatible with other Not necessarily compat-standards and guidelines standards and guidelines ible with any standard,
guideline, or other
methodology
;Fully developed and stable, Less fully developed Not necessarily fully
subject to evolution developed
Addressed to technical staff Addressed to technical Addressed to working-or to technical project man- project management or level technical staff
agement or to both to program managementor to both
DisciplineUsers
Discipline• Member Users
\
Member
\\
Central
/ SystemFunctions
/
Member.. Physical Connection
--.-.--_ LoglcaIConnection
DisciplineUsers
DISCIPLINE USERS ARE SCIENTISTS WHO USE AN ADSNETWORKMEMBER FACILITY IN THEIR RESEARCH,
MEMBERS ARE FACILITIES WHICH PARTICIPATE IN ADS, EACH
MEMBER PROVIDES A SERVICE TO DISCIPLINE USERS, A
MEMBER FACILITY MAY OPERATE INDEPENDENTLY OF ADS AS WELL -.
AS BEING PART OF ADS,
ADSCENTRAL SYSTEM FUNCTIONS ENCOMPASS TECHNICAL SERVICES
TO MEMBERS:0 DATA COMMUNICATION
0 CATALOGING
0 ADMINISTRATIVE SERVICES (SUCH AS RESOURCE ACCOUNTING)
0 USER ASSISTANCE
0 VALUE-ADDED SERVICES (SUCH AS DATA INTEGRATION),
CENTRAL SYSTEM FUNCTIONS MAY BE PERFORMED BY ONE OR MORE
MEMBERS OR DISTRIBUTED OVER THE NETWORK,
Adminlst retNo I ]
Resource Accounting,Reporting,TaskControl,QualityAssurance.UserSupport -_
i " i iD-m_mbe¢ II : 6-1
;'°°"'°'": l i : 1 .
(data let Access data:
resklewtce) • " rein, vseeet •generate; : • • • •
pre;>oco. • : : " • :• • • • •edut store • initiate data
• . ' • • • omln laimmuwmonmgimealoeiwalmaml_uneiIimooei linnliiilie•Oi_aeOioneieilolmsl• lb.
managemaintain" igOaaeee•illle_aeiaoe•iamlll•o•ilBla•i_ielOOlUleel0ol•ein• • re•ramBle :_ e• transfer (if •• • ' P'neceesary)mamtannManage oats• • • s • uodateo_, -
l : : • : / A : /I .... I , • I
•.... • " • It' i " I i• • • • 6-2 •
,.2 I : : : : A=.,cat,ona : : : : retrieve :celldeeco
software" ••el•see---ice elm • Ill • oilllilloilomllloilmolmloolllleel•i.mimmilleill.--il--llmmila_mlllllllaml appl Ca ions il• i•lllmlle oil • OR melillli •
.o.,..,.l) .to_e:m.na0e:I : : • : I I ,nftiate / : / i.,state,n; I : : : : I I trs.sfert,t /! OPT,ONALPAT" / i._.te I : : : : | I .._.s.,yI /I • i /
i • = : • l I II | i lI l : :" : : / IA I : I l |I I : • : : / m/ , I /• • " • • • I I " I I I l
1-3 I . • . . / ' I I Compute:processI I /,cqo_.... p.- I " :" : E / i , ida,......yz.: I / /
c-,,_.-",." ratio••.,so. I • : : • / I I i I -on,p.,.,..... I 11r /,.d_) d.y:m.na0e: / : ; .... . ........ --" ............ "-...... J. ......... !..I ............ '.-IIJ format:sum_ar-llllllllllOl lllllllllllllllllllllOllllllllOllllmlllllll I I l I II lie II l loll l lllll
_,.t._n: r --. • : . / i i - I .ze:e.trsct: I I• • ie • • • generste deta_.o_.,, / • . . • / , I / I I
configuration / : • : : / I ! / product I I il • • • • ".... : • : I , I / _ l I -iI i i : , • ; -- s . _ -- ,
I!I ", • , • , : I ,! | II l• " i /i '• • ' • |
. .IIii,i.i 'il .":: n,, ''" i III I o,,l,e,,:r_o,,Itn n el i"" |i" / IIiii U'll // . . . lI I I , . I _e.t,yt,pe. I I I .. I I : / , I • / I I
" I" LJ °da'eandI I -I I I " .1_,. I ',l .......... L_ e" 4J 91Nego a • process • I O sp ay da i Mike Clala
I identify general pro- . •I . .oe_,d..,,.. ............._.............. i..,.........................._,....... .,o_o0,: O,Od....J I I I _..,fo.e r_"l b,,,,......_ I I I elorith...... I I j / , I , I " I ' • I. I require- ces_ing cape- r •cite specific . w present• • nO packages
I l . I da_ap,od=,I I ,o.,.,yt.. I I I g _ I I : / I : I I I p._kaQe T. I ......_'"I I I I I I dataproduct I I I _,.ms,eques,I I : / , I . I II I&lz I : : " I r.qu.ome.t I I I I I : / I : I I U . I I ' I U
, , .z .. i I ' I *T -- :. n I Z' _ ' _ IIIII!, .." 4_ I I, 1 : / II , _ I liil' • I -o i i,,, . . I l.go,,.,......I I . I il ,I,11I I : : I l I t,o.que,y:_aent-I I : " / I I '. I I _ - Il i l : , _ ,,y,,ocet.ep.I.---4 : I I I I I I T I II, i ' : | -,o, ....,._.,,oo, , : -- ., , , , ,., ., ,,i , I : , I .,,ac,,.,.: I I : I I l I I I I" I%1 I II I u : l I ,.quest I I : I , l , l I ' '" 'I I I : I / , , . ' I : / II I I I o,,,o.._p.,., !1I " - i . I I all / I w • • • • -
- i¢; i l li,i i / II I i _,,_,,_/ IIinsert " Query io_a or 5-5 -- I i 9 5
In' .... tie• iII .... prO- , 4-5 , _ nvokelm- | -- I | Inserton dill _uery IC,ca for illeie _l_.l_ess it
..... ; ................. _i .............. d .... ,"......... ..... .J ........... l.................. j ........... I I.......... .L" ......................... .I.................. L. _---. _ .......,............. • Idali, p ocesl. - - • inlO Iocilor.....,.... com-°..... / prov,de I 1 p.....(,,,. r- ..... i 1 i . d,,,0rod.c,,
.o._,,,t,.. l .....,_y I re•0.... I . I computational / I I I :,.,........ . .rod.... / I I tso,lityt.es) / I ! I :osier,be £Socume_t : i " I / I I I •
• Ip . _ / l • :.i i _F : 1 II ! •t ; i + i +11, t, ; i I
Oeta Tcen_ Communicate. deliver, ira•stud dlta and process I
fir Sendce fr0m node to node or to I from ADS and other networks Ii
ACTIVITIES IN A DISTRIBUTED SYSTEM
A-11
IMA
SA
The
1981C
onference
On
Rem
ote
Sen
sing
Ed
ucatio
nM
ay18-22,
1981S
ession
ST
AF
FN
EE
DS
FO
RE
FF
EC
TIV
ER
EM
OT
ESE
NS
ING
EX
PLO
RA
TIO
N
byJam
esR
.D
avisP
hillipsP
etroleumC
ompany
Bartlesville,
Oklahom
a
Rem
otesensing
isassum
inga
role
inthe
searchfo
rnatural
resources.R
esearchhas
shown
thatsatellite
imagery
may
beim
portantin
locatingcertain
typesof
petroleumand
mineral
deposits.
Either
director
indirectindications
ofnatural
resourceoccurrences
haveto
bedetectibl,
fromstandard
orenhanced
imagery
data.T
heseindications
arethe
resultof
geochemical
alterationof
_oilsor
geochemical
stresson
vegetationin
affectedareas
ascom
paredto
thesurrounding
unaffectedarea.
Traditional
mapping
ofgeological
structurecan
beaccom
plishedusing
satelliteim
agerydata.
Inpetroleum
explorationthis
may
behelpful
inrem
oteunderdeveloped
countries,but
probablyw
illnot
beutilized
extensivelyin
well
mapped
areassuch
asthe
U.
S.,
Canada,
andE
urope.
Inthe
caseof
petroleum,
itis
generallyaccepted
thatpetroleum
migrates
tothe
surfacew
hereit
caninteract
geochemically
andgeobotanically.
Petroleum
rangingfrom
asphaltto
methane
isencountered
asseeps
orm
icroseepsin
soilsabove
petroleumtrapped
atdepth.
To
nalano
malies
have
beenrepo
rtedo
nLandsat
imagery,
for
example,
fromW
yom
ing.It
isbelieved
thatiron
depletionand
thepresence
ofhydrocarbons
inthe
soilover
theP
atrickD
rawfield
may
bethe
causeof
thestressed
sagebrushat
thatlocation
(N.
L.F
roman,
1976and
R.
W.
Marrs
andR
.G
aylord,1981).
At
otherlocations
suchanom
alieshave
beenattributed
todevelopm
entroads
andw
elllocations
developedafter
thediscovery
ofan
oilfield.
Tonal
anomalies
inRailroad
Valley,
Nevada
providean
interestingcase
forthe
useof
enhancedim
ageryto
clarifyan
anomaly.
Oil
was
discoveredin
theE
oceneat
4000feet
belowthe
valleyfloor.
The
anomalies
donot
coincidew
iththe
outlineof
theknow
nproduction.
This
casew
ouldprovide
agood
caseto
investigateboth
geochemically
andgeobotanically.
34
A FUNCTIONALCLASSIFICATIONOF OSTAIADSFEATURES
IMEMBERI ISUPPORT- SERVICEI
,> -- APPLICATIONS DATA -- ADMINISTRATIVE SERVICE
-- PROCESS (APPLICATIONS SOFTWARE) --TECHNICAL SERVICE
--COMPUTATIONAL FACILITY --DATA TRANSFER SERVICE
-- USER-SYSTEM INTERFACE
ADS
I2.
1. SupportMember Service
' !I I I I, I I1.2 1.3 1.4 . 2.1 2.2 2.3.
1.1 Process Computational User-System Administrative Technical DataApplications (Applications Facility Interface Service Service Transfer
Data Software) Service
! I I ! I I I1.4.1 2.1.1 2.2.1 2.3.1.
1.1.1 1.2.1 1.3.1 User Language Operations &Maintenance System Locators Data CommunicationsData Definition Computer Program Hardware 1.4.1.1 2.2.1.1 Intarfacea
1.1.1.1 Documentation Applications, System, 2.1.2 List of ADS Users ) •Data Dictionary 1.2.2 1.3.2 and Network Language Resources, Accounting 2.2.1.2
1.1.1.2 Data Requirements System Software 1.4.1.2 " Locator of Data Sets :Time Definition for a Process PrOgramming 2.1.3 and Sources
1.1.1.3 1.3.3 Language Financial Functions 2.2.1.3 2.3.2SPatial Definition Operations
1.1.1.4 Locator of Processes Oats Communlcatlona
General Vocabulary 1.4.2 2_1.4 and Their Sources Protocol1.1.1.S User Terminal Security, Access 2.2.1o4 2.3.2.t
Thesaurus 2.1.4.1 Locator of Computer Physical Layer1.4.3 Physical Security Facilities 2.3.2.2
1.1.2 User Procedure 2.1.4.2 2.2.1.5 Data Link Layer
Deta Structu're and Data Code Data Security Locator of System " 2.3.2.32.1.4.3 Services Network Layer
1.1.3 Access Security 2.3.2.4
Data Content 2.2.2 Transport Layer2.1.5 System Information 2.3.2.5
1.1.4 Performance Evaluation 2.2.2.1 Session LayerData Media On-Line 2.3.2.5
1.1.4.1 2.1.5 2.2.2.2 Presentation LayerMagnetic Tape Management-Oriented Off-Line 2.3.2.7
1.1.4.2 Documentation Application LayerRotating Magnetic Media 2.2.3
1.1.4.3 User-to-User 2.3.3
Optical Storage Media Message Service Media Transfer1.1.4.4
Microform NOTES: I. Standardsmayapptytothenodesofthishierarchyinoneormoreofthreeways: I1.1.4.5 • Howtodo If:
Graphic Image • How to describe it:• Howtouse iL
2. For each node of this hierarchy there may be kernel standards which apply to the system as a whole, and
extension standarcls which apply to one or more. t_ut not necessarily to all. ADS disctplines [user communities].
ADS HIERARCHICAL CLASSIFICATION SCHEME
I A-15
l
IMA
SA
The
1981C
onference
On
Rem
ote
Sen
sing
Ed
ucatio
nM
ay18-22,
1981S
ession
ST
AF
FN
EE
DS
FO
RE
FF
EC
TIV
ER
EM
OT
ESE
NS
ING
EX
PLO
RA
TIO
N
byJam
esR
.D
avisP
hillipsP
etroleumC
ompany
Bartlesville,
Oklahom
a
Rem
otesensing
isassum
inga
role
inthe
searchfo
rnatural
resources.R
esearchhas
shown
thatsatellite
imagery
may
beim
portantin
locatingcertain
typesof
petroleumand
mineral
deposits.
Either
director
indirectindications
ofnatural
resourceoccurrences
haveto
bedetectibl,
fromstandard
orenhanced
imagery
data.T
heseindications
arethe
resultof
geochemical
alterationof
_oilsor
geochemical
stresson
vegetationin
affectedareas
ascom
paredto
thesurrounding
unaffectedarea.
Traditional
mapping
ofgeological
structurecan
beaccom
plishedusing
satelliteim
agerydata.
Inpetroleum
explorationthis
may
behelpful
inrem
oteunderdeveloped
countries,but
probablyw
illnot
beutilized
extensivelyin
well
mapped
areassuch
asthe
U.
S.,
Canada,
andE
urope.
Inthe
caseof
petroleum,
itis
generallyaccepted
thatpetroleum
migrates
tothe
surfacew
hereit
caninteract
geochemically
andgeobotanically.
Petroleum
rangingfrom
asphaltto
methane
isencountered
asseeps
orm
icroseepsin
soilsabove
petroleumtrapped
atdepth.
To
nalano
malies
have
beenrepo
rtedo
nLandsat
imagery,
for
example,
fromW
yom
ing.It
isbelieved
thatiron
depletionand
thepresence
ofhydrocarbons
inthe
soilover
theP
atrickD
rawfield
may
bethe
causeof
thestressed
sagebrushat
thatlocation
(N.
L.F
roman,
1976and
R.
W.
Marrs
andR
.G
aylord,1981).
At
otherlocations
suchanom
alieshave
beenattributed
todevelopm
entroads
andw
elllocations
developedafter
thediscovery
ofan
oilfield.
Tonal
anomalies
inRailroad
Valley,
Nevada
providean
interestingcase
forthe
useof
enhancedim
ageryto
clarifyan
anomaly.
Oil
was
discoveredin
theE
oceneat
4000feet
belowthe
valleyfloor.
The
anomalies
donot
coincidew
iththe
outlineof
theknow
nproduction.
This
casew
ouldprovide
agood
caseto
investigateboth
geochemically
andgeobotanically.
34
MITREACTIVITIES:2
EXTEND KNOWLEDGE OF DATA SYSTEMS STANDARDS AND
GUIDELINES ORGANIZATIONS AND PROCESSES,
0 IDENTIFY STANDARDS-PROCESSING ORGANIZATIONS,
0 COLLECT STANDARDS AND GUIDELINES LISTS AND
CATALOGS, AND COPIES OF STANDARDS AND GUIDELINES,
0 ESTABLISH CONTACTS WITH STANDARDS-PROCESSING
ORGANIZATIONS (ANSI,NBS,ETC,),
0 IDENTIFY EXISTING PROCEDURES FOR EVALUATION OF
CANDIDATE STANDARDS,
MITREACTIVITIES:3
DETERMINE ADS MEMBERS' REQUIREMENTS FOR DATA SYSTEMS STANDARDSAND GUIDELINES
0 REVIEW PREVIOUS WORK ON ADSSTANDARDS REQUIREMENTS,
0 VISIT THREE PILOTS, COLLECT INFORMATION ON THEIR FUNCTIONAL
REQUIREMENTS PRACTICES, METHODS, FRAMEWORKS, DOCUMENTS, ETC,,
ESPECIALLY IN THE AREASOF DATA STRUCTURES, DATA COMMUNICATIONS,AND DATA IDENTIFICATION AND CATALOGING,
0 VISIT ORGANIZATIONS AND OPERATIONS OUTSIDE THE THREE PILOTS
WHICH MAY BECOMEADSMEMBERS, OR MIGHT BE TYPICAL OF FUTURE
ADS MEMBERS IN SOME WAY, COLLECT REQUIREMENTS INFORMATION ASABOVE,
0 CONSIDER HOW THESE COMMON FUNCTIONAL REQUIREMENTS MAY BE SATISFIED
BY THE IDENTIFICATION AND DEVELOPMENT OF STANDARDS AND GUIDELINES,
0 REPORT ON STANDARDS AND GUIDELINES AS SOLUTIONS TO PROBLEMSENCOUNTERED IN ADS,
MITREACTIVITIES:4
SURVEYANDANALYZEMETHODOLOGIESOFADSPILOTS,
0 VISIT THREE PILOTS, COLLECT DETAILED INFORMATION
ON PILOT METHODOLOGIES ESPECIALLY IN THE AREAS OF
DATA STRUCTURES, DATA COMMUNICATIONS, AND DATAIDENTIFICATION AND CATALOGING.
0 CONSIDER WHICH METHODOLOGIES MAY BE SUITABLE FOR
ADS-wIDE USE.
0 PRESENT FINDINGS,
MITREACTIVITIES:5
SURVEY EXISTING DATA SYSTEMS STANDARDS AND GUIDELINES
O CATEGORIZE, LIST, AND INDEX NoN-NASASTANDARDS AND
GUIDELINES WHICH MAY BE APPLICABLE TO ADSBASED ON
A PRELIMINARY SCREEN TO ELIMINATE STANDARDS AND
GUIDELINES WHICH ARE GROSSLY TECHNICALLY OR j
ADMINISTRATIVELY INAPPROPRIATE FOR ADS,
O PUBLISHA SURVEY DOCUMENT (MITRE MTR-81W5),O
O PREPARE AND ISSUE A SUPPLEMENT TO THE SURVEY DOCUMENT
INCORPORATING STANDARDS AND GUIDELINES FROM NASAPROGRAMS AND CENTERS_ AND UPDATING PREVIOUSLY PUBLISHED
SURVEY INFORMATION,
MITREACTIVITIES:6
COMPILE PRELIMINARY CANDIDATE SET OF
0STA/ADS DATA SYSTEMS STANDARDS AND
GUIDELINES
O COMPILE THE PILOT METHODOLOGIES AND THE
APPLICABLE NASA AND NoN-NASA STANDARDS
AND GUIDELINES INTO A SET TO BE EVALUATED
TO PRODUCE THE CANDIDATE ADSSTANDARDSAND GUIDELINES DOCUMENT,
MITREACTIVITIES: 7
DEVELOP OSTA/ADS DATA SYSTEMS STANDARDS AND
GUIDELINES EVALUATION PROCESSAND CRITERIA,
0 CONSIDER EVALUATION CRITERIA USED BY STANDARDS-
PROCESSING ORGANIZATIONS SUCH AS ANSI AND NBS,
o CONSIDER ADSSTANDARDS REQUIREMENTS IDENTIFIED
.IN A PREVIOUS TASK,
0 DEVELOP A PROCESS FOR EVALUATION OF POTENTIAL
ADS STANDARDS AND GUIDELINES,
0 DEVELOP CRITERIA FOR USE IN THE PROCESS TO
EVALUATE POTENTIAL ADS STANDARDS AND GUIDELINES,
OSTA/ADS Standards and Guidelines EvaluationProcess
PotentialOSTA/ADS
Standards&Guidelines
• Dupllcate/ _ _ . • TechnologicallyInappropriate
r ---__._%;_:__ :;_:'_;'t'u::'-','-_,'°,''''
y [DevelopOutsideThisRow or Defer]
.o _J::_.._ / OST.,Os<,, ._L_/S:..._"-----"1 _.,cfional I
I, "-,,__,_ | C,asslflca,onJ
I os,,,,osI ..-..JStandards I CombinePotential Yes
& [ Standard'Guideline SplitPotentialGuidelines _--4=. Withall or Partof StandardrGuidel[ne
Library ] OtherPotential Into2 PartsI_> rd'Guideline
'I .
I OSTA'AqS J <,_ Content _ NO
"_uit ableWithout_,,_I Standards& _
Yes ModifyTechnicalContentor RecommendedModifications
tobe Performedas a
SeparateProject
. It
• ModifyAdministrativeContent(Scope,etc.)
ForOSTA'ADSJ
() (_ ()
OSTA/ADS Standards and Guidelines EvaluationProcess (Continued)
EstablishAdministrative [
Control;PutIntoOSTNADSFormat
Circulatefor
Review
Receiveand_'- Consider
Comments
, _ 'Select•Action
l r 1 lMake Make No Make I
B
"Moderate" Minor Modifications Drop Major IModifications Modifications Needed Modifications
Add toOSTAJADS
Standards&Guidelines
Library
MITREACTIVITIES"8
EVALUATE PRELIMINARY CANDIDATE
STANDARDS AND GUIDELINES
0 PASSTHE SET OF PRELIMINARY CANDIDATE
STANDARDS AND GUIDELINES THROUGH THE
EVALUATION PROCESS,
MITREACTIVITIES"9
DEVELOP CANDIDATE 0STA/ADS DATA SYSTEMS
STANDARDS AND GUIDELINES REPORT
O ORGANIZE THE SET OF CANDIDATE 0STA/
ADS STANDARDS AND GUIDELINES_ CATE-GORIZEJ INDEX; PUT INTO AN 0STA/ADS
STANDARD FORMAT,
O PREPARE, PRODUCE, AND PUBLISH THE
SET OF CANDIDATE 0STA/ADS DATA SYSTEMS
STANDARDS AND GUIDELINES,
APPENDIXB
OSTA/ADSDATASYSTEMSSTANDARDSAND
GUIDELINESDEVELOPMENTPROGRAM
USERREQUIREMENTSFOR
ADSSTANDARDSANDGUIDELINES
I
PAUL CLEMENS MAY27,1981THE MITRE CORPORATION BC-097
McLEAN, VIRGINIA
PURPOSE
0 PRESENT RESULTS OF A SURVEY OF REPRESENTATIVE
ADS NETWORK MEMBERS TO IDENTIFY REQUIREMENTS
FOR ADS STANDARDS AND GUIDELINES
GOAL
= 0 INVITE COMMENT AND DISCUSSION.ON!
- FUNCTIONAL AREAS REQUIRING STANDARDS
- ADEQUACY OF IDENTIFIED STANDARDS REQUIREMENTS
- COMPLETENESS OF SURVEY
OUTLINEOF BRIEFING
o TASK OVERVIEW
O GENERAL FINDINGS
0 PILOT INTERCONNECTION FUNCTIONAL REQUIREMENTS
0 STANDARDS REQUIRED FOR PILOT INTERCONNECTION
FOR DATA SHARINGI
0 ISO OPEN SYSTEM INTERCONNECTION.REFERENCE
MODEL LAYER CHARACTERISTICS
0 CONCLUSIONS
TASKOVERVIEW- 2
DEVELOPMENTOFSTANDARDSREQUIREMENTS
GENERALFUNCTIONALREQUIREMENTSOFPILOTSANDOTHERDATASYSTEMS
0oo
COMMONFUNCTIONALREQUIREMENTSFORDATASHARING.INADS
FUNCTIONSWHICH'REQUIRESOMESTANDARDIZATIONINORDERTOPERMITEFFECTIVE
SYSTEMINTERCONNECTIONi
TASKOVERVIEW- 2
O REVIEWED 0STA,ADS,AND OTHER DISTRIBUTED DATA PROCESSING
DOCUMENTATION TO DETERMINE THOSE FUNCTIONS REQUIRING STANDARDS
IN A DISTRIBUTED ENVIRONMENT SUCH AS ADS,
PRIMARYSOURCES INCLUDED:
-!_ALLOPS _IORKSHOPSUMMARIES (GSFC)
- STANDARDS SURVEY (MITRE)
- DBMSWORKSHOP SUMMARIES (JPL)I
- PADSMETHODOLOGIESREPORT(CSC)
- ADS GENERIC REQUIREMENTS (CSC)
- DISTRIBUTED DATA PROCESSING STANDARDS FORECAST (NAC)
- PCDBMS USER REQUIREMENTS STUDY (0A0)
- ADS RESOURCES PILOT PROGRAM 5-YR PLAN (JSC)
TASKOVERVIEW- 3
O SURVEY MEANT TO ELICIT CONCERNS, INTERESTS, NATURE
OF PROGRAMS IN ADDITION TO STANDARDS REQUIREMENTS,
METHODOLOGIES, AND PRIORITIES
O VISITED AND SURVEYED PILOT PROJECTS AND OTHER DATA
SERVICES TO DETERMINE
-.FUNCTIONAL REQUIREMENTS
- DESIGNS, PLANS, METHODOLOGIES
- CURRENT USE OF STANDARDS
- PLANNED INTERACTION WITH ADS
- ROLE OF STANDARDS FOR ADS INTERCONNECTION
- SUGGESTIONS FOR STANDARDS DEVELOPMENT
- SUGGESTED STANDARDS & GUIDELINES
TASK0VERVIEW- 4
O ORGANIZATIONS AND PROJECTS VISITED
- PILOT ATMOSPHERES DATA SYSTEM (GSFC)
- EARTH'RESOURCES PILOT (JSC)
- OCEANIC PILOT SYSTEM (JPL)
- NATIONAL SPACE SCIENCE DATA CENTER (GSFC)
- ENVIRONMENTAL DATA AND INFORMATION SERVICE (NOAA)
I- U, S, GEOLOGICAL SURVEY (DOI)
TASKOVERVIEW- 5
0 DETERMINED GENERAL ADS REQUIREMENTS FOR STANDARDS
- INTERPRETED AND INTEGRATED DATA TO ESTABLISH
COMMON FUNCTIONAL REQUIREMENTS (To THE EXTENT
POSSIBLE WITHOUT A FIRM ADS FUNCTIONAL
DEFINITION)
- IDENTIFIED FUNCTIONAL AREAS NEEDING-THE SUPPORT
OF STANDARDS AND GUIDELINES
!
0 CATEGORIZED REQUIREMENTS FOR STANDARDS ACCORDING TO
ADS FEATURE CLASSIFICATION
0 IDENTIFIED AND PRIORITIZED THAT SUBSET OF STANDARDS
REQUIRED TO EFFECT THE INTERCONNECTION OF PILOT
SYSTEMS FOR DATA SHARING
GENERALFINDINGS- 1
OBSERVATIONS
0 DE FACTO STANDARDS PREVAIL
- USEOF IBMOR IBMLOOK-ALIKE EQUIPMENT AND IBM-COMPATIBLE VENDOR PRODUCTS
- UsEOFDECEQUIPMENT AND PRODUCTS
- OFF-THE-SHELF PRODUCTS ARE CHEAPER BUT DO NOT!
SUPPORT THE INTERCONNECTION OF DISSIMILAR SYSTEMS
0 TRADE-OFF BETWEEN STANDARDS AND TRANSLATIONS OR
REFORMATTING
- DIFFERENT REQUIREMENTS FOR SHORT AND LONG TERM
- NSSDCSUPPORTS WHATEVER FORMAT IS DESIRED ON
INPUT OR OUTPUT - THIS "SELLS" WELL, BUT RE-
QUIRES SIGNIFICANT TIME AND MONEY
GENERALFINDINGS-2
ROLEOFSTANDARDSIN ADS
O STANDARDS AND GUIDELINES PROVIDE SOLUTIONS TO THE
PROBLEMS ENCOUNTERED IN INTERCONNECTING DISSIMILAR
SYSTEMS FOR DATA SHARING
- VARYING TERMINOLOGY
- DIFFERENT DATA FORMATS
- DIFFERENT COMPUTING EQUIPMENTO
- DIFFERENT OPERATING SYSTEMS
- VARIOUS DATA BASE MANAGEMENT SYSTEMS
- DIFFERENT COMMUNICATIONS FACILITIES
- WIDE VARIETY oFDATA SETS
- INCOMPATIBILITY OF CATALOGS
GENERALFINDINGS- 3
AREASOFCONCERN
O STANDARDS ARE EITHER INADEQUATE OR TOO
COMPLICATED
O STANDARDS ARE REQUIRED ONLY TO CONNECT
DISSIMILAR SYSTEMSI
O MORE FRUITFUL TO -STANDARDIZE WAYS OF TALKING
ABOUT DATA THAN TO STANDARDIZE DATA
O LET INDUSTRY DEVELOP STANDARDS - UTILIZE
WHAT'S AVAILABLE
O STANDARDS WORK SHOULD BE PRACTICAL, REFLECT
THE REAL WORLD
FUNCTIONALREQUI REMENTS
FORPILOTSYSTEMINTERCONNECTION"
0 REQUIREMENTSFOR STANDARDSAND _UIDELINES
CORRELATEDWITH ADS FEATURE CLASSIFICATION
- HIGH LEVEL_ TOP-DOWN MODEL OF ADS
I
0 REQUIREMENTS FOR STANDARDS AND GUIDELINES
FOR PILOT SYSTEM INTERCONNECTION FOR DATA
SHARING
- FOUR OF SEVEN COLUMNS OF ADSCLASSIFICATION
- CORRELATE WITH WORKSHOP PANEL SUBJECTS
ADS
I I1.
"ember
2SUpport'-lYlce
I1.1
AppllcatlonaOala
I
I1.2
Proce... (Appllcatlona
Software)
I
II
1.3Compulatlonal
Facility
I
I1.4
Uaer-5yalemInter'ace
.I
./
r2.1
AdmlnlalrallYeService
I
2.2TechnIcalS.rvIc.
Iu.Data
Trana'.rS.nlce
I
1.3.2Do..eam-_r-2.3.2.1....,-Loy.2.3.2.2
00..UnIl ...,.,1.3.2.3
N..."", ...,.,2.3.2.4
T.....poIlLoy.1.3.2.5...-...,.,2.3.2..-...,.,U.2.7
AppIJcalIoA ...,.
1.3.3MIldIA Trani'"
1.3.1.Do..c-.u_InlerlKIl
2.U.r.telll Locator.1.2.1.1
UlloIADSU....I.2.U •loctlafol__
....-...2.2.1.3
Loca....oIProco........1lIIlr_c..
1.2.1.4Locatorole-puwF",_.
1.2.1.1Loca....018'__.
1.2.28,_......__1.2.2.1
c.une1.2.2.2
0IHJne
J.UBtcwtly. AcCt..J.1.4.1
PIlJIIctI-.,1.1.4.2Dolo-'
I.I.UAcc...-,
U.IOpon_a_
J.UR._.-....J.U
F1nIIIdoIF_
1.4.3Uti' PrOAdura
1.4.2U••T..........
1.4.1u..,Languog.1.4.1.1
AppIIca_:8,._.and N._IllUnauogl
1.4.1.2progr.....1ngLanguag.I.U
Opor_
U.I_or.
NOTU: r. __y~",,,,._..oIlhi"IIItI_Y"_Dl_tJl""H_'_",doll;'_",do_1I;• How"'UH,,"
Z. F"'.odt_oIW.hl"_ylh".....ybek"...__OIlPI'I",,,,..y_ __
......- -.I.-0IlPI'I"''''''''''-. OUIIlOf ......_ly",...ADSdI~.( -.v_J.
U.ICompu" Progr...Docum.ntatlon
I.UDo..R.qullo...nl.'OtIPrOC.1I
I.UDo.. SIIUCtur. and Do.. Cod.
I.UD... Content
I.UDo.. 0011111110<11.1.l.1D." Dictlonaly
I.I.Unm.o.nnltlotl
U.USpatial Oollnllion
U.UG.n,ral VocabulAlJ'
1.1.1.5Thuu",.
1.1.4Do.....dtaI.U.I
UogMUOTepe1.1.4.2-...... ...gMlla ..tdlo
1.1.4.3OplicolSlofooe_
I.l.UMic:ro'onlIII
1.1.4.5G_Im_
b:lI....
W
,os II
SupportMember Service
! ! ii !Data
Applications User-System TechnicalData Interface Service Transferservlce
! i It:_ User Language Data CommunicationsI Data Definition System Locators
o--, " Interfaces
Data Dictionary Applications System, Llstof ADS Users
and Network Language Data Communications
Time Dellnillon Locator of Data Sets ProtocolUser Terminat and Sources
Spatial Definition Physical LayerLocator ol System
General Vocabulary User Procedure Services Data Link Layer
Data Structure and Data Code Network LayerSystem Information
Transport LayerData Content On-Une
Session LayerOff-Line
Data Media __ Presentation Layer
User-to-User Application LayerMessage Service
_ CATALOGSDATAFORMATS "USE._. "- DIRECTORIES•& ISO/OSI& DESCRIPTIONS INTERFACE DICTIONARIES MODEL
RELATIONSHIP BETWEENFUNCTIONAL,TECHNICAL,ANDSTANDARDSREQUIREMENTS
ADS REQUIRED REQUIREDCAPABILITIES TECHNOLOGY STANDARDS
LIST OF DATA HOLDINGS 0 PRINT 0 TERMINOLOGY
0 DATA DESCRIPTION
REMOTE ACCESS TO 0 DIAL-UP COMM. 0 VIRTUAL TERMINAL PROTO.
CATALOGS 0 DBMS/FILE MGMT. 0 CATALOG LOCATORS
0 CATALOG STRUCTUREI- 0 QUERY LANGUAGE
REMOTE ACCESS TO DATA 0 HIGH-SPEED COMM. 0 DATA FORMATS
0 LARGE VOLUME DATA MGMT. 0 COMM, PROTOCOLS
00P, SYS, INTERFACE
o DBMSINTERFACE
DISTRIBUTED NETWORK 0 DISTRIBUTED SYSTEM 0 NETWORK .DIRECTORY
SOFTWARE (COMM., OP. 0 TASK ADDRESSING
SYS.,DBMS)
STANDARDSREQUIREMENTSFORAPPLICATIONSDATA- 1
o ADS STANDARDS FOR DATA SHARING ARE
REQUIRED IN FOURGENERAL AREAS'
- DATA DESCRIPTION
- DATA FORMATS, STRUCTURES, AND CODES
- DATA CONTENT REPRESENTATION
' - DATA MEDIA
STANDARDSREQUIREMENTSFORAPPLICATIONSDATA- 2
DATADESCRIPTION
O GUIDELINES ARE REQUIRED FOR THE DESCRIPTION
OF DATA CHARACTERISTICS
- SPACECRAFT AND SENSORS USED
- SENSOR CHARACTERISTICSI
- ASPECTS OF REALITY DESCRIBED BY THE DATA
- GEOGRAPHICAL COVERAGE
- TEMPORAL CHARACTERISTICS OF DATA
- FORM OF THE DATA (GRAPHIC, NUMERIC, TEXTUAL)
- PARAMETERS ASSOCIATED WITH FORM OF DATA
- QUALITY OF THE DATA
- PROCESSING PERFORMED ON THE DATA
- DATA IDENTIFICATION SCHEME
STANDARDSREQUIREMENTSFORAPPLICATIONSDATA- 3
0 GENERAL VOCABULARY STANDARDS ARE REQUIRED IN
ORDER TO TALK ABOUT DATA & DATA-RELATED
ACTIVITIES
- DEFINITIONS
- WORDS
- TERMS- UNITS
I
0 STANDARD SET OF KEY ELEMENTS OR CODE NAMES
FORDATASUBELEMENTS
0 SPATIAL DEFINITION STANDARDS FOR BOTH DESCRIB-
ING AND FOR LABELING DATA
- SPATIAL RESOLUTION
- SPATIAL LOCATION (GRIDS, COORDINATE SYSTEMS)
- LABELING STANDARDS
- CONVERSION PARAMETERS
STANDARDSREQUIREMENTSFORAPPLICATIONSDATA- ff
DATAFORMATS,STRUCTURES,AridCODES
o Two FORMAT STANDARDIZATION APPROACHES
- STANDARDIZE THE ARRANGEMENT AND REPRESENTATION
OF DATA.
- STANDARDIZE THE MECHANISM FOR DESCRIBING WHAT
EXISTS WITHIN THE ADSMEMBERSHIP,I
o STANDARD DATA INTERCHANGE FORMATS ARE REQUIRED FOR
USE BETWEEN MEMBER-NODES -
- STANDARD DATA DESCRIPTORS (HEADERS)
- STANDARD NUMBER REPRESENTATIONS
- STANDARD CHARACTER CODES
- STANDARD RECORD STRUCTURE DESCRIPTION
- STANDARDSREQUIREMENTSFORAPPLICATIONSDATA- 5
O STANDARD TERMINOLOGY AND GUIDELINES ARE REQUIRED
FOR THE USE OF DATAAGGREGATES SUCH AS:
- STRINGS
- ARRAYS
- LISTS
- TREES
- PACKETSI
0
0 A METHODOLOGY FOR DESCRIBING DATA CONTENT IN A
UNIFORM OR STANDARDIZED MANNERIS NECESSARY,
- GEOGRAPHIC CODING AND REFERENCING
- NULL, MISSING, OR FUTURE DATA
STANDARDSREQUIREMEB!TSFORAPPLICATIONSDATA- 6
DATACONTENTREPRESENTATION
0 STANDARDDATA FORMATSARE REQUIREDTO REPRESENT
APPROPRIATE CATEGORIESOF DATA, SUCH AS
- IMAGE DATA
- GRAPHIC DATA
-MULTIDIMENSIONAL DATA SETS
- TEXTUAL DATAI
•
DATAMEDIA
0 A FAMILY OF STANDARD MEDIA FOR THE STORING AND
PHYSICAL TRANSFER OF ADS DATA IS _EEDED
- MAGNETIC TAPE
- ROTATING MAGNETIC MEDIA
- OPTICAL.STORAGE MEDIA
STANDARDSREQUIREMENTSFORUSER-SYSTEMINTERFACE- 1
0 STANDARD MAN-MACHINE INTERFACE LANGUAGE(S)
(COMMAND LANGUAGE, MENU, CONVERSATIONAL INTER-
ACTION, OR COMBINATION) TO
- ESTABLISH INTERACTIONS WITH ADS
- REQUEST HELP IN USING ADS
I
- SEARCH CATALOGS OF DATA PRODUCTS AND SERVICES
- REQUEST DATA PRODUCTS AND SERVICES
- REQUEST ACCOUNTING AND BILLING INFORMATION
- REPORT PROBLEMS
[USER LANGUAGE(S) TO DO ABOVE WOULD REQUIRE
TRANSLATION PROTOCOLS FOR
- QUERY REPRESENTATION
- DBMSRESPONSE- FILE STRUCTURES
- DATA ACCESS
-CATALOG STRUCTURES]
STANDARDSREQUIREMENTSFORUSER-SYSTEMINTERFACE-2
0 STANDARD DATA MANIPULATION FUNCTIONS
- SCALING
- SUMMING
- COMBINING
0 STANDARD EDITING FUNCTIONS
I
0 STANDARD BACKUP/RECOVERY PROCEDURES
0 GUIDELINES FOR TERMINAL EQUIPMENT TO BE
SUPPORTED BY ADS
o VIRTUAL TERMINAL PROTOCOL STANDARD-
0 USER PROCEDURE GUIDELINES
STAI_IDARDSREQ!IIREMENTSFORTECHNICALSERVICES- 1
0 STANDARDS ARE REQUIRED FOR NAMING DATA
SETS, PROCESSES, AND MEMBERS WITHINADS
- PROVIDE USER INTERFACE TO ADSRESOURCES
- STANDARD FORMATS FOR INFORMATION EXCHANGE
- ACCESSABLE BY USER LANGUAGEI
- "HELP" FUNCTION
STANDARDSREQUIREMENTSFORTECHNICALSERVICES- 2
O STANDARD FORMAT(S) FOR LISTING ADS MEMBERS IS
REQUIRED THAT WOULD LIST SUCH ITEMS AS:
- NAME AND ADDRESS
- TYPE OF MEMBERSHIP
- EQUIPMENT (TERMINAL, HOST)
- OPERATING SYSTEM,
- DBMS- TRAFFIC CAPACITY
0 SUMMARY LEVEL DATA DESCRIPTION STANDARDS ARE
REQUIRED FOR DATA LOCATION
- CONVENTIONS FOR THE EXISTENCE, LOCATION, AND
USE OF REDUNDANT DATA ENTITIES
- CONVENTIONS FOR DATA BASE VALIDAT.ION
- CONVENTIONS FOR DISPLAY OF LOCATOR RESPONSES
- STANDARD REFERENCE FRAMES (GEOGRAPHICAL &
TEMPORAL)
STANDARDS REQUIREMENTS FnRTECHNICAL SERVICES - 3
o STANDARD FORMATS ARE REQUIRED FOR LISTING SYSTEMRESOURCES
- ApPLICATIONS SOFTWARE PACKAGES
• SOURCE• DOCUMENTATION• PROCESS RESIDENCE
- COMPUTATIONAL FACILITIES
• LOCATION• CAPABILITIES/RESOURCES• AVAILABILITY• CHARGES• EQUIPMENT
- SYSTEM SERVICES
o STANDARDS ARE REQUIRED FOR UPDATING~ ADDING~ ANDDELETING INFORMATION ENTITIES
- DATA- MEMBERS- SYSTEM RESOURCES
STANDARDSREQUIREMENTSFORDATATRANSFERSERVICES- 1
0 STANDARDS ARE REQUIRED TO FACILITATE THE TRANSFER
OF DATA THROUGHOUT THE ADS NETWORK
- PHYSICAL INTERCONNECTION OF DISSIMILAR SYSTEMS
- RULES AND PROCEDURES FOR TRANSMITTING DATA
ACROSS THE INTERCONNECTION OF DISSIMILAR
SYSTEMSI
O IS0 REFERENCE MODEL FOR OPEN SYSTEM INTERCONNECTION
(IS0/TC97/SC16 N227) PROVIDES A FRAMEWORK FOR DE-
FINING THESE STANDARDS
STANDARDSREQUIREMENTSFORDATATRANSFERSERVICES- 2
0 INTERCONNECTION STANDARDS ARE REQUIRED FOR PHYSICAL INTERFACE AND THE
METHODOLOGIES, CONTROL PROCEDURES, AND RULES WHICH ALLOW DATA INTERCHANGE,
SOME EXAMPLES ARE;
- DATA LINK CHARACTERISTICS
, SPEED
. ERROR RATE
- TRANSMISSION CHARACTERISTICS
. HALF OR FULL DUPLEX
. SYNCHRONOUS OR ASYNCHRONOUS
- DATA ORIENTATION!
. LINE ORIENTED
. CHARACTER (BYTE) ORIENTED
. BIT ORIENTED
. PACKET ORIENTED
- DATACODES,ASCII, EBCDIC
- ERROR CONTROL
. REDUNDANCY
. PARITY
. CYCLICAL REDUNDANCY CHECK
- TERMINAL CHARACTERISTICS
, SPEEDS
, CODES
, COUPLING (DIRECT, MODERN, OR ACOUSTIC)
, BUFFERING AND ERROR CONTROL
t_I
STANDARDSREQUIREMENTSFORDATATRANSFERSERVICES- 3
0 STANDARD INTERFACES ARE REQUIRED FOR THE TRANSFER OF FILES AMONG MEMBER
NODES OF ADS NETWORK,
- FILES INCLUDE:
, DATA SETS
, INFORMATION ABOUT DATA SETS
, GENERAL OF SYSTEMS INFORMATION
, MESSAGES/QUERIES
, APPLICATIONS SOFTWAREI
o - MEMBER NODES MAY INCLUDE_
, INDIVIDUALS
, FACILITIES
, PROCESSES
, DATA
- TRANSFER CAN BE:
, PHYSICAL
, ELECTRONIC (MANY DEGREES OF TRANSPARENCY)
STANDARDSREQUIREMENTSFORDATATRANSFERSERVICES- 4
o ISO/OSI MODEL REQUIRES THAT STANDARDS BE DEFINED
IN TWO AREAS
- STANDARD ADSSERVICES HAVE TO BE DEFINED
FOR EACH OF THE MODEL'S LAYERS
. FUNCTIONS TO BE PERFORMED IN EACH LAYER
. PRIMITIVES (REQUEST AND RESPONSES) TO BE
i PASSED BETWEEN LAYERS
. PARAMETER INFORMATION REQUIRED TO SUPPORT
SERVICES
- STANDARD PEER PROTOCOLS ARE REQUIRED TO PROVIDE
NECESSARY PROCEDURES FOR THE FUNCTIONAL UNITS
WITHIN A SPECIFIC LAYER, BUT DISTRIBUTED
THROUGHOUT THE NETWORK, TO INTERACT WITH EACH
OTHER AND EXCHANGE INFORMATION
A B A B
N+ILAYER
iII
i _OG ICAL GROUPN LOGICAL GROUP"LAYER OF FUNCTIONS s OF FUNCTIONS
i
1 " -J1_ N-1I
LAYER A B A B
NODE X NODE Y
A = LAYERSERVICESB = PRIMITIVES/ PARAMETERSC = PEERPROTOCOL
0 EXCHANGE OF PRIMITIVES AND PARAMETERS SUPPORT SERVICES PROVIDED BY A LAYER
TO ITS NEXT HIGHER LAYER
0 PEER PROTOCOLS HANDLE INTERACTION BETWEEN UNITS OF THE SAME LAYER
OSILAYERCHARACTERISTICS- 1
PHYSICALLAYER
0 TYPE OF SERVICES PROVIDED
- PHYSICAL CONNECTION
- DATA UNIT TRANSMISSION
- FAULT CONDITION NOTIFICATION
0 TYPE OF FUNCTIONS PERFORMEDI
- ACTIVATION
- DEACTIVATION
- UPWARD MULTIPLEXING
- FAULT DETECTION
0 PRIMITIVE / PARAMETER EXAMPLES
- CONNECTION REQUEST
- CONNECTION INDICATION
- FAULT INDICATION / NATURE OF FAULT
OSILAYERCHARACTERISTICS- 2
0 REPRESENTATIVE PROTOCOLS
- EIARS-232-C- EIARS-449- CCITTX.21
!L_
OSI LAYERCHARACTERISTICS- 3
DATALINK LAYER
0 TYPE OF SERVICES PROVIDED
- ACTIVATE_ MAINTAIN_ DEACTIVATE DATA LINKS
- FRAME SYNCHRONIZATION
- ERROR DETECTION AND RECOVERY
I
0 TYPE OF FUNCTIONS PERFORMED
- DATA LINK ESTABLISHMENT
- DATA UNIT TRANSFER
- ERROR NOTIFICATION
- FLOWCONTROL- DOWNWARD MULTIPLEXING
0SlLAYERCHARACTERISTICS-4
0 PRIMITIVE / PARAMETER EXAMPLES
- ESTABLISHMENT REQUEST / ADDRESS, FACILITY, CLASS
OF SERVICE
- RESET REQUEST
- RECALL REQUEST / CHANGE CONNECTION PARAMETERS
0 REPRESENTATIVE PROTOCOLS
- CHARACTER-ORIENTEDI
IS01745ANDANSIX328. IBMBINARY SYNCHRONYMS COMMUNICATIONS
PROTOCOL (BSC)
- BIT-ORIENTED
, IS0 HIGH LEVEL DATA-LINK CONTROL (HDLC)
. ANSIADVANCED DATA COMMUNICATIONS CONTROL
PROCEDURE (ADCCP)
- OTHERS
., LAP/LAP-B PORTION OF ANSI X,25
, IBM SYNCHRONOUS DATA LINK CONTROL (SDLC)
OSlLAYERCHARACTERISTICS- 5
NETWORKLAYER
0 TYPE OF SERVICES PROVIDED :
- NETWORK CONNECTION
- CONNECTION ENDPOINT IDENTIFICATION
- ERROR NOTIFICATION
- SEQUENCE CONTROL (OPTIMAL)I
- DATA UNIT DELIVERY CONFIRMATION
0 TYPE OF FUNCTIONS PERFORMED
- ROUTING AND SWITCHING
- RESET
- TERMINATION
- RECALL
- UPWARD MULTIPLEXING
OSILAYERCHARACTERISTICS- 6
- SEGMENTING AND BLOCKING
- ERROR DETECTION
- ERROR RECOVERY
- MAPPING NETWORK ADDRESSES WITH THE TRANSPORT
ADDRESSES
- RESOURCE MANAGEMENT
- RELAYING (TRANSPARENT FORWARDING OF DATA
UNITS FROM ONE NETWORK ENTITY TO ANOTHER)
I
O PRIMITIVE / PARAMETER EXAMPLES
- ESTABLISHMENT REQUEST / ADDRESS, FACILITY CLASS
OF SERVICE
- RESET REQUEST
- RECALL REQUEST / NETWORKCONNECTION PARAMETERS
O REPRESENTATIVE PROTOCOLS
- CCITTX.25(PACKET SWITCHED)
- CCITTX,21(SYNCHRONOUSCIRCUITSWITCHED)- CCITT .20 (ASYNCHRONOUS PUBLIC DATA NET)
- RS-366-A (AUTO-CALLING FOR TELEPHONE)
0Sl LAYERCHARACTERISTICS- 7
TRANSPORTLAYER
O TYPE OF SERVICES PROVIDED
- CONNECTION ESTABLISHMENT
- DATA TRANSFER
- FLOW CONTROL
O TYPE OF FUNCTIONS PERFORMEDI
- SELECTING APPROPRIATE NETWORK SERVICE
- MULTIPLEXING TRANSPORT CONNECTIONS
- ESTABLISHING AN OPTIMUM DATA UNIT SIZE
- MAPPING TRANSPORT ADDRESSES ONTO THE
NETWORK
- DETECTING ERRORS IN RECEIVED DATA
- BYPASSING FLOW CONTROL FOR EXPEDITED DATA
- PURGING DATA TO FACILITATE RECOVERY
0SILAYERCHARACTERISTICS- 8
O PRIMITIVE / PARAMETER EXAMPLES
- CONNECTION REQUEST / CALLING & CALLED
ADDRESSES_ REQUIRED FACILITIES_ •QUALITY
OF SERVICE
- CLEAR INDICATION / NETWORK FAILURE
0 REPRESENTATIVEPROTOCOLS
•- - CCITTRECOMMENDATION S,70 (TELETAX)
- ARPATRANSMISSIONCONTROLPROTOCOL(TCP!
o VERSION 4)
0SILAYERCHARACTERISTICS- 9
SESSIONLAYER
O TYPE OF SERVICES PROVIDED
- SESSION ESTABLISHMENT
- SESSION MANAGEMENT
, - USER DATA EXCHANGE
- DATA QUARANTINE (RESTRICTION OF
WHICH DATA ARE SENT OR RECEIVED)
- INTERACTION MANAGEMENT
0SILAYERCHARACTERISTICS-10
O TYPE OF FUNCTIONS PERFORMED
- BIND PRESENTATION ENTITIES INTO A COOPERATING
RELATIONSHIP
- ENABLE PRESENTATION ENTITIES TO DETERMINE
UNIQUE VALUES OF OPERATING PARAMETERS
- SUPPORT TRANSFER OF UNIT OF DATA
- YIELDS CONTROL OF DATA UNIT TO sENDING
, PRESENTATION ENTITY
- PROVIDES DIALOG CONTROL USED TO ESTABLISH
2-WAY SIMULTANEOUS INTERACTION, 2-WAY ALTERNATE
INTERACTION, OR I-WAY INTERACTION
- MAPPING SESSION CONNECTIONS INTO TRANSPORT
CONNECTIONS
- FLOW CONTROL
- CONNECTION RECOVERY
O PRIMITIVES / PARAMETERS NOT WELL DEFINED
O REPRESENTATIVE PROTOCOLS
- BELL SYSTEM'S VERSION OF X.25 (BX.25) WHICH
DESCRIBES A SESSION LAYER PROTOCOL TO WORK
WITH X.25 NETWORK SERVICES.
OSILAYERCHARACTERISTICS-11
PRESENTATIONLAYER
o TYPE OF SERVICES PROVIDED
- DATA TRANSFORMATION: CODE AND CHARACTER SET
TRANSLATIONS
- INFORMATION FORMATTING: MODIFICATION OF DATA
= LAYOUTI
-SYNTAX SELECTION: INITIAL SELECTIONS AND
SUBSEQUENT MODIFICATION OF THE TRANSFORMATIONS
AND FORMATS USED
0 TYPE OF FUNCTIONS PERFORMED
- PRESENTATION-SERVICE ESTABLISHMENT
- SERVICE INITIALIZATION
- IMAGE NEGOTIATION (DETERMINE NECESSARY CONVERSION)
- INFORMATION TRANSFORMATION AND FORMATTING
- PRESENTATION-SERVlCE RELEASE
0 PRIMITIVE / PARAMETER EXAMPLE
- PRESENTATION CONNECTION REQUEST / CODE, FORMAT
OSILAYERCHARACTERISTICS- 12
O TYPE OF PROTOCOLS UNDER DEVELOPMENT
- VIRTUALTERMINAL PROTOCOL
, HANDLE A NUMBER OF TERMINAL CLASSES AND PARAMETER
PROFILES TO ACCOMMODATE DIFFERENT APPLICATIONS
- VIRTUAL FILE PROTOCOL
, FORMATTING OF FILE-STORE COMMANDS
, COMMUNICATION OF FILE INFORMATION
. CODE CONVERSION(
- JOB TRANSFER AND MANIPULATION PROTOCOL
i , CONTROL OF RECORD STRUCTURES AND RELATED DEVICES
, COMMAND FORMATTING
, DATA FORMATTING
0SILAYERCHARACTERISTICS- 13
APPLICATIONLAYER
0 TYPE OF SERVICES PROVIDED
-IDENTIFICATION OF INTENDED COMMUNICATIONS PARTNERS
- AGREEMENT ON PRIVACY MECHANISMS
- AUTHENTICATION OF INTENDED COMMUNICANTS
-DETERMINATION OF COST OF ALLOCATION METHODOLOGY
i - DETERMINATION OF ADEQUACY OF REQUIRED RESOURCES
- DETERMINATION OF THE ACCEPTABLE QUALITY OF SERVICE
- AGREEMENT ON RESPONSIBILITY FOR ERROR RECOVERY
- INFORMATION TRANSFER
O TYPE OF FUNCTIONS PERFORMED
- INITIATION OF THE INTERCONNECTION
- TERMINATION OFTHE INTERCONNECTION
- SYNCHRONIZATION
- COMMITMENT OF RESOURCES
- TASKING
- INFORMATION TRANSFER
0SILAYERCHARACTERISTICS- 14
O PRIMITIVES ARE UNDEFINED
O TYPE OF PROTOCOLS To BE DEVELOPED
- SYSTEM MANAGEMENT
ACTIVATION/DEACTIVAtION MANAGEMENT
, MONITORING
, ERROR CONTROL
, RECOVERY
' - APPLICATIONS MANAGEMENT
, AUTHENTICATION
, ACCESS CONTROL
, ACCOUNTING
, DEADLOCK RECOVERY,
, COMMITMENT
- USER APPLICATION.
, REMOTE JOB ENTRY
, SUBPROCESS SELECTION
, FILE ACCESS
, (ADDITIONAL USER SPECIFIC)
CONCLUSIONS- 1
o REQUIREMENTS OF PILOTS FOR STANDARDS REFLECT THE
FUNCTIONAL PRIORITIES AND SCOPE OF EACH PILOT
- PADSis CURRENTLY DEALING WITH THE INTERCON-
NECTION OF DISSIMILAR OPERATING SYSTEMS AND
DBMSsTO PROVIDE ACCESS TO DISTRIBUTED ATMOS-
PHERIC DATA AND CATALOGS
- OPS PRESENT EMPHASIS IS ON THE MANAGEMENT OF
OCEANIC DATA AND PROVIDING ACCESS TO THESE
LARGE GEOREFERENCED DATA BASES TO REMOTE USERS
- ERPIS DEALING PRIMARILY WITH THE CATALOGING
AND PROVISION OF THE WIDE VARIETY OF DATA
ASSOCIATED WITH EARTH RESOURCES (LANDSAT
IMAGERY, METEOROLOGICAL DATA, CROP STATISTICS)
AND THE DEVELOPMENT OF TECHNIQUES FOR MULTI-
TEMPORAL/MULTI-SENSOR DATA CORRELATION
CONCLUSIONS - 2
esc· I PADS STANDARDS REQUIREMENTS
o ADS STANDARD DATA SET DESCRIPTOR LANGUAGE
o ADS TRANSMISSION DATA FORMAT
o ADS DATA UNITS STANDARD
o ADS DATA LABELS STANDARDS
o ADS DATA ORGANIZATION STANDARDS
o DATA QUALITY STATUS
O'STANDARD FOR DBMS CALL YIELDING ATTRIBUTE SETISTRUCTURE INFORMATION
o ADS STANDARD QUERY LANGUAGE- OPERATOR INTERFACE- REQUEST TRANSMISSION- DBMS INTERFACE
o ADS DATA MANIPULATION LANGUAGE
o ADS DATA SECURITY SPECIFICATIONS
o ADS INTERPROCESSOR COMMAND/STATUS MESSAGE FORMAT
o DIRECTORY ENTRY FORMAT
o MAN-MACHINE INTERFACE
CONCLUSIOHS- 3
OCEANPILOTSYSTEMSTANDARDSREQUIREMENTS
O CATALOGINGAND DIRECTORY STANDARDS
- TERMINOLOGY
O COMMUNICATIONSPROTOCOLS
O DATA STRUCTURES
O DATA DEFINITION
' DATA ELEMENT DICTIONARY
- DBAFUNCTION
o SOFTWARE TRANSPORTABILITY
- TAE,VICAR
o ADSSYSTEM/NETWORKCHARACTERISTICS- DISTRIBUTIONOF DATA
- DATA TO BE SHARED
- STANDARDS FOR USER INTERFACE
J
CONCLUSIONS- 4
EARTHRESOURCESPI LOTSTANDARDSREQUIREMENTS
0 GLOBAL DATA DIRECTORY
- FORMAT AND STRUCTURE STANDARDS
0 ACCESS TO CATALOGS
- DATA DESCRIPTION STANDARDSI
o
o ACCESS TO DATA
- EXTERNAL DATA FORMAT STANDARDS
- COMMUNICATION PROTOCOL STANDARDS
- STANDARD INTERFACES TO
, OPERATING SYSTEMS
,DBMS, USERS
0 STANDARDS FOR SOFTWARE TRANSPORTABILITY
CONCLUSI0_IS- 5
O SUGGESTED PRIORITIES FOR ADS
STANDARDS DEVELOPMENT
- TERMINOLOGY
- DATA DESCRIPTION
- DATA LOCATIONS
-.EXTERNAL DATA FORMAT(S)
- USER (COMMAND, QUERY) LANGUAGE
- SOFTWARE TRANSPORTABILITY
- DISSIMILAR OPERATING SYSTEM INTERFACES
- DISSIMILAR DBMS INTERFACES
APPENDIXC
OSTA/ADSSTANDARDSANDGUIDELINESDEVELOPMENTPROGRAM
o ADSPILOTMETHODOLOGIESASCANDIDATESFORADSSTANDARDSl
PAULA,GIRAGOSIAN OSTA/ADSDATASYSTEMSTHEMITRECORPORATION STANDARDSWORKSHOPMcLEAN,VIRGINIA MAY27,1981
BC-103
.PRESENTATI ONOUTLINE
OBJECTIVE
To IDENTIFY AND DOCUMENT METHODOLOGIES OF THE ADS PILOTS:
• PILOT ATMOSPHERES DATA SYSTEM (PADS)
AT GODDARD SPACE FLIGHT CENTER (GSFC)
• EARTH RESOURCES PILOT SYSTEM (ERPS)
AT JOHNSON SPACE CENTER (JSC)
• OCEANIC PILOT SYSTEM (OPS)
AT JET PROPULSION LABORATORY (JPL)I
METHODOLOGIES.MAY SERVE AS A BASIS FOR THE INTERCONNECTION OF ADSPILOTS FOR DATA SHARING
OUTLINE
(CONTINUED)
METHODOLOGYDEFINITION'
PRACTICES, CONVENTIONS, PROCEDURES, OR STANDARDS WHICH ARE UTILIZED
IN THE DESIGN, DEVELOPMENT' AND IMPLEMENTATION OF THE PILOT SYSTEMS,
C_I
OUTLINE
(CONTINUED)
PILOT ATMOSPHERES DATA SYSTEM (PADS)
• OVERVIEW
• PADSCOMMUNICATION
- SYSTEM OF NETWORK APPLICATION PROCESSORS (SNAP)
- COMMUNICATION CONTROL SOFTWARE (COMM)
- REMOTE.SERVICES SUBSYSTEM (RSS)
9 • USER INTERFACE
• CATALOG STRUCTURE
• CATALOG INTERFACE
• COMMUNICATION FACILITY INDEPENDENCE
• SOFTWARE DEVELOPMENT METHODOLOGY
• FUTURE METHODOLOGY ENHANCEMENTS
OUTLINE
(CONTINUED)
EARTH RESOURCESPILOTSYSTEM (ERPS)
• OVERVIEW
• ERPCOMMUNICATIONS
• USER INTERFACE
• RESEARCH, TEST & EVALUATION (RT&E) DATA BASE
? - RT&EDIRECTORY- RT&ECATALOGSTRUCTURE
• DATA DEFINITION STRUCTURE
- DATA PROVISIONING
- DATA HANDLING TECHNIQUES
• FUTURE METHODOLOGY EVALUATION PROGRAMS
OUTLINE
(CONTINUED)
OCEANIC PILOT SYSTEM (OPS)
• OVERVIEW
• OPSCOMMUNICATION
• USER INTERFACE
• DATA STRUCTURE/DEFINITIONI
- STANDARD FORMAT DATA UNIT (SFDU)
- DATA HANDLING METHODS
• CATALOG STRUCTURE
• SOFTWARE DEVELOPMENT METHODOLOGY
• FUTURE ENHANCEMENTS
CONCLUSIONS
PILOTATMOSPHERESDATASYSTEM(PADS)
I
PADSCOMMUNICATION
• SYSTEM OF NETWORK APPLICATIONS PROCESSORS (SNAP)a
. • COMMUNICATIONS CONTROL SOFTWARE (COMM)
• REMOTE SERVICES SUBSYSTEM (RSS)
I.Go
INITIAL CONFIGURATIONOFSYSTEM0FNETWORKEDAPPLICATIONSPROCESSORS(SNAP)
¢ VISIBLE INFRARED SPIN SCAN RADIOMETER.(VISSR)
ATMOSPHERE SOUNDERS (VAS) PROCESSOR
PDP- 11/70
RSX- 11M
VAS DATA MANAGEMENT SYSTEM (VASDM)
INTEGRATED DATABASE MANAGEMENT SYSTEM (IDBMS) PROCESSOR
9 VAX- 11/780VAX/VMS
SEED
ATMOSPHERICAND OCEANOGRAPHICINFORMATION PROCESSINGSYSTEM (A01PS)
PDP- 11/70RSX 11D
vas DATA MANAGEMENTSYSTEM
CENTRAL COMMUNICATIONS PROCESSOR (CCP)
PDP- 11/34RSX 1IN
INITIALCONFIGURATIONOF"SYSTEMOFNETWORKEDAPPLICATIONSPROCESSORS(SNAP)
AOIPS SYSTEM
PDP I
IDATA USER
BASE TERMINALS
VAS SYSTEM
CENTRAL <---
COMMUNICATIONS _ MM_ 1PROCESSOR < CO PDP
PDP 11/70
DATA USER
BASE TERMINALS
IDBMS VAX SYSTEM
. Co.._ wax11/780
DATA USER
BASE TERMINALS
C-10
CURRENTPADS/RSSCAPA ILITIES
• LOGON/LOGOFF VIA INTERACTIVE TERMINAL
• ESTABEISH/REMOVE USER IDANDPAsSWORD
• DISPLAY CATALOG INFORMATION
Q MODIFY ATTRIBUTE VALUES FOR LOCAL CATALOG ENTRY
• ALLOCATE NEW CATALOG ENTRY AND ALLOCATE DISK SPACE
• COPY A CATALOGED DATA SET
? • DELETE A CATALOG ENTRY AND DATA SET
• SEND r_ESSAGETO OTHER LOGGED-ONUSER(S)
• NETWORKSTATISTICS FOR _ETHORKCOMMUNICATION
PADS/RSSPROVIDES'
• COMMUNICATION FACILITY INDEPENDENCE
• USER INTERFACE
(.-3
L • CATALOG INTERFACE
PADSIRSSCOI_!MUI_IICATIONFACILITYINDEPENDENCE
• PACKET COMMUNICATIONS
• VIRTUAL CIRCUIT CONNECTION
C3It,-,=Lo
TRA,%MISSIOr,ITYPES*
• REQUEST FOR A DISPLAY OF PREDEFINED, COMPLETION OR ERROR MESSAGE
• REQUEST FOR DATA [RANSMISSION
• APPLICATION DATA SET
• TEMPORARY DATA SET FOR USER DISPLAY
? • REMOTE SERVICE REQUEST
*EACH TRANSMISSION TYPE HAS A UNIQUE HEADER FORMAT,
PADS/RSSCOMMUNICATIONFUNCTIONS
• REQUEST VIRTUAL CIRCUIT
• RESPOND TO CONNECTION REQUEST BY VIRTUAL CIRCUIT
COMPLETION,
• SEND DATA RECORD
0 RECEIVE DATA RECORD
• SEND EOF
? • DISCONNECT VIRTUAL CIRCUIT
PADSIRSSNETWORKSNAPCOMMUNICATIONS
LAYER
7 APPLICATION [ FILE TRANSFER
RSS I CATALOG INTERFACEMESSAGE TRANSFER
6 PRESENTATION RSS FORMATTING SERVICE
5 SESSION RSS OPERATING SYSTEMINTERFACE ROUTINES
4 TRANSPORT COMMEND-TO-END
3 ,NETWORK CONTROL COP_
2 .. LINK ADCCP/DDCMP
1 PHYSICAL RS-232C/DMC-11 COAXIAL CABLE
PADSUSERINTEP.FACE
- USER INTERFACE IS ACCOMPLISHED VIA A MENU PROCESSOR
C3II--=
,,,J
PADSCAIALOGSIRUCTURE
3 LEVEL HIERARCHICAL STRUCTURE
FIRST LEVEL
o 0STA DATA SET DIRECTORY
- TEST BED IMPLEMENTATION IN JUNE 1981
- AND UTILIZING VISTA DBMS
SECOND LEVELI
Q PILOT CLIMATE CATALOG
- SUMMARY PART UTILIZING ORACLE DBMS
-TEXT ACCESSED AS AN EDIT FILE
- IMPLEMENTATION SCHEDULED FOR JULY 1981
THIRD LEVEL
• RSS/SNAP INVENTORIES AS DEFINED BY VAS DM/TAE DEMONSTRATION
CATALOGINTERFACEDEFI, IITION
• OPEN THE CATALOG
• INSERT NEW CATALOG ENTRY
• DELETE CATALOG ENTRY
• MODIFY EXISTING ATTRIBUTE VALUES
• EXTRACT HOST SYSTEM DATA SET ID
• EXTRACT USER DEFINED NAME AND ATTRIBUTE OF CATALOGED
DATA SETSI
• EXTRACT MULTIPLE SETS OF CATALOG ENTRIES USING SEARCH
CRITERIA (NAME QUANTIFIER)
• CLOSE CATALOG
METI-IODOLOGYFOR INTERSYSTEMCATALOGINGOF DATASETATTRIBUIES
• ATTRIBUTE MAPPING AND VALUE TRANSACTION MECHANISM
NEEDED,
• PADS USES "SUPER SET" APPROACH.
C_I
o
SUPERSETAPPROACH
EACHSYSTEMMAPSITSOWNATTRIBUTESINTOA MASTEREXTERNALSUPERSET
DATADATEDATADATE _ DATATIME _ HHMMSSDATATIME _ CNTRLATIT _ YYMMDD
" CTRLAT _ DELTALATIT _ LATiTDELLAT _ CNTRLONGI ; LONGICTRLONG _ DELTALONGI _ _-- _ CELLDELLONG GEORCELL ALTALT INSTRUMENT FLUXFLUX TEMPERATURE---"-._ ANGLE
SENS.ANGLE -_- TEMP
INSOLATION C IONALTITUDE INSTFLUXIONCONC.
SYSTEMA EXTERNAL SYSTEMBSUPERSET
RSSSOFIWAREDEVELOPMENT
• SOFTWARE MODULARITY
• STANDARDIZED LANGUAGE
• ISOLATION OF OPERATING SYSTEM AND CATALOG
MANAGEMENT DEPENDENT ROUTINES
I
RSSSOFTWAREMODULARITY
• STRUCTURED ANALYSIS
• MODULE SIZE LIMITATION
• MODULE PROLOG DOCUMENTATION
C3I
ISOLATIONOFOPERATINGSYSTEMDEPE_IDENTROUTINES
SYSTEM DEPENDENT CODE IS LIMITED TO:
• INTERFACE TO DISSIMILAR OPERATING SYSTEMS AND
DATA CATALOGS
• ENCODE AND DECODE DATA TRANSFER PACKETS
C_!
FUTUREMETHODOLOGYENHANCF_MErlTSIN II-IEPADSPROGRAM
• EXTEND PRESENT SNAP CONFIGURATION TO INCLUDE ADDITIONAL SYSTEMS
- VAS ASSESSMENT PROCESSOR (VAX 11/780 OPERATING UNDER TAE)
- GODDARD f_iODELING& SIMULATION FACILITY (AMDAHL 470 V/7B
OPERATING UNDER VM
- PILOT CLIMATE DATA BASE MANAGEMENT SYSTEM (VAX 11/780)
• PROVIDE ADDITIONAL USER-0RIENTED SNAP CAPABILITIES
9 - INTERFACE TO TESTBED CENTRAL DIRECTORY OF DATA BASESDotJ1
- INTERFACE TO OTHER CATALOGS/INVENTORIES (PCDMS)
- CATALOG SEARCH-BY-ATTRIBUTE QUERY
FUTUREMETHODOLOGYENHA_ICEFIENTSIN THEPADSPROGRAM
(CONTINUED)
0 UTILIZATION OF ALTERNATE NETWORK COMMUNICATIONS
TECHNOLOGY
- HYPERCHANNEL LOCAL .AREA _!ETWORK
- DECNEI
- PUBLIC PACKET SWITCHING r'IETWORK
I
? EARIHRESOURCESPILOTSYSTEM(ERPS)"-,I
EARTHRESOURCESPI LOTCOMMUNICATIONS
MULTIPLE HOST:
AS/3000
JOHNSONSPACE 3650COMTENCOMMUNICATIONSPROCESSORCENTER(JSC) VM/CMS
LABORATORYFOR F IBM3031
APPLICATIONSIN 1 3670COMTENCOMMUNICATIONSPROCESSORREMOTESENSING VM/CMS= (LARS)
IBM BISYNCHRONOUS PROTOCOL
REMOTE SPOOLING AND COMMUNICATIONS SUBSYSTEM (RSCS)
Two 9600 BAUD LINES CONNECT THE HOSTS
EARTHRESOURCESDATAAPPLICATIONSNETWORK .....
_AS/3000 I IBM 3031 gRIM
PLICATIONS IAPPLICATIONS ITERMIN_SPROCESSOR [ PROCESSOR __]
r _o_. _o_. ____1O_ER t 3650 9600 baud. 3670 _---O_ER --,|RJE JR_OTE _OMHUNICATIONS 9600 baud COMHUNICATIONS_--R_OTE
SITES [ CONTROLLER CONTROLLER ]-----SITES
iJ _I- [
JSC TERMINALS LARS TERMINALS
EARTHRESOURCESUSERINI.ERFACE
• CMS COMMAND LANGUAGE PROVIDES THE USER WITH ACCESS
TO ERDANET CAPABILITIES,
C3I
0
RT&EDIRECTORYFORLANDSATAND GROUNDTRUTHDATA
• USER ACCESS' SUBSET'
• USER CAN SEARCH RT&E CATALOG USING 32 DIFFERENT SELECTION CRITERIA IN
ANY COMBINATION OF LOGICAL OPERATIONS, PROVISIONS HAVE BEEN MADE TO
ACCOMODATE UP TO 50 DIFFERENT SEARCH PARAMETERS,
• USER IS SUPPLIED WITH SEGMENT NUMBER AND ACQUISITION DATE INFORMATIONIL_
_" NECESSARY FOR CATALOG ACCESS,
RT&ECATALOGSTRUCTURE
THREE LEVEL HIERARCHICAL STRUCTURE ,.
• FIRST LEVEL PROVIDES ACCESS BY DATA TYPE AND LATITUDE AND
LONGITUDE
• SECOND LEVEL PROVIDES ACCESS TO:
- METEORLOGICAL DATA BY BLOCK NUMBER AND STATION NUMBER
- LANDSAT DATA BY SEGMENT NUMBER, ACQUISITION DATE ANDCROP YEARI
- GROUND TRUTH DATA BY SEGMENT NUMBER AND ACQUISITION DATE
• THIRD LEVEL PROVIDES USER WITH LOCATION OF DATA
DATADFFINITION/STRUCIURE
• STANDARD HEADER RECORD FORMATS FOR
- LANDSAT
- METEOROLOGICAL DATA
I
FUTUREMETHODOLOGYEVALUATIONPROGRAMS
• LARS WILL SEEK TO STANDARDIZE ON FORTRAN 77 PROGRAMMING LANGUAGE,
• JSC WILL CONTINUE TO IDENTIFY AND EVALUATE MACHINE INDEPENDENT
LANGUAGES SUCH AS ADA,
• EXPLORE WIDE BANDWIDTH COMMUNICATIONS METHODS TO INCLUDE
SATELLITE, MICROWAVE, FIBER-0PTICS,
C3I
u'3C"3Irj
(SdO)IIJ3.1.SAS tO-lid31NV330
0CEANICPILOTCOMMUNICATIONS
• VAXIVMSDECVAX-11i780APPLICATIONSPROCESSOR
• RSX-11MDECPDP-11/44COMMUNICATIONSPROCESSOR
• PCL-IIBus
• DECNET
• DZ-11ASYNCHRONOUS.MULTIPLEXER AUTO-ANSWER MODEM WILLIL_
o, SERVICE DIAL-UP TERMINALS AT 300 AND 1200 BPS,
OCEANICCONFIGURATIONI,
DEC DEC
PDP-II/44 VAX 11/780COMMUNICATIONS APPLICATIONS
PROCESSOR DATA BASEn ' PROCESSORI
I..111 IIII!1USER TERMINALS
USERINTERFACE
• MENU DRIVEN INTERFACE
• COMMAND LANGUAGE INTERFACE
• TRANSPORTABLE APPLICATIONS EXECUTIVE (TAE)
• DATA BASE QUERY PROCESSORc_I
oo
MENUPROCESSOR
• RANDOM ACCESS FILE OF MENU PAGES
• THREE KINDS OF MENU SUBTASKS:
- INPUT PROMPTING
- DISPLAY DYNAMIC SYSTEM INFORMATION
- ACTIVATIONAND SCHEDULINGOF SYSTEMFUNCTIONSP
!
STANDARDFORMATDATAUNIT(SFDU)
• DATA WILL BE STORED, PROCESSED,AND TRANSMITTED
IN THE PROPOSED STANDARD FORMAT DATA UNIT (SFDU)
STRUCTURE,
SFDUSTRUCTURE
MESSAGE DATA UNIT (MDU)
MESSAGE PRIMARY LABEL ELEMENTS
LABEL GROUP SECONDARY LABEL ELEMENTS
MESSAGE TEXT* ELEMENTSCONTENTS GROUP
I
• MESSAGE: SINGLE MDU
BATCH: MULTIPLE MDUs
TRANSMISSION: MULTIPLE BATCHES
* TEXT MAY INCLUDE NUMERIC
BAICHDATAUNIT
PRIMARY _ PRIMARY LABELII
MESSAGEDATA I| SECONDARY LABEL IIUNIT I I
TEXTI I• _ I• I
SECONDARY • PRIMARY LABEL IMESSAGEDATA I SECONDARYLABEL IUNIT #1 I I
I TEXT_ I
SECONDARY [ | I, I PRIMARY LABEL I
MESSAGE DATA. I I
UNIT #N I SECONDARY LABEL I/• I I!TEXT I
PRIMARYLABEL
DATA UNIT SPECIFICATION
CHARACTERSET SPECIFICATION*
DATA UNIT CONTENTS CLASSIFICATION
BATCH DATA UNIT TOTAL LENGTH*
MESSAGE DATA UNIT TOTAL LENGTH
START OF MESSAGE CONTENTS POINTER*
* OPTIONAL
PRIMARYLABELSTRUCTURECHARACTERISTICS
• APPLICATIONS INDEPENDENT, GLOBAL
• PHYSICAL CHARACTERISTICS OF DATA UNIT TO INCLUDE DATA
UNIT LENGTH, POINTERS TO START OF MESSAGE CONTENTS,
_- CHARACTER SET
• ORGANIZATIONAL CONTROL
• TYPE OF DATA
• . SYSTEM ELEMENT
? • MEMBER WHICH CREATED OR MODIFIED DATA UNIT
DATAUNITSPECIFICA[ION
< 8 BIT }
011213 415 617 00 DEFINEDBY CHARSETSPEC,' 01 BINARY
: I-10 EBCDIC
"-[ I" 1 11 ASCIIPRIMARY LABEL SPECIFICATION
00 8 BITS
PRIMAR_ 11 6 BITS (CHAR, SET SPEC,
LABEL MUST BE PRESENT)I
_" VERSIONL.n
DATA UNIT TYPE
0 - MESSAGE
1- BATCH (BATCH UNIT rOTAL LENGTH)
- 0 TYPE -1 (No CONTENTS GROUP)
- 1 TYPE 2 (MESSAGE LABEL GROUP LENGTH MUST BE PRESENT)
PRIMARY.LABEL INTERPRETATION
CHARACTERSETSPECIFICATION
CHARACTER #1 CHARACTER #2
ANSI X3,4- 1977 } ANSIWORKINGPAPERX3.41-1974 X3L5/80-16FI
DEFINES SPECIFIC CHARACTER SET
FOR _ESSAGE LABEL GROUP
DAIAUNITCONrENIS
< 3 BYTES OR 9 CHAR, >
CONTROL CONTENTS SYSTEM SEcoNDARY SECONDARY LABEL IDENTIFIES-- SECONDARY LABEL STRUCTURE
AUTHORITY CLASS CLAss LABEL ID ( Assoc, WITH SYSTEM CLASS,
T T T BINARY LABEL - 7 BITS
• CHAR, LABEL - 3 CHAR,
, I9 CONTROL AUTHORITY DEFINES CONTENTS CLASSIFICATION SYSTEM CLASS RELATES
OR CONTROLS CONTENTS OF DEFINESGROSSLOGICAL COMPONENT SYSTEM
REMAINDER OF DATA UNIT, ASSOCIATION OF APPLICATION
BINARY LABELS - 6 BITS DATA, BINARY LABEL - 6 BITSBINARY LABELS - 5 BITS
CHAR, LABELS - 2 CHAR, CHAR, LABEL - 2 CHAR.CHAR, LABELS - 2 CHAR,
BATCHDATAUNITTOTALLE._IGTH
<---4 BYTES OR 5 CHARACTERS-->
DEFINES THE OVERALL LENGTH OF THE COMPLETE BATCH DATA,
STARTING AT THE FIRST BIT OF THIS .ELEMENT AND INCLUDING
ALL OF THE REMAINING ELEMENTS WITHIN THE PRIMARY AND
SECONDARY MESSAGE DATA UNITS WHICH COMPRISE THE BATCH.
I
BINARY LABELS: 4 OCTETS (32 BITS) TOTAL NUMBER OF OCTETS
ENCLOSED BETWEEN THE FIRST BIT OF THIS ELEMENT AND THE LAST
BIT OF THE LAST MDU WITHIN THE BATCH DATA UNIT,. CHAR.
LABELS: 5 CHAR. (30 OR 40 BITS) TOTAL NUMBER OF CHARACTERS
BETWEEN THE FIRSTBIT OF THIS ELEMENT AND THE LAST BIT OF
THE LAST MDU WITHIN THE BATCH DATA UNIT.
MESSAGEDATAUNITTOTAL-LENGTH
<---4 BYTES OR 5 CHARACTERS'' >
DEFINES LENGTH OF MESSAGE DATA UNIT FROM FIRST BIT OF THIS
ELEMENT INCLUDING REMAINING LABELING AND TEXT ELEMENTS. IF
?> SFDU is A BATCH DATA UNIT, THIS FIELD DEFINES LENGTH OF PRIMARY
MESSAGE DATA UNIT.
BINARY LABELS: 32 BITS - CONTAINS SUBELEMENT DENOTING
NUMBER OF 8 BIT GROUPS FROM FIRST BIT OF ELEMENT TO LAST
BIT OFTHE MSDU. CHAR, LABELS: 5 CHAR, (30 oR 40 BITS)
SHALL DEFINE TOTAL NUMBER .OFCHARACTERS BETWEEN FIRST
BIT OF THIS ELEMENT AND THE LAST BIT OF MESSAGE DATA UNIT.
STARTOFMESSAGECONIEr'_]SP01NIER
( ' 16BITS/4CHAR, )
I !SPECIFIES THE NUMBER OF BYTES (OCTETS OR CHARACTERS) TO
BEGINNING OF MESSAGE,.I
O
FOR BINARY LABELS, 2 OCTETS (16 BITS) AND CONTAINS
BINARY QUANTITY WHICH SPECIFIES THE NUMBER OF OCTETS
BETWEEN FIRST BIT OF THIS ELEMENT AND LAST BIT OF
LABEL STRUCTURE AT START OF DATA UNIT CONTENTS,
FORCHAR, LABELS 4 CHARACTERS DEFINE THE TOTAL MUMBER OF
CHARACTERS BETWEEN FIRST BIT OF THIS ELEMENT AND LAST
BIT OF LABEL STRUCTURE PRECEDING START OF DATA UNIT,
SECONDARYLABELSTRUCTURE
ORIGINATOR IDENTIFICATION
MODIFIER IDENTIFICATION
ANTECEDENT PROCESS IDENTIFICATION
C3lL,"I
'-' DATA UNIT STATUS TAG
_ESSAGE CONTENTS GROUP COUNTER
APPLICATIONS KEYS
TEXT OR NEXT LABEL
I
SECONDARYLABELSTRUCIURE
• APPLICATION DEPENDENT
• DEFINED BY SECONDARY LABEL ID FIELD WITHIN PRIMARY
LABEL
• MAY CONTAIN FIXED FORMAT TEXT ELEMENTS
-• PROVIDES A WIDE VARIETY OF APPLICATION KEYINGC_!_. FUNCTIONS
• ACTUAL LENGTH OF ANY FIELD IS SPECIFIED BY SECONDARY
LABEL IDENTIFIER
• NUMBER OF INSTANCES WITHIN ANY FIELD IS VARIABLE
SECONDARYLABELSTRUCIURE
• ORIGINATOR IDENTIFICATION ELEMENT
- SPECIFIC ADDRESS OF APPLICATION I']ODEWHICH FIRST CREATED DATA UNIT
• MODIFIER IDENTIFICATION ELEMENT
- IDENTIFIES SPECIFIC ADDRESS WHICH LAST MODIFIED ANY COMPONENT OF
THE DATA,
• ANTECEDENT PROCESS IDENTIFICATIONnI
- IDENTIFIES AN AUDIT TRAIL WHICH COMPLETELY SPECIFIES PROCESSESWHICH HAVE BEEN APPLIED TO DATA UNIT SINCE CREATION
• DATA UNIT STATUS INDICATION ELEMENT
- USED TO RECORD ERRORS UETECTED DURING DATA UNIT FORMATION, ALSO
INDICATES SEQUENCE OF DATA SEGMENTS CONTAINED I_ITHINTEXT AND TO
SPECIFY CORRECTIONS TO SUBSEQUENT SECONDARY LABEL FIELDS WHICH
FORM APPLICATION ACCESS KEYS FOR TExT DATA,
SECONDARY "LABEL STRUCTURE
• MESSAGE CONTENTS GROUP COUNTER
- DEFINES NUMBER OF STANDALONE ITEMS OF TEXT ARE INCLUDEDIN THE MESSAGE CONTENTS GROUP. FOR EXAMPLE~ HOW MANYSEPARATE DATA PACKETS ARE EMBEDDED WITHIN MESSAGE DATAUNIT.
• ApPLICATION KEYS
- PROVIDE A MECHANISM WHEREBY TEXT DATA MAY BE ASSOCIATEDWITH ApPLICATION DEPENDENT REFERENCE KEYS FOR CATALOGIDENTIFICATIONS AND ACCESS.
DATAHANDLII'IGMETHODS
O MAGNETIC TAPE MEDIA
- 9 TRACK
- 800/1600 BPI (INITIAL CAPABILITY)
- 1000/6250 BPI (LATER CAPABILITY)
- HEADER RECORD FOR EACH TAPE WILL BE MODIFIED
ToSFDU FORMATI
• DISK MEDIA
- 1 MEGABYTE LIMITATIO'I
- SFDUFORMAT
- TIME DURATION FOR ONLINE RESIDENCE
OCEANICCATALOGINTERFACE
ONLINE CATALOG ACCESS, SEARCH, AND DISPLAY IS
PROVIDED THROUGH MENU PROCESSOR,
C_Iu1
OCEANICCATALOGSIRUCTURE
Two LEVEL HIERARCHICAL STRUCTURE
• FIRST LEVEL CONTAINS A DESCRIPTIVE OVERVIEW
OF THE DATA SET
• SECOND LEVEL.PROVIDES THE DATA SET LOCATION
C'_It.m..,j
OCEANICPILOTCATALOGPRELIMINARYDESIGN
• CATALOG FEATURES
- DATA SET NAME
- DATA SET COVERAGE
- DATA SET SIZE
- GEOPHYSICAL PARAMETERS
- SAMPLING FREQUENCY
- DATA SET RESIDENCE
I
SOFTWAREDEVELOPMENTMETHODOLOGIES
• STRUCTURED ANALYSIS
• FoPDOWNDEVELOPMENT
• MODULAR DESIGN
• STANDARD LANGUAGE
• DOCUMENTATION AND CODING STANDARDS
OC_NICFUTUREENHANCEMENTS
• COMMAND LANGUAGE
• "tRANSPORTABLEAPPLICATIONS EXECUTIVE
UTILIZATION
• DATA BASE QUERY LANGUAGE
• UTILIZATION OF HIGH TECHNOLOGY CONCEPTS
m - DIGITAL OPTICAL DISK0
- DATA COMPRESSION TECHNIQUES
CONCLUSION
• EACH ADS PILOT EXHIBITS
A METHODOLOGY STRENGTH
IN DIFFERENT AREAS
C_I
PADSMETHODOLOGYSTRENGTHS
• DATA COMMUNICATIONS
• USER INTERFACE
• DATA CATALOG STRUCTURE
C3I
ERPSMETHODOLOGYSTRENGTIIS
• DATA DEFINITION/STRUCTURE
• DATA CATALOG STRUCTURE
I
L.Q
OPSMETHODOLOGYSTRENGTHS
• DATA FORMAT
• DATA CATALOG STRUCTURE
C_I
CO_':CLUSIONS
• SFDU CONCEPT PROVIDES A BASIC FRAMEWORK FOR AN OSTA/ADS
STANDARD DATA FORMAT
- OSICOMPATIBLE
- APPLICATIONS ORIENTED
- COMMUNICATIONS INDEPENDENT
- SELF-DEFINING
? - PROVIDES DISTRIBUTED CONTROL
- APPLICABLE TO ALL THREE PILOTS
Appendix D
OSTA/ADS Data Systems Standards Workshop - _Ist of Reference Materials
i. "The Pilot Atmospheres Data System: Its Methodologies and General Applicability,"
Preliminary Draft, CSC/TM-81/6037, Computer Sciences Corporation, January 1981.
2. "The Transportable Applicatlons Executive: A Conceptual Design," Computer Sciences
Corporation, November 1980.
3. "Software Engineering Standards and Practices," Ronald W. Durachka, January 1981.
4. "Structured Programming Series. Volume VII, Addendum: Documentation Standards,"
AD-A016 414, IBM Federal Systems Division, April 1975.
5. "Software Acquisition Management Guidebook: Regulations, Specifications and
Standards,"AD-AOl6 401, MITRE Corporation, October 1975.
6. "Programming Language Standards,"AD/A-Ol6 771, IBM Corporation, March 1975.
7. "Telemetry Computation Branch Quality Assurance Procedures Programming andDocumentation Standards," CSC/TM-76/6115, Computer Sciences Corporation, May 1976.
8. "Standards Guide for Space and Earth Sciences Computer Software," X-601-72-7 Preprint,
Goddard Space Flight Center, January 1972.
9. "Federal Computer Network Protocol Standards Program: An Overview," Institute for
Computer Sciences and Technology, National Bureau of Standards.
i0. "Federal Information Processing Standards Publications (FIPS PUBS)," Revision,
Institute for Computer Sciences and Technology, National Bureau of Standards,
February 1980.
ii. "Architectural Considerations for Federal Database Standards," Seymour Jeffery,
Dennis Fife, Donald Deutsch and Gary Sockut, Systems and Software Division, NationalBureau of Standards, December 1978.
12. "DBMS Standards: Current Status and Future Directions," Donald R. Deutsch andEric K. Clemons.
13. "Conversion of Federal ADP Systems: A Tutorial," Joseph Collica, Mark Skall,
Gloria Bolotsky, Institute for Computer Sciences and Technology, National Bureau ofStandards, August 1980.
14. "Features of Network lnterptoceSs Communication Protocols," Draft Report,ICST/HLNP-80-12, Systems and Network Architecture Division, National Bureau of
Standards, September 1980.
15. "Formal Description Techniques for Network Protocols," Draft Report, ICST/HLNP-80-3,Systems and Network Architecture Division, National Bureau of Standards, June 1980.
16. "Features of the File Transfer Protocol (FIP) and the Data Presentation Protocol
(DPP)," Draft Report, ICST/HLNP-80-6, Systems and Network Architecture Division,
National Bureau of Standards, September 1980.
17. "Features of Internetwork Protocol," Draft Report, ICST/HLNP-80-8, Systems and
Network Architecture Division, National Bureau of Standards, July 1980.f
D-I
18. "Service Specification of the File Transfer Protocol (FTP) and the Data PresentationProtocol (DPP)," Draft Report, ICST/HLNP-80-9, Systems and Network ArchitectureDivision, NatlonalBureau of Standards, October 1980.
19. "Service Specification of an Internetwork Protocol," Draft Report, ICST/HLNP-80-11,
Systems and Network ArchitectureDivlsion, National Bureau of Standards, September1980.
20. "Common Command Language Feature Analysis," Draft Report, ICST/HLNP-80-4, Systemsand Network Architecture Division, National Bureau of Standards, June 1980.
21. "SpecificatiOn of The Transport Protocol," Draft Report, ICST/HLNP-
81-1, Systems and Network Architecture Division, National Bureau of Standards,February 1981.
22. "Features of the Transport and Session Protocols," Draft Report, ICST/HLNP-80-1,
Systems and Network Architecture Division, National Bureau of Standards, March 1980.
23. "Specification of The Session Protocol," Draft Report, ICST/HLNP-81-2,Systems and Network Architecture Division, National Bureau of Standards,March, 1981.
24. "Guideline for Planning and Management of Database Applications," FIPS PUB 77,National Bureau of Standards, September 1980.
25. "Prospectusfor Data Dictionary System Standard," NBSIR 80-2115, Institute forComputer Sciences and Technology, National Bureau of Standards, September 1980.
26. "Survey of Representative Scientific Database Systems_'Draft, Kofl Apenyo,Jet Propulsion Laboratory, November 15, 1980.
27. "Data Management and Computation: Issues and Recommendations," Draft 7, NationalAcademy of Sciences National Research Council, September 1980.
28. "Survey of Standards Applicable to a DataBase Management Systems," Draft, Jose L.
Urena, Jet Propulsion Laboratory, November 15, 1980.
29. "Functional Requirements for an Applications Data Base Management System," Draft,Guy M. Lohman, Jet Propulsion Laboratory, November 15, 1980.
30. "Software Development Plan for NAFEC's Air Traffic Control Simulation Facility(ATCSF) Volume II: Software Development Standards," CSC/TR-79/60616, ComputerSciences Corporation, March 1980.
31. "NASA Pilot Climate Data Base Catalog," Preliminary, OAO, January 1981.
32. "Oceanic Pilot System Standard Proctlces," L.A. Meredith, Jet Propulsion Laboratory,July 31, 1980.
33. "Standard Format for the Transfer of Geocoded Polygon Data," CCRS Research Report
79-3, Spaclal Data Transfer Committee, December 1979.
34. "A Proposed Logical Standard for ImageData Exchange," Allcia C. Anderson, May 1980.
D_2 •
35. "Standardization of Computer Compatible Tape Formats for Remote Sensing Data,"Valerie L. Thomas and Florlan E. Guertin.
36. "User Computer Compatible Tape (CCT) Format Family Requirements," CCB-CCT-0001A,
October 16, 1978.
37. "Landsat-D User CCT Tape Format," FOR-LSD-O001 A, August 28, 1979.
38. "The CCT Family of Tape Formats,"CCB-CCT-0002 A, August 28, 1979.
39. "EDIS Data Dictionary System, Version I User's Guide," Environmental Data andInformation Service, NOAA, June1980.
L
40. "Aerospace Data Systems Standards," X-560-63-Z, Goddard Space Flight Center,
January, 1963.
41. "NASA End-to-End Data System (NEEDS) Guidelines for Data Communications Standards;Packet Telemetry," Needs Modular Data Transport System Team, January 30, 1981.
42. "Applications Data Service (ADS) Study Report," R.F. desJardins, NASA/Goddard
Space Flight Center, May 1981.
43. "OSTA Data Systems Planning Workshop Report," R.F. desJardlns, NASA/Goddard
Space Flight Center, May 1981.
44. "Survey of Federal, National, and International Standards Applicable to the
NASA Applications Data Service," T. Kuch and R. Sakamoto, NASA Contract Report166675, NASA, March 1981.
45. "Data Processing - Open Systems Interconnectlon - Basic Reference Model," 7498,International Standards Organization, December 3, 1980.
46. "Guidelines for the Organization and Representation of Data Elements for DataInterchange," 7352, International Standards Organization, November, 1980._
47. "Overview and Status of the ISO/ANSI Reference Model of Open Systems Intereonnection,"
Richard desJardlns, NASA/Goddard Space Flight Center.
48. "Multlmisslon End-to-End Information System (EELS) 'Standard Format Data Unit'
Development Guidelines and Standards," Preliminary Review Draft, 663-11, Jet
Propulsion Laboratory, January 15, 1981.
49. "An Automated Registration System," N.Y. Chu and R.L. Nugent, Lockheed, December 1980.
50. "A Case Study in Data Management in a Research and OperatlonalComposlte Environment,"
J.A. Wilkinson, Lockheed, December 1980.
51. "AgRISTARS Interim Catalog Ground Data summary, Data Acquisition Year 1978,"
H.M. Doyle and V.L. Cook, JSC - 17120, March 1981.
D-S
52. "Lockheed Support for Detailed Data Requirements Submission," J.A. Wilkinson,
JSC-17279, December 1980.
53. "Intra-GSFC Interface Control Documentation; Content And Formal Requirements,"
T. Chen and J. Ishikawa, MITRE Working Paper 6626, MITRE, January 18, 1980.
54. "Handbook for the Preparation of Interface Control Documentation," Thomas Chen,
MITRE Technical Report MTR-4827, MITRE, September1980.
55. "Alternative System Architectures for Data Catalogs in a Distributed Data
Base Environment," Terry Kuch, May 7, 1981.
56. "Common Operating System Command Language," CODASYL, Journal of Development,
September 1980.
57. "Operating System Command and Response Language - Design Criteria," ANSI,
September 1980.
58. "Operating System Command and Response Language - Draft Language Specification,"ANSI, April 1981.
59. "Draft Vocabulary for Use by X3HI," S.J. Mellor, University of California,
February 2, 1981.
60. "Virtual Terminal Feature Analysis," Draft Report, ICST/HLNP-81-3, Systems And
Network Architecture Division, National Bureau of Standards, March 1981.
61. "Specification And Analysis of Local Area Network Architecture Based on the ISO
Reference Model," Draft Report, ICST/LANP-81-1, Systems & Network ArchitectureDivision, National Bureau of Standards, April 1981.
62. "Service Specification of a Network Interprocess Communication Protocol,"
Draft Report, ICST/HLNP-80-15, Systems & Network Architecture Division,
National Bureau of Standards, October 1980.
63. "Formal Methods for Communication Protocol Specification & Verification,"
Draft Report, ICST/HLNP-80-7, Systems & Network Architecture Division,National Bureau of Standards, June 1980.
64. "Coming of Age: A Long-Awaited Standard for Heterogeneous Nets," Harold C.
Folts, Data Communications, January 1981.
65. "A Data Dictionary for Distributed Data Bases," Martella and Schreiher inDistributed Data Bases eds Delobel and Litwin, North-Holland, 1980.
66. "Parallel Grouped Binary Time Code for Space and Ground Applications - PB5,"
draft, NASA/GSFC, Aerospace Data Systems Standard 5.6, December 16, 1980.
D-4
67. "American National Standard Specification for an Information Interchange
Data Descriptive File," X3LS/80-16F, Subcommittee Working Paper, March 24,1980.
68. "The Standard Family of CCT Formats," Valerie L. Thomas and Florian E.
Guertin, April 1981.
69. "Interface Control Document Between NASA Goddard Space Flight Center (GSFC)
and Department of Interior EROS Data Center (EDC) for Landsat-D, Fully and
Partially Processed Multispectral Scanner Computer Compatible Tape(CCT-AM/PM)," ORI, Inc., Contract NAS5-26167. April 17, 1981.
70. "Proposal for a Universal Time Code Structure and New Standard Timecode
Formats," Greenberg, Hooke and MacMedan, Jet Propulsion Laboratory,
June 17, 1981.
71. "Overview of Reference Model of Open Systems Interconnectlon," Harold C.
Folts, National Communications System and Richard desJardins, Computer
Technology Associates, January 29-30, 1981.
72. "Service Specification of Transport and Session Protocols," Draft ReportNo. ICST/HLNP-80-2 of the National Bureau of Standards Institute for
Computer Sciences and Technology, Center for Computer Systems Engineering,
Systems and Network Architecture Division, March 1980.
D-5
APPENDIX E
UNPUBLISHED PREWORKSHOP DOCUMENTATION
National Aeronautics and N_ti_ASpace Administration
Goddard Space Right CenterGreenbelt. Maryland20771
TO: Distribution
FROM: 934/Coordlnator OSTA/ADS Data Systems Standards Workshop
SUBJECT: Office of Space and Terrestrial Applications/Appllcations
Data Service (OSTAIADS) Data Systems Standards Workshop
You are cordially invited to attend the Office of Space and Terrestrial
Applications/Applications Data Service (OSTA/ADS) Data Systems Standards
Workshop to be held at Goddard Space Flight Center in Greenbelt, MarylandMay 27-29, 1981. During the meeting, the work of the ADS Standards
contractor MITREwill be reviewed and guidance and suggestions will be
given for consideration in preparing the Preliminary OSTA/ADS Standardsand Guidelines, planned for August publication. Related information and
plans will also be shared.
The planned agenda for the workshop is enclosed. Your attention is called
to the panel sessions Thursday afternoon. The purpose of the panels is to
provide in-depth discussion on high priority subjects among persons w/th
expertise in these areas. Five topics have been identified which may besuperseded by issues or items of greater importance that are identified
during the workshop.
The evening dinner session scheduled for Wednesday, May 27th, will feature
James Burrows, Director of the Institute for Computer Science & Technology
of the National Bureau of Standards. He will discuss the NBS Data SystemsStandards Program.
The workshop is scheduled to begin at.9:00 a.m. Wednesday, May 27 in Building
26, Room 205, _rithregistration beginning at 8:30. A map of the Center is
enclosed for your convenience. Your name will be given to the Gatehouse fora security pass to be picked up when you enter the facility. During the
conference, messages may be left for attendees at (301)344-5831.
The conference room is equipped with a viewgraph machine and screen. If you
are a speaker and require any additional audlo-visual equipment, please informus as soon as possible. Presentors are asked to bring original artwork or
good xerox copies of their vlewgraph material in order to simplify art
reproduction for the conference report.
E-I
There are no registration fees as such associated with the workshop. There
will, however, be a fee of approximately $6.00 for refreshments during the
conference and at the Thursday evening panel working session. The Wednesdayevening dinner sesslonwill be held at a local resturant. Dinner tickets
may be purchased at registration for approximately $i0.00.
The Systems and Applied Sciences Corporation (SASC) is assisting the
sponsor in coordinating the Workshop. If you need help with transportation
or reservations, or have any general logistic questions, please direct them
to Ms. Linda Mason, SASC, (301)699-5400 or (800)638-0925. Questions
regarding the technical program should be directed to Barbara Walton,FTS 344-9413.
Included with this letter is a llst of hotels/motels in the Greenbelt area.
Those individuals coming from out of town should make reservations at the
hotel of their choice as soon as possible. YoU are also asked to fill out
the enclosed form indicating your intention to attend and return it to theaddress below.
Ms. Linda Mason
Conference Management
Systems And Applied Sciences Corporation6811 Kenilworth Avenue
R/verdale, Maryland 20840
Barbara Walton
Enclosures
E-2
NationaAeronautcsan0 /%SASpace Administration
' "Goddard Space Flight Center• Greenbelt, Maryland
20771
ReplytoAttnof. 934
TO: Respondents
FROM: Coordinator, OSTA/ADS Data Systems Standards Workshop
SUBJECT: Pre'Workshop Documentation
This pre-workshopmailing is being made to aid participants in preparing for
the Office of Spaceand Terrestrial Applications/Applications Data Service
Data Systems Standards Workshop to be held at Goddard Space Flight Center
May 27-29, 1981. The theme of the workshop is "Standards Needed to Inter'connect ADS Pilots for Data Sharing." The following documentation isattached:
i. OSTA/ADS Data Systems Standards Workshop - Instructions to Panels
2. OSTA/ADS Data Systems Standards Workshop - List of ReferenceMaterials
3. Abstract and goal of each MITRE Workshop session4. Excerpts from "Applications Data Service (ADS) Study Report"
5. Excerpts from "OSTA Data Systems Planning Workshop Report"
6. Excerpts from "Survey of Federal, Nat±onal, and International
Standards Applicable to the NASA Applications Data Service"7. "Data-Processing - Open Systems Interconnection - Basic Reference
Model"
8. "Guidelines for the Organization and Representation of Data Elements
for Data Interchange"9. "Overview and Status of the ISO/ANSI Reference Model of Open Systems
Interconnectlon"
i0. "Multimission End-to-End Information System (EELS) 'Standard Format
Data Unit' Development Guidelines and Standards," PreliminaryReview Draft
In addition, a "library" of reference materials for use by the panels is being
gathered. A list of the references which have been gathered to date is attached.Please bring any additional references to the workshop or mail to
Barbara A. WaltonCode 934
Goddard Space Flight Center
Greenbelt, Maryland 20771
in time for arrival by May 26, 1981.
Please review the enclosed material prior to the meeting. Items i and 3,
sections 6 and i0 of 4, section 13 of 5, and section 2 of 6 are especially
critical for your participation. Additionally, the executive summaries of4 and 5 provide excellent background material if you are unfamiliar with ADS.
The remaining material is more specific to individual panel concerns.
E-3
Page 2
If you have any general logistic questions, please contact LindaMason,
Systems and Applied Sciences C _rporatlon, 301-699-6279. Questions regardingthe technical program should be directed to Barbara Walton at FTS 344-9413.
Barbara Walton
Enclosures
E-4
OSTA/ADS Data Systems Standards Workshop - Instructions to Panels
The theme of this workshop, being held May 27-29, 1981, is "Standards Needed to
Interconnect ADS Pilots for Data Sharing." The materials you have been sent are
intended to help in your preparation for the workshop. Please try to read at leastthe sections mentioned in the cover memo and bring them with you to the workshop.
General instructions for panels during the workshop follow.
i. Critique the MITRErepresentation of pilot methodologies for accuracyand completeness.
2. Identify the requirements for standards and guidelines needed in your
panel's area to interconnect the ADS pilots for data sharing. Describe
these requirements as separate elements and %stablish an orderly method
for identifying and grouping the elements. (This identification method isto be used in all the following steps to track, trace, or label related
information).
3. Make a preliminary assessment of the adequacy of currently identified pilot
methodologies andexternal standards in meeting these requirements.
4. Identify any other methodologies you are aware of which may contribute tothe solution to your panel's aspect of the problem.
5. Make recommendations for future work, providing descriptions and estimate
of effort where possible.
6. Provide the panel's consensus on the need for a continuing working groupin this area and suggest membership thereof.
Each panel will be asked to draft a short report summarizing its results. Secretarial
support will be provided to facilitate this. More specific information for each panelarea and additional issues to be addressed follow.
E-5
Standards Needed to Interconnect ADS Pilots for Data Sharing
Panel A - Catalogues, Directories, and Dictionaries
Chairman: Jose Urena, JPL - FTS 792-3428
Multiple definitions for the above terms are in current use within OSTA/ADS.
Consideration needs to be made of the functional layers of information about data
and the responsibilities for producing that information within the OSTA. These
layers should be refined and terminology to reference each recommended in orderto facilitate future communication.
E-6
Standards Needed to Interconnect ADS Pilots for Data Sharing
Panel B - User Interfaces
Chairman: Jim Brown, JPL - FTS 792-5109
Some of the key elements of this area are:
(i) Dial-up procedures
(2) Terminals (minimum, desirable, extended capability)
(3) Common capabilities
(4) Language interfaces (query, command, menu)
(5) Display capabilities
E-7
Standards Needed to Interconnect ADS Pilots for Data Sharing
Panel C - Use of ISO Open Systems Interconnection - Basic Reference Model
Chairman: Ed Greene, GSFC r 344-8685
This panel will address the question of which layer(s) should be used for pilot
interconnection, which protocol to use and what interfaces between higher layersare needed. More specificall_ the panel is asked to come to consensus as to what
each layer means within OSTA/ADS. Use of X.25, TELENET, DECNET and PADS RSS shouldbe examined for potential impact.
E-8
Standards Needed to Interconnect ADS Pilots for Data Sharing
Panel D - Data Formats and Descriptions
Chairman: Ed Greenberg, JPL --F'rS 792-3387
Some of the key elements of this area are:
(i) Structure/organizatlon of data sets
(2) Header content and format
(3) Character codes
(4) Data Bodes
Please note that data description as used by this panel is information about data
required for processing data, whereas catalogs contain information required to locatedata and request access.
E-9
Appendix F
OSTA/ADS Data Systems Standards Workshop - List of Attendees4
Portia W. Bachman Gary BrammerGoddard Space Flight Center LARS
Code 934 Purdue UniversityGreenbelt, MD 20771 1220 Potter Drive
(301) 344-9415 West Lafayette, IN 47906(317) 749-2052
Earl Beard
Goddard Space Flight Center James W. Brown
Code 565 Jet Propulsion LaboratoryGreenbelt, MD 20771 Code 125/128(301) 344-5623 4800 Oak Grove Drive
Pasadena, CA 91109William Benton (213) 354-5109 or FTS 792-5109Lockheed
1830 NASA Road 1 Thomas Burns
Houston, TX 77058 MITRE Corporation1820 Dolley Madison Blvd.
Richard L. Berman McLean, VA 22102Computer Sciences Corp. (703) 827-68868728 Colesville Road
Silver Spring, MD 20910 James Burrows
(301) 589-1545 x228 or x770 National Bureau of Standards
Room A200, Building I01Manju Bewtra Washington, DC 20234Computer Sciences Corp. (202) 921-31518728 Colesville Road
Silver Spring, MD 20910 Paul Clemens
(301) 589-1545 x771 MITRE Corporation
1820 Dolley Madison Blvd., Rm. W665Joseph Bishop McLean, VA 22102NASA HQ, Code TS (703) 827-6659600 Independence Ave., SW
Washington, DC 20546 Christopher J. Daly(202) 755-2430 Goddard Space Flight Center
Code 565.1
William Bisignani Greenbelt, MD 20771MITRE Corp. (301) 344-66051820 Dolley Madison Blvd.McLean, VA 22102 Richard desJardins
(703) 827-6806 Computer Technology Associates1501 Wilson Blvd.
Albert W. Bowers Arlington, VA 22209MITRE Corporation (703) 841-07871820 Dolley Madison Blvd.
McLean, VA 22102 Ai C. Fang(703) 827-6871 NASA HQ, Code ECD-4
600 Independence Ave., SWWashington, DC 20546(202) 755-8573
F-I
Dennis Fife Steve Haight
National Bureau of Standards ORI, Inc.
Room A257, Building 225 1400 Spring Street
Washington, DC 20234 Silver Spring, MD 20910(202) 921-3491 ' (301) 588-6180 x265
David Freeman Larry Herath
LARS Goddard Space Flight Center
Purdue University Code 931.2
1220 Potter Drive Greenbelt, MD 20771
West Lafayette, IN 47906 (301) 344-9521
J. Patrick Gary Adrian Hooke
Goddard Space Fl{ght Center Jet Propulsion LaboratoryCode 934 4800 Oak Grove Drive
Greenbelt, MD 20771 Pasadena, CA 91109
(301) 344-6079 (213) 354-3063
Paul Giragosian David Howell
MITRE Corporation Goddard Space Flight Center
1820 Dolley Madison Blvd. Code 933.1
McLean, VA 22102 Greenbelt, MD 20771
(703) 827-6924 (301) 344-9041
Ronald C. Glaser John Johnson
Computer Sciences Corporation Jet Propulsion Laboratory
9504 Dragon Claw Code 79-6
Columbia, MD 21046 4800 Oak Grove Drive
(301) 596-3946 Pasadena, CA 91109FTS 792-2143
Alan Goldfine
National Bureau of Standards Leon Jordan
Washington, DC 20234 Computer Sciences Corporation8728 Colesville Road "
Edward Greenberg Silver Spring, MD 20910
Jet Propulsion LaboratoryMS 233-208 John Kiebler
4800 Oak Grove Drive NASA HQ, Code ECD-4
Pasadena, CA 91109 600 Independence Ave., SW(213) 354-3387 Washington, DC 20546
(202) 755-8573
Edward Greene
Goddard Space Flight Center Stan KleinCode 503 ORI, Inc.
Greenbelt, MD 20771 1400 Spring Street
(301) 344-8685 Silver Spring, MD 20910
Edgar M. Greville Gerald M. Knaup
Computer Sciences Corporation Goddard Space Flight Center8728 Colesville Road Code 934
Silver Spring, MD 20910 Greenbelt, MD 20771
(301) 589-1545 x696 (301) 344-6034
F-2
Lou Kramer Ed SchlosserLARS Lockheed
Purdue University 1830 NASA Road
1220 Potter Drive Houston, TX 77058
West Lafayette, IN 47906William Shaffer
Terry Kuch NASA HQ, Code ECD-4
MITRE Corporation 600 Independence Avenue, SW
1820 Dolley Madison Blvd., Rm. W27 Washington, DC 20546McLean, VA 22102
(703) 827-7124 AI Skopetz
Goddard Space Flight CenterRobert R. Lovell Code 730.4
NASA HQ, Code EC-4 Greenbelt, MD 20771
600 Independence Avenue, SW (301) 344-8593
Washington, DC 20546Peter M. Smith
Merv MacMedan Goddard Space Flight Center!
Jet Propulsion Laboratory Code 931.2
Code 233-208 Greenbelt, MD 207714800 Oak Grove Drive (301) 344-9489
Pasadena, CA 91109
FTS 792-7004 or 5793 Robert R. StephensNASA HQ, Code TS
James Moulton 600 Independence Avenue, SWNational Bureau of Standards Washington, DC 20546
Room B219, Building 225 (202) 755-2430
Washington, DC 20234
(202) 921-2601 Sam Steppel
Computer Sciences CorporationLawrence V. Novak 8728 Colesville Road
Goddard Space Flight Center Silver Spring, MD 20910Code 931 (301) 589-1545 x674
Greenbelt, MD 20771
(301) 344-9538 Ellen G. Stolarik
OAO CorporationWilliam Poland 5050 Powder Mill Road
Goddard Space Flight Center Beltsville, MD 20705Code 730.4 (301) 937-3090
Greenbelt, MD 20771(301) 344-8592 Frank Stone
OAO CorporationRichard D. Sakamoto 5050 Powder Mill Road
MITRE Corporation Beltsville, MD 20705
1820 Dolley Madison Blvd.Room W657 David Stowell
McLean, VA 22102 OAO Corporation(703) 827-7022 5050 Powder Mill Road
Beltsville, MD 20705
Roy G. SaltmanNational Bureau of Standards Valerie L. Thomas
Building 225 Goddard Space Flight Center
Washington, DC 20234 Code 563(202) 921-3491 Greenbelt, MD 20771
(301) 344-5252
F-3
Jose Urena Jim Wilkinson
Jet Propulsion Laboratory LockheedCode 138-308 1830 NASA Road
4800 Oak Grove Drive Houston, TX 77058Pasadena, CA 91109
FTS 792-3428 Fred Wulff
NASA HQ, Code T
Anthony Villasenor 600 Independence Avenue, SW
NASA HQ, Code ECD-4 Washington, DC 20546600 Independence Avenue, SW (202) 755-2430
Washington, DC 20546
(202) 755-8573 Frank Yap
Computer Sciences CorporationBarbara A. Walton 8728 Colesville Road
Goddard Space Flight Center Silver Spring, MD 20910Code 934 (301) 589-1545 x773
Greenbelt, MD 20771(301) 344-9413 Phil Yu
Goddard Space Flight CenterNoreen Welch Code 934
ORI, Inc. Greenbelt, MD 20771
1400 Spring Street (301) 344-9414
Silver Spring, MD 20910
F-4
BIBLIOGRAPHIC DATA SHEET
1. Report No. 2. Government AccessionNo. 3. Recipient's Catalog No.NASA CP-2196
4. Title and Subtitle 5. Report Date
OFFICE OF SPACE AND TERRESTRIAL APPLICATIONS December 1981
(OSTA)/APPLICATIONS DATA SERVICE (ADS) DATA 6.P_rming OrganizationCodeSYSTEMS STANDARDS
7. Author(s) 8. Performing Organization Report No.
Barbara A. Walton, editor
9. Performing Organization Name and Address 10. Work Unit No.
Goddard Space Flight Center
Greenbelt, MD 20771 11. Contract or Grant No.
13. Type of Report and Period Covered
12. SponsoringAgency Name and Address
National Aeronautics and Space Administration Conference Publication
Washington, DC 20546
14. Sponsoring Agency Code
15. Supplementary Notes
16. Abstract
This volume contains the proceedings of the Office of Space and Terrestrial
Applications (OSTA)/Applications Data Service (ADS) Data Systems Standards
Workshop, held May 27-29, 1981 at Goddard Space Flight Center in Greenbelt,
Maryland. The purpose of the workshop was to identify standards needed
to interconnect ADS pilots for data sharing, to assess current pilotmethodologies, and to make recommendations for future work. The theme of
the panel groups was "Standards Needed to Interconnect ADS Pilots for
Data Sharing." The panel topics were: catalogs, directories, and
dictionaries; user interfaces; use of ISO open systems intereonnection -
basic reference model; and data formats and descriptions. This document
contains reports from the panels, summaries of the talks and discussions,
and view-graph presentation material.
17. Key Words(_lectedby Author(s)) 18. DistributionStatement
Applications Data Service
Data Systems Standards Unlimited - UnclassifiedGuidelines
Data Sharing Network Subject Category 14
19. _curity Classif.(ofthisreport) 20. Security Classif.(ofthispage) 21. No. of Pages 22. Price*
Unclassified Unclassified 276 AI3
*For sale by the National Techni_l Information Se_ice, Springfield, Virginia 22161. GSFC 25-44 (10/77
_,U.S. GOVERNMENT PRINTING OFFICE: 1981 539-007/26 I-3
National Aeronauticsand SPECIAL FOURTH CLASS MAIL Postage and Fees Paid
,,_,C"ace Administration BOOK National Aeronautics andSpace AdministrationNASA-451
Washington,D.C.20546Official Business
Penalty for Private Use, $300
_A If Undeliverable (Section 158POSTMASTER:
Postal Manual) Do Not Return