Avionics, Navigation, And Instrumentation

Transcription

Avionics,Navigation, andInstrumentationIntroductionGail ChaplineReconfigurable RedundancyPaul SollockShuttle Single Event Upset EnvironmentPatrick O’NeillDevelopment of Space ShuttleMain Engine InstrumentationArthur HillUnprecedented Rocket EngineFault-Sensing SystemTony FiorucciCalibration of Navigational AidesUsing Global Positioning ComputersJohn Kiriazes242Engineering InnovationsThe Space Shuttle faced many vehicle control challenges duringascent, as did the Orbiter during on-orbit and descent operations.Such challenges required innovations such as fly-by-wire, computerredundancy for robust systems, open-loop main engine control, andnavigational aides. These tools and concepts led to groundbreakingtechnologies that are being used today in other space programsand will be used in future space programs. Other government agenciesas well as commercial and academic institutions also use theseanalysis tools. NASA faced a major challenge in the development ofinstruments for the Space Shuttle Main Engines—engines that operatedat speeds, pressures, vibrations, and temperatures that wereunprecedented at the time. NASA developed unique instruments andsoftware supporting shuttle navigation and flight inspections. In addition,the general purpose computer used on the shuttle had static randomaccess memory, which was susceptible to memory bit errors or bit flipsfrom cosmic rays. These bit flips presented a formidable challenge asthey had the potential to be disastrous to vehicle control.

ReconfigurableRedundancy—The Novel ConceptBehind theWorld’s FirstTwo-Fault-TolerantIntegratedAvionics SystemSpace Shuttle Columbia successfullyconcluded its first mission onApril 14, 1981, with the world’s firsttwo-fault-tolerant Integrated AvionicsSystem—a system that represented acurious dichotomy of past and futuretechnologies. On the one hand, manyof the electronics components, havingbeen selected before 1975, werealready nearing technical obsolescence.On the other hand, it used what werethen-emerging technologies; e.g.,time-domain-multiplexed data buses,fly-by-wire flight control, and digitalautopilots for aircraft, which provideda level of functionality and reliabilityat least a decade ahead of the avionicsin either military or commercialaircraft. Beyond the technological“nuts and bolts” of the on-boardsystem, two fundamental yet innovativeprecepts enabled and shaped the actualimplementation of the avionics system.These precepts included the following:n The entire suite of avionicsfunctions, generally referred to as“subsystems”—data processing(hardware and software), navigation,flight control, displays and controls,communications and tracking, andelectrical power distribution andcontrol—would be programmaticallyand technically managed as anintegrated set of subsystems.Given that new and unique typesof complex hardware and softwarehad to be developed and certified,it is difficult to overstate the rolethat approach played in keeping thoseactivities on course and on scheduletoward a common goal.n A digital data processing subsystemcomprised of redundant centralprocessor units plus companioninput/output units, resident software,digital data buses, and numerousremote bus terminal units wouldfunction as the core subsystem tointerconnect all avionics subsystems.It also provided the means for thecrew and ground to access allvehicle systems (i.e., avionics andnon-avionics systems). There wereexceptions to this, such as the landinggear, which was lowered by the crewvia direct hardwired switches.STS-1 launch (1981) from Kennedy Space Center, Florida. First crewed launch using two-fault-tolerantIntegrated Avionics System.Engineering Innovations243

Avionics System PatternedAfter Apollo; Featuresand Capabilities Unlike AnyOther in the IndustryThe preceding tenets were very muchinfluenced by NASA’s experiencewith the successful Apollo primarynavigation, guidance, and controlsystem. The Apollo-type guidancecomputer, with additional specializedinput/output hardware, an inertialreference unit, a digital autopilot,fly-by-wire thruster control, and analphanumeric keyboard/display unitrepresented a nonredundant subset ofcritical functions for shuttle avionicsto perform. The proposed shuttleavionics represented a challenge fortwo principal reasons: an extensiveredundancy scheme and a relianceon new technologies.Shuttle avionics required thedevelopment of an overarching andextensive redundancy managementscheme for the entire integratedavionics system, which met the shuttlerequirement that the avionics systembe “fail operational/fail safe”—i.e.,two-fault tolerant with reaction timescapable of maintaining safecomputerized flight control in avehicle traveling at more than 10times the speed of high-performancemilitary aircraft.Shuttle avionics would also rely onnew technologies—i.e., time-domaindata buses, digital fly-by-wireflight control, digital autopilots foraircraft, and a sophisticated softwareoperating system that had verylimited application in the aerospaceindustry of that time, even fornoncritical applications, much lessfor “man-rated” usage. Simply put,no textbooks were available to guidethe design, development, and flightcertification of those technologies244Engineering Innovationsand only a modicum of off-the-shelfequipment was directly applicable.Why Fail Operational/Fail Safe?Previous crewed spacecraft weredesigned to be fail safe, meaning thatafter the first failure of a criticalcomponent, the crew would abortthe mission by manually disabling theprimary system and switching overto a backup system that had onlythe minimum capability to return thevehicle safely home. Since the shuttle’sbasic mission was to take humansand payloads safely to and from orbit,the fail-operational requirement wasintended to ensure a high probabilityof mission success by avoiding costly,early termination of missions.Early conceptual studies of ashuttle-type vehicle indicated thatvehicle atmospheric flight controlrequired full-time computerizedstability augmentation. Studies alsoindicated that in some atmosphericflight regimes, the time required fora manual switchover could result inloss of vehicle. Thus, fail operationalactually meant that the avionics had tobe capable of “graceful degradation”such that the first failure of a criticalcomponent did not compromise theavionic system’s capability to maintainvehicle stability in any flight regime.The graceful degradation requirement(derived from the fail-operational/fail-safe requirement) immediatelyprovided an answer to how manyredundant computers would benecessary. Since the computers werethe only certain way to ensure timelygraceful degradation—i.e., automaticdetection and isolation of an errantcomputer—some type of computerizedmajority-vote technique involving aminimum of three computers wouldbe required to retain operationalstatus and continue the mission afterone computer failure. Thus, fourcomputers were required to meetthe fail-operational/fail-saferequirement. That level of redundancyapplied only to the computers. Tripleredundancy was deemed sufficient forother components to satisfy thefail-operational/fail-safe requirement.Central Processor UnitsWere Available Off the Shelf—Remaining Hardwareand Software Would Needto be DevelopedThe next steps included: selectingcomputer hardware that was formilitary use yet commerciallyavailable; choosing the actualconfiguration, or architecture, ofthe computer(s), data bus network,and bus terminal units; and thendeveloping the unique hardware andsoftware to implement the world’sfirst two-fault-tolerant avionics.In 1973, only two off-the-shelfcomputers available for military aircraftoffered the computational capability forthe shuttle. Both computers were basicprocessor units—termed “centralprocessor units”—with only minimalinput/output functionality. NASAselected a vendor to provide the centralprocessor units plus new companioninput/output processors that would bedeveloped to specifications provided byarchitecture designers. At the time, noproven best practices existed forinterconnecting multiple computers,data buses, and bus terminal unitsbeyond the basic active/standby manualswitchover schemes.The architectural concept figuredheavily in the design requirements forthe input/output processor and twoother new types of hardware “boxes” as

Interconnections Were Key to Avionics Systems SuccessShuttle Systems RedundancyShuttle Systems ElementsDiagram illustrates the eight “flight-critical”buses of the 24 buses on the Orbiter.Four General Purpose ComputersCentralProcessingUnitConnections toData Buses(24 per computer)Input/OutputProcessorEight Flight-criticalMultiplexer/DemultiplexersFlight Forward 1PrimarySecondaryFlight-criticalBus 1Multiplex InterfaceAdapters (24 per computer)General PurposeComputer 1Flight Aft 1PrimarySecondaryFlight-critical Bus 5Two MultiplexInterface AdaptersConnections totwo Data BusesPrimary PortSecondary PortControlElectronicsFlight Forward 2PrimaryAssortment ofvarious modulesselected tointerface withdevices in theregion supportedby exerSecondaryGeneral PurposeComputer 2Flight-criticalBus 2Flight Aft 2PrimaryConnectionsto VariousVehicleSubsystemsSecondaryFlight-critical Bus 6Flight Forward 3PrimaryGeneral PurposeComputer 3SecondaryFlight-criticalBus 3Architecture designers for the shuttleavionics system had three goals: provideinterconnections between the fourcomputers to support a synchronizationscheme; provide each computer accessto every data bus; and ensure that themultiplexer/demultiplexers weresufficiently robust to preclude a singleinternal failure from preventing computerFlight Aft 3PrimarySecondaryFlight-critical Bus 7General PurposeComputer 4Flight Forward 4PrimarySecondaryFlight-criticalBus 4Flight Aft 4PrimarySecondary Primary Controlling Computer Listen Only Unless Crew-initiatedReconfiguration Enables Control CapabilityFlight-critical Bus 8access to the systems connected to thatmultiplexer/demultiplexer.redundancy in the form of two independentreconfiguration capability. The totalTo meet those goals, engineers designedports for connections to two data buses.complement of such hardware on thethe input/output processor to interfaceThe digital data processing subsystemvehicle consisted of 24 data buses,with all 24 data buses necessary to coverpossessed eight flight-critical data buses19 multiplexer/demultiplexers, and anthe shuttle. Likewise, each multiplexer/and the eight flight-critical multiplexer/almost equal number of other types ofdemultiplexer would have internaldemultiplexers. They were essential to thespecialized bus terminal units.Engineering Innovations245

well as the operating system software,all four of which had to be uniquelydeveloped for the shuttle digital dataprocessing subsystem. Each of thosefour development activities wouldeventually result in products thatestablished new limits for the so-called“state of the art” in both hardware andsoftware for aerospace applications.In addition to the input/outputprocessor, the other two new deviceswere the data bus transmitter/receiverunits—referred to as the multiplexinterface adapter—and the busterminal units, which was termedthe “multiplexer/demultiplexer.”NASA designated the software asthe Flight Computer Operating System.The input/output processors (onepaired with each central processorunit) was necessary to interface theunits to the data bus network. Thenumerous multiplexer/demultiplexerswould serve as the remote terminalunits along the data buses toeffectively interface all the variousvehicle subsystems to the data busnetwork. Each central processorunit/input/output processor pair wascalled a general purpose computer.The multiplexer/demultiplexer was anextraordinarily complex device thatprovided electronic interfaces for themyriad types of sensors and effectorsassociated with every system on thevehicle. The multiplex interfaceadaptors were placed internal to theinput/output processors and themultiplexer/demultiplexers to provideactual electrical connectivity to the databuses. Multiplex interface adaptorswere supplied to each manufacturer ofall other specialized devices thatinterfaced with the serial data buses.The protocol for communication onthose buses was also uniquely defined.The central processor units laterbecame a unique design for tworeasons: within the first several months246Engineering Innovationsin the field, their reliability was so poorthat they could not be certified for theshuttle “man-rated” application; andfollowing the Approach and LandingTests (1977), NASA found that thesoftware for orbital missions exceededthe original memory capacity. Thecentral processor units were allupgraded with a newer memory designthat doubled the amount of memory.That memory flew on SpaceTransportation System (STS)-1 in 1981.Although the computers were the onlydevices that had to be quad redundant,NASA gave some early thought tosimply creating four identical stringswith very limited interconnections.The space agency quickly realized,however, that the weight and volumeassociated with so much additionalhardware would be unacceptable.Each computer needed the capabilityto access every data bus so thesystem could reconfigure and regaincapability after certain failures. NASAaccomplished such reconfiguration bysoftware reassignment of data buses todifferent general purpose computers.The ability to reconfigure the systemand regain lost capability was a novelapproach to redundancy management.Examination of a typical mission profileillustrates why NASA placed a premiumon providing reconfiguration capability.Ascent and re-entry into Earth’satmosphere represented the missionphases that required automatic failuredetection and isolation capabilities,while the majority of on-orbit operationsdid not require full redundancy whenthere was time to thoroughly assess theimplications of any failures thatoccurred prior to re-entry. When acomputer and a critical se

Avionics, Navigation, and Instrumentation Introduction Gail Chapline Reconfigurable Redundancy Paul Sollock Shuttle Single Event Upset Environment Patrick O’Neill Development of Space Shuttle Main Engine Instrumentation Arthur Hill Unprecedented Rocket Engine Fault-Sensing System Tony Fiorucci Calibration of Navigational Aides Using Global Positioning Computers John Kiriazes. Reconfigurable .File Size: 2MBPage Count: 14