The Space Station Freedom will offer facilities for experimentation and testing not available and not feasible or possible on earth. Due to a restricted space availability on board, the experimentation equipment and its organization will be frequently changing. This requires careful attention to electromagnetic compatibility between experimentation and other SSF equipment. To analyze the interactions between different equipment modules, a software system ISEAS is under development. Development of ISEAS was approached in two phases. In the 1st phase a PC version prototype of ISEAS was developed. In the 2nd phase, the PC prototype will be adapted to a VAX range of computers. The purpose of this paper is to review the design of the VAX version of ISEAS, and to recommend any suitable changes

Bykat, Alex

English

NASA Technical Reports Server

-24410
1993
NASA/ASEE SUMMER FACULTY FELLOWSHIP PROGRAM
MARSHALL SPACE FLIGHT CENTER
THE UNIVERSITY OF ALABAMA IN HUNTSVILLE
A REVIEW OF ISEAS DESIGN
Prepared by:
Academic Rank:
Institution:
MSFC Colleague:
NASA/MSFC:
Office:
Division:
Branch:
Alex Bykat, Ph.D.
Professor of Computer Science
Department of Mathematics and Computer Science
Armstrong State College
Savannah, GA 31419
Dawn Trout
Systems Analysis & Integration Lab
Systems Definition Division
Electromagnetics and Environments Branch
V
https://ntrs.nasa.gov/search.jsp?R=19940019937 2020-06-16T16:51:50+00:00Z

1. Introduction.
The Space Station Freedom will offer facilities for experimentation and testing
not available and not feasible or possible on earth. Due to a restricted space availabil-
ity on board, the experimentation equipment and its organization wiU be frequently
changing. This requires careful attention to electromagnetic compatibility between
experimentation and other SSF equipment. To analyze the interactions between
different equipment modules, a software system ISEAS [6] is under development.
Development of ISEAS was approached in two phases. In the 1st phase a PC
version prototype of ISEAS was developed. In the 2nd phase, the PC prototype will
be adapted to a VAX range of computers. The purpose of this paper is to review the
design of the VAX version of ISEAS, and to recommend any suitable changes.
2. Architecture of ISEAS.
ISEAS consists of the following components: interactive interface, analysis
module, output module, and data base containing data used by analysis routines.
ISEAS user communicates via the interface his requests for analysis instances, types
of analysis result displays, and supplies appropriate data. The interface will be
implemented using ORACLE/SQL relational database environment running on a
VAX platform. User's requests are passed to the control module which performs the
analysis. The analysis routines will be implemented in C. The output module offering
different ways of result's presentation will be implemented in Fortran. The data base
will be created using the services of the ORACLE/SQL running on a VAX platform.
3. Design methodology
ISEAS is to be developed using a structured software approach [3, p.4]. Struc-
tured methodology offers a methodical approach to development, yielding good
system design, correct and efficient data model, smooth implementation, and a basis
for ease of maintenance. The methodology spans a whole software life cycle which
consists of essentially sequential phases: Project initiation, Requirements elucidation,
Feasibility study, System Analysis, System Design, Implementation, Testing, Installa-
tion, and finally System Review. Once fielded, the System Maintenance follows.
The review is limited to Analysis and Design Stages. The purpose of the Analysis
stage is to consider what is to be done and what are the system's data requirements,
while the purpose of the Design stage is to consider how it is to be done.
3.1 Deliverables
At each of the Software Life Cycle stages, structured software methodology
V-1
predicatesa number of deliverables.The SystemAnalysis stage requires the following
deliverables: 1) Context Diagram which presents a top level design of the system
addressing its purpose and main functions, 2) Data Flow Diagrams which present
processes within the system, functions that system will perform, and flow of data as
these processes and functions are invoked, 3) Data models expressed via Entity
Relationship Diagrams (ERD) which present the various data entities and relation-
ships that are recognized by the system, 4) Decomposition Diagrams which present
the logic of the system through hierarchical structure of the modules of the system.
The System Design stage requires: 1) Transition Diagrams which present a reorga-
nized Decomposition Diagrams after taking into account the module types in addition
to their functionality, 2) Structure Charts which present the structure of system
modules and their data interfaces, 3) Pseudocode or Action Diagrams which present
the actions defining the modules.
3.2 Data Normalization
A Relational Database consists of data items, relations among them and opera-
tions that can be applied. Whereas "primitive" operations are defined by a chosen
relational database -- in ISEAS case it is ORACLE -- definitions of relations are left
to the system designers. To assure efficiency, to avoid data redundancy and inaccessi-
bility, to protect against data loss, etc., the data must be normalized. It is a common
practice to expect the relation tables to satisfy at least the first three (Codd) Normal
Forms which present essentially steps for relationship transformation with the aim of
assuring elimination of various anomalies (in particular data modification anomalies).
4. Review findings
The following summarizes review findings. A more detailed exposition can be
found in [Bykat, 1993].
[3] presents ERD, Structured Charts, and Pseudocode. Omission of the other four
items results in missing documentation of modules, inconsistencies, and possibilities
for module design improvement. There are violations of the Structured Charts
presentation semantics. Pseudo-code for a number of modules is missing.
Database table are presented but show violations of the first three normal forms.
Backup requirements as well as requirements concerning support of local and
remote users [2, p.53] have not been addressed.
5 Conclusions.
ISEAS is a needed and timely project. The proposed version offers fundamental
V-2
capabilities but requires further technical (EMC) developmentand evaluation of the
offered capabilitiesand their functionality. In particular, current calculationsview the
equipment and their componentsas "point sources".The sizeof the equipment, the
location of a componentwithin the equipment are not taken into consideration.
EMC analysisrecommendationsare essentiallydiadic: passor fail. This could be
addressedby calculationsfor repositioning the equipment to find a location in which
initially failing equipment would passthe EMC criteria. A further extension would be
finding optimal configuration of a given equipment for EMC purposes.
6 Recommendations.
The recommendations fall into three categories. The first category relates to the
strategy of ISEAS development, the second category relates to technical issues, while
the third category presents a path for further development of ISEAS.
6.1 Strategy.
The main goal of the ISEAS project is to provide a tool for evaluation and
analysis of EMC for the Space Station Freedom. This goal should be enlarged to
"provide a tool for evaluation and analysis of EMC for the EMC community at large
and for the Space Station Freedom in particular".
There are a variety of applications where ISEAS (or its descendant) delivered on
a workstation platform would be of considerable benefit. Many of these applications
are in commercial areas (aircraft manufacturers, land/water-based vehicle manufactur-
ers, etc.), while other are in government agencies (Navy, Air Force, etc). In such
applications EMC considerations are important, if not critical (eg. interference with
navigational equipment, etc.).
NASA is now at crossroads, searching for ways serve broader national needs".
This will lead the agency towards much greater involvement in private sector through
attempts to "push technology through the federal door and into commercial market-
place ''1. Such involvement has to be contemplated and planned a priori rather than as
an afterthought. ISEAS offers an opportunity for such involvement.
I recommend therefore development of a VAX version in parallel with development
of a workstation version of ISEAS operating in a multitasking Unix environment
supporting Xll windowing environment, and with a suitable relational database.
speech by Rep. Alan Mollohan (D-W.V.) delivered at the 31st Goddard Memorial
Symposium, 3/9/93 (Space News, 6/14/1993, p.19)
V-3
6.2 Technical.
R1. Develop Data Flow Diagrams and Decomposition Diagrams. Revise and com-
plete Design Phase documentation. Gain: Lead to correct structure of the system.
R2. Complete the normalization of data. Gain: Avoid data modification anomalies.
R3. A user interacts with ISEAS in two distinct modes: define and select. ISEAS code
should adopt the same philosophy in presentation of forms and screens for da-
ta/request entry. Gain: ISEAS code will be much shorter and much more efficient.
R4. Partial description of entities during data input should not be accepted by ISEAS.
Gain: ISEAS code will be much shorter and much more efficient.
R5. Before the input of new data affected files should be preserved as prior versions.
Gain: efficient restoration of prior version.
R6. Extend analysis selection capability to allow any combination of analyses to be
performed. Gain: Batch mode execution of analyses.
6_3 Future development.
An intelligent object oriented interface for ISEAS should be developed to offer
ease of use and functionalities which current version lacks. It should offer a graphical
mouse-relocatable component and connectivity icons to aid graphical environment
data input, visual validation, and reconfiguration of analyzed environments. It would
allow improved presentation of results through a 2-dimensional "interference regions",
easing subsequent graphical modification of equipment configurations.
Electro-magnetic compatibility analysis is a ripe candidate for further automation
through knowledge based methodology [4, 5]. Development of EASE-MagIC, an
Expert Analysis System of Electro-Magnetic Interference and Compatibility, would
serve this purpose. Such a knowledge based system can offer evaluations controlled
through heuristic rules, on demand instructive explanations of the analysis and its
conclusions, and through such explanations -- coupled with the proposed graphical
interface -- it would offer a sophisticated tool for EMC training.
7. References.
1. Bykat A., "A detailed look at ISEAS design", NASA TR, 1993
2. BCSS, "Integrated Space Station Freedom Electromagnetic Compatibility Analysis System (ISEAS)
VAX Requirements Specification Document (DS04)", NASA ISEASVAX-DS-04-1.0, April 1993
V-4
3. BCSS, "Integrated Space Station Freedom Electromagnetic Compatibility Analysis System (ISEAS)
VAX Version Design Specification (DS08)", NASA ISEASVAX-DS-08-1.0, June 1993
4. Drozxl A.L., "Overview of Present EMC Analysis/Prediction Tools and Future Thrusts Directed at
Developing AI/Expert Systems', in IEEE EMC Symposium, Annaheim 1992, pp. 528-529
5. LoVetri J., Henneker W.H., "Fuzzy Logic Implementation of Electromagnetic Interactions
Modelling Tool', in IEEE EMC Symposium, Annaheim 1992, pp. 127-130
6. Pearson S.D., Smith D.H., "A System Engineering Approach to Electromagnetic Compatibility
Analysis for the Space Station Freedom Program", in EMC Symposium 1991, pp.
V-5



A review of ISEAS design

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server