Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “flight software (FSW)”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Guidance, Navigation, and Control Program

The Rendezvous and Proximity Operations Program (RPOP) is real-time guidance, navigation, and control (GN&C) domain piloting-aid software that provides 3D Orbiter graphics and runs on the Space Shuttle's Criticality-3 Payload and General Support Computer (PGSC) in the crew cockpit. This software provides the crew with Situational Awareness during the rendezvous and proximity operations phases of flight. RPOP can be configured from flight to flight, accounting for mission-specific flight scenarios and target vehicles, via initialization load (I-load) data files. The software provides real-time, automated, closed-loop guidance recommendations and the capability to integrate the crew s manual backup techniques. The software can bring all relative navigation sensor data, including the Orbiter's GPC (general purpose computer) data, into one central application to provide comprehensive situational awareness of the rendezvous and proximity operations trajectory. RPOP also can separately maintain trajectory estimates (past, current, and predicted) based on certain data types and co-plot them, in order to show how the various navigation solutions compare. RPOP s best estimate of the relative trajectory is determined by a relative Kalman filter processing data provided by the sensor suite s most accurate sensor, the trajectory control sensor (TCS). Integrated with the Kalman filter is an algorithm that identifies the reflector that the TCS is tracking. Because RPOP runs on PC laptop computers, the development and certification lifecycles are more agile, flexible, and cheaper than those that govern the Orbiter FSW (flight software) that runs in the GPC. New releases of RPOP can be turned around on a 3- to 6-month template, from new Change Request (CR) to certification, depending on the complexity of the changes.

Hinkel, Heather↗
NASA NTRS2012

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗
NASA NTRS2019

CHANGO: A Software Tool for Boost Stage Guidance of the Space Launch System Exploration Mission 1

The Day of Launch Initiation Load Update (DOLILU) System is the means by which the Space Launch System (SLS) Vehicle trajectory is designed, verified, and uploaded on the Day of Launch (DOL) in order to ensure a safe flight. Launch vehicles are designed to fly down a narrow angle of attack and sideslip angle corridor in order to keep them within structural load limits. The angle of attack and sideslip angle response to the launch vehicle experiences can vary significantly based upon the winds experienced on the DOL. SLS Boost Stage flight employs an open-loop guidance scheme through Solid Rocket Booster (SRB) separation. In the SLS open-loop scheme, the vehicle will fly a prescribed set of attitudes as a function of the change in altitude since launch. This set of reference attitude values and corresponding altitude reference independent values are designed with ground software using winds measured on the DOL with the goal of minimizing angle of attack and sideslip angle, thereby minimizing related ascent integrated vehicle structural loads. The table of Boost Stage attitude commands as a function of altitude gained since launch is called the chi table. A software tool called CHANGO (Chi Angle Optimizer) designs the Boost Stage chi table which is uploaded to the vehicle’s flight computer and used during ascent by the flight software (FSW). The wind and atmospheric conditions are measured prior to launch and pre-processed to become input to the CHANGO software along with a set of parameters developed in advance of the DOL. CHANGO’s target set consists of the heading and altitude rate at SRB separation determined well before launch by the Program to Optimize Simulated Trajectories (POST). CHANGO consists of a simplified three degree-of-freedom (3-DOF) simulation representing the SLS launch configuration. In general, the launch azimuth is strongly correlated with the heading at SRB separation, and the initial pitchover rate is strongly correlated with the altitude rate at SRB separation. CHANGO uses an adaptation of Powell’s method to vary the initial pitchover rate and launch azimuth to solve a 2-dimentional minimization problem. CHANGO’s trajectory simulation is phase-based, with flight events separating the phases. Each flight phase has different attitude alignment logic. CHANGO’s 3-DOF simulation starts when the vehicle’s thrust-to-weight ratio equals one, and ends at a pre-calculated SRB separation time.

Ahmad, Naeem↗
NASA NTRS2013

Orion MPCV Touchdown Detection Threshold Development and Testing

A robust method of detecting Orion Multi ]Purpose Crew Vehicle (MPCV) splashdown is necessary to ensure crew and hardware safety during descent and after touchdown. The proposed method uses a triple redundant system to inhibit Reaction Control System (RCS) thruster firings, detach parachute risers from the vehicle, and transition to the post ]landing segment of the Flight Software (FSW). The vehicle crew is the prime input for touchdown detection, followed by an autonomous FSW algorithm, and finally a strictly time based backup timer. RCS thrusters must be inhibited before submersion in water to protect against possible damage due to firing these jets under water. In addition, neglecting to declare touchdown will not allow the vehicle to transition to post ]landing activities such as activating the Crew Module Up ]righting System (CMUS), resulting in possible loss of communication and difficult recovery. A previous AIAA paper gAssessment of an Automated Touchdown Detection Algorithm for the Orion Crew Module h concluded that a strictly Inertial Measurement Unit (IMU) based detection method using an acceleration spike algorithm had the highest safety margins and shortest detection times of other methods considered. That study utilized finite element simulations of vehicle splashdown, generated by LS ]DYNA, which were expanded to a larger set of results using a Kriging surface fit. The study also used the Decelerator Systems Simulation (DSS) to generate flight dynamics during vehicle descent under parachutes. Proto ]type IMU and FSW MATLAB models provided the basis for initial algorithm development and testing. This paper documents an in ]depth trade study, using the same dynamics data and MATLAB simulations as the earlier work, to further develop the acceleration detection method. By studying the combined effects of data rate, filtering on the rotational acceleration correction, data persistence limits and values of acceleration thresholds, an optimal configuration was determined. The lever arm calculation, which removes the centripetal acceleration caused by vehicle rotation, requires that the vehicle angular acceleration be derived from vehicle body rates, necessitating the addition of a 2nd order filter to smooth the data. It was determined that using 200 Hz data directly from the vehicle IMU outperforms the 40 Hz FSW data rate. Data persistence counter values and acceleration thresholds were balanced in order to meet desired safety and performance. The algorithm proved to exhibit ample safety margin against early detection while under parachutes, and adequate performance upon vehicle splashdown. Fall times from algorithm initiation were also studied, and a backup timer length was chosen to provide a large safety margin, yet still trigger detection before CMUS inflation. This timer serves as a backup to the primary acceleration detection method. Additionally, these parameters were tested for safety on actual flight test data, demonstrating expected safety margins.

Daum, Jared↗
NASA NTRS2013

Orion MPCV Touchdown Detection Threshold Development and Testing

A robust method of detecting Orion Multi-Purpose Crew Vehicle (MPCV) splashdown is necessary to ensure crew and hardware safety during descent and after touchdown. The proposed method uses a triple redundant system to inhibit Reaction Control System (RCS) thruster firings, detach parachute risers from the vehicle, and transition to the post-landing segment of the Flight Software (FSW). An in-depth trade study was completed to determine optimal characteristics of the touchdown detection method resulting in an algorithm monitoring filtered, lever-arm corrected, 200 Hz Inertial Measurement Unit (IMU) vehicle acceleration magnitude data against a tunable threshold using persistence counter logic. Following the design of the algorithm, high fidelity environment and vehicle simulations, coupled with the actual vehicle FSW, were used to tune the acceleration threshold and persistence counter value to result in adequate performance in detecting touchdown and sufficient safety margin against early detection while descending under parachutes. An analytical approach including Kriging and adaptive sampling allowed for a sufficient number of finite element analysis (FEA) impact simulations to be completed using minimal computation time. The combination of a persistence counter of 10 and an acceleration threshold of approximately 57.3 ft/s2 resulted in an impact performance factor of safety (FOS) of 1.0 and a safety FOS of approximately 2.6 for touchdown declaration. An RCS termination acceleration threshold of approximately 53.1 ft/s(exp)2 with a persistence counter of 10 resulted in an increased impact performance FOS of 1.2 at the expense of a lowered under-parachutes safety factor of 2.2. The resulting tuned algorithm was then tested on data from eight Capsule Parachute Assembly System (CPAS) flight tests, showing an experimental minimum safety FOS of 6.1. The formulated touchdown detection algorithm will be flown on the Orion MPCV FSW during the Exploration Flight Test 1 (EFT-1) mission in the second half of 2014.

Daum, Jared↗
NASA NTRS2016

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗
NASA NTRS2003

XML: James Webb Space Telescope Database Issues, Lessons, and Status

This paper will present the current concept using extensible Markup Language (XML) as the underlying structure for the James Webb Space Telescope (JWST) database. The purpose of using XML is to provide a JWST database, independent of any portion of the ground system, yet still compatible with the various systems using a variety of different structures. The testing of the JWST Flight Software (FSW) started in 2002, yet the launch is scheduled for 2011 with a planned 5-year mission and a 5-year follow on option. The initial database and ground system elements, including the commands, telemetry, and ground system tools will be used for 19 years, plus post mission activities. During the Integration and Test (I&T) phases of the JWST development, 24 distinct laboratories, each geographically dispersed, will have local database tools with an XML database. Each of these laboratories database tools will be used for the exporting and importing of data both locally and to a central database system, inputting data to the database certification process, and providing various reports. A centralized certified database repository will be maintained by the Space Telescope Science Institute (STScI), in Baltimore, Maryland, USA. One of the challenges for the database is to be flexible enough to allow for the upgrade, addition or changing of individual items without effecting the entire ground system. Also, using XML should allow for the altering of the import and export formats needed by the various elements, tracking the verification/validation of each database item, allow many organizations to provide database inputs, and the merging of the many existing database processes into one central database structure throughout the JWST program. Many National Aeronautics and Space Administration (NASA) projects have attempted to take advantage of open source and commercial technology. Often this causes a greater reliance on the use of Commercial-Off-The-Shelf (COTS), which is often limiting. In our review of the database requirements and the COTS software available, only very expensive COTS software will meet 90% of requirements. Even with the high projected initial cost of COTS, the development and support for custom code over the 19-year mission period was forecasted to be higher than the total licensing costs. A group did look at reusing existing database tools and formats. If the JWST database was already in a mature state, the reuse made sense, but with the database still needing to handing the addition of different types of command and telemetry structures, defining new spacecraft systems, accept input and export to systems which has not been defined yet, XML provided the flexibility desired. It remains to be determined whether the XML database will reduce the over all cost for the JWST mission.

Detter, Ryan↗
NASA NTRS2005

System Design and Performance of the Two-Gyro Science Mode For the Hubble Space Telescope

For fifteen years, the science mission of the Hubble Space Telescope (HST) required using at least three of the six on-board rate gyros for attitude control. Failed gyros were eventually replaced through Space Shuttle Servicing Missions. The tragic loss of the Space Shuttle Columbia has resulted in the cancellation of all planned Shuttle based missions to HST. While a robotic servicing mission is currently being planned instead, controlling with alternate sensors to replace failed gyros can extend the HST science gathering until a servicing mission can be performed, and also extend science at HST's end of life. Additionally, sufficient performance may allow a permanent transition to operations with less than 3 gyros (by intentionally turning off working gyros saving them for later use) allowing for an even greater science mission extension. To meet this need, a Two Gyro Science (TGS) mode has been designed and implemented using magnetometers (Magnetic Sensing System - MSS), Fixed Head Star Trackers (FHSTs), and Fine Guidance Sensors (FGSs) to control vehicle rate about the missing gyro input axis. The development of the TGS capability is the largest re-design of HST operations undertaken, since it affects several major spacecraft subsystems, the most heavily being the Pointing Control System (PCS) and Flight Software (FSW). Additionally, and equally important, are the extensive modifications and enhancements of the Planning and Scheduling system which must now be capable of scheduling science observations while taking into account several new constraints imposed by the TGS operational modes (such as FHST availability and magnetic field geometry) that will impact science gathering efficiency and target availability. This paper discusses the systems engineering design, development, and performance of the TGS mode, now in its final stages of completion.

Prior, Michael↗
NASA NTRS2005

System Design and Performance of the Two-Gyro Science Mode For the Hubble Space Telescope

For fifteen years, the science mission of the Hubble Space Telescope (HST) required using at least three of the six on-board rate gyros for attitude control. Failed gyros were eventually replaced through Space Shuttle Servicing Missions. The tragic loss of the Space Shuttle Columbia has resulted in the cancellation of all planned Shuttle based missions to HST. While a robotic servicing mission is currently being planned instead, controlling with alternate sensors to replace failed gyros can extend the HST science gathering until a servicing mission can be performed, and also extend science at HST s end of life. Additionally, sufficient performance may allow a permanent transition to operations with less than 3 gyros (by intentionally turning off working gyros saving them for later use) allowing for an even greater science mission extension. To meet this need, a Two Gyro Science (TGS) mode has been designed and implemented using magnetometers (Magnetic Sensing System - MSS), Fixed Head Star Trackers (FHSTs), and Fine Guidance Sensors (FGSs) to control vehicle rate about the missing gyro input axis. The development of the TGS capability is the largest re-design of HST operations undertaken, since it affects several major spacecraft subsystems, the most heavily being the Pointing Control System (PCS) and Flight Software (FSW). Additionally, and equally important, are the extensive modifications and enhancements of the Planning and Scheduling system which must now be capable of scheduling science observations while taking into account several new constraints imposed by the TGS operational modes (such as FHST availability and magnetic field geometry) that will impact science gathering efficiency and target availability. This paper discusses the systems engineering design, development, and performance of the TGS mode, now in its final stages of completion.

Prior, Michael↗
NASA NTRS2007

NASA CEV Reference GN&C Architecture

The Orion Crew Exploration Vehicle (CEV) will be the first human spacecraft built by NASA in almost 3 decades and will be the first vehicle to perform both Low Earth Orbit (LEO) missions and lunar missions since Apollo. The awesome challenge of designing a Guidance, Navigation, and Control (GN&C) system for this vehicle that satisfies all of its various mission requirements is countered by the opportunity to take advantage of the improvements in algorithms, software, sensors, and other related GN&C technology over this period. This paper describes the CEV GN&C reference architecture developed to support the overall NASA reference configuration and validate the driving requirements of the Constellation (Cx) Architecture Requirements Document (CARD, Reference 1) and the CEV System Requirements Document (SRD, Reference 2). The Orion GN&C team designed the reference architecture based on the functional allocation of GN&C roles and responsibilities of CEV with respect to the other Cx vehicles, such as the Crew Launch Vehicle (CLV), Earth Departure Stage (EDS), and Lunar Surface Area Module (LSAM), across all flight phases. The specific challenges and responsibilities of the CEV GN&C system from launch pad to touchdown will be introduced along with an overview of the navigation sensor suite, its redundancy management, and flight software (FSW) architecture. Sensors will be discussed in terms of range of operation, data utility within the navigation system, and rationale for selection. The software architecture is illustrated via block diagrams, commensurate with the design aspects.

Tamblyn, Scott↗
NASA NTRS2007

Framework Based Guidance Navigation and Control Flight Software Development

This viewgraph presentation describes NASA's guidance navigation and control flight software development background. The contents include: 1) NASA/Goddard Guidance Navigation and Control (GN&C) Flight Software (FSW) Development Background; 2) GN&C FSW Development Improvement Concepts; and 3) GN&C FSW Application Framework.

McComas, David↗
NASA NTRS2007

Operating System Abstraction Layer (OSAL)

This viewgraph presentation reviews the concept of the Operating System Abstraction Layer (OSAL) and its benefits. The OSAL is A small layer of software that allows programs to run on many different operating systems and hardware platforms It runs independent of the underlying OS & hardware and it is self-contained. The benefits of OSAL are that it removes dependencies from any one operating system, promotes portable, reusable flight software. It allows for Core Flight software (FSW) to be built for multiple processors and operating systems. The presentation discusses the functionality, the various OSAL releases, and describes the specifications.

Yanchik, Nicholas J.↗
NASA NTRS2007

Flight Software Design and On-orbit Maintenance

This viewgraph presentation discusses the maintenance of flight software (FSW) on-orbit and the design of that software to allow maintenance of programs while they are on orbit.

Calder, Alexander C.↗
NASA NTRS2008

Visual Target Tracking on the Mars Exploration Rovers

Visual Target Tracking (VTT) has been implemented in the new Mars Exploration Rover (MER) Flight Software (FSW) R9.2 release, which is now running on both Spirit and Opportunity rovers. Applying the normalized cross-correlation (NCC) algorithm with template image magnification and roll compensation on MER Navcam images, VTT tracks the target and enables the rover to approach the target within a few cm over a 10 m traverse. Each VTT update takes 1/2 to 1 minute on the rovers, 2-3 times faster than one Visual Odometry (Visodom) update. VTT is a key element to achieve a target approach and instrument placement over a 10-m run in a single sol in contrast to the original baseline of 3 sols. VTT has been integrated into the MER FSW so that it can operate with any combination of blind driving, Autonomous Navigation (Autonav) with hazard avoidance, and Visodom. VTT can either guide the rover towards the target or simply image the target as the rover drives by. Three recent VTT operational checkouts on Opportunity were all successful, tracking the selected target reliably within a few pixels.

target approach↗
NASA NTRS2012

Orion GN and C Model Based Development: Experience and Lessons Learned

The Orion Guidance Navigation and Control (GN&C) team is charged with developing GN&C algorithms for the Exploration Flight Test One (EFT-1) vehicle. The GN&C team is a joint team consisting primarily of Prime Contractor (Lockheed Martin) and NASA personnel and contractors. Early in the GN&C development cycle the team selected MATLAB/Simulink as the tool for developing GN&C algorithms and Mathworks autocode tools as the means for converting GN&C algorithms to flight software (FSW). This paper provides an assessment of the successes and problems encountered by the GN&C team from the perspective of Orion GN&C developers, integrators, FSW engineers and management. The Orion GN&C approach to graphical development, including simulation tools, standards development and autocode approaches are scored for the main activities that the team has completed through the development phases of the program.

Jackson, Mark C.↗
NASA NTRS2012

Spacecraft Avionics Software Development Then and Now: Different but the Same

NASA has always been in the business of balancing new technologies and techniques to achieve human space travel objectives. NASA s historic Software Production Facility (SPF) was developed to serve complex avionics software solutions during an era dominated by mainframes, tape drives, and lower level programming languages. These systems have proven themselves resilient enough to serve the Shuttle Orbiter Avionics life cycle for decades. The SPF and its predecessor the Software Development Lab (SDL) at NASA s Johnson Space Center (JSC) hosted flight software (FSW) engineering, development, simulation, and test. It was active from the beginning of Shuttle Orbiter development in 1972 through the end of the shuttle program in the summer of 2011 almost 40 years. NASA s Kedalion engineering analysis lab is on the forefront of validating and using many contemporary avionics HW/SW development and integration techniques, which represent new paradigms to NASA s heritage culture in avionics software engineering. Kedalion has validated many of the Orion project s HW/SW engineering techniques borrowed from the adjacent commercial aircraft avionics environment, inserting new techniques and skills into the Multi-Purpose Crew Vehicle (MPCV) Orion program. Using contemporary agile techniques, COTS products, early rapid prototyping, in-house expertise and tools, and customer collaboration, NASA has adopted a cost effective paradigm that is currently serving Orion effectively. This paper will explore and contrast differences in technology employed over the years of NASA s space program, due largely to technological advances in hardware and software systems, while acknowledging that the basic software engineering and integration paradigms share many similarities.

Mangieri, Mark L.↗
NASA NTRS2013

On a Formal Tool for Reasoning About Flight Software Cost Analysis

A report focuses on the development of flight software (FSW) cost estimates for 16 Discovery-class missions at JPL. The techniques and procedures developed enabled streamlining of the FSW analysis process, and provided instantaneous confirmation that the data and processes used for these estimates were consistent across all missions. The research provides direction as to how to build a prototype rule-based system for FSW cost estimation that would provide (1) FSW cost estimates, (2) explanation of how the estimates were arrived at, (3) mapping of costs, (4) mathematical trend charts with explanations of why the trends are what they are, (5) tables with ancillary FSW data of interest to analysts, (6) a facility for expert modification/enhancement of the rules, and (7) a basis for conceptually convenient expansion into more complex, useful, and general rule-based systems.

Spagnuolo, John N., Jr.↗
NASA NTRS2011

Mars Science Laboratory Flight Software Internal Testing

The Mars Science Laboratory (MSL) team is sending the rover, Curiosity, to Mars, and therefore is physically and technically complex. During my stay, I have assisted the MSL Flight Software (FSW) team in implementing functional test scripts to ensure that the FSW performs to the best of its abilities. There are a large number of FSW requirements that have been written up for implementation; however I have only been assigned a few sections of these requirements. There are many stages within testing; one of the early stages is FSW Internal Testing (FIT). The FIT team can accomplish this with simulation software and the MSL Test Automation Kit (MTAK). MTAK has the ability to integrate with the Software Simulation Equipment (SSE) and the Mission Processing and Control System (MPCS) software which makes it a powerful tool within the MSL FSW development process. The MSL team must ensure that the rover accomplishes all stages of the mission successfully. Due to the natural complexity of this project there is a strong emphasis on testing, as failure is not an option. The entire mission could be jeopardized if something is overlooked.

entry, descent, and landing (EDL)↗