Search NASA⌕ Search

SEARCH · Search NASA

Results for “software development management”

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 433 records · Page 24
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

ELISA, a demonstrator environment for information systems architecture design

This paper describes an approach of reusability of software engineering technology in the area of ground space system design. System engineers have lots of needs similar to software developers: sharing of a common data base, capitalization of knowledge, definition of a common design process, communication between different technical domains. Moreover system designers need to simulate dynamically their system as early as possible. Software development environments, methods and tools now become operational and widely used. Their architecture is based on a unique object base, a set of common management services and they host a family of tools for each life cycle activity. In late '92, CNES decided to develop a demonstrative software environment supporting some system activities. The design of ground space data processing systems was chosen as the application domain. ELISA (Integrated Software Environment for Architectures Specification) was specified as a 'demonstrator', i.e. a sufficient basis for demonstrations, evaluation and future operational enhancements. A process with three phases was implemented: system requirements definition, design of system architectures models, and selection of physical architectures. Each phase is composed of several activities that can be performed in parallel, with the provision of Commercial Off the Shelves Tools. ELISA has been delivered to CNES in January 94, currently used for demonstrations and evaluations on real projects (e.g. SPOT4 Satellite Control Center). It is on the way of new evolutions.

Panem, Chantal↗
NASA NTRS1987

Microvax-based data management and reduction system for the regional planetary image facilities

Presented is a progress report for the Regional Planetary Image Facilities (RPIF) prototype image data management and reduction system being jointly implemented by Washington University and the USGS, Flagstaff. The system will consist of a MicroVAX with a high capacity (approx 300 megabyte) disk drive, a compact disk player, an image display buffer, a videodisk player, USGS image processing software, and SYSTEM 1032 - a commercial relational database management package. The USGS, Flagstaff, will transfer their image processing software including radiometric and geometric calibration routines, to the MicroVAX environment. Washington University will have primary responsibility for developing the database management aspects of the system and for integrating the various aspects into a working system.

Arvidson, R.↗
NASA NTRS2009

Conversion from Tree to Graph Representation of Requirements

A procedure and software to implement the procedure have been devised to enable conversion from a tree representation to a graph representation of the requirements governing the development and design of an engineering system. The need for this procedure and software and for other requirements-management tools arises as follows: In systems-engineering circles, it is well known that requirements- management capability improves the likelihood of success in the team-based development of complex systems involving multiple technological disciplines. It is especially desirable to be able to visualize (in order to identify and manage) requirements early in the system- design process, when errors can be corrected most easily and inexpensively.

Mayank, Vimal↗
NASA NTRS2022

Ideas on the NASA Senior Review and Mission Extension Process

Extended mission budgets fund a significant part of our community, particularly young scientists who in a relatively short time are exposed to a broad range of experiences and opportunities available in space science and other STEM fields. In particular, mission-funded science offers a relatively stable funding stream that enables meaningful mentoring efforts and interactions, including apprenticeships ranging from project management, to mission operations, to data processing and analysis, to hardware and software development, to STEM-related education and outreach. It moreover provides professional contacts that fuel diversity in mission leadership and in the science and technical workforce at-large. Last but not least, it sustains the scientific productivity of NASA’s missions, which constitute major national investments meriting their full exploitation. Budgets cuts, however, are exercising pressure on the science and operations of the extended mission fleet despite being only a small portion of the overall Division budget. The history of Heliophysics has demonstrated that maintaining the operation of missions beyond their prime phase invariably leads to a much deeper knowledge of the original mission science goals, together with new applications often not foreseen during their original design. Their operation as part of the Heliophysics System Observatory (HSO)---a coordinated, 1eliophysics, multipoint observing system of the heliosphere, is a prime example. Some of the first activities undertaken by the Parker Solar Probe and Solar Orbiter missions required recreating the larger context of their new observations by using the diversity of HSO mission capabilities. The marginal cost of maintaining this valuable, working science resource, in the form of both continuing high quality data access and expertise, is small compared to the cost of the original missions or of new missions to achieve similar objectives, making the operation of extended missions, the best “science per dollar” investment in Heliophysics. We argue that reducing both extended mission operations and science budgets will have a ripple effect across the community, including reducing employment and training opportunities for young scientists, to lowering the quality/impact of the Heliophysics Systems Observatory. Instead, we suggest that the proposal process for mission extension should be re-examined. We offer several ideas for reducing costs of extended missions toward maintaining science output and streamlining the management process.

A. Vourlidas↗
NASA NTRS1997

Integrity Constraint Monitoring in Software Development: Proposed Architectures

In the development of complex software systems, designers are required to obtain from many sources and manage vast amounts of knowledge of the system being built and communicate this information to personnel with a variety of backgrounds. Knowledge concerning the properties of the system, including the structure of, relationships between and limitations of the data objects in the system, becomes increasingly more vital as the complexity of the system and the number of knowledge sources increases. Ensuring that violations of these properties do not occur becomes steadily more challenging. One approach toward managing the enforcement or system properties, called context monitoring, uses a centralized repository of integrity constraints and a constraint satisfiability mechanism for dynamic verification of property enforcement during program execution. The focus of this paper is to describe possible software architectures that define a mechanism for dynamically checking the satisfiability of a set of constraints on a program. The next section describes the context monitoring approach in general. Section 3 gives an overview of the work currently being done toward the addition of an integrity constraint satisfiability mechanism to a high-level program language, SequenceL, and demonstrates how this model is being examined to develop a general software architecture. Section 4 describes possible architectures for a general constraint satisfiability mechanism, as well as an alternative approach that, uses embedded database queries in lieu of an external monitor. The paper concludes with a brief summary outlining the, current state of the research and future work.

Fernandez, Francisco G.↗
NASA NTRS2014

An Architecture to Enable Autonomous Control of Spacecraft

Autonomy is required for manned spacecraft missions distant enough that light-time communication delays make ground-based mission control infeasible. Presently, ground controllers develop a complete schedule of power modes for all spacecraft components based on a large number of factors. The proposed architecture is an early attempt to formalize and automate this process using on-vehicle computation resources. In order to demonstrate this architecture, an autonomous electrical power system controller and vehicle Mission Manager are constructed. These two components are designed to work together in order to plan upcoming load use as well as respond to unanticipated deviations from the plan. The communication protocol was developed using "paper" simulations prior to formally encoding the messages and developing software to implement the required functionality. These software routines exchange data via TCP/IP sockets with the Mission Manager operating at NASA Ames Research Center and the autonomous power controller running at NASA Glenn Research Center. The interconnected systems are tested and shown to be effective at planning the operation of a simulated quasi-steady state spacecraft power system and responding to unexpected disturbances.

space power systems↗
NASA NTRSDate not supplied

An Agile-Like Approach to Hardware Development: The Ejectable Data Recorder (EDR) for Orion's Ascent Abort 2 (AA-2) Test Flight

On July 2, 2019, the Ascent Abort 2 (AA-2) Flight Test Vehicle was launched from Cape Canaveral, with the goal of demonstrating the performance of Orion’s Launch Abort System (LAS) and collecting data from hundreds of sensors throughout the vehicle. The data collected during this test flight is of paramount importance, as it will be used to certify the Orion vehicle for human spaceflight. Originally, the data was to be downlinked via a single string network of antennas on the LAS, with the associated risk of potential data dropouts, as well as loss of data once the LAS was jettisoned. Thus, additional antennas were added onto the crew module (CM) to support data downlink post-LAS jettison, a buffer rebroadcast capability was added to fill in any gaps in data downlink transmissions, and an ejectable data recorder (EDR) subsystem was added to the CM as a redundant measure to collect all the instrumentation data. The EDR subsystem was added to the project about one year after the project commenced, which significantly reduced the available development time when compared with the other subsystems of the AA-2 Test Flight. The project was further accelerated by six months, around the critical design review gate. Due to the schedule compression challenge and the fact that the EDR subsystem was a backup system and not flight critical, the EDR subsystem was further challenged to find a new and more efficient way to develop hardware. Thus, the EDR subsystem experimented with different management and systems engineering processes, team sizes, communication methods, and tools. Some examples are novel uses of SharePoint as a Data-centric Project Management & Systems Engineering environment, a continuous testing approach through the lifecycle, and a Skunkworks approach to managing the team. The EDR subsystem blended Commercial Off The Shelf (COTS) hardware with in-house developed hardware and software to create a novel data retrieval capability. The capability evolved rapidly through a hardware in the loop simulation environment that enabled incremental component updates for not only the EDR subsystem but across the entire Crew Module. This paper will present an overview of how the EDR subsystem was managed and compare it to an Agile approach to managing projects. The paper will further provide a recommended approach to future Agile-like hardware development that incorporates lessons learned from the EDR experience.

Agile↗
NASA NTRS2010

The Role and Quality of Software Safety in the NASA Constellation Program

In this study, we examine software safety risk in the early design phase of the NASA Constellation spaceflight program. Obtaining an accurate, program-wide picture of software safety risk is difficult across multiple, independently-developing systems. We leverage one source of safety information, hazard analysis, to provide NASA quality assurance managers with information regarding the ongoing state of software safety across the program. The goal of this research is two-fold: 1) to quantify the relative importance of software with respect to system safety; and 2) to quantify the level of risk presented by software in the hazard analysis. We examined 154 hazard reports created during the preliminary design phase of three major flight hardware systems within the Constellation program. To quantify the importance of software, we collected metrics based on the number of software-related causes and controls of hazardous conditions. To quantify the level of risk presented by software, we created a metric scheme to measure the specificity of these software causes. We found that from 49-70% of hazardous conditions in the three systems could be caused by software or software was involved in the prevention of the hazardous condition. We also found that 12-17% of the 2013 hazard causes involved software, and that 23-29% of all causes had a software control. Furthermore, 10-12% of all controls were software-based. There is potential for inaccuracy in these counts, however, as software causes are not consistently scoped, and the presence of software in a cause or control is not always clear. The application of our software specificity metrics also identified risks in the hazard reporting process. In particular, we found a number of traceability risks in the hazard reports may impede verification of software and system safety.

Layman, Lucas↗
NASA NTRS1974

Study on Spacelab software development and integration concepts

A study was conducted to define the complexity and magnitude of the Spacelab software challenge. The study was based on current Spacelab program concepts, anticipated flight schedules, and ground operation plans. The study was primarily directed toward identifying and solving problems related to the experiment flight application and tests and checkout software executing in the Spacelab onboard command and data management subsystem (CDMS) computers and electrical ground support equipment (EGSE). The study provides a conceptual base from which it is possible to proceed into the development phase of the Software Test and Integration Laboratory (STIL) and establishes guidelines for the definition of standards which will ensure that the total Spacelab software is understood prior to entering development.

Source record↗
NASA NTRSDate not supplied

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗
NASA NTRSDate not supplied

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗
DOE OSTI2024

Using containers to speed up development, to run integration tests and to teach about distributed systems

GlideinWMS is a workload manager provisioning resources for many experiments including CMS and DUNE. The software is distributed both as native packages and specialized production containers. Following an approach used in other communities like web development we built our workspaces, system-like containers to ease development and testing. Developers can change the source tree or check out a different branch and quickly reconfigure the services to see the effect of their changes. In this paper, we’ll talk about what differentiates workspaces from other containers. We’ll describe our base system composed of three containers. A one-node cluster including a compute element and a batch system. A GlideinWMS Factory controlling pilot jobs. And a scheduler and Frontend, to submit jobs and provision resources. Additional containers can be used for optional components. This system can easily run on a laptop and we’ll share our evaluation of different container runtimes, with an eye for ease of use and performance. Finally, we’ll talk about our experience as developers and with students. The GlideinWMS workspaces are easily integrated with IDEs like VS Code, simplifying debugging and allowing development and testing of the system also when offline. They simplified the training and onboarding of new team members and Summer interns. And they were useful in workshops where students could have first-hand experience with the mechanisms and components that, in production, run millions of jobs.

Mambelli, Marco↗
DOE OSTI2025

Using Containers to Speed Up Development, to Run Integration Tests and to Teach About Distributed Systems

GlideinWMS is a workload manager provisioning resources for many experiments, including CMS and DUNE. The software is distributed both as native packages and specialized production containers. Following an approach used in other communities like web development, we built our workspaces, system-like containers to ease development and testing. Developers can change the source tree or check out a different branch and quickly reconfigure the services to see the effect of their changes. In this paper, we will talk about what differentiates workspaces from other containers. We will describe our base system, composed of three containers: a one-node cluster including a compute element and a batch system, a GlideinWMS Factory controlling pilot jobs, and a scheduler and Frontend to submit jobs and provision resources. Additional containers can be used for optional components. This system can easily run on a laptop, and we will share our evaluation of different container runtimes, with an eye for ease of use and performance. Finally, we will talk about our experience as developers and with students. The GlideinWMS workspaces are easily integrated with IDEs like VS Code, simplifying debugging and allowing development and testing of the system even when offline. They simplified the training and onboarding of new team members and summer interns. And they were useful in workshops where students could have first-hand experience with the mechanisms and components that, in production, run millions of jobs.

Mambelli, Marco [Fermilab] (ORCID:0000000294892681↗
NASA NTRS1989

Specification of parameters for development of a spatial database for drought monitoring and famine early warning in the African Sahel

Parameters were described for spatial database to facilitate drought monitoring and famine early warning in the African Sahel. The proposed system, referred to as the African Drought and Famine Information System (ADFIS) is ultimately recommended for implementation with the NASA/FEMA Spatial Analysis and Modeling System (SAMS), a GIS/Dymanic Modeling software package, currently under development. SAMS is derived from FEMA'S Integration Emergency Management Information System (IEMIS) and the Pacific Northwest Laborotory's/Engineering Topographic Laboratory's Airland Battlefield Environment (ALBE) GIS. SAMS is primarily intended for disaster planning and resource management applications with the developing countries. Sources of data for the system would include the Developing Economics Branch of the U.S. Dept. of Agriculture, the World Bank, Tulane University School of Public Health and Tropical Medicine's Famine Early Warning Systems (FEWS) Project, the USAID's Foreign Disaster Assistance Section, the World Resources Institute, the World Meterological Institute, the USGS, the UNFAO, UNICEF, and the United Nations Disaster Relief Organization (UNDRO). Satellite imagery would include decadal AVHRR imagery and Normalized Difference Vegetation Index (NDVI) values from 1981 to the present for the African continent and selected Landsat scenes for the Sudan pilot study. The system is initially conceived for the MicroVAX 2/GPX, running VMS. To facilitate comparative analysis, a global time-series database (1950 to 1987) is included for a basic set of 125 socio-economic variables per country per year. A more detailed database for the Sahelian countries includes soil type, water resources, agricultural production, agricultural import and export, food aid, and consumption. A pilot dataset for the Sudan with over 2,500 variables from the World Bank's ANDREX system, also includes epidemiological data on incidence of kwashiorkor, marasmus, other nutritional deficiencies, and synergistically-related infectious diseases.

Rochon, Gilbert L.↗
NASA NTRS1991

Environmental analysis using integrated GIS and remotely sensed data - Some research needs and priorities

This paper discusses some basic scientific issues and research needs in the joint processing of remotely sensed and GIS data for environmental analysis. Two general topics are treated in detail: (1) scale dependence of geographic data and the analysis of multiscale remotely sensed and GIS data, and (2) data transformations and information flow during data processing. The discussion of scale dependence focuses on the theory and applications of spatial autocorrelation, geostatistics, and fractals for characterizing and modeling spatial variation. Data transformations during processing are described within the larger framework of geographical analysis, encompassing sampling, cartography, remote sensing, and GIS. Development of better user interfaces between image processing, GIS, database management, and statistical software is needed to expedite research on these and other impediments to integrated analysis of remotely sensed and GIS data.

Davis, Frank W.↗
NASA NTRS1994

Window-Based Graphics For Scheduling

XOPPS computer program generates window-based graphics for scheduling and planning projects. Provides easy and fast on-screen "what-you-see-is-what-you-get" editing capabilities. Object-oriented, but unique in its capability for creating objects that have date attributes. Can be used in conjunction with project-management software. Written in C language for Sunseries workstations running SunOS. XOPPS was developed in 1992, based on the Sunview version of OPPS (NPO-18439) developed in 1990. It is copyrighted work with all copyright vested in NASA.

Mulnix, Cassie↗
NASA NTRS1994

The ground vehicle manager's associate

An overview of MAX, a software framework for manager's associate systems, is presented. MAX is used to develop and execute a problem-solving strategy for the task planning of semi-autonomous agents with the assistance of human performance. This paper describes the use of MAX in the supervisory management of robotic vehicles as they explore a planetary surface.

Edwards, Gary R.↗