The current Shuttle Program was used as a working model and certified data source in the identification of Space Transportation System (STS) operational cost drivers. Changes to flight hardware, processing methodologies, and identification of automation applications that would reduce costs were derived by reference to that data. The CIRCA 2000 Criteria were developed using these critical analyses of the on-going Shuttle Program. Several innovative suggestions are reviewed

Dickinson, William J.

Scholz, Arthur L.

English

NASA Technical Reports Server

N89-19829 
CIRCA 2000 
0 P E RAT1 ONS CRITERIA 
Arthur L. Scholz 
Boeing Aerospace Operations NASA 
Cocoa Beach, FL 32932-0220 
William J. Dickinson 
Kennedy Space Center, FL 32899 
Abstract 
The current Shuttle Program was used as a working model and certified data 
source Changes to flight 
hardware, processing methodologies, and identification of automation 
applications that would reduce costs were derived reference to that data. 
The CIRCA 2000 Criteria were developed using these critical analyses of the 
on-going Shuttle Program. 
in the identification of STS operational cost drivers. 
by 
Several innovative suggestions are reviewed. 
In 1986, the Kennedy Space Center com- 
missioned BAO (Boeing Aerospace Operations) 
to perform the SGOE/T Study, (Shuttle Ground 
Operations Efficiencies I Technologies Study". 
This Study was a one year contract (Phase 1) 
with two priced options (Phase 2 and Phase 3). 
We are currently in Phase 3 of that Study. Each 
Phase of the Study has had a different thrust. 
The Phase 1 primary objective was to identify 
the Shuttle Program operational cost drivers 
and reduce the overall operational cost either 
through improving the efficiency of the ground 
operations or with the addition of selected 
technology elements to cut costs. The results 
of the study indicated that although it may be 
too late to "significantly" change the existing 
Shuttle System per se, development of launch 
site criteria for use by the various design 
agencies and their contractors would be ben- 
eficial for future programs, either manned or 
unmanned. One of the significant conclusions 
was that increased application of automation 
to evaluate systems and conduct operations 
will provide several ways of reducing launch 
operations costs and providing benefits: 
o Increase the speed of the total checkout 
(reduce time-in-flow requirements) 
o Reduce manpower requirements 
o Reduce the possibility of human error 
o Minimize documentat ion changes 
(improve test-to-test consistency) and 
provide the potential for "learning curve" 
reduction in the time required for manual 
tasks. 
The data also clearly indicated that the lack of 
emphasis on maintenance requirements during 
the early design portion of the Program has had 
a very significant impact on recurring, oper- 
ational costs. Bypassing these considerations 
in favor of other high priority items to save 
front-end costs in the design phase of the 
Shuttle has significantly increased operational 
costs at KSC and, therefore, Life Cycle Costs 
for the Program. 
A Phase 2 product of the SGOElT Study was 
development of the description of a generic 
launch vehicle to be operational by the year 
2000 and titled "Circa 2000" or "Circa 2K" for 
short. The objective was to use the operations 
cost drivers identified in Phase 1 of the Study. 
The approach was to develop individual 
operational requisites for the four segments of 
Ql a launch system. 
" I  
https://ntrs.nasa.gov/search.jsp?R=19890010458 2020-03-20T04:08:22+00:00Z
The Circa 2000 System's four areas include: 
Management and System Engineering 
Vehicle Design 
Test and Checkout 
LaunchedPad 
In each of these areas, the Circa 2000 system 
defines design requirements that will signif-  
icantly reduce the launch operations costs 
contribution to Life Cycle Costs (LCC). 
Personnel interested in further information are 
referred to William J. "Bill" Dickinson, phone 
number (407) 867-2780, at the Kennedy Space 
Center. Due to the primary interest of this 
audience, this paper will concentrate on the 
"Test and Checkout" segment (see Figure 7 ) ,  
because that area will benefit the most from 
the incorporation of additional automation 
techniques. 
Figure 1 
TEST AND CHECKOUT 
TEST RND CHECKOUT 
~ Some of the CIRCA 2000 criteria for that 
i segment include: 
I 1. 100% Computer Connectivity 
Operations Requirement: 
All computers associated in any manner 
with operations, flight or ground, must 
ma in ta in  comp le te  connnec t i v i t y  
(bridging). 
Rationale: 
The amount of data required to support and 
maintain any operational system requires 
that eff iciency in acquisit ion of 
I 
I 
82 
operational data be always maintained. 
Paperwork (its development, maintenance, 
use and control) currently requires a large 
portion of the operations budget. A 
significant reduction in the total Life 
Cycle Costs can be achieved by intensive 
application and use of automation to 
replace paperwork. 
Sample Concept: 
Utilization of commercial DBMS (Data Base 
Management System) which support SQL 
(Standard Query Language) and provide for 
data import and export in a manner that 
meets the requirements of MIL-STD- 
1840A. 
Technology Requirement: 
Distributed DBMS that will provide the 
required flexible computer connectivity. 
I I .  Automated Electronic OMl's 
Operations Requirement: 
Operational and support procedures should 
be computer-based and maintained. 
Automation of the OM1 (Operations and 
Maintenance Instructions) process; i.e., 
development, maintenance, and use, 
provides improvements in: 
Rationale: 
0 costs 
o Discipline of usage 
o Performance data verification 
o Configuration change compliance 
Sample Concept: 
Assembly and checkout procedures would 
be  received from each vendor  
electronical ly (per MlL-STD- l840A,  
including graphics). These data would then 
be processed into an operational-site 
procedure format. As procedures are 
scheduled for performance, the test 
conductor would initiate them from his 
terminal and follow the displayed test 
progress. The displays will include 
instructions for manual operations, 
progress of the automated test sequences, 
or the requirements for hardware 
replacement and retest in the event of an 
out-of-tolerance test result indication. 
Techno logy Require men t : 
Procedure authoring and update, standard- 
ized Aext and graphics formats. 
111. Automatic Test Requirements 
Verification 
Operations Requirement: 
S a t i s f a c t i o n  of  a p p r o v e d  t e s t  
requirements wi l l  be  automatical ly 
correlated with the completion of the 
associated procedures. Completion of 
individual test requirements will be 
verified within the automated testing 
system. 
Current manual method is labor intensive, 
inefficient, inadequate, and error prone. 
Rationale: 
Sample Concept: 
A truly paperless, automated OM1 will have 
sequence execut ion control led by 
scheduling systems that track the 
completion of each procedure and task. As 
each task is completed, without error, or 
after maintenance 
accompl ished, al l  
requirements wou Id 
verified. 
Technology Requirement: 
Operational systems 
processing, networking, 
connectivity. 
IV. Integrated Fault Tolerant 
Suite (IFTAS) 
Operations Requirement: 
Avionics systems must 
reliability by providing 
and retest is  
associated test 
be automatically 
distributed data 
and co m p u t e r/data 
Avionics 
provide for higher 
several levels of 
fault tolerance thru redundancy to support 
mandated system availability. 
Rationale: 
To support on-board checkout and mission 
success, the entire avionics suite must be 
designed to provide that level of fault 
tolerance required to assure that the 
system is available when required. This 
is best accomplished by assuring the 
robustness of a l l  mission cri t ical 
systems, and providing fault tolerance 
where it is required (similar to the 
minimum equipment l is t  used by 
commercial aircraft). 
Sample Concept: 
Future systems must be designed such that 
systems in general can be dynamically 
configured to provide for more than one 
function. Should an allocated processor or 
sub-system fail, another processor with a 
lesser priority function should be assigned 
to reconfigure and perform the function of 
the failed processor. This will force a 
high degree of commonality, require 
distributed processing, and provide a 
system more capable of surviving in 
adversity. 
Technology Requirement: 
Distributed processing, development of 
layered architectures, commonality of 
equipment elem en ts. 
V. Returned Vehicle Self-Test for 
Ref lig ht 
Operations Requirement: 
After flight, the returned vehicle should 
have sufficient self-test capability to 
verify its flight readiness or provide 
problem isolation down to the LRU (Line 
Replaceable Unit). 
Rationale: 
To accomplish an order-of-magnitude cost 
reduction, we must strive to achieve the 
160-hrs. (or better) turnaround time. The 
original STS turnaround objective was 
160-hrs. STS actual processing times 
have grown an order of magnitude beyond 
that original goal. 
Sample Concept: 
During flight, BIT ident i f iedrecords 
anomalies. After landing, BIT/BITE 
isolates problem to LRU level. After 
replacement, BIT retests the system and 
verifies flight readiness. 
Technology Requirement: 
Development of BIT/BITE to meet specific 
requirements. 
V I .  Autonomous Guidance Navigation 
and Control (GN&C) 
Operations Requirement: 
Eliminate vehicle dependence on GSE for 
test and checkout. 
Rationale: 
Onboard BIT/BITE of GN&C can eliminate, 
simplify, or reduce the requirement for 
ground support operations. 
Sample Concept: 
Boeing 757/767 or advanced military 
a i r c ra f t  compu te r i zed  e lec t ron ics  
p r o v i d i n g  s e l f - t e s t  a n d  f a u l t  
i d e n t i f i c a t i o n  w i th  fau l t - t o le ran t  
computers. Ability to replace circuit 
boards without system shutdown. Easy 
accessibil i ty. 
VII. Software Commonality 
Operations Requirement: 
The vehicle should utilize the same set of 
software for ground operation test, inte- 
I gration, and for flight. 
Rationale: 
Current STS ground operations are 
accomplished with several different 
programs depending on the stage of 
testing. This results in many hours of 
time for reloading the main computer 
memory. For example, the final prelaunch 
load requires 14  clock-hours to 
accomplish. 
Sample Concept: 
The Avionics should be designed as a 
distributed system with one or more high 
speed buses providing communications 
between subsystems as required. 
Each subsystem should have the capability 
of autonomous ground operations by com- 
manding the system to a standalone mode. 
I 
In this mode all required external stimuli 
would be simulated by the subsystem in a 
sufficient manner to verify its proper 
operation. This would allow each 
subsystem to be tested independently of 
the operational state of the other systems. 
When all ground testing and vehicle 
integration is complete, each subsystem 
would be commanded to the flight mode 
without additional computer reloading. 
Technology Requirement: 
Distributed, layered architecture. 
In a paper presented last year (1987) at the 
Space Congress in Cocoa Beach, FL, David 
Lowry and Tom Feaster described plans for 
research and development of computerized 
tools to incorporate supportability factors in 
the early phases of system design (Reference 
2). The concept includes the role that 
CAE/CAD/CAM should play in improving design 
for supportability. There is an accumulation 
of evidence from recent research performed 
by the Human Resources Laboratory at 
Wright-Patterson Air Force Base that 
indicates that the accumulation of 
operational maintenance and logistics support 
characteristics must begin early in the 
development of system concept studies. This 
research indicates, also, that one of the best 
ways to improve design for support is to 
include the operational maintenance and 
logistics data and factors directly in the 
daily working procedures and systems used by 
the design engineering personnel (Ref. 3). 
There is a need, then, to develop the technical 
capability to develop generic operational 
maintenance criteria, logistics factors and 
provide operational requirements and criteria 
feedback directly into the CAD process being 
used by the aerospace industry. This 
technical capability does not exist today 
except in limited scope and then only in 
isolated cases. 
The current status of design for support is 
primarily that of studies and analyses being 
performed "off-line" from the main "perfor- 
m an ce - o r i e n t ed " e ng i n e e r i n g des i g n act i v- 
ities; usually being performed "after the 
fact" without any real input to major design 
84 
decisions. The development of the technical 
capability to enter maintenance and logistics 
factors (along w i t h  equipment design 
information and performance parameters) 
directly into the main CAD process can change 
this picture. 
Equipment and systems designed from the 
b e g  inn ing  w i th  access ib i l i t y  a n d  
supportability to meet operational criteria 
can become a standard, on-line design 
product. 
Computer-based, automated analysis models 
are an essential part of the CAD process. 
Presently these models are used to assess 
system element performance characteristics 
as well as weight & balance. These 
automated analysis models are one of the 
reasons for the quick reaction time of the 
CAD process. Consideration of operations 
maintenance and logistics data in the 
analyses models will also be necessary if 
meeting approved Life Cycle Cost targets is 
going to truly be a primary objective in the 
future. 
The abil ity to view objects in three 
dimensions is now resident within many CAD 
systems. Color presentation of objects is 
now possible. These characteristics will 
afford opportunities to use a totally 
integrated CAE/CAD/CAM system to perform 
maintainability evaluations of proposed 
equipment during early design without the 
high cost of Class 1 mockups. 
The design and drawing data generated by 
CAD can be, and are, being bridged to the 
databases that operate the numerical 
controlled machines within the manufacturing 
facility. The data flows from CAD to CAM and 
eventually, by hardcopy, to field and service 
o rg a n izat ions . U n f o rt u n ate1 y , the data bases 
that are used in operational maintenance and 
logistics analysis models have not been linked 
with the CAD/CAM engineering databases. 
Design tasks in the future will require inter- 
change of operational maintenance, access- 
ibility, and supportability criteria and data 
with the established CAD/CAM systems if 
costs are to be truly optimized and reduced to 
meet the current cost targets. 
REDUCE LIFE CYCLE COSTS 
BE CREATIVE ! ! BE INNOVATIVE ! ! 
DESIGN the SUPPORT 
not 
SUPPORT 
References 
1. Shuttle Ground Operations Efficiencies /Technologies 
Study, Phase 2 Final Report, Vol. 6, May,l988, 
Kennedy Space Center. 
Contacts: A. L. Scholz, Boeing; 
W. J. Dickinson, NASA-KSC 
the DESIGN 
3. Askern, William B., "Maintenance and Logistics 
Factors in Computer Aided Design", Air Force Human 
Resources Laboratory, Wright Patterson AFB, 
NASA RECON 84A16548. 
2. Lowry, David J.. Boeing; Feaster, Thomas A,, 
Control of Life Cycle Costs", Proceedings of the Twenty 
Fourth Space Congress,l987. 
, NASA-KSC; "Regaining Space Leadership Through 
85 


CIRCA 2000 operations criteria

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server