Paul E. Sollock1 FOUR DECADES OF EVOLUTION TOWARD FLEXIWARE ( From the perspective of an Apollo, Shuttle, ISS and Shuttle Upgrades Veteran) Definitions Flexiware: My term for an idealized amorphous melding of code and electronic devices which enable a Flight Computer System to readily incorporate design changes necessary to meet changes in functional and performance requirements. Flight Computer System: The integrated set of HW and SW which provides real time data I/O, processing and error protection in support of vehicle systems. Note the I/O includes User Interfaces, onboard and/or elsewhere.

Paul E. Sollock2 FIRST GENERATION DIGITAL FLIGHT COMPUTERS (1960s) The Hardware and Software used in the first generation of digital flight computers (1960s) were very accurate descriptions of “how” a computer could accommodate changing requirements. –Hardware components were stacked into sealed, encapsulated modules like “cordwood” –By contrast, Software was “hand-crafted” by skilled artisans who practically “memorize” their code and could readily tweak it upon request.

Paul E. Sollock3 SECOND GENERATION DIGITAL FLIGHT COMPUTER SYSTEMS (1970s) With the inception of ICs and PROMS, Hardware became slightly less difficult to change –Instruction Set tweaks by PROM R/R, a.k.a. Firmware change. –Minor HW logic changes by delicate placement of “softwires” on multilayer circuit cards Conversely, Software became harder to change –Increases in size and complexity (to meet increased scope of applications) moved it beyond the domain of (most) artisans –Memory limitations frequently prevented ideal “structure” and modular design Increasing scope and complexity of vehicles, and mission requirements, increased risk of requirements errors and/or requirements creep. Management of HW and/or SW changes in concert with ongoing system development/verification became a critical element of Project success. This above situation prompted 2 signs to appear on my Boss’s office wall: –“Better is the Enemy of Good” –“The more innocuous the design change, the more far-reaching the consequences”

Paul E. Sollock4 THIRD GENERATION FLIGHT COMPUTER SYSTEMS 1980s Increasing density of ICs and early Gate Array devices provided limited additional means for hardware design modifications –Firmware designation extended to include Programmable Gate Array Devices –Space Radiation Effects became a significant consideration in selection of EEE Parts Application of Software Engineering principles, in conjunction with increased memory capacity, did allow SW designs which accommodated incremental change traffic. However, while technology advances in HW and SW offer the potential for increased capabilities, our ability to generate correct, and stable, requirements did not increase commensurately. The quotes on my boss’s wall may have faded, but they were still proven correct more than once.

Paul E. Sollock5 FOURTH GENERATION FLIGHT COMPUTER SYSTEMS ((1990s to present) Hardware device technology (FPGA, etc) has evolved such that HW (re)design flexibility is an essential element in early prototyping—to the point of offering alternative implementations once allocated to SW. –Mitigation of space radiation effects has become (arguably) the predominant influence on EEE parts selection and overall FCS architecture. Conversely, utilization of COTS Software for OS, and other, functions effectively limits SW (re)design flexibility in areas that were once the province of SW artisans. In 40 years, the classical distinction between Hardware and Software has become increasingly blurred. The net result is increased design flexibility that should be exploited for early prototyping. Today’s increasingly complex systems demand thorough and detailed prototyping to ensure (1) correct and complete requirements and (2) a HW/SW implementation capable of meeting all those requirements.