Search NASA⌕ Search

SEARCH · Search NASA

Results for “software cost cost risk”

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 91 records · Page 5

Managing Technical and Cost Uncertainties During Product Development in a Simulation-Based Design Environment

An approach for objective and quantitative technical and cost risk analysis during product development, which is applicable from the earliest stages, is discussed. The approach is supported by a software tool called the Analytical System for Uncertainty and Risk Estimation (ASURE). Details of ASURE, the underlying concepts and its application history, are provided.

Karandikar, Harsh M.↗

Requirements UML Tool (RUT) Expanded for Extreme Programming (CI02)

A procedure for capturing and managing system requirements that incorporates XP user stories. Because costs associated with identifying problems in requirements increase dramatically over the lifecycle of a project, a method for identifying sources of software risks in user stories is urgently needed. This initiative aims to determine a set of guide-lines for user stories that will result in high-quality requirement. To further this initiative, a tool is needed to analyze user stories that can assess the quality of individual user stories, detect sources cf software risk's, produce software metrics, and identify areas in user stories that can be improved.

McCoy, James R.↗

System Risk Balancing Profiles: Software Component

The Software QA / V&V guide will be reviewed and updated based on feedback from NASA organizations and others with a vested interest in this area. Hardware, EEE Parts, Reliability, and Systems Safety are a sample of the future guides that will be developed. Cost Estimates, Lessons Learned, Probability of Failure and PACTS (Prevention, Avoidance, Control or Test) are needed to provide a more complete risk management strategy. This approach to risk management is designed to help balance the resources and program content for risk reduction for NASA's changing environment.

Kelly, John C.↗

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗

Tutorial: Electrified Aircraft Propulsion Approaches for Modeling and Electrical Hardware-in-the-Loop Testing

This tutorial session outlines capabilities made available by the National Aeronautics and Space Administration for testing electrified aircraft propulsion (EAP) hardware and software prior to using turbomachinery. Removing these components from the experimentation process until necessary significantly reduces the development and testing costs and safety risks. Three facilities, the NASA Electric Aircraft Testbed (NEAT) and the Hybrid Propulsion Emulation Rig (HyPER) are unique facilities that provide the following capabilities: (i) the verification of megawatt-scale electrical and electromechanical system components at altitude, (ii) the verification of EAP control systems on sub-scale representative electromechanical architectures. The importance, operation, and specifications of each facility is described with detail. Provided examples of past testing showcase the abilities of each facility. Simple and complex methods for replicating the steady state and dynamical mechanical loading on the electrical power system are discussed

Electrified Aircraft Propulsion↗

Wallops Ship Surveillance System

Approved as a Wallops control center backup system, the Wallops Ship Surveillance Software is a day-of-launch risk analysis tool for spaceport activities. The system calculates impact probabilities and displays ship locations relative to boundary lines. It enables rapid analysis of possible flight paths to preclude the need to cancel launches and allow execution of launches in a timely manner. Its design is based on low-cost, large-customer- base elements including personal computers, the Windows operating system, C/C++ object-oriented software, and network interfaces. In conformance with the NASA software safety standard, the system is designed to ensure that it does not falsely report a safe-for-launch condition. To improve the current ship surveillance method, the system is designed to prevent delay of launch under a safe-for-launch condition. A single workstation is designated the controller of the official ship information and the official risk analysis. Copies of this information are shared with other networked workstations. The program design is divided into five subsystems areas: 1. Communication Link -- threads that control the networking of workstations; 2. Contact List -- a thread that controls a list of protected item (ocean vessel) information; 3. Hazard List -- threads that control a list of hazardous item (debris) information and associated risk calculation information; 4. Display -- threads that control operator inputs and screen display outputs; and 5. Archive -- a thread that controls archive file read and write access. Currently, most of the hazard list thread and parts of other threads are being reused as part of a new ship surveillance system, under the SureTrak project.

Smith, Donna C.↗

Improving Performance via Energy Efficiency JUSTIFI: Open-Source Software for Identifying and Quantifying Non-Energy Benefits

Energy efficiency is pivotal to achieving operational excellence, as it enhances value while reducing waste. This presentation explores the integration of non-energy benefits (NEBs) into energy efficiency projects, which can lead to risk reduction, value creation, and cost savings. By quantifying NEBs - such as improved safety, decreased pollution, and increased productivity - companies can strengthen their business cases for energy investments, ultimately improving payback periods and aligning with strategic goals. Designed for a diverse audience, from trained auditors to novices in energy assessments, we have developed open-source software called JUSTIFI, NEB finding methodology, and training materials which build on existing frameworks and leverages resources from the U.S. Department of Energy and Better Plants energy system analysis software suite such as MEASUR. This work aims to maximize ROI through NEB identification, utilizing tools like JUSTIFI and the NEBs Discovery Protocol.

97 MATHEMATICS AND COMPUTING↗

IPAD products and implications for the future

The betterment of productivity through the improvement of product quality and the reduction of cost is addressed. Productivity improvement is sought through (1) reduction of required resources, (2) improved ask results through the management of such saved resources, (3) reduced downstream costs through manufacturing-oriented engineering, and (4) lowered risks in the making of product design decisions. The IPAD products are both hardware architecture and software distributed over a number of heterogeneous computers in this architecture. These IPAD products are described in terms of capability and engineering usefulness. The future implications of state-of-the-art IPAD hardware and software architectures are discussed in terms of their impact on the functions and on structures of organizations concerned with creating products.

Miller, R. E., Jr.↗

JPSS Science Data Services for the Direct Readout Community

The Suomi National Polar-orbiting Partnership (S-NPP) and Joint Polar Satellite System (JPSS) High Rate Data (HRD) link provides Direct Broadcast data to users in real-time, utilizing their own remote field terminals. The Field Terminal Support (FTS) provides the resources needed to support the Direct Readout communities by providing software, documentation, and periodic updates to enable them to produce data products from SNPP and JPSS. The FTS distribution server will also provide the necessary ancillary and auxiliary data needed for processing the broadcasts, as well as making orbital data available to assist in locating the satellites of interest. In addition, the FTS provides development support for the algorithm and software through GSFC Direct Readout Laboratory (DRL) International Polar Orbiter Processing Package (IPOPP) and University of Wisconsin (UWISC) Community Satellite Processing Package (CSPP), to enable users to integrate the algorithms into their remote terminals. The support the JPSS Program provides to the institutions developing and maintaining these two software packages, will demonstrate the ability to produce ready-to-use products from the HRD link and provide risk reduction effort at a minimal cost. This paper discusses the key functions and system architecture of FTS.

Data Processing↗

Interdependent figure-of-merit software development

This program was undertaken in order to understand the complex nature of interdependent performance in space missions. At the first step in a planned sequence of progress, a spread sheet program was developed to evaluate different fuel/oxidizer combinations for a specific Martian mission. This program is to be linked with output attained using sophisticated software produced by Gordon and McBride. The programming to date makes use of 11 independent parameters. Optimization is essential when faced with the incredible magnitude of costs, risks, and benefits involved with space exploration. A system of weights needs to be devised on which to measure the options. It was the goal to devise a Figure of Merit (FoM) on which different choices can be presented and made. The plan was to model typical missions to Mars, identify the parameters, and vary them until the best one is found. Initially, most of the focus was placed on propellant selection.

Ramohalli, K.↗

Implementation of Human System Integration Workshop at NASA for Human Spaceflight

The human is a key element in the complex system of systems underlying space exploration missions. As a critical system, its operating bands and requirements need to be characterized and integrated with other systems. Optimal integration of the human system with hardware and software elements has an impact on multiple aspects of mission execution, including human health and performance, risk mitigation, effective design and functionality, enhanced safety, and reduced lifecycle costs. The field of Human Systems Integration (HSI) represents an interdisciplinary and comprehensive cross-cutting approach encompassing technical and management processes for integrating human as a system consideration and objective within and across all other system components and multiple domains. In addition to human activities, HSI covers training, operations and support dimensions. Moreover, HSI is an essential enabler to systems engineering practice, emphasizing human system aspects toward optimizing fully integrated system of systems performance while systematically infusing the needs of all users during the earliest stages of development. Consistent with the National Space Exploration Campaign, NASA is developing the Gateway, a lunar orbiting platform that will serve as astronaut habitat, support transit to deep space, validate new technologies and systems, and function as a science laboratory and communications hub, among other uses. It is an essential element of a phase that will extend human exploration into deep space through evolvable infrastructure and advanced technology, supporting assembly and logistics of other exploration architecture elements. In an effort to explore the current status and forward plan of HSI implementation in the mission (system of systems) lifecycle, the HSI Employee Resource Group conducted an HSI workshop using the Gateway Program as a case study. It revealed how different organizations at the Johnson Space Center incorporate HSI in their processes in preparation for the development and operation of the Gateway. The workshop focused on HSI methodology for implementation of the six NASA HSI domains: Human Factors Engineering, Operations Resources, Habitability and Environment, Maintainability and Supportability, Safety, and Training. Results from the workshop are reported on this paper, as well as some historical background of HSI at NASA, and the success in using an Employee Resource Group to promote technical knowledge. The authors hope that this information can be used to disseminate best practices for translational applications to other space exploration systems.

Silva-Martinez, Jackelynne↗

Implementation of Human System Integration Workshop at NASA for Human Spaceflight

The human is a key element in the complex system of systems underlying space exploration missions. As a critical system, its operating bands and requirements need to be characterized and integrated with other systems. Optimal integration of the human system with hardware and software elements has an impact on multiple aspects of mission execution, including human health and performance, risk mitigation, effective design and functionality, enhanced safety, and reduced lifecycle costs. The field of Human Systems Integration (HSI) represents an interdisciplinary and comprehensive cross-cutting approach encompassing technical and management processes for integrating human as a system consideration and objective within and across all other system components and multiple domains. In addition to human activities, HSI covers training, operations and support dimensions. Moreover, HSI is an essential enabler to systems engineering practice, emphasizing human system aspects toward optimizing fully integrated system of systems performance while systematically infusing the needs of all users during the earliest stages of development. Consistent with the National Space Exploration Campaign, NASA is developing the Gateway, a lunar orbiting platform that will serve as astronaut habitat, support transit to deep space, validate new technologies and systems, and function as a science laboratory and communications hub, among other uses. It is an essential element of a phase that will extend human exploration into deep space through evolvable infrastructure and advanced technology, supporting assembly and logistics of other exploration architecture elements. In an effort to explore the current status and forward plan of HSI implementation in the mission (system of systems) lifecycle, the HSI Employee Resource Group conducted an HSI workshop using the Gateway Program as a case study. It revealed how different organizations at the Johnson Space Center incorporate HSI in their processes in preparation for the development and operation of the Gateway. The workshop focused on HSI methodology for implementation of the six NASA HSI domains: Human Factors Engineering, Operations Resources, Habitability and Environment, Maintainability and Supportability, Safety, and Training. Results from the workshop are reported on this paper, as well as some historical background of HSI at NASA, and the success in using an Employee Resource Group to promote technical knowledge. The authors hope that this information can be used to disseminate best practices for translational applications to other space exploration systems.

Silva-Martinez, Jackelynne↗

Internet Technology on Spacecraft

The Operating Missions as Nodes on the Internet (OMNI) project has shown that Internet technology works in space missions through a demonstration using the UoSAT-12 spacecraft. An Internet Protocol (IP) stack was installed on the orbiting UoSAT-12 spacecraft and tests were run to demonstrate Internet connectivity and measure performance. This also forms the basis for demonstrating subsequent scenarios. This approach provides capabilities heretofore either too expensive or simply not feasible such as reconfiguration on orbit. The OMNI project recognized the need to reduce the risk perceived by mission managers and did this with a multi-phase strategy. In the initial phase, the concepts were implemented in a prototype system that includes space similar components communicating over the TDRS (space network) and the terrestrial Internet. The demonstration system includes a simulated spacecraft with sample instruments. Over 25 demonstrations have been given to mission and project managers, National Aeronautics and Space Administration (NASA), Department of Defense (DoD), contractor technologists and other decisions makers, This initial phase reached a high point with an OMNI demonstration given from a booth at the Johnson Space Center (JSC) Inspection Day 99 exhibition. The proof to mission managers is provided during this second phase with year 2000 accomplishments: testing the use of Internet technologies onboard an actual spacecraft. This was done with a series of tests performed using the UoSAT-12 spacecraft. This spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 6 months! On board software was modified to add an IP stack to support basic IP communications. Also added was support for ping, traceroute and network timing protocol (NTP) tests. These tests show that basic Internet functionality can be used onboard spacecraft. The performance of data was measured to show no degradation from current approaches. The cost to implement is much less than current approaches due to the availability of highly reliable and standard Internet tools. Use of standard Internet applications onboard reduces the risk of obsolescence inherent in custom protocols due to extremely wide use across all domains. These basic building blocks provide the framework for building onboard software to support direct user communication with payloads including payload control. Other benefits are payload to payload communication from dissimilar spacecraft, constellations of spacecraft, and reconfigurability on orbit. This work is funded through contract with the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC).

Rash, James↗

EVA Task and 3D Pose Recognition from Video

Extravehicular Activity (EVA) has been known to involve potential risks of biomechanical stresses and injuries to crewmembers. Gathering of EVA motion patterns is necessary for risk analysis and mitigation. However, many existing techniques, such as motion capture systems, are not only cost-prohibitive but are impractical for retrospective analysis of past missions. In this work, a software tool was developed, which can estimate the 3D poses of a spacesuit from photographs or videos, without using special sensors or equipment. The tool is based on the state-of-the-art artificial intelligence and machine learning (AI/ML) system, which was trained by studying and capturing motion patterns of past and current spacesuit test data. The AI/ML tool was further enhanced using synthetically generated data, in which the suit postures, backgrounds, camera angles and illumination conditions were parametrically adjusted and rendered for training. The tool, incorporated the methodologies of Convolutional Neural Network (CNN), was trained, and tested in the cloud computing environment. The trained model was then applied on new imagery and video to extract estimated joint positions and suit outlines. The joint positions were further processed to capture activity (“digging”), pose labels (“bending”), and other useful downstream information. The model performance on new imagery and video was successfully assessed for accuracy and reliability. This AI/ML based posture recognition tool thus allows for the quantification of injury risk and task performance characterization for both current and past missions and training, which can immensely help to improve EVA task and suit design.

Kyung Han Kim↗

A Cybersecurity Threat Profile for a Connected Lighting System

In this paper we analyze a threat profile performed on a fault-detection use case for streetlights. A threat profile establishes security requirements, justifies security measures, yields actionable controls, and effectively communicates risk to stakeholders. This effort provides critical information for making threat-based decisions to increase security at a reasonable cost, and can effectively be used by development teams, software architects, and managers to make cybersecurity a part of their ongoing culture of awareness, training, and prevention. This leads to more secure systems and better-understood security. On-premise, cloud, and hybrid architectures with different authentication mechanisms were modeled and later categorized using the Microsoft STRIDE framework. An analysis of the recommended controls for each threat was performed to determine which controls could and should be put in place by manufacturers or third-party suppliers, and which controls need to be left up the end-user to implement.

97 MATHEMATICS AND COMPUTING↗

A Cybersecurity Threat Profile for a Connected Lighting System

In anticipation of improved energy performance and cost savings, cities and building owners are increasingly considering “smart lighting initiatives” that aim to convert their collection of simple luminaires (i.e., lighting fixtures) into an intelligent connected lighting system (CLS) capable of remotely monitoring energy consumption and fault conditions, and possibly implementing adaptive lighting schemes. The U.S. Department of Energy (DOE) has set an national goal of tripling the energy efficiency and demand flexibility of the buildings sector by 2030, relative to 2020 levels 1. It is forecast that connected lighting systems can contribute to that goal by delivering 125 TWh of annual energy savings by 2035 2, equivalent to the annual output of 50 typical (500 MW) power plants. However, these energy savings and the DOE goal are put at significant risk if connected technologies are not adopted due to real or perceived cybersecurity concerns. Connected IoT devices such as these have historically been rife with vulnerabilities which sometimes put security considerations secondary to functionality and operability. What are the cybersecurity threats that will impact these systems, as formerly banal luminaires transition into intelligent connected devices that collect information about themselves, their surrounding environment, and possibly us? In this paper we analyze a threat profile performed on a fault-detection use case for streetlights. A threat profile establishes security requirements, justifies security measures, yields actionable controls, and effectively communicates risk to stakeholders. This effort provides critical information for making threat-based decisions to increase security at a reasonable cost, and can effectively be used by development teams, software architects, and managers to make cybersecurity a part of their ongoing culture of awareness, training, and prevention. This leads to more secure systems and better-understood security. On-premise, cloud, and hybrid architectures with different authentication mechanisms were modeled and later categorized using the Microsoft STRIDE framework. An analysis of the recommended controls for each threat was performed to determine which controls could and should be put in place by manufacturers or third-party suppliers, and which controls need to be left up the end-user to implement. Fifty-seven threats were identified. Among our key findings: (1) 65% (37/57) of the threats did not involve the luminaires, but rather the other components needed to communicate with and manage them; (2) 63% (36/57) of the threats could have been mitigated through manufacturer-implemented defensive techniques or “controls”; and (3) 23% (13/57) of the threats were dependent on the network configuration. Recommendations based on the results of this work are made to key stakeholder groups. Notably, lighting technology developers are advised to address all threats that can be reasonably controlled with baked-in technology solutions (e.g., encryption or authentication controls), and employ some form of secure supply chain management and tracking where other parts (e.g., sensors, microprocessors) of a luminaire must also be built and manufactured with the proper security controls in place. Developers should also review threats involving assets not developed in-house to understand how connectivity with other devices will affect their product during system operation and determine if a compensating control for a defense-in-depth strategy will be needed. Finally, those interested in deploying CLS should compare the differences between cloud and on-premise models to determine which is more suitable for their needs and the abilities of their security team.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

COSTMODL: An automated software development cost estimation tool

The cost of developing computer software continues to consume an increasing portion of many organizations' total budgets, both in the public and private sector. As this trend develops, the capability to produce reliable estimates of the effort and schedule required to develop a candidate software product takes on increasing importance. The COSTMODL program was developed to provide an in-house capability to perform development cost estimates for NASA software projects. COSTMODL is an automated software development cost estimation tool which incorporates five cost estimation algorithms including the latest models for the Ada language and incrementally developed products. The principal characteristic which sets COSTMODL apart from other software cost estimation programs is its capacity to be completely customized to a particular environment. The estimation equations can be recalibrated to reflect the programmer productivity characteristics demonstrated by the user's organization, and the set of significant factors which effect software development costs can be customized to reflect any unique properties of the user's development environment. Careful use of a capability such as COSTMODL can significantly reduce the risk of cost overruns and failed projects.

Roush, George B.↗

ARCADE (Advanced Reactor Cyber Analysis and Development Environment)

SAND2025-11780O ARCADE (Advanced Reactor Cyber Analysis and Development Environment) software performs cybersecurity experiments on Defensive Cyber Security Architectures (DCSA) for Distributed Control Systems (DCSs). The application is integrated into a cohesive environment that performs cyber risk analyses and reduces costs. ARCADE can investigate the entire cyber-attack surface of a DCS from the physics of control, down to the firmware of individual components with automated efficiency. ARCADE has five major functional components: the Data Broker system, the virtualization environment, the cyber-attack simulator, the cyber-physical analysis system, and the physics simulator. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Valme, Romuald↗