Return to "SHUTTLE AVIONICS - Design Constraints & Considerations - A Guide Book"
DPS 1.
MEMORY DUMP & COMPARE
Constraint
Shuttle memory "Dump and Compares" delay testing
Impact
- Time lost due to actual dump and compare operations
- Large infrastructure required to process tapes
Design Objectives
- Design system capable of utilizing real-time hardware/software techniques to validate contents of memory, e.g. "checksums".
DPS 2.
MASS STORAGE DEVICE CAPABILITY
Constraint
A faster method of loading the Mass Storage device is needed
Impact
- The Shuttle's Mass Memory units are magnetic tape storage devices that require loading from the LPS system , up the LDB, to the on-board computer which is in a special memory configuration, then to the mass memory unit . Loading a MMU takes 1hr 40mins, dump and compare a MMU takes 1hr 10mins , and many off line hours are worked processing memory tape products.
Design Objectives
- Develop a "hard drive'" system that can be loaded from a disk drive. Loading from a disk, and dumping to a disk could greatly simplify load, dump and compare operations (assuming dump and compares are required).
- Explore megneto-optical drives where cartridge could be loaded on the ground and "popped" in to flight drive.
DPS 3.
GPC MULTIPLE MEMORY CONFIGURATIONS
Constraint
Each Shuttle on-board computer operation requires being in a unique memory overlay configuration.
Impact
- Some ground operations require the on-board system being in a "flight OPS" which have operational and safety considerations.
- Special GPC memory configurations for RMS, cargo, KU communication and MMU testing constrains scheduling flexibility.
- Operations which require differing LDB configurations must wait upon one another. For example, some hazardous activities require redundant launch data busses (LDB’s), such as many hydraulic activities and hypergolic servicing. A single LDB configurations examples are one LDB connected to a G9 machine and the other LDB connected to a P9 machine. Therefore, operations requiring redundant LDB configurations must run serial to those operations requiring the single LDB/multiple memory configurations.
Design Objectives
- Perform all operations in a single memory configuration.
- Provide data bus connectivity to on-board systems from the ground to provide independent control.
DPS 4.
LAUNCH BUS SPEEDUP
Consideration
Shuttle Launch Data Bus (LDB) is too slow
Impact
- Slow speed limits time between commands going up the bus
- Slow speed limits quickest time critical SAFING command can get out
Design Objectives
- Increase speed of Launch Data Bus
DPS 5.
MDM RETEST
Consideration
Single failure in an MDM requires massive retest of unrelated systems
Impact
- Activation of end item systems (mobilizing a level of ground support above and beyond that needed for DPS checkout) takes time and adds work content
Design Objectives
- Insure that DPS components can be recertified for flight readiness without activating end item functions (RJD trickle current verification is an innovative example of how to do this)
DPS 6.
CRT VIDEO OUTPUT
Consideration
Provide the ground visibility of the on-board CRT's.
Impact
- Since the ground can not see the on-board CRT's, any problems requiring CRT output knowledge introduces guesswork and uncertainty.
Design Objectives
- Provide CRT video output for ground display capability.
Return to KSC Next Gen Site
Edgar Zapata, NASA Kennedy Space Center
Shuttle Process Engineering Directorate, Fluid Systems Division