Search NASA⌕ Search

SEARCH · Search NASA

Results for “reference 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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Human Exploration of Mars Design Reference Architecture 5.0, Addendum #2

This report serves as the second Addendum to NASA-SP-2009-566, "Human Exploration of Mars Design Reference Architecture 5.0." The data and descriptions contained within this Addendum capture some of the key assessments and studies produced since publication of the original document, predominately covering those conducted from 2009 through 2012. The assessments and studies described herein are for the most part independent stand-alone contributions. Effort has not been made to assimilate the findings to provide an updated integrated strategy. That is a recognized future effort. This report should not be viewed as constituting a formal plan for the human exploration of Mars.

Drake, Bret G.↗
DOE OSTI2023

A Functional Reference Architecture and Assessment Thereof for the National Ignition Facility Industrial Controls Systems

The Industrial Control System (ICS) at the National Ignition Facility (NIF) has an effective, well-established architecture based off a conventional cyclical software paradigm focused on maintainability and the identification of issues. This architecture exhibits scalability in ensuring expansions of the system conform to the existing architecture, modularity enough to allow relatively easy integrations of such expansions and works as a successful tool to introduce control system engineers new to the NIF ICS to the structure of the system at each layer. This architecture, like most software architectures, is object-oriented, lending itself to ease of understanding by control systems engineers and software engineers familiar with an object-oriented perspective. There are occasions, however, where engineers of other disciplines require insight into the functionality and structure of the ICS for the purposes of understanding fundamentally how their own system is or will be governed by the ICS, without the need for the details of operation of the ICS or the object-oriented view. For this reason, a functional architecture of the ICS could be a potent tool for communicating this insight. Even more powerful, a generalization of this proposed functional ICS architecture in the form of a National Ignition Facility and Photon Science (NIF & PS) Industrial Controls Reference Architecture could communicate this insight not just to systems governed by the ICS in the NIF proper, but across entirety of the NIF & PS Principal Associate Directorate (PAD), anywhere an instance of the ICS architecture is present, such as the approximately 40 “small labs” distributed across the directorate. Such a tool will provide an alternative means of understanding the implementation of these control systems, conducive to a larger variety of engineering and scientific disciplines.

42 ENGINEERING↗
DOE OSTI2021

IoT Intrusion Detection Taxonomy, Reference Architecture, and Analyses

This paper surveys the deep learning (DL) approaches for intrusion-detection systems (IDSs) in Internet of Things (IoT) and the associated datasets toward identifying gaps, weaknesses, and a neutral reference architecture. A comparative study of IDSs is provided, with a review of anomaly-based IDSs on DL approaches, which include supervised, unsupervised, and hybrid methods. All techniques in these three categories have essentially been used in IoT environments. To date, only a few have been used in the anomaly-based IDS for IoT. For each of these anomaly-based IDSs, the implementation of the four categories of feature(s) extraction, classification, prediction, and regression were evaluated. We studied important performance metrics and benchmark detection rates, including the requisite efficiency of the various methods. Four machine learning algorithms were evaluated for classification purposes: Logistic Regression (LR), Support Vector Machine (SVM), Decision Tree (DT), and an Artificial Neural Network (ANN). Therefore, we compared each via the Receiver Operating Characteristic (ROC) curve. The study model exhibits promising outcomes for all classes of attacks. The scope of our analysis examines attacks targeting the IoT ecosystem using empirically based, simulation-generated datasets (namely the Bot-IoT and the IoTID20 datasets).

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2003

Reference architecture for space data systems

Architectures for terrestrial data systems that are built and managed by a single organization are inherently complex. In order to understand any large-scale system architecture, and to judge its applicability for its nominal task, a description of the system must be produced that exposes a number of distinct viewpoints. Within the CCSDS Architecture Working Group we have adapted the Reference Model for Open Distributed Processing to describe large, multi-national, space data systems.

CCSDS space communication reference architecture s↗
NASA NTRS2010

Goals and Strategies for the Human Lunar Reference Architecture

The presentation examines common goals for human lunar exploration and strategic guidance. Three major sections include illustrative example goals, introduction to the GPoD campaign, and GPoD overview. The first section includes slides about strategic view of partnerships, the moon as a stepping stone and a uniquely preserved record, human-robotic partnership, innovative engagement, strategic considerations, and evaluation of campaigns against common goals. The second section examines campaigns considered, the philosophy of GPoD, GPoD campaign phase definitions, and GPoD design decision points. The third section examines lunar exploration capabilities, extended stay-relocation exploration mode, notional campaign destinations for GPoD, early robotics phase, development of the GPoD early robotics phase, polar exploration/system validation phase, polar relocatability phase, non-polar relocatability phase, long duration phase, and return to evaluation of campaigns.

Seaman, Calvin H.↗
NASA NTRS2011

Destination Deimos: A Design Reference Architecture for Initial Human Exploration of the Mars System

The two biggest challenges to successful human operations in interplanetary space are flight dynamics, constrained by the cold hard physics of the rocket equation, and bioastronautics, the psychophysiological realities of human adaptation, or lack thereof, to the deep space environment. Without substantial innovation in project/mission architecture and vehicle design, human exploration of the Mars system could be problematic for decades. Although a human landing on Mars is inevitable, humans-in-the-loop telerobotic exploration from the outer Martian moon Deimos is the best way to begin. Precursor robotic missions for reconnaissance and local site preparation will be required.

Logan, James S.↗
NASA NTRS2009

Nuclear Thermal Rocket/Vehicle Characteristics And Sensitivity Trades For NASA's Mars Design Reference Architecture (DRA) 5.0 Study

This paper summarizes Phase I and II analysis results from NASA's recent Mars DRA 5.0 study which re-examined mission, payload and transportation system requirements for a human Mars landing mission in the post-2030 timeframe. Nuclear thermal rocket (NTR) propulsion was again identified as the preferred in-space transportation system over chemical/aerobrake because of its higher specific impulse (I(sub sp)) capability, increased tolerance to payload mass growth and architecture changes, and lower total initial mass in low Earth orbit (IMLEO) which is important for reducing the number of Ares-V heavy lift launches and overall mission cost. DRA 5.0 features a long surface stay (approximately 500 days) split mission using separate cargo and crewed Mars transfer vehicles (MTVs). All vehicles utilize a common core propulsion stage with three 25 klbf composite fuel NERVA-derived NTR engines (T(sub ex) approximately 2650 - 2700 K, p(sub ch) approximately 1000 psia, epsilon approximately 300:1, I(sub sp) approximately 900 - 910 s, engine thrust-toweight ratio approximately 3.43) to perform all primary mission maneuvers. Two cargo flights, utilizing 1-way minimum energy trajectories, pre-deploy a cargo lander to the surface and a habitat lander into a 24-hour elliptical Mars parking orbit where it remains until the arrival of the crewed MTV during the next mission opportunity (approximately 26 months later). The cargo payload elements aerocapture (AC) into Mars orbit and are enclosed within a large triconicshaped aeroshell which functions as payload shroud during launch, then as an aerobrake and thermal protection system during Mars orbit capture and subsequent entry, descent and landing (EDL) on Mars. The all propulsive crewed MTV is a 0-gE vehicle design that utilizes a fast conjunction trajectory that allows approximately 6-7 month 1-way transit times to and from Mars. Four 12.5 kW(sub e) per 125 square meter rectangular photovoltaic arrays provide the crewed MTV with approximately 50 kW(sub e) of electrical power in Mars orbit for crew life support and spacecraft subsystem needs. Vehicle assembly involves autonomous Earth orbit rendezvous and docking between the propulsion stages, in-line propellant tanks and payload elements. Nine Ares-V launches -- five for the two cargo MTVs and four for the crewed MTV -- deliver the key components for the three MTVs. Details on mission, payload, engine and vehicle characteristics and requirements are presented and the results of key trade studies are discussed.

Borowski, Stanley K.↗
NASA NTRS2009

Power Requirements for The NASA Mars Design Reference Architecture (DRA) 5.0

This paper summarizes the power systems analysis results from NASA s recent Mars DRA 5.0 study which examined three architecture options and resulting mission requirements for a human Mars landing mission in the post-2030 timeframe. DRA 5.0 features a long approximately 500 day surface stay split mission using separate cargo and crewed Mars transfer vehicles. Two cargo flights, utilizing minimum energy trajectories, pre-deploy a cargo lander to the surface and a habitat lander into a 24-hour elliptical Mars parking orbit where it remains until the arrival of the crew during the next mission opportunity approximately 26 months later. The pre-deployment of cargo poses unique challenges for set-up and emplacement of surface assets that results in the need for self or robotically deployed designs. Three surface architecture options were evaluated for breadth of science content, extent of exploration range/capability and variations in system concepts and technology. This paper describes the power requirements for the surface operations of the three mission options, power system analyses including discussion of the nuclear fission, solar photovoltaic and radioisotope concepts for main base power and long range mobility.

Cataldo, Robert L.↗
DOE OSTI2019

Volatile Memory Extraction- Based Approach for Level 0-1 CPS Forensics

Most security analyzers operate on system state that is far removed from end-point components in cyber-physical systems (CPS) identified as level 0-1 in the Purdue Architecture Reference Architecture (PERA) [1]. For example, many operate on system logs and other data dumps to disks. Tremendous value that can be gained in cyber security forensics if low level details such as dynamic changes to volatile memory can be extracted and provided to more sophisticated analysis tools. However, obtaining detailed and dynamic system state at the level of volatile memory is extremely challenging [2]. Here, we attempt to apply IT memory forensic mechanisms to CPS end-point devices and statistically evaluate them. Our focus is to extract volatile and dynamically changing internal information form CPS 0-1 level devices, and design preliminary schemes to exploit that extracted information. This new capability of generating a sequence of volatile memory snapshots for offline, detailed and sophisticated analysis opens a new class of cyber security schemes for CPS forensic analysis. As a case study for our ongoing research, we apply the proposed methodology to Modicon PLC using Modbus protocol. We extract the memory layout and subject the device to read operations at the most critical regions of memory. Similarly, write operations are initiated to carefully determine memory locations (for example, bytes that hold the firmware version number). This capability of generating a sequence of volatile memory snapshots for offline, detailed and sophisticated analysis opens a new class of cyber security schemes for CPS forensic analysis. Also, the ability to dynamically make controlled modifications to specific memory locations opens the potential for new mechanisms such as taint analysis and watermarking.

Asmar Awad, Rima↗
NASA NTRS2010

Reference Avionics Architecture for Lunar Surface Systems

Developing and delivering infrastructure capable of supporting long-term manned operations to the lunar surface has been a primary objective of the Constellation Program in the Exploration Systems Mission Directorate. Several concepts have been developed related to development and deployment lunar exploration vehicles and assets that provide critical functionality such as transportation, habitation, and communication, to name a few. Together, these systems perform complex safety-critical functions, largely dependent on avionics for control and behavior of system functions. These functions are implemented using interchangeable, modular avionics designed for lunar transit and lunar surface deployment. Systems are optimized towards reuse and commonality of form and interface and can be configured via software or component integration for special purpose applications. There are two core concepts in the reference avionics architecture described in this report. The first concept uses distributed, smart systems to manage complexity, simplify integration, and facilitate commonality. The second core concept is to employ extensive commonality between elements and subsystems. These two concepts are used in the context of developing reference designs for many lunar surface exploration vehicles and elements. These concepts are repeated constantly as architectural patterns in a conceptual architectural framework. This report describes the use of these architectural patterns in a reference avionics architecture for Lunar surface systems elements.

Somervill, Kevin M.↗
NASA NTRS1996

The NIST Real-Time Control System (RCS): A Reference Model Architecture for Computational Intelligence

The Real-time Control System (RCS) developed at NIST and elsewhere over the past two decades defines a reference model architecture for design and analysis of complex intelligent control systems. The RCS architecture consists of a hierarchically layered set of functional processing modules connected by a network of communication pathways. The primary distinguishing feature of the layers is the bandwidth of the control loops. The characteristic bandwidth of each level is determined by the spatial and temporal integration window of filters, the temporal frequency of signals and events, the spatial frequency of patterns, and the planning horizon and granularity of the planners that operate at each level. At each level, tasks are decomposed into sequential subtasks, to be performed by cooperating sets of subordinate agents. At each level, signals from sensors are filtered and correlated with spatial and temporal features that are relevant to the control function being implemented at that level.

Albus, James S.↗
DOE OSTI2021

Software-defined Networking for Energy Delivery Systems (SDN4EDS): An Architectural Blueprint (Final Report)

This is the initial version of a reference for suppliers and energy companies of all sizes to deploy networks based on software-defined networking technology (SDN) to improve reliability, reduce cyber security attack surface, and facilitate mitigation of adversarial behavior. It is a living document and will progress over the life cycle of the Software-Defined Networking for Energy Delivery Systems (SDN4EDS) project. Version 2 of this report provides information on the Red Team tabletop assessment performed against the initial reference architecture. Version 3 of this report updates the reference architecture with lessons learned from the Red Team tabletop assessment, as well as provides additional details for the use cases. It also provides information on the decision process that could be used by an organization when considering deploying SDN in their environment. The final version of this report consolidates all the interim reports generated by the project into a final report. It also draws from PNNL’s experience in deploying SDN to make recommendations on how SDN could be deployed in a utility environment, and provides rationale for those decisions allowing individual utilities to make risk-based and knowledge-based decisions on how to best deploy SDN in their own environment

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Software-defined Networking for Energy Delivery Systems (SDN4EDS): An Architectural Blueprint (Final Summary Report)

This is the initial version of a reference for suppliers and energy companies of all sizes to deploy networks based on software-defined networking technology (SDN) to improve reliability, reduce cyber security attack surface, and facilitate mitigation of adversarial behavior. It is a living document and will progress over the life cycle of the Software-Defined Networking for Energy Delivery Systems (SDN4EDS) project. Version 2 of this report provides information on the Red Team tabletop assessment performed against the initial reference architecture. Version 3 of this report updates the reference architecture with lessons learned from the Red Team tabletop assessment, as well as provides additional details for the use cases. It also provides information on the decision process that could be used by an organization when considering deploying SDN in their environment. The final version of this report consolidates all the interim reports generated by the project into a final report. It also draws from PNNL’s experience in deploying SDN to make recommendations on how SDN could be deployed in a utility environment, and provides rationale for those decisions allowing individual utilities to make risk-based and knowledge-based decisions on how to best deploy SDN in their own environment. This summary report provides a higher-level overview of the project reports. Readers interested in additional detail, including results of the Red Team assessments and the final configuration, are encouraged to read the full final report.

97 MATHEMATICS AND COMPUTING↗