Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “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 1,045 records · Page 58

A general purpose CCD controller

A new type of controller for scientific CCDs that has been designed and tested at NASA-Goddard is described. It features the flexibility of software waveform generation as well as the speed and accuracy of clocking by hardware. The basic CCD operation is described as well as the controller architecture; controller operation; experimental verification; and software, hardware, and data acquisition.

Chen, P. C.↗

Tool Use Within NASA Software Quality Assurance

As space mission software systems become larger and more complex, it is increasingly important for the software assurance effort to have the ability to effectively assess both the artifacts produced during software system development and the development process itself. Conceptually, assurance is a straightforward idea - it is the result of activities carried out by an organization independent of the software developers to better inform project management of potential technical and programmatic risks, and thus increase management's confidence in the decisions they ultimately make. In practice, effective assurance for large, complex systems often entails assessing large, complex software artifacts (e.g., requirements specifications, architectural descriptions) as well as substantial amounts of unstructured information (e.g., anomaly reports resulting from testing activities during development). In such an environment, assurance engineers can benefit greatly from appropriate tool support. In order to do so, an assurance organization will need accurate and timely information on the tool support available for various types of assurance activities. In this paper, we investigate the current use of tool support for assurance organizations within NASA, and describe on-going work at JPL for providing assurance organizations with the information about tools they need to use them effectively.

software assurance↗

Feasibility of using the Massively Parallel Processor for large eddy simulations and other Computational Fluid Dynamics applications

The results of an investigation into the feasibility of using the MPP for direct and large eddy simulations of the Navier-Stokes equations is presented. A major part of this study was devoted to the implementation of two of the standard numerical algorithms for CFD. These implementations were not run on the Massively Parallel Processor (MPP) since the machine delivered to NASA Goddard does not have sufficient capacity. Instead, a detailed implementation plan was designed and from these were derived estimates of the time and space requirements of the algorithms on a suitably configured MPP. In addition, other issues related to the practical implementation of these algorithms on an MPP-like architecture were considered; namely, adaptive grid generation, zonal boundary conditions, the table lookup problem, and the software interface. Performance estimates show that the architectural components of the MPP, the Staging Memory and the Array Unit, appear to be well suited to the numerical algorithms of CFD. This combined with the prospect of building a faster and larger MMP-like machine holds the promise of achieving sustained gigaflop rates that are required for the numerical simulations in CFD.

Bruno, John↗

Architecture for Survivable Systems Processing (ASSP). Technology benefits for Open System Interconnects

The Architecture for Survivable Systems Processing (ASSP) program is a two phase program whose objective is the derivation, specification, development and validation of an open system architecture capable of supporting advanced processing needs of space, ground, and launch vehicle operations. The output of the first phase is a set of hardware and software standards and specifications defining this architecture at three levels. The second phase will validate these standards and develop the technology necessary to achieve strategic hardness, packaging density, throughput requirements, and interoperability/interchangeability.

Wood, Richard J.↗

Certification of CFD heat transfer software for turbine blade analysis

Accurate modeling of heat transfer effects is a critical component of the Turbine Branch of the Turbomachinery and Propulsion Systems Division. Being able to adequately predict and model heat flux, coolant flows, and peak temperatures are necessary for the analysis of high pressure turbine blades. To that end, the primary goal of my internship this summer will be to certify the reliability of the CFD program GlennHT for the purpose of turbine blade heat transfer analysis. GlennHT is currently in use by the engineers in the Turbine Branch who use the FORTRAN 77 version of the code for analysis. The program, however, has been updated to a FORTRAN 90 version which is more robust than the older code. In order for the new code to be distributed for use, its reliability must first be certified. Over the course of my internship I will create and run test cases using the FORTRAN 90 version of GlennHT and compare the results to older cases which are known to be accurate, If the results of the new code match those of the sample cases then the newer version will be one step closer to certification for distribution. In order to complete these it will first be necessary to become familiar with operating a number of other programs. Among them are GridPro, which is used to create a grid mesh around a blade geometry, and FieldView, whose purpose is to graphically display the results from the GlennHT program. Once enough familiarity is established with these programs to render them useful, then the work of creating and running test scenarios will begin. The work is additionally complicated by a transition in computer hardware. Most of the working computers in the Turbine Branch are Silicon Graphics machines, which will soon be replaced by LINUX PC's. My project is one of the first to make use the new PC's. The change in system architecture however, has created several software related issues which have greatly increased the time and effort investments required by the project.Although complications with the project continue to arise, it is expected that the goal of my internship can still be achieved within the remaining time period. Critical steps have been achieved and test scenarios can now be designed and run. At the completion of my internship, the FORTRAN 90 version of GlennHT should be well on its way to certification.

Jordan, William A.↗

Software Surrogate

In 1994, Blackboard Technology received a NASA Phase I SBIR award entitled "A Blackboard-Based Framework for Mixed-Initiative, Crewed- Space-System Applications." This research continued in Phase II at JSC, where a generic architecture was developed in which a software surrogate serves as the operator's representative in the fast-paced realm of nearly autonomous, intelligent systems. This SBIR research effort addressed the need to support human-operator monitoring and intervention with intelligent systems such as those being developed for NASA's crewed space program.

Source record↗

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗

Plug and Play Integration through Space Object Standardization

Plug and play is an industry standard promoted by Intel and Microsoft, and others that allows users to add and remove various input and output devices without making specific customizations to their systems. The idea behind concept is that using standard products eases integration of components and promotes capabilities of conforming products. The concept works because vendors comply with a standard specification. This paper reports the development of a reference architecture for the mission control domain, which is leveraging off this revolutionary concept. Standards are being developed at the application layer, which enable "plug and play" of mission software products. A Mission Control, reference architecture has been defined. For each sub-domain, the interfaces are modeled in Interface Definition Language (IDL). A subset of the IDL has been developed within both commercial off-the-shelf (COTS) and government (GOTS) products. Selected vendors have agreed to modify their products to be compatible with the defined IDL. The plug and play integration of these different products has been validated in a demonstration testbed.

Boyce, Leslye↗

Developing Load Cell Monitoring on the Mock UF 6 Feed and Withdrawal System

A proof-of-concept load cell monitoring system has been developed for the Mock Feed and Withdrawal (F&W) System at Oak Ridge National Laboratory (ORNL). This system leverages industry-standard commercial off-the-shelf (COTS) hardware and software in a modular and scalable design. The Mock F&W System was designed to simulate operations at a uranium hexafluoride (UF 6 ) gas centrifuge enrichment plant F&W area. It provides a test bed for process-monitoring technologies. Water, used as a surrogate for UF 6 , is pumped from three feed tanks, through a process surge tank, and is then cut between two tails tanks and three product tanks. The weight of the each tank is continuously monitored using a load cell monitoring system. In addition to the F&W stations, large and small accountancy stations are monitored. The Mock F&W System allows ORNL to test and evaluate capabilities of industry-standard process monitoring hardware and software. A variety of commonly used weighing indicators are connected to the load cells to monitor the weight at each station. These weighing indicators are representative of the types likely found in operating facilities. A data center modeled after those currently used for international safeguards was installed to collect and manage the weight data. This data center provides a robust and flexible test bed for testing and developing software solutions. COTS software packages that leverage industry-standard communication protocols provide a data flow architecture that is modular, interoperable, and scalable. One software package provides communication drivers to collect the raw weight data from the weighing indicators. A data historian is used to store the raw data. Custom in-house algorithms have been developed using MATLAB to analyze the raw historical data and to automatically identify process information. This information includes the number of cycles completed and the mass of material transferred from stations to the process. The process information identified by the analysis is stored in a Microsoft SQL Server database. Visualization concepts have been developed that display the analyzed process information alongside visually compelling plots and animations of the raw data. The load cell monitoring system developed on the Mock F&W System was designed as a proof of concept that could be scaled to a field trial at an operating facility. This system, built with industry standard hardware and software, has allowed ORNL to develop capabilities that provide confidence in the ability to leverage existing operator load cell monitoring equipment with minimal impact on operations. The international safeguards community is evaluating the use of load cell monitoring as an additional safeguards measure; this system demonstrates a practical solution to collect, store, analyze, and visualize load cell weight data.

commercial off the shelf↗

NASA Access Mechanism: Lessons learned document

The six-month beta test of the NASA Access Mechanism (NAM) prototype was completed on June 30, 1993. This report documents the lessons learned from the use of this Graphical User Interface to NASA databases such as the NASA STI Database, outside databases, Internet resources, and peers in the NASA R&D community. Design decisions, such as the use of XWindows software, a client-server distributed architecture, and use of the NASA Science Internet, are explained. Users' reactions to the interface and suggestions for design changes are reported, as are the changes made by the software developers based on new technology for information discovery and retrieval. The lessons learned section also reports reactions from the public, both at demonstrations and in response to articles in the trade press and journals. Recommendations are included for future versions, such as a World Wide Web (WWW) and Mosaic based interface to heterogeneous databases, and NAM-Lite, a version which allows customization to include utilities provided locally at NASA Centers.

Burdick, Lisa↗

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS), an avionics software operating environment. The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plugand- play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS application programmer interfaces (APIs) that use the cFS infrastructure. These APIs are used to standardize the communication protocols on NASAs space SDRs. The cFS-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFS-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC S‑ band Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station (ISS). Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets (EDS) inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗

STRS Compliant FPGA Waveform Development

The Space Telecommunications Radio System (STRS) Architecture Standard describes a standard for NASA space software defined radios (SDRs). It provides a common framework that can be used to develop and operate a space SDR in a reconfigurable and reprogrammable manner. One goal of the STRS Architecture is to promote waveform reuse among multiple software defined radios. Many space domain waveforms are designed to run in the special signal processing (SSP) hardware. However, the STRS Architecture is currently incomplete in defining a standard for designing waveforms in the SSP hardware. Therefore, the STRS Architecture needs to be extended to encompass waveform development in the SSP hardware. The extension of STRS to the SSP hardware will promote easier waveform reconfiguration and reuse. A transmit waveform for space applications was developed to determine ways to extend the STRS Architecture to a field programmable gate array (FPGA). These extensions include a standard hardware abstraction layer for FPGAs and a standard interface between waveform functions running inside a FPGA. A FPGA-based transmit waveform implementation of the proposed standard interfaces on a laboratory breadboard SDR will be discussed.

Nappier, Jennifer↗

STRS Compliant FPGA Waveform Development

The Space Telecommunications Radio System (STRS) Architecture Standard describes a standard for NASA space software defined radios (SDRs). It provides a common framework that can be used to develop and operate a space SDR in a reconfigurable and reprogrammable manner. One goal of the STRS Architecture is to promote waveform reuse among multiple software defined radios. Many space domain waveforms are designed to run in the special signal processing (SSP) hardware. However, the STRS Architecture is currently incomplete in defining a standard for designing waveforms in the SSP hardware. Therefore, the STRS Architecture needs to be extended to encompass waveform development in the SSP hardware. A transmit waveform for space applications was developed to determine ways to extend the STRS Architecture to a field programmable gate array (FPGA). These extensions include a standard hardware abstraction layer for FPGAs and a standard interface between waveform functions running inside a FPGA. Current standards were researched and new standard interfaces were proposed. The implementation of the proposed standard interfaces on a laboratory breadboard SDR will be presented.

Nappier, Jennifer↗

Memory forensic analysis of a programmable logic controller in industrial control systems

In industrial control systems (ICS), programmable logic controllers (PLCs) are used to automate physical processes such as nuclear plants and power grid stations, and are often subject to cyber attacks. As in conventional IT domain, the memory analysis of the PLCs can help answer important forensic questions about the attack, such as the presence of malicious firmware, injection of modified control logic (the program running on the PLC), and manipulation of I/O devices (e.g., sensors and actuators). Unlike conventional IT domain, PLCs have heterogeneous hardware architecture, proprietary firmware and control software, making it challenging to employ a unified framework for their memory forensics. For merely extracting artifacts of forensic importance, reverse-engineering the firmware is a tedious task, and the effort needs to be repeated for every PLC model. As a community, a step-wise approach to tackle this challenge is to analyze the memory of specific PLCs, and subsequently find a generic framework applicable to all PLCs. Our work is a step forward in this direction. By following a methodology that focuses on the functional layer of PLCs instead of reverse engineering the firmware, we analyze the digital forensic artifacts available in a common PLC, Allen-Bradley ControlLogix 1756-L61. Before diving into the memory dump, we analyze the PLC control software to create a list of important artifacts that are sure to exist in the PLC memory dump. The approach employs a setup where PLC control software RSLogix-5000 is connected to the PLC, and the memory dump can be obtained as and when needed. We create test cases that sequentially highlight each category of artifacts, followed by an examination of the resultant impact on memory. After attaining the listed artifacts, we employ conventional string and known data searches to extract interesting information present in this PLC's memory. The memory analysis profile, presented as a Python library and shared with the community, can help a forensic investigator to readily extract forensic artifacts from the same model's controller. The adopted approach may help researchers in creating memory profile of other PLCs, and ultimately formulating a generic PLC memory analysis framework.

Rais, Muhammad Haris↗

Designing a decentralized fault-tolerant software framework for smart grids and its applications

The vision of the ‘Smart Grid’ anticipates a distributed real-time embedded system that implements various monitoring and control functions. As the reliability of the power grid is critical to modern society, the software supporting the grid must support fault tolerance and resilience of the resulting cyber-physical system. This paper describes the fault-tolerance features of a software framework called Resilient Information Architecture Platform for Smart Grid (RIAPS). The framework supports various mechanisms for fault detection and mitigation and works in concert with the applications that implement the grid-specific functions. The paper discusses the design philosophy for and the implementation of the fault tolerance features and presents an application example to show how it can be used to build highly resilient systems.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

The enhanced ASDEX Upgrade pellet centrifuge launcher

Pellets played an important role in the program of ASDEX Upgrade serving both for investigations on efficient particle fuelling and high density scenarios but also for pioneering work on Edge Localised Mode (ELM) pacing and mitigation. Initially designed for launching fuelling pellets from the magnetic low field side, the system was converted already some time ago to inject pellets from the magnetic high field side as much higher fuelling efficiency was found using this configuration. In operation for more than 20 years, the pellet launching system had to undergo a major revision and upgrading, in particular of its control system. Furthermore, the control system installed adjacent to the launcher had to be transferred to a more distant location enforcing a complete galvanic separation from torus potential and a fully remote control solution. Changing from a hybrid system consisting of PLC S5/S7 and some hard wired relay control to a state of the art PLC system allowed the introduction of several new operational options enabling more flexibility in the pellet experiments. This article describes the new system architecture of control hardware and software, the operating procedure, and the extended operational window. First successful applications for ELM pacing and triggering studies are presented as well as utilization for the development of high density scenarios.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗

A field programmable gate array-based timing and control system for the dynamic compression sector

A field programmable gate array (FPGA)-based timing and trigger control system has been developed for the Dynamic Compression Sector (DCS) user facility located at the Advanced Photon Source (APS) at Argonne National Laboratory. The DCS is a first-of-its-kind capability dedicated to dynamic compression science. All components of the DCS laser shock station—x-ray choppers, single-shot shutter, internal laser triggers, and shot diagnostics—must be synchronized with respect to the arrival of x rays in the hutch. An FPGA synchronized to the APS storage ring radio frequency clock (352 MHz) generates trigger signals for each stage of the laser and x-ray shutter system with low jitter. The developed FPGA-based control system was the first system used to control the laser and the shutter system since its commissioning, and it has been developing since then to improve the timing jitter. The system is composed of a Zynq FPGA, a debug card, line drivers, and a power supply. The delay and offsets of the trigger signals can be adjusted by using a user-friendly graphical user interface with high precision. Here, the details of the system architecture, timing requirements, firmware, and software implementation along with the performance evaluation are presented in this paper. The system offers low timing jitter (15.5 ps rms) with respect to the APS 352 MHz clock, suitable for the 100 ps (FWHM) x-ray bunch duration at the APS.

47 OTHER INSTRUMENTATION↗