SEARCH · Engineering Papers

Results for “software lifecycle”

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.

SourceResearch connectionFrom yearThrough year

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

At least 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS2015

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The development of the Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large complex systems engineering challenge being addressed in part by focusing on the specific subsystems handling of off-nominal mission and fault tolerance. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML), the Mission and Fault Management (M&FM) algorithms are crafted and vetted in specialized Integrated Development Teams composed of multiple development disciplines. NASA also has formed an M&FM team for addressing fault management early in the development lifecycle. This team has developed a dedicated Vehicle Management End-to-End Testbed (VMET) that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. The flexibility of VMET enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the algorithms utilizing actual subsystem models. The intent is to validate the algorithms and substantiate them with performance baselines for each of the vehicle subsystems in an independent platform exterior to flight software test processes. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test processes. Risk reduction is addressed by working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and detection and responses that can be tested in VMET and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM. The plan for VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

DOE OSTI2023

Cyber-Informed Engineering Implementation Guide: Version 1.0 [Slides]

This Implementation Guide describes the principles of Cyber-Informed Engineering (CIE) and outlines questions that engineering teams should consider during each phase of a system's lifecycle to effectively employ these principles. It describes what it means to engineer systems in a cyber-informed way, rather than offering a comprehensive, step-by-step process or procedure for CIE implementation. This guide complements - but does not replace - the application of cybersecurity standards or practices currently in place within an organization. Engineers and technicians that design critical energy infrastructure installations can use this Implementation Guide to integrate the 12 principles of CIE into each phase of the engineering lifecycle, from concept to retirement. The guide is aimed at system or design engineers, rather than software engineers or operational cybersecurity practitioners. The engineers who design, build, operate, and maintain the physical infrastructure are best positioned to leverage a system's engineering design to diminish the severity of cyber attacks or digital technology failures. CIE expands cybersecurity decisions into the engineering space, not by asking engineers to become cyber experts, but by calling on engineers to apply engineering tools and make engineering decisions that improve cybersecurity outcomes. CIE examines the engineering consequences that a sophisticated cyber attacker could achieve and drives engineering changes that may provide deterministic mitigations to limit or eliminate those consequences.

24 POWER TRANSMISSION AND DISTRIBUTION↗

DOE OSTI2023

Cyber-Informed Engineering Implementation Guide

This Implementation Guide describes the principles of Cyber-Informed Engineering (CIE) and outlines questions that engineering teams should consider during each phase of a system’s lifecycle to effectively employ these principles. It describes what it means to engineer systems in a cyber-informed way, rather than offering a comprehensive, step-by-step process or procedure for CIE implementation. This guide complements—but does not replace—the application of cybersecurity standards or practices currently in place within an organization. Engineers and technicians that design critical energy infrastructure installations can use this Implementation Guide to integrate the 12 principles of CIE into each phase of the engineering lifecycle, from concept to retirement. The guide is aimed at system or design engineers, rather than software engineers or operational cybersecurity practitioners. The engineers who design, build, operate, and maintain the physical infrastructure are best positioned to leverage a system’s engineering design to diminish the severity of cyber attacks or digital technology failures. CIE expands cybersecurity decisions into the engineering space, not by asking engineers to become cyber experts, but by calling on engineers to apply engineering tools and make engineering decisions that improve cybersecurity outcomes. CIE examines the engineering consequences that a sophisticated cyber attacker could achieve and drives engineering changes that may provide deterministic mitigations to limit or eliminate those consequences.

42 ENGINEERING↗

NASA NTRS2009

Fully Employing Software Inspections Data

Software inspections provide a proven approach to quality assurance for software products of all kinds, including requirements, design, code, test plans, among others. Common to all inspections is the aim of finding and fixing defects as early as possible, and thereby providing cost savings by minimizing the amount of rework necessary later in the lifecycle. Measurement data, such as the number and type of found defects and the effort spent by the inspection team, provide not only direct feedback about the software product to the project team but are also valuable for process improvement activities. In this paper, we discuss NASA's use of software inspections and the rich set of data that has resulted. In particular, we present results from analysis of inspection data that illustrate the benefits of fully utilizing that data for process improvement at several levels. Examining such data across multiple inspections or projects allows team members to monitor and trigger cross project improvements. Such improvements may focus on the software development processes of the whole organization as well as improvements to the applied inspection process itself.

Shull, Forrest↗

NASA NTRS2016

A Structured, Model-Based Systems Engineering Methodology for Operations System Design

Two widely accepted techniques for lowering the cost and risk of developing systems are (1) the use of a defined systems engineering (SE) process or methodology and (2) the reuse of existing (previously built) system components. The first technique is represented, for example, in materials published by NASA (e.g., NASA Systems Engineering Handbook) or by professional societies such as INCOSE (International Council on Systems Engineering). Well-formed SE techniques provide value by establishing the proper scope of the system (e.g., requirements), and by identifying and resolving problems relatively early in project lifecycles, when fixes are less expensive. The second technique (reuse) is applied most commonly to hardware and software; it seeks to avoid replicating design and implementation costs while also reducing risk by placing proven capabilities into operational use. In this paper, we outline a methodology combining these two techniques and extending reuse beyond hardware and software to foundational aspects of a Mission Operation System’s (MOS) design. We describe the system design artifacts that result (e.g., requirements, design documentation), as well as the reusable patterns and elements of the design, and their interrelationships. This approach is enabled by model-based systems engineering (MBSE) techniques and tools and is currently available in SysML form as a plug-in to MagicDraw. Additionally, usage of a rigorous MBSE approach allows for training materials and tutorials to be packaged within the overall model itself. The results of such an approach include decreased cost and risk during the design phase, improved ability of the MOS development team to investigate trade spaces and identify impacts to important flight-ground trade studies. Such results extend into decreased costs and risk in later phases due to improved design, decreased need for late fixes or development of "glue-ware" or scripts to fill unanticipated gaps in functionality, and improved ability to identify and plan testing and other validation activities. Finally, lower operational costs can be expected, both due to improved quality of the MOS, increased ease of maintaining updated knowledge of system configuration, and the fact that training and procedural materials are also updated at the same time as accepted system changes.

Bindschadler, Duane L.↗

DOE OSTI2021

Towards a New Supply Chain Cybersecurity Risk Analysis Technique

Supply chain cyber-attacks, such as the SolarWinds Orion attack, are occurring with greater frequency. These attacks compromise a digital device before it is sent to customers, bypassing traditional security controls to remain persistent and undetected in operational environments. While supply chain attacks are prevalent, methods for analyzing the risk of these attacks are currently unavailable. This paper proposes new supply chain cyber-attack difficulty and risk metrics to evaluate the relative risk of an attack throughout the supply chain lifecycle. Difficulty metrics for each stakeholder in a digital device’s supply chain (e.g., hardware manufacturing, firmware development, software development, storage, and distribution entities) are calculated using scores from cybersecurity maturity questionnaires in a Bayesian Network leaky Noisy-MAX model. These difficulty metrics are then used to calculate an overall supply chain cyber-attack risk. Vulnerability and recoverability metrics are also proposed to evaluate the relative stakeholder influence in the attack risk. These proposed relative risk metrics enable continuous supply chain monitoring, provide decision-makers with information necessary for improved supplier selection, and help drive improvements in the cybersecurity posture of the stakeholders in their supply chain.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRSDate not supplied

Adding a Verification View for Autonomous Real-Time Architecture

Spacecraft software systems continue to increase in complexity and must frequently operate autonomously for extended periods. Thus, the consequences of software flaws are increasing and it is necessary to improve development methods to minimize the risk of latent flaws in the operational software. Traditional software architectures place verification as one element in the development architectural view and treat verification as a later lifecycle activity that is considered complete when the system is certified for flight. The Gateway Vehicle System Manager team, recognizing the importance of verification throughout the system lifecycle, is treating verification as an additional architectural view that receives continuous attention from the requirements analysis phase and continuing for the life of the operational system. The verification view consists of two viewpoints: development and operational. We present background on the verification view and discuss the approaches the Vehicle System Manager team is taking.

James B Dabney↗

NASA NTRS1993

Software forecasting as it is really done: A study of JPL software engineers

This paper presents a summary of the results to date of a Jet Propulsion Laboratory internally funded research task to study the costing process and parameters used by internally recognized software cost estimating experts. Protocol Analysis and Markov process modeling were used to capture software engineer's forecasting mental models. While there is significant variation between the mental models that were studied, it was nevertheless possible to identify a core set of cost forecasting activities, and it was also found that the mental models cluster around three forecasting techniques. Further partitioning of the mental models revealed clustering of activities, that is very suggestive of a forecasting lifecycle. The different forecasting methods identified were based on the use of multiple-decomposition steps or multiple forecasting steps. The multiple forecasting steps involved either forecasting software size or an additional effort forecast. Virtually no subject used risk reduction steps in combination. The results of the analysis include: the identification of a core set of well defined costing activities, a proposed software forecasting life cycle, and the identification of several basic software forecasting mental models. The paper concludes with a discussion of the implications of the results for current individual and institutional practices.

Griesel, Martha Ann↗

NASA NTRS2008

Problem Reporting System

The Problem Reporting System (PRS) is a Web application, running on two Web servers (load-balanced) and two database servers (RAID-5), which establishes a system for submission, editing, and sharing of reports to manage risk assessment of anomalies identified in NASA's flight projects. PRS consolidates diverse anomaly-reporting systems, maintains a rich database set, and incorporates a robust engine, which allows tracking of any hardware, software, or paper process by configuring an appropriate life cycle. Global and specific project administration and setup tools allow lifecycle tailoring, along with customizable controls for user, e-mail, notifications, and more. PRS is accessible via the World Wide Web for authorized user at most any location. Upon successful log-in, the user receives a customizable window, which displays time-critical 'To Do' items (anomalies requiring the user s input before the system moves the anomaly to the next phase of the lifecycle), anomalies originated by the user, anomalies the user has addressed, and custom queries that can be saved for future use. Access controls exist depending on a user's role as system administrator, project administrator, user, or developer, and then, further by association with user, project, subsystem, company, or item with provisions for business-to-business exclusions, limitations on access according to the covert or overt nature of a given project, all with multiple layers of filtration, as needed. Reporting of metrics is built in. There is a provision for proxy access (in which the user may choose to grant one or more other users to view screens and perform actions as though they were the user, during any part of a tracking life cycle - especially useful during tight build schedules and vacations to keep things moving). The system also provides users the ability to have an anomaly link to or notify other systems, including QA Inspection Reports, Safety, GIDEP (Government-Industry Data Exchange Program) Alert, Corrective Actions, and Lessons Learned. The PRS tracking engine was designed as a very extensible and scalable system, able to support additional applications, with future development possibilities already discussed, including Incident Surprise Anomalies (for anomalies occurring during Operations phases of NASA Flight projects), GIDEP and NASA Alerts, and others.

Potter, Don↗

DOE OSTI2023

Cyber-Informed Engineering Principles: What’s in it for me?

CIE is an emerging method to integrate cybersecurity considerations into the conception, design, development, and operation of any physical system that has digital connectivity, monitoring, or control. CIE complements—but does not replace—the application of cybersecurity standards or practices currently in place within an organization. Rather, it expands cybersecurity decisions into the engineering space, not by asking engineers to become cyber experts, but by calling on engineers to apply engineering tools and make engineering decisions that improve cybersecurity outcomes. CIE examines the engineering consequences that a sophisticated cyber attacker could achieve, and drives engineering changes that may provide deterministic mitigations to limit or eliminate those consequences. Engineers and technicians that design critical energy infrastructure installations can integrate the 12 principles of CIE into each phase of the engineering lifecycle, from concept to retirement. These principles are aimed at system or design engineers, operators, and technicians, rather than software engineers or operational cybersecurity practitioners, because the engineers who design, build, operate, and maintain the physical infrastructure are best positioned to leverage a system’s engineering design to diminish the severity of cyber attacks or digital technology failures. This approach creates new opportunities for engineering teams—and not just cybersecurity teams—to secure the system using the physics and mechanics of engineering controls—not just digital monitoring and controls.

99 GENERAL AND MISCELLANEOUS↗

DOE OSTI2026

Integrated System Planning: Emerging Software Requirements in the Power Industry

Power system planning software remains fragmented across organizational boundaries, with specialized tools for capacity expansion, production cost modeling, power flow, and dynamic analysis operating on incompatible data models and assumptions. This article argues that the fragmentation is not merely a technical problem but a predictable consequence of Conway's law: software architectures mirror the departmental structures within which they are developed. Regulatory milestones like Federal Energy Regulatory Commission (FERC) Order 888 formalized these divisions, but the roots trace back to the distinct engineering disciplines-mechanical, chemical, and electrical-that staffed generation and transmission planning departments in vertically integrated utilities. As the industry moves toward integrated system planning (ISP) that coordinates generation, transmission, and distribution investment decisions, the software ecosystem must evolve accordingly. We identify five categories of software requirements to enable this transition: coherent data inputs decoupled from individual applications, unified and extensible data schemas, modular component representations that support multiple abstraction levels, lifecycle management of planning datasets, and well-defined application programming interface (API) contracts that separate data exchange from algorithmic control. We examine how these requirements interact with three common workflow patterns-serial gate clearing, sequential multiapplication, and convergence oriented-and discuss the interface design principles each demands. We then outline a vision for platform-based planning architectures where specialized analytical services compose through standardized interfaces and where artificial intelligence (AI)/machine learning (ML) tools augment decision support within a disciplined software infrastructure. The practices proposed here offer a path from today's siloed tool collections toward collaborative planning ecosystems capable of handling the complexity of modern power system transformation.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS2018

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.↗

NASA NTRS2004

SCDM in a Distributed Environment

The Software Configuration Management (SCM) of the Space Launch Initiative (SLI) Advanced Engineering Environment (AEE) products is performed in a distributed environment-meaning the activities performed during the project lifecycle are across numerous NASA Centers, facilities, organizations, colleges and industry. SCM is the glue that holds the project and products together-especially in a distributed environment. It identifies, controls, accounts, and verified the details of the products; the schedule of activities; the assigned responsibilities; and the required resources, including staff, tools, and computer facilities. Data/document management (DM) captures and conveys the SCM and project efforts. SCM and DM are integrally linked; hence, Software Configuration and Data Management (SCDM). This paper discusses one team's challenges in implementing SCDM in a distributed environment. The distributed nature of the project introduces new opportunities for moving SCDM to the next level of usefulness in today's high-tech development arena. The lessons learned from the implementation of distributed SCDM in support of the SLI AEE Project provide valuable information for future implementations of SCM and DM.

Crowley, Sandra L.↗

NASA NTRS2011

Safety-Critical Partitioned Software Architecture: A Partitioned Software Architecture for Robotic

The flight software on virtually every mission currently managed by JPL has several major flaws that make it vulnerable to potentially fatal software defects. Many of these problems can be addressed by recently developed partitioned operating systems (OS). JPL has avoided adopting a partitioned operating system on its flight missions, primarily because doing so would require significant changes in flight software design, and the risks associated with changes of that magnitude cannot be accepted by an active flight project. The choice of a partitioned OS can have a dramatic effect on the overall system and software architecture, allowing for realization of benefits far beyond the concerns typically associated with the choice of OS. Specifically, we believe that a partitioned operating system, when coupled with an appropriate architecture, can provide a strong infrastructure for developing systems for which reusability, modifiability, testability, and reliability are essential qualities. By adopting a partitioned OS, projects can gain benefits throughout the entire development lifecycle, from requirements and design, all the way to implementation, testing, and operations.

(Avionics Application Standard Software Interface ↗

NASA NTRS2019

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↗

NASA NTRS2019

Implementation of Human System Integration Workshop at NASA for Human Spaceflight

Silva-Martinez, Jackelynne↗

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↗

DOE OSTI2024

Integration of Rucio Metadata in Belle II

Rucio is a Data Management software that has become a de-facto standard in the HEP community and beyond. It allows the management of large volumes of data over their full lifecycle. The Belle II experiment located at KEK (Japan) recently moved to Rucio to manage its data over the coming decade (O(10) PB/year). In addition to its Data Management functionalities, Rucio also provides support for storing generic metadata. Rucio metadata already provides accurate accounting of the data stored all over the sites serving Belle II. Annotating files with generic metadata opens up possibilities for finer-grained metadata query support. We will first introduce some of the new developments aimed at providing good performance that were done to cover Belle II use-cases like bulk insert methods, metadata inheritance, etc. We will then describe the various tests performed to validate Rucio generic metadata at Belle II scale (O(100M) files), detailing the import and performance tests that were made.

97 MATHEMATICS AND COMPUTING↗