Engineering PapersSearch

SEARCH · Engineering Papers

Results for “agile development”

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 19 records

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and procedure for developing software. This paper will discuss the some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies.

Agile Development

A Roadmap for Using Agile Development in a Traditional Environment

One of the newer classes of software engineering techniques is called 'Agile Development'. In Agile Development software engineers take small implementation steps and, in some cases, they program in pairs. In addition, they develop automatic tests prior to implementing their small functional piece. Agile Development focuses on rapid turnaround, incremental planning, customer involvement and continuous integration. Agile Development is not the traditional waterfall method or even a rapid prototyping method (although this methodology is closer to Agile Development). At the Jet Propulsion Laboratory (JPL) a few groups have begun Agile Development software implementations. The difficulty with this approach becomes apparent when Agile Development is used in an organization that has specific criteria and requirements handed down for how software development is to be performed. The work at the JPL is performed for the National Aeronautics and Space Agency (NASA). Both organizations have specific requirements, rules and processes for developing software. This paper will discuss some of the initial uses of the Agile Development methodology, the spread of this method and the current status of the successful incorporation into the current JPL development policies and processes.

software methodology

ISS Double-Gimbaled CMG Subsystem Simulation Using the Agile Development Method

This paper presents an evolutionary approach in simulating a cluster of 4 Control Moment Gyros (CMG) on the International Space Station (ISS) using a common sense approach (the agile development method) for concurrent mathematical modeling and simulation of the CMG subsystem. This simulation is part of Training systems for the 21st Century simulator which will provide training for crew members, instructors, and flight controllers. The basic idea of how the CMGs on the space station are used for its non-propulsive attitude control is briefly explained to set up the context for simulating a CMG subsystem. Next different reference frames and the detailed equations of motion (EOM) for multiple double-gimbal variable-speed control moment gyroscopes (DGVs) are presented. Fixing some of the terms in the EOM becomes the special case EOM for ISS's double-gimbaled fixed speed CMGs. CMG simulation development using the agile development method is presented in which customer's requirements and solutions evolve through iterative analysis, design, coding, unit testing and acceptance testing. At the end of the iteration a set of features implemented in that iteration are demonstrated to the flight controllers thus creating a short feedback loop and helping in creating adaptive development cycles. The unified modeling language (UML) tool is used in illustrating the user stories, class designs and sequence diagrams. This incremental development approach of mathematical modeling and simulating the CMG subsystem involved the development team and the customer early on, thus improving the quality of the working CMG system in each iteration and helping the team to accurately predict the cost, schedule and delivery of the software.

Inampudi, Ravi

A Roadmap for using Agile Development in a Traditional System

I. Ensemble Development Group: a) Produces activity planning software for in spacecraft; b) Built on Eclipse Rich Client Platform (open source development and runtime software); c) Funded by multiple sources including the Mars Technology Program; d) Incorporated the use of Agile Development. II. Next Generation Uplink Planning System: a) Researches the Activity Planning and Sequencing Subsystem for Mars Science Laboratory (APSS); b) APSS includes Ensemble, Activity Modeling, Constraint Checking, Command Editing and Sequencing tools plus other uplink generation utilities; c) Funded by the Mars Technology Program; d) Integrates all of the tools for APSS.

uplink planning systems

Ground System Architectures Workshop GMSEC SERVICES SUITE (GSS): an Agile Development Story

The GMSEC (Goddard Mission Services Evolution Center) Services Suite (GSS) is a collection of tools and software services along with a robust customizable web-based portal that enables the user to capture, monitor, report, and analyze system-wide GMSEC data. Given our plug-and-play architecture and the needs for rapid system development, we opted to follow the Scrum Agile Methodology for software development. Being one of the first few projects to implement the Agile methodology at NASA GSFC, in this presentation we will present our approaches, tools, successes, and challenges in implementing this methodology. The GMSEC architecture provides a scalable, extensible ground and flight system for existing and future missions. GMSEC comes with a robust Application Programming Interface (GMSEC API) and a core set of Java-based GMSEC components that facilitate the development of a GMSEC-based ground system. Over the past few years, we have seen an upbeat in the number of customers who are moving from a native desktop application environment to a web based environment particularly for data monitoring and analysis. We also see a need to provide separation of the business logic from the GUI display for our Java-based components and also to consolidate all the GUI displays into one interface. This combination of separation and consolidation brings immediate value to a GMSEC-based ground system through increased ease of data access via a uniform interface, built-in security measures, centralized configuration management, and ease of feature extensibility.

Software Development/Agile

Agile Development Methods for Space Operations

Main stream industry software development practice has gone from a traditional waterfall process to agile iterative development that allows for fast response to customer inputs and produces higher quality software at lower cost. How can we, the space ops community, adopt state of the art software development practice, achieve greater productivity at lower cost, and maintain safe and effective space flight operations? At NASA Ames, we are developing Mission Control Technologies Software, in collaboration with Johnson Space Center (JSC) and, more recently, the Jet Propulsion Laboratory (JPL).

Trimble, Jay

VIPER Lunar Rover Agile Mission Systems

Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.

Agile

Hybridized Agile Software Development of Flight Control Team Tools for International Space Station's Payload Operations Integration Center

Ground systems operations at the National Aeronautics and Space Administration's (NASA) Payload Operations and Integration Center (POIC) at Marshall Space Flight Center (MSFC) recently increased via a High Operations Tempo (HOT) initiative, in order to support more science activities with a fourth crew member on the International Space Station (ISS). The Flight Control Team's (FCT) need to support this increasing pace of payload science operations was the impetus for creating a series of new tools. While their need was clear, the full scope and user experience for each tool was not as well-understood, thus establishing a fixed set of initial requirements was not feasible. A hybridized Agile Software Development (ASD) paradigm was created to take advantage of this uncertainty, plan for it, permit the exploration of novel concepts, and also facilitate a rapid and flexible response to inevitably changing requirements. The POIC's hybridized ASD approach places preeminent focus on providing customer value through the delivery of high quality, customer-focused solutions in short timeframes. This has been successfully achieved through creating unprecedented modes of cooperation and collaboration between operations and software development teams, frequent user evaluations of the software with well-defined feedback mechanisms, increased human factors involvement, and a dedication to successful outcomes by the whole of the POIC. Since space science operations and software development are not typically so closely linked, this paper discusses an approach that offers an optimal way to provide an increased return on investment and a faster time-to-completion than traditional software development paradigms, while aiming at delivering high quality products and customer-driven value.

Albers, Cerese M.

Hybridized Agile Software Development of Flight Control Team Tools for International Space Station's Payload Operations Integration Center

Ground systems operations at the National Aeronautics and Space Administration's (NASA) Payload Operations and Integration Function (POIF) is increasing, via the High Operations Tempo (HOT) initiative, its ability to support more science activities with a fourth crew member on the International Space Station (ISS). The Flight Control Team's need to support this increased crew presence mandated the need for a series of software tools to better handle the increasing pace of payload science operations. The overall need was clear from the outset, but the full scope and user experience for each tool, were not as well understood, so establishing a fixed set of initial requirements was not feasible. An Agile Software Development (ASD) paradigm takes advantage of uncertainty, and plans for it, so it was deemed the most appropriate approach to create room for exploring novel concepts, and to mount a rapid and flexible response to inevitiably changing requirements. It facilitated the need for unprecedented collaboration between the Product Team (i.e. users from the Flight Control Team) and the Development Team (i.e. POIC systems engineers, developers, testers). This is a process shift in the development, test, and release of software from one that is prescriptive to one that is adaptive, which is necessary for these tools to have longevity. The application of ASD to the product development lifecycle permitted the timely incorporation of customer feedback, and, allowed for continuous quality improvements. This resulted in a suite of tools that are efficient, user-friendly, and enable POIF ground systems to support the increasing pace of payload science operations. ASD is not as much a set of prescriptive processes as it is a shift in mindset; one that moves from planning against change, to planning for change, thereby iteratively growing software towards user-defined value.

Albers, Cerese M.

Splashdown Visualization of Spent Stages

The state of the art for many Earth-to-orbit trajectory analysis toolsets used at NASA is somewhat dated in terms of the languages they are written in and their user interfaces. Many of these programs are written in languages like Fortran or C that are no longer considered modern in the technology industry, and are command-line based without any means of interpreting the data outputs. This presentation is meant to demonstrate a specific use case for a newly developed web app that visualizes the output data for one of these tools. Specifically, one key usage is to investigate and validate launches for notional multi-stage vehicle concepts to various non-standard high-inclination orbits. Some NASA requirements dictate that trajectories be designed such that no surviving debris lands closer than 200 nautical miles (nm) from foreign landmasses or 27 nm from the continental United States, therefore validating re-entry locations of spent stages is an integral part of the launch planning process. In addition, at programmatic levels it can prove insightful and clarifying for the decision-making process to enhance the technical results of numerical simulations with visualizations. The intent with this tool is to provide the mission analyst and program level management with an intuitive and clear grasp of key information on possible mission scenarios either departing from or arriving at Earth, and in the future, the moon or Mars as well. The software tool was developed with an agile development approach and utilizes the latest frameworks and technologies. The front end uses the React JavaScript library for making a state of the art frontend and a backend based on the Django Python framework for handling data using Python’s powerful and free scientific libraries. In addition, the CesiumJS open-source library is key for visualizing these end-to-end trajectories on a high-resolution Earth model. The presentation will demonstrate the current capability and tested use cases.

Jack Agolli

Final Report of the NASA Office of Safety and Mission Assurance Agile Benchmarking Team

To ensure that the NASA Safety and Mission Assurance (SMA) community remains in a position to perform reliable Software Assurance (SA) on NASAs critical software (SW) systems with the software industry rapidly transitioning from waterfall to Agile processes, Terry Wilcutt, Chief, Safety and Mission Assurance, Office of Safety and Mission Assurance (OSMA) established the Agile Benchmarking Team (ABT). The Team's tasks were: 1. Research background literature on current Agile processes, 2. Perform benchmark activities with other organizations that are involved in software Agile processes to determine best practices, 3. Collect information on Agile-developed systems to enable improvements to the current NASA standards and processes to enhance their ability to perform reliable software assurance on NASA Agile-developed systems, 4. Suggest additional guidance and recommendations for updates to those standards and processes, as needed. The ABT's findings and recommendations for software management, engineering and software assurance are addressed herein.

Software Assurance

Team Software Development for Aerothermodynamic and Aerodynamic Analysis and Design

A collaborative approach to software development is described. The approach employs the agile development techniques: project retrospectives, Scrum status meetings, and elements of Extreme Programming to efficiently develop a cohesive and extensible software suite. The software product under development is a fluid dynamics simulator for performing aerodynamic and aerothermodynamic analysis and design. The functionality of the software product is achieved both through the merging, with substantial rewrite, of separate legacy codes and the authorship of new routines. Examples of rapid implementation of new functionality demonstrate the benefits obtained with this agile software development process. The appendix contains a discussion of coding issues encountered while porting legacy Fortran 77 code to Fortran 95, software design principles, and a Fortran 95 coding standard.

Alexandrov, N.

Morpheus: Advancing Technologies for Human Exploration

NASA's Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing. Designed to serve as a vertical testbed (VTB) for advanced spacecraft technologies, the vehicle provides a platform for bringing technologies from the laboratory into an integrated flight system at relatively low cost. This allows individual technologies to mature into capabilities that can be incorporated into human exploration missions. The Morpheus vehicle is propelled by a LOX/Methane engine and sized to carry a payload of 1100 lb to the lunar surface. In addition to VTB vehicles, the Project s major elements include ground support systems and an operations facility. Initial testing will demonstrate technologies used to perform autonomous hazard avoidance and precision landing on a lunar or other planetary surface. The Morpheus vehicle successfully performed a set of integrated vehicle test flights including hot-fire and tethered hover tests, leading up to un-tethered free-flights. The initial phase of this development and testing campaign is being conducted on-site at the Johnson Space Center (JSC), with the first fully integrated vehicle firing its engine less than one year after project initiation. Designed, developed, manufactured and operated in-house by engineers at JSC, the Morpheus Project represents an unprecedented departure from recent NASA programs that traditionally require longer, more expensive development lifecycles and testing at remote, dedicated testing facilities. Morpheus testing includes three major types of integrated tests. A hot-fire (HF) is a static vehicle test of the LOX/Methane propulsion system. Tether tests (TT) have the vehicle suspended above the ground using a crane, which allows testing of the propulsion and integrated Guidance, Navigation, and Control (GN&C) in hovering flight without the risk of a vehicle departure or crash. Morpheus free-flights (FF) test the complete Morpheus system without the additional safeguards provided during tether. A variety of free-flight trajectories are planned to incrementally build up to a fully functional Morpheus lander capable of flying planetary landing trajectories. In FY12, these tests will culminate with autonomous flights simulating a 1 km lunar approach trajectory, hazard avoidance maneuvers and precision landing in a prepared hazard field at the Kennedy Space Center (KSC). This paper describes Morpheus integrated testing campaign, infrastructure, and facilities, and the payloads being incorporated on the vehicle. The Project s fast pace, rapid prototyping, frequent testing, and lessons learned depart from traditional engineering development at JSC. The Morpheus team employs lean, agile development with a guiding belief that technologies offer promise, but capabilities offer solutions, achievable without astronomical costs and timelines.

Olansen, Jon B.

Extreme Programming: Maestro Style

"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Norris, Jeffrey

Integrating Human System Information with the Systems Platform for Aggregating and Relating Capabilities (SPARC)

Within Human Health and Performance, there exists a wealth of human system information that’s used a regular basis in support of NASA human exploration objectives, but the challenge is that all of this information was stored in multiple different locations and organized for specific uses, limiting its effectiveness and straining communication across multiple groups. To address this challenge, our project, the Systems Platform for Aggregating and Relating Capabilities (SPARC) was tasked with developing a new NASA internal web application that aggregates and relates multiple programs’ human system products, such as technical standards, program requirements and verifications, human system risks, research and evidence, and exploration capabilities, into one centralized platform that addresses the needs of human health and performance from multiple different perspectives. Using agile development methodologies, user-experience (UX) driven design principles, data visualization, and a strong emphasis on continuous improvement though consistent stakeholder engagement, the SPARC project released a beta version in less than 4 months, broadly launched version 1.0.0 Agency-wide three months after the beta, and has over 180 users in the first year of development. Our second year of development will see us moving from our initial capabilities to increasingly robust and complex integrations and visualizations, including Directed Acyclical Graphs (DAGs), natural language processing (NLP) for dynamic generation of relationships between the sources of truth, and an expansion into hierarchical levels of system design in support of the human exploration programs.

Data science

Candidate control design metrics for an agile fighter

Success in the fighter combat environment of the future will certainly demand increasing capability from aircraft technology. These advanced capabilities in the form of superagility and supermaneuverability will require special design techniques which translate advanced air combat maneuvering requirements into design criteria. Control design metrics can provide some of these techniques for the control designer. Thus study presents an overview of control design metrics and investigates metrics for advanced fighter agility. The objectives of various metric users, such as airframe designers and pilots, are differentiated from the objectives of the control designer. Using an advanced fighter model, metric values are documented over a portion of the flight envelope through piloted simulation. These metric values provide a baseline against which future control system improvements can be compared and against which a control design methodology can be developed. Agility is measured for axial, pitch, and roll axes. Axial metrics highlight acceleration and deceleration capabilities under different flight loads and include specific excess power measurements to characterize energy meneuverability. Pitch metrics cover both body-axis and wind-axis pitch rates and accelerations. Included in pitch metrics are nose pointing metrics which highlight displacement capability between the nose and the velocity vector. Roll metrics (or torsion metrics) focus on rotational capability about the wind axis.

Murphy, Patrick C.