Search NASA⌕ Search

SEARCH · Search NASA

Results for “systems engineering software architecture”

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 469 records · Page 26

A Space Based Internet Protocol System for Sub-Orbital Tracking and Control

Personnel from the Goddard Space Flight Center Wallops Flight Facility (GSFC/WFF) in Virginia are responsible for the overall management of the NASA Sounding Rocket Program. Payloads are generally in support of NASA's Space Science Enterprise's missions and return a variety of scientific data as well as providing a reasonably economical means of conducting engineering tests for instruments and devices used on satellites and other spacecraft. The fifteen types of sounding rockets used by NASA can carry payloads of various weights to altitudes from 50 km to more than 1,300 km. Launch activities are conducted not only from established missile ranges, but also from remote locations worldwide requiring mobile tracking and command equipment to be transported and set up at considerable expense. The advent of low earth orbit (LEO) commercial communications satellites provides an opportunity to dramatically reduce tracking and control costs of launch vehicles and Unpiloted Aerial Vehicles (UAVs) by reducing or eliminating this ground infrastructure. Additionally, since data transmission is by packetized Internet Protocol (IP), data can be received and commands initiated from practically any location. A low cost Commercial Off The Shelf (COTS) system is currently under development for sounding rockets which also has application to UAVs and scientific balloons. Due to relatively low data rate (9600 baud) currently available, the system will first be used to provide GPS data for tracking and vehicle recovery. Range safety requirements for launch vehicles usually stipulate at least two independent tracking sources. Most sounding rockets flown by NASA now carry GPS receivers that output position data via the payload telemetry system to the ground station. The Flight Modem can be configured as a completely separate link thereby eliminating requirement for tracking radar. The system architecture which integrates antennas, GPS receiver, commercial satellite packet data modem, and a single board computer with custom software is described along with the technical challenges and the plan for their resolution. These include antenna development, high Doppler rates, reliability, environmental ruggedness, hand over between satellites and data security. An aggressive test plan is included which in addition to environmental testing measures bit error rate, latency and antenna patterns. Actual flight tests are planned for the near future on aircraft, long duration balloons and sounding rockets and these results as well as the current status of the project are reported.

Bull, Barton↗

Approach-Phase Precision Landing with Hazard Relative Navigation: Terrestrial Test Campaign Results of the Morpheus/ALHAT Project

The Morpheus Project began in late 2009 as an ambitious e ort code-named Project M to integrate three ongoing multi-center NASA technology developments: humanoid robotics, liquid oxygen/liquid methane (LOX/LCH4) propulsion and Autonomous Precision Landing and Hazard Avoidance Technology (ALHAT) into a single engineering demonstration mission to be own to the Moon by 2013. The humanoid robot e ort was redirected to a deploy- ment of Robonaut 2 on the International Space Station in February of 2011 while Morpheus continued as a terrestrial eld test project integrating the existing ALHAT Project's tech- nologies into a sub-orbital ight system using the world's rst LOX/LCH4 main propulsion and reaction control system fed from the same blowdown tanks. A series of 33 tethered tests with the Morpheus 1.0 vehicle and Morpheus 1.5 vehicle were conducted from April 2011 - December 2013 before successful, sustained free ights with the primary Vertical Testbed (VTB) navigation con guration began with Free Flight 3 on December 10, 2013. Over the course of the following 12 free ights and 3 tethered ights, components of the ALHAT navigation system were integrated into the Morpheus vehicle, operations, and ight control loop. The ALHAT navigation system was integrated and run concurrently with the VTB navigation system as a reference and fail-safe option in ight (see touchdown position esti- mate comparisons in Fig. 1). Flight testing completed with Free Flight 15 on December 15, 2014 with a completely autonomous Hazard Detection and Avoidance (HDA), integration of surface relative and Hazard Relative Navigation (HRN) measurements into the onboard dual-state inertial estimator Kalman lter software, and landing within 2 meters of the VTB GPS-based navigation solution at the safe landing site target. This paper describes the Mor- pheus joint VTB/ALHAT navigation architecture, the sensors utilized during the terrestrial ight campaign, issues resolved during testing, and the navigation results from the ight tests.

Crain, Timothy P.↗

Methodology for Designing Fault-Protection Software

A document describes a methodology for designing fault-protection (FP) software for autonomous spacecraft. The methodology embodies and extends established engineering practices in the technical discipline of Fault Detection, Diagnosis, Mitigation, and Recovery; and has been successfully implemented in the Deep Impact Spacecraft, a NASA Discovery mission. Based on established concepts of Fault Monitors and Responses, this FP methodology extends the notion of Opinion, Symptom, Alarm (aka Fault), and Response with numerous new notions, sub-notions, software constructs, and logic and timing gates. For example, Monitor generates a RawOpinion, which graduates into Opinion, categorized into no-opinion, acceptable, or unacceptable opinion. RaiseSymptom, ForceSymptom, and ClearSymptom govern the establishment and then mapping to an Alarm (aka Fault). Local Response is distinguished from FP System Response. A 1-to-n and n-to- 1 mapping is established among Monitors, Symptoms, and Responses. Responses are categorized by device versus by function. Responses operate in tiers, where the early tiers attempt to resolve the Fault in a localized step-by-step fashion, relegating more system-level response to later tier(s). Recovery actions are gated by epoch recovery timing, enabling strategy, urgency, MaxRetry gate, hardware availability, hazardous versus ordinary fault, and many other priority gates. This methodology is systematic, logical, and uses multiple linked tables, parameter files, and recovery command sequences. The credibility of the FP design is proven via a fault-tree analysis "top-down" approach, and a functional fault-mode-effects-and-analysis via "bottoms-up" approach. Via this process, the mitigation and recovery strategy(s) per Fault Containment Region scope (width versus depth) the FP architecture.

Barltrop, Kevin↗

Development of a Ground Test and Analysis Protocol for NASA's NextSTEP Phase 2 Habitation Concepts

The NASA Next Space Technologies for Exploration Partnerships (NextSTEP) program is a public-private partnership model that seeks commercial development of deep space exploration capabilities to support human spaceflight missions around and beyond cislunar space. NASA first issued the Phase 1 NextSTEP Broad Agency Announcement to U.S. industries in 2014, which called for innovative cislunar habitation concepts that leveraged commercialization plans for low-Earth orbit. These habitats will be part of the Deep Space Gateway (DSG), the cislunar space station planned by NASA for construction in the 2020s. In 2016, Phase 2 of the NextSTEP program selected five commercial partners to develop ground prototypes. A team of NASA research engineers and subject matter experts (SMEs) have been tasked with developing the ground-test protocol that will serve as the primary means by which these Phase 2 prototypes will be evaluated. Since 2008, this core test team has successfully conducted multiple spaceflight analog mission evaluations utilizing a consistent set of operational tools, methods, and metrics to enable the iterative development, testing, analysis, and validation of evolving exploration architectures, operations concepts, and vehicle designs. The purpose of implementing a similar evaluation process for the Phase 2 Habitation Concepts is to consistently evaluate different commercial partner ground prototypes to provide data-driven, actionable recommendations for Phase 3. This paper describes the process by which the ground test protocol was developed and the objectives, methods, and metrics by which the NextSTEP Phase 2 Habitation Concepts will be rigorously and systematically evaluated. The protocol has been developed using both a top-down and bottom-up approach. Top-down development began with the Human Exploration and Operations Mission Directorate (HEOMD) exploration objectives and ISS Exploration Capability Study Team (IECST) candidate flight objectives. Strategic questions and associated rationales, derived from these candidate architectural objectives, provide the framework by which the ground-test protocol will address the DSG stack elements and configurations, systems and subsystems, and habitation, science, and EVA functions. From these strategic questions, high-level functional requirements for the DSG were drafted and associated ground-test objectives and analysis protocols were established. Bottom-up development incorporated objectives from NASA SMEs in autonomy, avionics and software, communication, environmental control and life support systems, exercise, extravehicular activity, exploration medical operations, guidance navigation and control, human factors and behavioral performance, human factors and habitability, logistics, Mission Control Center operations, power, radiation, robotics, safety and mission assurance, science, simulation, structures, thermal, trash management, and vehicle health. Top-down and bottom-up objectives were integrated to form overall functional requirements - ground-test objectives and analysis mapping. From this mapping, ground-test objectives were organized into those that will be evaluated through inspection, demonstration, analysis, subsystem standalone testing, and human-in-the-loop (HITL) testing. For the HITL tests, mission-like timelines, procedures, and flight rules have been developed to directly meet ground test objectives and evaluate specific functional requirements. Data collected from these assessments will be analyzed to determine the acceptability of habitation element configurations and the combinations of capabilities that will result in the best habitation platform to be recommended by the test team for Phase 3.

Gernhardt, Michael L.↗

C++ Resource Intelligent Compilation for GPU Enabled Applications

We are nearing the limits of Moore's Law with current computing technology. As industries push for more performance from smaller systems, alternate methods of computation such as Graphics Processing Units (GPUs) should be considered. Many of these systems utilize the Compute Unified Device Architecture (CUDA) to give programmers access to individual compute elements of the GPU for general purpose computing tasks. Direct access to the GPU's parallel multi-core architecture enables highly efficient computation and can drastically reduce the time required for complex algorithms or data analysis. Of course not all systems have a CUDA-enabled device to leverage, and so applications must consider optional support for users with these devices. Resource Intelligent Compilation (RIC) addresses this situation by enabling GPU-based acceleration of existing applications without affecting users without GPUs. Resource Intelligent Compilation (RIC) creates C/C++ modules that can be compiled to create a standard CPU version or GPU accelerated version of a program, depending on hardware availability. This is accomplished through a toolbox of programming strategies based on features of the CUDA API. Using this toolbox, existing applications can be modified with ease to support GPU acceleration, and new applications can be generated with just a few simple modifications. All of this culminates in an accelerated application for users with the appropriate hardware, with no performance impact to standard systems. This memorandum presents all the important features involved in supporting and implementing RIC and an example of using RIC to accelerate an existing mathematical model, without removing support for standard users. Through this memorandum, NASA engineers can acquire a set of guidelines to follow for RIC-compliant development, seamlessly accelerating C/C++ applications.

GPU↗

A Space Based Internet Protocol System for Launch Vehicle Tracking and Control

Personnel from the Goddard Space Flight Center Wallops Flight Facility (GSFC/WFF) in Virginia are responsible for the overall management of the NASA Sounding Rocket and Scientific Balloon Programs. Payloads are generally in support of NASA's Space Science Enterprise's missions and return a variety of scientific data as well as providing a reasonably economical means of conducting engineering tests for instruments and devices used on satellites and other spacecraft. Sounding rockets used by NASA can carry payloads of various weights to altitudes from 50 km to more than 1,300 km. Scientific balloons can carry a payload weighing as much as 3,630 Kg to an altitude of 42 km. Launch activities for both are conducted not only from established ranges, but also from remote locations worldwide requiring mobile tracking and command equipment to be transported and set up at considerable expense. The advent of low earth orbit (LEO) commercial communications satellites provides an opportunity to dramatically reduce tracking and control costs of these launch vehicles and Unpiloted Aerial Vehicles (UAVs) by reducing or eliminating this ground infrastructure. Additionally, since data transmission is by packetized Internet Protocol (IP), data can be received and commands initiated from practically any location. A low cost Commercial Off The Shelf (COTS) system is currently under development for sounding rockets that also has application to UAVs and scientific balloons. Due to relatively low data rate (9600 baud) currently available, the system will first be used to provide GPS data for tracking and vehicle recovery. Range safety requirements for launch vehicles usually stipulate at least two independent tracking sources. Most sounding rockets flown by NASA now carry GP~ receivers that output position data via the payload telemetry system to the ground station. The Flight Modem can be configured as a completely separate link thereby eliminating the requirement for tracking radar. The system architecture that integrates antennas, GPS receiver, commercial satellite packet data modem, and a single board computer with custom software is described along with the technical challenges and the plan for their resolution. These include antenna development, high Doppler rates, reliability, environmental ruggedness, hand over between satellites, and data security. An aggressive test plan is included which, in addition to environmental testing, measures bit error rate, latency and antenna patterns. Actual launches on a sounding rocket and various aircraft flights have taken place. Flight tests are planned for the near future on aircraft, long duration balloons and sounding rockets. These results, as well as the current status of the project, are reported.

Bull, Barton↗

Streamlining GNC Architecture Development and FSW Integration for the Mars Ascent Vehicle

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface of another atmospheric planetary body outside of the Earth-Moon system. Significant light-time delay requires complete autonomy of flight throughout ascent, and naturally a high level of reliability is desired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls (GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiency of algorithm integration onto the MAV flight processor, and to increase confidence that said integration is successful and without human error. An interface architecture is proposed for the GNC suite that allows both the guidance and navigation subsystems to provide code algorithms directly in C++, and the controls subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code from the GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendly wrapper which abstracts the integration of the GNC algorithm code into an interface-level API that is compatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSW team’s partnership, and this strong interface between these two teams have allowed the GNC/FSW teams to greatly increase confidence of efficient and error-free implementation of the GNC code onto MAV for a successful flight.

Engineering↗

Prototype and Evaluation of AutoHelp: A Case-based, Web-accessible Help Desk System for EOSDIS

AutoHelp is a case-based, Web-accessible help desk for users of the EOSDIS. Its uses a combination of advanced computer and Web technologies, knowledge-based systems tools, and cognitive engineering to offload the current, person-intensive, help desk facilities at the DAACs. As a case-based system, AutoHelp starts with an organized database of previous help requests (questions and answers) indexed by a hierarchical category structure that facilitates recognition by persons seeking assistance. As an initial proof-of-concept demonstration, a month of email help requests to the Goddard DAAC were analyzed and partially organized into help request cases. These cases were then categorized to create a preliminary case indexing system, or category structure. This category structure allows potential users to identify or recognize categories of questions, responses, and sample cases similar to their needs. Year one of this research project focused on the development of a technology demonstration. User assistance 'cases' are stored in an Oracle database in a combination of tables linking prototypical questions with responses and detailed examples from the email help requests analyzed to date. When a potential user accesses the AutoHelp system, a Web server provides a Java applet that displays the category structure of the help case base organized by the needs of previous users. When the user identifies or requests a particular type of assistance, the applet uses Java database connectivity (JDBC) software to access the database and extract the relevant cases. The demonstration will include an on-line presentation of how AutoHelp is currently structured. We will show how a user might request assistance via the Web interface and how the AutoHelp case base provides assistance. The presentation will describe the DAAC data collection, case definition, and organization to date, as well as the AutoHelp architecture. It will conclude with the year 2 proposal to more fully develop the case base, the user interface (including the category structure), interface with the current DAAC Help System, the development of tools to add new cases, and user testing and evaluation at (perhaps) the Goddard DAAC.

Mitchell, Christine M.↗

NextSTEP Appendix A Modular ECLSS Effort Lessons Learned

NASA’s Artemis program provides the first steps for earth-independent exploration starting with crewed habitats in cislunar space and progressing toward crewed landings on the lunar surface that will prepare systems and crews for the exploration of Mars. The Next Space Technology for Exploration Partnerships (NextSTEP) is a public-private partnership model that facilitates commercial development of deep space exploration capabilities in support of more extensive human spaceflight missions in and beyond cislunar space. NASA issued the original NextSTEP Broad Agency Announcement (BAA) to U.S. industry in late 2014 and issued the second BAA (NextSTEP-2) in April 2016. The first appendix under NextSTEP-2, Appendix A, focused on developing deep space habitation concepts, engineering design and development, and risk reduction efforts leading to a habitation capability in cislunar space. NASA solicited concepts to develop and refine the evolvable, modular architecture, functional allocation options, standards, and common interfaces required to enable interoperability of the aggregate system to provide long duration deep space transit habitation, specifically enhancements and testing of deep space Environmental Control and Life Support Systems (ECLSS). Collins Aerospace, formerly UTC Aerospace Systems (UTAS), was awarded a Phase 1 and subsequent Phase 2 contract to “develop concepts that group ECLS systems into logical modules maximizing the use of common components and the development of unique methods and design concepts that support in-flight maintenance and repair for future exploration systems.” This paper summarizes the work accomplished under this effort, the lessons that can be applied to development of forthcoming habitation elements, and the gaps remaining to achieve a more resilient, maintainable, repairable and adaptable system capable of installation on a wide variety of habitat platforms. A primary accomplishment of this effort is the development and maturation of a modular palletization concept to enable standard rack interfaces, post-launch outfitting, and decoupling of structural supports that withstand launch environments from those needed for lower on-orbit loads in order to reduce installed mass and repurposing of panels within the habitat. In the course of the effort, Collins assessed numerous architecture trades, including the use of condensing and noncondensing heat exchangers, the ability of modular units to accommodate various habitat volumes and thermal loading, and the most appropriate order of and timing of delivery of regenerative ECLSS hardware to orbital habitats. In addition to the modularity of hardware elements, Collins developed software approaches for distributed/modular command, control, and communication systems and innovative Bayesian fault detection and isolation techniques. Finally, the effort explored advanced maintainability and supportability concepts including the definition of maintenance units (MUs) in place of the traditional Orbital Replacement Units (ORUs), increasing parts commonality to reduce the number and type of spare parts, the use of augmented reality to guide crews during maintenance and repair procedures, and how crews would prepare for and recover from long durations of habitat dormancy. Now that the NextSTEP Modular ECLSS effort has come to a close, it’s important to identify the lessons learned and where they can be leveraged to improve NASA’s broader program of ECLSS technology development and demonstration and ultimately how they can increase the performance of future surface and orbital habitats.

NextSTEP↗

NextSTEP Appendix A Modular ECLSS Effort Lessons Learned

NASA’s Artemis program provides the first steps for earth-independent exploration starting with crewed habitats in cislunar space and progressing toward crewed landings on the lunar surface that will prepare systems and crews for the exploration of Mars. The Next Space Technology for Exploration Partnerships (NextSTEP) is a public-private partnership model that facilitates commercial development of deep space exploration capabilities in support of more extensive human spaceflight missions in and beyond cislunar space. NASA issued the original NextSTEP Broad Agency Announcement (BAA) to U.S. industry in late 2014 and issued the second BAA (NextSTEP-2) in April 2016. The first appendix under NextSTEP-2, Appendix A, focused on developing deep space habitation concepts, engineering design and development, and risk reduction efforts leading to a habitation capability in cislunar space. NASA solicited concepts to develop and refine the evolvable, modular architecture, functional allocation options, standards, and common interfaces required to enable interoperability of the aggregate system to provide long duration deep space transit habitation, specifically enhancements and testing of deep space Environmental Control and Life Support Systems (ECLSS). Collins Aerospace, formerly UTC Aerospace Systems (UTAS), was awarded a Phase 1 and subsequent Phase 2 contract to “develop concepts that group ECLS systems into logical modules maximizing the use of common components and the development of unique methods and design concepts that support in-flight maintenance and repair for future exploration systems.” This paper summarizes the work accomplished under this effort, the lessons that can be applied to development of forthcoming habitation elements, and the gaps remaining to achieve a more resilient, maintainable, repairable and adaptable system capable of installation on a wide variety of habitat platforms. A primary accomplishment of this effort is the development and maturation of a modular palletization concept to enable standard rack interfaces, post-launch outfitting, and decoupling of structural supports that withstand launch environments from those needed for lower on-orbit loads in order to reduce installed mass and repurposing of panels within the habitat. In the course of the effort, Collins assessed numerous architecture trades, including the use of condensing and noncondensing heat exchangers, the ability of modular units to accommodate various habitat volumes and thermal loading, and the most appropriate order of and timing of delivery of regenerative ECLSS hardware to orbital habitats. In addition to the modularity of hardware elements, Collins developed software approaches for distributed/modular command, control, and communication systems and innovative Bayesian fault detection and isolation techniques. Finally, the effort explored advanced maintainability and supportability concepts including the definition of maintenance units (MUs) in place of the traditional Orbital Replacement Units (ORUs), increasing parts commonality to reduce the number and type of spare parts, the use of augmented reality to guide crews during maintenance and repair procedures, and how crews would prepare for and recover from long durations of habitat dormancy. Now that the NextSTEP Modular ECLSS effort has come to a close, it’s important to identify the lessons learned and where they can be leveraged to improve NASA’s broader program of ECLSS technology development and demonstration and ultimately how they can increase the performance of future surface and orbital habitats.

NextSTEP↗

Machine Learning–Guided Boolean Matrix Inference for Real-Time O-RAN Conflict Detection

Open Radio Access Networks (O-RAN) are emerging, software-driven cellular architectures that promote flexibility by enabling components from different vendors to interoperate. Multiple control applications called xApps can independently adjust network parameters in near real time, often without awareness of each other's actions. This creates a system highly prone to unintended conflicts and performance degradation due to the inherent complexity of such openness. To model such systems and ultimately prevent or mitigate xApp conflicts, it is essential to understand the dynamic relationships between xApps (A), the control parameters they adjust (P), and the resulting KPI responses (K). While the mappings from A to P and from K to A can often be derived from xApp specifications, the relationship from P to K is typically hidden within the system’s dynamics and must be inferred from observed data. We propose a novel data-driven Boolean inference framework that uncovers the hidden P?K dependencies using machine learning and interpretable rule induction. Continuous parameters and KPIs are first binarized using decision tree classifiers, and a binary influence matrix L is then inferred by solving Boolean matrix equations over time. This compact representation improves interpretability and enables real-time tracking of dynamically evolving parameter-KPI dependencies. We demonstrate the effectiveness of our method in a realistic mobile handover scenario, where it accurately recovers the underlying logic and enables proactive conflict detection.

42 - ENGINEERING↗

Modeling Constellation Virtual Missions Using the Vdot(Trademark) Process Management Tool

The authors have identified a software tool suite that will support NASA's Virtual Mission (VM) effort. This is accomplished by transforming a spreadsheet database of mission events, task inputs and outputs, timelines, and organizations into process visualization tools and a Vdot process management model that includes embedded analysis software as well as requirements and information related to data manipulation and transfer. This paper describes the progress to date, and the application of the Virtual Mission to not only Constellation but to other architectures, and the pertinence to other aerospace applications. Vdot s intuitive visual interface brings VMs to life by turning static, paper-based processes into active, electronic processes that can be deployed, executed, managed, verified, and continuously improved. A VM can be executed using a computer-based, human-in-the-loop, real-time format, under the direction and control of the NASA VM Manager. Engineers in the various disciplines will not have to be Vdot-proficient but rather can fill out on-line, Excel-type databases with the mission information discussed above. The author s tool suite converts this database into several process visualization tools for review and into Microsoft Project, which can be imported directly into Vdot. Many tools can be embedded directly into Vdot, and when the necessary data/information is received from a preceding task, the analysis can be initiated automatically. Other NASA analysis tools are too complex for this process but Vdot automatically notifies the tool user that the data has been received and analysis can begin. The VM can be simulated from end-to-end using the author s tool suite. The planned approach for the Vdot-based process simulation is to generate the process model from a database; other advantages of this semi-automated approach are the participants can be geographically remote and after refining the process models via the human-in-the-loop simulation, the system can evolve into a process management server for the actual process.

Hardy, Roger↗

Enabling Wireless Avionics Intra-Communications

The Electromagnetics and Sensors Branch of NASA Langley Research Center (LaRC) is investigating the potential of an all-wireless aircraft as part of the ECON (Efficient Reconfigurable Cockpit Design and Fleet Operations using Software Intensive, Networked and Wireless Enabled Architecture) seedling proposal, which is funded by the Convergent Aeronautics Solutions (CAS) project, Transformative Aeronautics Concepts (TAC) program, and NASA Aeronautics Research Institute (NARI). The project consists of a brief effort carried out by a small team in the Electromagnetic Environment Effects (E3) laboratory with the intention of exposing some of the challenges faced by a wireless communication system inside the reflective cavity of an aircraft and to explore potential solutions that take advantage of that environment for constructive gain. The research effort was named EWAIC for "Enabling Wireless Aircraft Intra-communications." The E3 laboratory is a research facility that includes three electromagnetic reverberation chambers and equipment that allow testing and generation of test data for the investigation of wireless systems in reflective environments. Using these chambers, the EWAIC team developed a set of tests and setups that allow the intentional variation of intensity of a multipath field to reproduce the environment of the various bays and cabins of large transport aircraft. This setup, in essence, simulates an aircraft environment that allows the investigation and testing of wireless communication protocols that can effectively be used as a tool to mitigate some of the risks inherent to an aircraft wireless system for critical functions. In addition, the EWAIC team initiated the development of a computational modeling tool to illustrate the propagation of EM waves inside the reflective cabins and bays of aircraft and to obtain quantifiable information regarding the degradation of signals in aircraft subassemblies. The nose landing gear of a UAV CAD model was used to model the propagation of a system in a "deployed" configuration versus a "stowed" configuration. The differences in relative field strength provide valuable information about the distribution of the field that can be used to engineer RF links with optimal radiated power and antenna configuration that accomplish the intended system reliability. Such modeling will be necessary in subsequent studies for managing multipath propagation characteristics inside a main cabin and to understand more complex environments, such as the inside wings, landing gear bays, cargo bays, avionics bays, etc. The results of the short research effort are described in the present document. The team puts forth a set of recommendations with the intention of informing the project and program leadership of the future work that, in the opinion of the EWAIC team, would assist the ECON team reach the intended goal of developing an all-wireless aircraft.

Torres, Omar↗

A cross-platform execution engine for the quantum intermediate representation

Hybrid languages like the quantum intermediate representation (QIR) are essential for programming systems that mix quantum and conventional computing models, while execution of these programs is often deferred to a system-specific implementation. Here, we develop the QIR Execution Engine (QIR-EE) for parsing, interpreting, and executing QIR across multiple hardware platforms. QIR-EE uses LLVM to execute hybrid instructions specifying quantum programs and, by design, presents extension points that support customized runtime and hardware environments. We demonstrate an implementation that uses the XACC quantum hardware-accelerator library to dispatch prototypical quantum programs on different commercial quantum platforms and numerical simulators, and we validate execution of QIR-EE on IonQ, Quantinuum, and IBM hardware. Our results highlight the efficiency of hybrid executable architectures for handling mixed instructions, managing mixed data, and integrating with quantum computing frameworks to realize cross-platform execution.

LLVM↗

Towards a Decision Support System for Space Flight Operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The discrepancy of the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the three increments of this vision. These increments include (1) hardware and software system components and interfaces with the NASA ground system, (2) uncertainty management and (3) re-planning and automated execution. Each of these increments provide value independently; but some may also enable building of a subsequent increment.

Meshkat, Leila↗

Towards a decision support system for space flight operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The differences between the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the four increments of this vision. These increments include (1) the existing capabilities (2) hardware and software system components and interfaces with the NASA ground system, (3) uncertainty management and (4) re-planning and automated execution. Each of these increments provides value independently; but some may also enable building of a subsequent increment.

Ruszkowski, James↗

Enhancing Cloud Cybersecurity: Prescriptive Controls for Operational Technology

This whitepaper provides strategic insights and recommendations into security cloud-based solutions for electric utilities, encompassing operational technology (OT), virtual power plants (VPP), distributed energy resources (DERs), applications, networks, and data storage as they transition to and leverage cloud infrastructure through managed service providers (MSPs) and cloud service providers (CSPs). Principles derived from established frameworks serve as a foundation for best practices across cybersecurity projects and remove the constraints of settling on a single framework. For organizations that prefer not to integrate a specific framework altogether, elements of the proposed approach could be adopted or tailored to best fit defined requirements and expected functionalities. The Cirrus assessment, a utility cloud feasibility tool, and the roadmap it provides serve as a precursor to this paper, which seeks to be a valuable resource for defining next steps following cloud technology integration feasibility appraisal. With its comprehensive approach to adoption, the Cirrus framework offers strategic guidance on responsibly preparing for or deploying a utility cloud solution. The previously published whitepaper, “Use Case-Informed Framework for Utility Cloud Migration,” details the guiding strategy, research, and deployment of cloud solutions within electric and interconnected grid systems. Before implementing the controls suggested in this document, it is recommended that stakeholders complete Cirrus's cloud integration assessment and pair the results with their unique cybersecurity controls to form a comprehensive cloud-based utility cybersecurity plan. The Cirrus outcome will consider a series of future architectures for the grid before and after the energy transition and evaluate the arguments for and against cloud applications for each electric and interconnected grid layer. This document is a companion to the original whitepaper, "Use Case-Informed Framework for Utility Cloud Migration" to further identify and recommend security controls based on Cirrus’s cloud integration assessment output. The following whitepaper outlines the cybersecurity controls that secure cloud-service models pertinent to the electric sector using the predefined categories identify, protect, detect, and respond and recover. The objective is to outline prescriptive security controls based on the type of architecture and data stored in the cloud. The focus includes dissecting the shared responsibility model and elucidating what on-premises Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) entail. A pivotal consideration in this context is allocating responsibility for foundational cybersecurity aspects—having used Cirrus for the cloud integration assessment. The ensuing controls detailed herein also represent a checklist of controls necessary for a secure cloud transition, equipping utilities with the knowledge to navigate this digital transformation with confidence and strategic foresight in a safe and responsible manner.

42 ENGINEERING↗

Evolution and Reengineering of NASA's Flight Dynamics Facility (FDF)

The NASA Goddard Space Flight Center's Flight Dynamics Facility (FDF) is a multimission support facility that performs ground navigation and spacecraft trajectory design services for a wide range of scientific satellites. The FDF also supports the NASA Space Network by providing orbit determination and tracking data evaluation services for the Tracking Data Relay Satellite System (TDRSS). The FDF traces its history to early NASA missions in the 1960's, including navigation support to the Apollo lunar missions. Over its 40 year history, the FDF has undergone many changes in its architecture, services offered, missions supported, management approach, and business operation. As a fully reimbursable facility (users now pay 100% of all costs for FDF operations and sustaining engineering activities), the FDF has faced significant challenges in recent years in providing mission critical products and services at minimal cost while defining and implementing upgrades necessary to meet future mission demands. This paper traces the history of the FDF and discusses significant events in the past that impacted the FDF infrastructure and/or business model, and the events today that are shaping the plans for the FDF in the next decade. Today's drivers for change include new mission requirements, the availability of new technology for spacecraft navigation, and continued pressures for cost reduction from FDF users. Recently, the FDF completed an architecture study based on these drivers that defines significant changes planned for the facility. This paper discusses the results of this study and a proposed implementation plan. As a case study in how flight dynamics operations have evolved and will continue to evolve, this paper focuses on two periods of time (1992 and the present) in order to contrast the dramatic changes that have taken place in the FDF. This paper offers observations and plans for the evolution of the FDF over the next ten years. Finally, this paper defines the mission model of the future for the FDF based on NASA's current mission list and planning for the Constellation Program. As part of this discussion the following are addressed: the relevance and benefits of a multi-mission facility for NASA's navigation operations in the future; anticipated technologies affecting ground orbit determination; continued incorporation of Commercial Off-the-shelf (COTS) software into the FDF; challenges of a business model that relies entirely on user fees to fund facility upgrades; anticipated changes in flight dynamics services required; and considerations for defining architecture upgrades given a set of cost drivers.

Stengle, Thomas↗