Search NASA⌕ Search

SEARCH · Search NASA

Results for “Practice Guidelines”

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.

288 records · Page 16
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Evaluation of Cable Harness Post-Installation Testing

The Cable Harness Post-Installation Testing Report was written in response to an action issued by the Ares Project Control Board (PCB). The action for the Ares I Avionics & Software Chief Engineer and the Avionics Integration and Vehicle Systems Test Work Breakdown Structure (WBS) Manager in the Vehicle Integration Office was to develop a set of guidelines for electrical cable harnesses. Research showed that post-installation tests have been done since the Apollo era. For Ares I-X, the requirement for post-installation testing was removed to make it consistent with the avionics processes used on the Atlas V expendable launch vehicle. Further research for the report involved surveying government and private sector launch vehicle developers, military and commercial aircraft, spacecraft developers, and harness vendors. Responses indicated crewed launch vehicles and military aircraft perform post-installation tests. Key findings in the report were as follows: Test requirements identify damage, human-rated vehicles should be tested despite the identification of statistically few failures, data does not support the claim that post-installation testing damages the harness insulation system, and proper planning can reduce overhead associated with testing. The primary recommendation of the report is for the Ares projects to retain the practice of post-fabrication and post-installation cable harness testing.

King, M. S.↗
NASA NTRS1996

Strain Gage Selection Criteria for Textile Composite Materials

This report will provide a review of efforts to establish a set of strain gage selection guidelines for textile reinforced composite materials. A variety of strain gages were evaluated in the study to determine the sensitivity of strain measurements to the size of the strain gage. The strain gages were chosen to provide a range of gage lengths and widths. The gage aspect ratio (the length-to-width ratio) was also varied. The gages were tested on a diverse collection of textile composite laminates. Test specimens featured eleven different textile architectures: four 2-D triaxial braids, six 3-D weaves, and one stitched uniweave architecture. All specimens were loaded in uniaxial tension. The materials' moduli were measured in both the longitudinal (parallel to the O deg. yarns) and the transverse (perpendicular to the O deg. yarns) directions. The results of these measurements were analyzed to establish performance levels for extensometers and strain gages on textile composite materials. Conclusions are expressed in a summary that discusses instrumentation practices and defines strain gage selection criteria.

Masters, John E.↗
NASA NTRS2002

Investigation Into The Needs of Part 135 Operators to Access Airports Restricted Under FAR Part 135 Sections 135.213, 135.219 and/or 135.225

NASA and the FAA have joint interests and responsibilities for developing guidelines and standards for cockpit displays of Flight Information Services (FIS) information and for developing enhancements to the planned FAA Data Link (FISDL) services. NASA and the FAA have established responsibilities in connection with development tasks for enhancements to the FISDL project. This report is the result of NASA Task 2, "Weather Support Concept- Part 135 Operations." The objective of the task was to determine the needs of Part 135 operators as they relate to FAA Part 135 Sections 135.213, 135.219 and 135.225, which pertain to weather reporting requirements at destination airports. This report discusses the results of two questionnaires completed by volunteer Part 135 operators that questioned their operations, their needs for flying to airports without weather reporting compatibilities, and suggestions for modifying FARs 135.213, 135.219 and 135.225. The operators pointed out airports in areas of the CONUS that were needed for IFR operations but lacked weather reporting capabilities and they offered practical suggestions for changes to the FARs. Related to operators's needs, and discussed in this report, were the Fractional Ownership NPRM and the possible impact of GPS WAAS and LAAS approaches.

Eckert, Clifford A.↗
NASA NTRS2019

Adaptations of guidance, navigation, and control verification and validation philosophies for small spacecraft

Decades of experience developing increasingly capable and more complex space-craft have resulted in a set of accepted practices and philosophies to verify and validate (V&V) guidance, navigation, and control (GN&C) subsystems. Until recently, small, low-cost spacecraft have had very simple or non-existent GN&C subsystems requiring minimal or no subsystem testing. As the next generation of small spacecraft take on more challenging GN&C requirements, the GN&C community is struggling with how to scale the subsystem V&V effort to produce spacecraft approaching the reliability of flagship-class missions while staying within the reduced resources of a small satellite project.For this paper, we will examine five aspects of GN&C V&V (requirements definition, software testing and analysis, hardware component testing, integrated vehicle testing, and in-flight V&V) and compare the V&V campaign of a flagship-class mission (Mars 2020) to that of two recent, successful CubeSat missions: ASTERIA and MarCO. Experiences from the development of these CubeSats yield valuable lessons learned and guidelines for future small spacecraft designers.

Chen, George T.↗
NASA NTRS2019

Adaptations of Guidance, Navigation and Control Verification and Validation Philosophies for Small Spacecraft

Decades of experience developing increasingly capable and more complex space-craft have resulted in a set of accepted practices and philosophies to verify and validate (V&V) guidance, navigation, and control (GN&C) subsystems. Until recently, small, low-cost spacecraft have had very simple or non-existent GN&C subsystems requiring minimal or no subsystem testing. As the next generation of small spacecraft take on more challenging GN&C requirements, the GN&C community is struggling with how to scale the subsystem V&V effort to produce spacecraft approaching the reliability of flagship-class missions while staying within the reduced resources of a small satellite project. For this paper, we will examine five aspects of GN&C V&V (requirements definition, software testing and analysis, hardware component testing, integrated vehicle testing, and in-flight V&V) and compare the V&V campaign of a flagship-class mission (Mars 2020) to that of two recent, successful CubeSat missions: ASTERIA and MarCO. Experiences from the development of these CubeSats yield valuable lessons learned and guidelines for future small spacecraft designers.

Pong, Christopher M.↗
NASA NTRS2006

ISHM Decision Analysis Tool: Operations Concept

The state-of-the-practice Shuttle caution and warning system warns the crew of conditions that may create a hazard to orbiter operations and/or crew. Depending on the severity of the alarm, the crew is alerted with a combination of sirens, tones, annunciator lights, or fault messages. The combination of anomalies (and hence alarms) indicates the problem. Even with much training, determining what problem a particular combination represents is not trivial. In many situations, an automated diagnosis system can help the crew more easily determine an underlying root cause. Due to limitations of diagnosis systems,however, it is not always possible to explain a set of alarms with a single root cause. Rather, the system generates a set of hypotheses that the crew can select from. The ISHM Decision Analysis Tool (IDAT) assists with this task. It presents the crew relevant information that could help them resolve the ambiguity of multiple root causes and determine a method for mitigating the problem. IDAT follows graphical user interface design guidelines and incorporates a decision analysis system. I describe both of these aspects.

Source record↗
NASA NTRS2021

A Fully Automated Approach to Requirement Extraction from Design Documents

Design documents are intended to outline the goalsof a system or project, which are utilized in the creation ofspecific software requirements. At the NASA Jet PropulsionLaboratory, California Institute of Technology, Functional DesignDescription (FDD) documents describe the scope of theproject and reflect the design and implementation of the system.The specifications in the document are not explicitly writtenas requirements, though these guidelines must be reflected inthe official software requirements. In this work we present afully automatic approach to extracting software requirementsfrom design documents as well as comparing the extractedrequirements to those that exist in the official software requirementdatabase. We do this through (1) sentence extractionfrom the design document, (2) the incorporation of coreferenttext, and (3) aligning the extracted text to the official softwarerequirements. Via natural language processing and informationretrieval techniques, our system results in an automated processthat ensures that the specifications in the design document resultin official software requirements. We find that extraction ofimperatives results in a recall rate of 0.73 and the TF-IDF cosinesimilarity metric is shown to be a useful and successful way tocompare requirements.Though there has been recent work investigating the usefulnessof natural language processing techniques in requirement engineering,this has not been made use of in the aerospace industry.Aerospace requirement engineering is a field particularly ripefor this type of innovation because these techniques can bothautomate some of needlessly manual work and contribute toaerospace safety practices by identifying issues that a humanmay miss. We present the first fully automated approach thatextracts requirements from a design document and comparesthem to a database, and use these findings as encouragementfor future work that makes use of natural language processingtechniques in aerospace requirement engineering.

Briggs, Paul↗
NASA NTRSDate not supplied

Rapid Development of Instrument Thermal Models: Perspectives and Guidelines from NASA Goddard’s Instrument Design Laboratory

The Instrument Design Laboratory (IDL), part of NASA Goddard Space Flight Center’s Integrated Design Center (IDC), is a concurrent and collaborative environment which allows for rapid development of science instrumentation concepts within the span of less than two weeks. Science goals set by a Principal Investigator from government, industry or academia are translated into engineering requirements, from which a team of engineers spanning multiple disciplines use an established study process and a suite of analysis tools to work towards an instrument point design. As part of this process, a staff thermal engineer is tasked with designing a thermal control system which meets all incoming thermal requirements, while iterating real-time with other subsystems to ensure compatibility and functionality as a completed system. Thermal engineers on spaceflight projects typically have weeks or months to develop thermal models. However, the severe time limitation in this conceptual study setting makes thermal design particularly difficult, as rapid thermal modeling solely over the span of a few days is required to develop the instrument thermal design and understand the performance over its intended mission, especially if the instrument concept contains multiple thermal challenges such as dynamic environments or high heat dissipating components. In this paper, the authors provide a condensed guide for the most efficient ways to develop thermal models and conduct thermal analysis within the span of one-to-two weeks, as informed by decades of design experience and best practices in the IDL. The authors also focus on quick methods for determining worst-case thermal environments, deciding which modeling details are essential at this early phase, and quantifying the engineering resources necessary for thermal control. This paper concludes with specific thermal design tips for different instrument types across the electromagnetic spectrum.

Kan Yang↗
NASA NTRS2009

Proceedings of the First NASA Formal Methods Symposium

Topics covered include: Model Checking - My 27-Year Quest to Overcome the State Explosion Problem; Applying Formal Methods to NASA Projects: Transition from Research to Practice; TLA+: Whence, Wherefore, and Whither; Formal Methods Applications in Air Transportation; Theorem Proving in Intel Hardware Design; Building a Formal Model of a Human-Interactive System: Insights into the Integration of Formal Methods and Human Factors Engineering; Model Checking for Autonomic Systems Specified with ASSL; A Game-Theoretic Approach to Branching Time Abstract-Check-Refine Process; Software Model Checking Without Source Code; Generalized Abstract Symbolic Summaries; A Comparative Study of Randomized Constraint Solvers for Random-Symbolic Testing; Component-Oriented Behavior Extraction for Autonomic System Design; Automated Verification of Design Patterns with LePUS3; A Module Language for Typing by Contracts; From Goal-Oriented Requirements to Event-B Specifications; Introduction of Virtualization Technology to Multi-Process Model Checking; Comparing Techniques for Certified Static Analysis; Towards a Framework for Generating Tests to Satisfy Complex Code Coverage in Java Pathfinder; jFuzz: A Concolic Whitebox Fuzzer for Java; Machine-Checkable Timed CSP; Stochastic Formal Correctness of Numerical Algorithms; Deductive Verification of Cryptographic Software; Coloured Petri Net Refinement Specification and Correctness Proof with Coq; Modeling Guidelines for Code Generation in the Railway Signaling Context; Tactical Synthesis Of Efficient Global Search Algorithms; Towards Co-Engineering Communicating Autonomous Cyber-Physical Systems; and Formal Methods for Automated Diagnosis of Autosub 6000.

Denney, Ewen↗
NASA NTRS1999

Boom Softening and Nacelle Integration on an Arrow-Wing High-Speed Civil Transport Concept

During the last cycle of concept design and wind-tunnel testing, the goal of the low-boom- shaped HSCT concepts (the B-935, the LB-16, and the LB- 1 8) was to meet mission requirements and generate shaped, ground-level pressure signatures with nose shock strengths of 1.0 psf or less. The wind-tunnel tests of these concepts produced results that were partially successful and encouraging although not fully up to expectations. In spite of this, however, these conceptual designs were overly optimistic and not acceptable because: the wing planforms had excessive area; the wing structural aspect ratio was too high; one concept had aft-fuselage rather than under-the-wing engines; and the gross takeoff weights were unrealistically low because of engines that were early, high-tech versions of later, revised, more-realistic engines. The need for reducing the ground-level overpressure shock strengths still existed; a need to be met within more restrictive guidelines of mission performance and gross takeoff weight limitations. Therefore, it was decided that the next conceptual design cycle would focus on decreased nose shock strengths, "boom softening," in the signatures of the Boeing and the McDonnell Douglas baseline concepts rather than low-boom concepts with shaped-signature designs. Overly-optimistic results were not the only problem with these low-sonic-boom concepts. Papers given at the 1994 Sonic-Boom Workshop had demonstrated that the problem of successful nacelle integration on HSCT concepts had only been partially solved. Wind-tunnel pressure signature data, from the HSCT-11B (a.k.a. the LB-18) wind-tunnel model, showed that the Langley HSCT design and analysis method had been successful in reducing the nacelle-volume disturbances in the flow field. This was due.to the engine nacelles mounted behind the wing trailing-edge on the aft fuselage so that no nacelle-wing interference-lift flow-field disturbances were generated. While acceptable from a sonic-boom research point of view, this concept was unacceptable from several practical and structural considerations. Preliminary wind-tunnel pressure signature data from the LB-16 wind-tunnel model, which had the engine nacelles mounted under the wings (the usual location), indicated that the application of the Langley nacelle-integration method had been only partially successful in the reduction of the nacelle-volume with nacelle-wing interference-lift pressure disturbances. So, "boom softening" had to also address the task of successful integration of the engine nacelles, with the engines in the required under-the-wing location. Unless this problem was solved, low-sonic-boom and low-drag modifications to the wing planform, the airfoil shape, and the fuselage longitudinal area distribution could be nullified if the nacelle disturbances added increments to the nose-shock strengths that were removed through component tailoring. In this paper, an arrow-wing boom-softened HSC7 concept which incorporated modifications to a baseline McDonnell Douglas concept is discussed. The analysis of the concept's characteristics will include estimates of weight, center of gravity, takeoff field length, mission range, and predictions of its ground-level sonic-boom pressure signature. Additional modifications which enhanced the softened-boom performance of this concept are also described as well as estimates of the performance penalties induced by these modifications.

Mack, Robert J.↗
NASA NTRS2005

Amateur Cleanrooms: Costs May Not Offset Benefits

Contamination and Coatings Branch During my career at NASA, I have encountered a variety of cleanroom systems. With many projects, cost pressures and lack of adequate facilities have forced the managers to resort to amateur cleanrooms to manufacture spacecraft and instruments. These rooms are usually spaces that have been used for other purposes that are converted to cleanroom, usually without the assistance of a contamination control specialist. Often, scientists and engineers are successful in converting an area for experimental use. However, when the area is used for production, countless difficulties are encountered. This paper will document some of the disasters that I have personally witnessed and offer some guidelines for contamination professionals to follow if you are called upon to assist in the development of new cleanrooms. Cleanroom come in all shapes and sizes from special purpose mini-environments (such as flow benches) to large, expansive production facilities. These areas may require a variety of unit operations to be carried out within a short range of each other. The design of the cleanroom should account for compatibilities of these operations to protect the product and personnel. The level of cleanliness has traditionally been associated with the method of ventilation. However, just because and =ea has HEPA filters and greater that 20 air changes per hour does not mean that it is a cleanroom. Airflow is extremely complex; the only way to properly design a cleanroom is through the use of a computer based model. In the aerospace industry, few engineered cleanrooms are modeled. Modeling has been perceived as expensive; however, modern programs and fast computers are changing perception. It is the lack of appreciation for how air flow and location within a cleanroom affects the product that causes most of the problems I have experienced. Currently, the rules defining the best air flow design practices are based on simplistic historical data that are often wrong. The performance of a cleanroom is defined by a set of complex interactions between the airflow, sources of contamination and heat, position of the air terminals and exhausts as well as the objects occupying the space in question. These subtleties are almost never appreciated in the setup of amateur cleanrooms (and sadly, in some engineered cleanroom as well). Experience with the room, measurement of air flows in the room, and black light inspections can be used to

Ramsey, W. Lawrence↗
NASA NTRS2018

Human-Automation Allocations for Current Robotic Space Operations

Within the Human Research Program, one risk delineates the uncertainty surrounding crew working with automation and robotics in spaceflight. The Risk of Inadequate Design of Human and Automation/Robotic Integration (HARI) is concerned with the detrimental effects on crew performance due to ineffective user interfaces, system designs and/or functional task allocation, potentially compromising mission success and safety. Risk arises because we have limited experience with complex automation and robotics. One key gap within HARI, is the gap related to functional allocation. The gap states: We need to evaluate, develop, and validate methods and guidelines for identifying human-automation/robot task information needs, function allocation, and team composition for future long duration, long distance space missions. Allocations determine the human-system performance as it identifies the functions and performance levels required by the automation/robotic system, and in turn, what work the crew is expected to perform and the necessary human performance requirements. Allocations must take into account each of the human, automation, and robotic systems capabilities and limitations. Some functions may be intuitively assigned to the human versus the robot, but to optimize efficiency and effectiveness, purposeful role assignments will be required. The role of automation and robotics will significantly change in future exploration missions, particularly as crew becomes more autonomous from ground controllers. Thus, we must understand the suitability of existing function allocation methods within NASA as well as the existing allocations established by the few robotic systems that are operational in spaceflight. In order to evaluate future methods of robotic allocations, we must first benchmark the allocations and allocation methods that have been used. We will present 1) documentation of human-automation-robotic allocations in existing, operational spaceflight systems; and 2) To gather existing lessons learned and best practices in these role assignments, from spaceflight operational experience of crew and ground teams that may be used to guide development for future systems. NASA and other space agencies have operational spaceflight experience with two key Human-Automation-Robotic (HAR) systems: heavy lift robotic arms and planetary robotic explorers. Additionally, NASA has invested in high-fidelity rover systems that can carry crew, building beyond Apollo's lunar rover. The heavy lift robotic arms reviewed are: Space Station Remote Manipulator System (SSRMS), Japanese Remote Manipulator System (JEMRMS), and the European Robotic Arm (ERA, designed but not deployed in space). The robotic rover systems reviewed are: Mars Exploration Rovers, Mars Science Laboratory rover, and the high-fidelity K10 rovers. Much of the design and operational feedback for these systems have been communicated to flight controllers and robotic design teams. As part of the mitigating the HARI risk for future human spaceflight operations, we must document function allocations between robots and humans that have worked well in practice.

robotic allocation↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRSDate not supplied

Planetary Protection Lunar Policy: A Case Study in Balancing COSPAR Guidelines, Scientific Consensus, NASA Policy, and Mission Implementation

With the increase of missions to the Earth’s Moon over the next decade, NASA initiated an assessment and review of the policy and protection of Earth’s Moon to enable scientific exploration. The assessment involved gathering scientific consensus regarding the Earth’s Moon and proposed mission operations considering an understanding of the desired science needs for the Moon. This process involved seeking advice from the National Academies of Science, Engineering, and Medicine’s (NASEM) Committee on Planetary Protection, engagement with the Committee on Space Research (COSPAR) Planetary Protection Panel (PPP), and consultation within NASA. To begin this process, NASA issued a NASA Interim Directive (NID) 8715.128 entitled, “Planetary Protection Categorization for Robotic and Crewed Missions to the Earth’s Moon” in July of 2019. This NID defined sensitive regions (e.g., permanently shadowed regions) on the Moon and required reporting on missions to these sensitive areas. Meanwhile, a NASEM study on the impact of human activities on lunar polar volatiles and the scientific value of protecting the surface and subsurface regions of the Earth’s Moon from organic and biological contamination was initiated. This resulted in a NASEM report entitled, “Planetary Protection for the Study of Lunar Volatiles” which enabled further dialogue within NASA and with COSPAR. COSPAR PPP then leveraged this scientific consensus along with multi-agency input to develop an updated COSPAR Policy on Planetary Protection in June 2021 resulting in updated mission categorizations for Earth’s Moon (existing Category II for orbiters, and new categories IIa and IIb for landed missions). NASA then updated its current planetary protection policy to apply directly to NASA and NASA partnered missions in NASA Procedural Requirements (NPR) 8715.24 entitled, “Planetary Protection Provisions for Robotic Extraterrestrial Missions”. Along with the policy update NASA’s Office of Planetary Protection has worked with mission and programmatic teams to streamline reporting requirements to a simplified checkbox and fill-in-the-blank type of template. Throughout the abovementioned process, open and transparent communication between the policy makers and implementers was essential to ensure a balance with the updated policy, scientific intent, and practicality for each mission to be responsive and achieve mission success, including Artemis I and each of its secondary payloads, Gateway, CAPSTONE and Lunar Trailblazer.

James Benardini↗
NASA NTRS1994

Quality assurance and risk management: Perspectives on Human Factors Certification of Advanced Aviation Systems

This paper is based on the experience of engineering psychologists advising the U.K. Ministry of Defense (MoD) on the procurement of advanced aviation systems that conform to good human engineering (HE) practice. Traditional approaches to HE in systems procurement focus on the physical nature of the human-machine interface. Advanced aviation systems present increasingly complex design requirements for human functional integration, information processing, and cognitive task performance effectiveness. These developing requirements present new challenges for HE quality assurance (QA) and risk management, requiring focus on design processes as well as on design content or product. A new approach to the application of HE, recently adopted by NATO, provides more systematic ordering and control of HE processes and activities to meet the challenges of advanced aircrew systems design. This systematic approach to HE has been applied by MoD to the procurement of mission systems for the Royal Navy Merlin helicopter. In MoD procurement, certification is a judicial function, essentially independent of the service customer and industry contractor. Certification decisions are based on advice from MoD's appointed Acceptance Agency. Test and evaluation (T&E) conducted by the contractor and by the Acceptance Agency provide evidence for certification. Certification identifies limitations of systems upon release to the service. Evidence of compliance with HE standards traditionally forms the main basis of HE certification and significant non-compliance could restrict release. The systems HE approach shows concern for the quality of processes as well as for the content of the product. Human factors certification should be concerned with the quality of HE processes as well as products. Certification should require proof of process as well as proof of content and performance. QA criteria such as completeness, consistency, timeliness, and compatibility provide generic guidelines for progressive acceptance and certification of HE processes. Threats to the validity of certification arise from problems and assumptions in T&E methods. T&E should seek to reduce the risk of specification non-compliance and certification failure.

Taylor, Robert M.↗
NASA NTRSDate not supplied

Designing for Advanced Aerial Mobility: Human-Autonomy Teaming and In-Time System-Wide Safety Assurance

The continued growth of aviation shall require new innovative technologies and operational concepts to meet the ever-increasing demands on air transportation. The NASA Advanced Air Mobility (AAM) project focuses on emerging aviation markets, such as Urban Air Mobility (UAM). UAM is defined as “...a safe and efficient system for air passenger and cargo transportation within an urban area. It is inclusive of small package delivery and other urban unmanned aerial system services and supports a mix of onboard/ground-piloted and increasingly autonomous operations” ([1]). The AAM project emphasizes technology development and validating system-level concepts and solutions in coordination with other NASA Aeronautics Research Mission Directorate (ARMD) projects to enable UAM metro- and micro-plex vertiport and airspace concepts of operations. The NASA AAM research portfolio includes the concepts of Remote Supervisor-in-Command (RSC) and Fleet and Airspace Manager (FAM) as possible human roles for consumer fleet providers. NASA research in RSC is focused on development of guidelines and standards for remote pilots/operators passively and actively controlling a large fleet of autonomous aircraft. For FAM, flight and ground system concepts and technologies to enable high density homogeneous operations at increased scale from vertiport(s), and coordination with other humans in the systems (e.g., UAM urban airspace manager, Air Traffic Control) are key research areas. The envisioned UAM operations are posited to require autonomous systems to enable functions ranging from fleet and resource management to vehicle control. Although automation has become increasingly sophisticated and ubiquitous in civil aviation, autonomy represents a significant evolution in automation, which has generally been limited in functional scope and capability. As autonomy takes on increasing responsibilities, humans and machines will be required to work together in new and different ways [2], rather than traditional design approaches focused on how machines (i.e., autonomy) can do the work of people. The emerging field of human-autonomy teaming (HAT) represents a comprehensive and prioritized research-driven approach to enable the success of future emerging aviation market applications through capabilities and principles that facilitate humans and machine working and thinking better together. The NASA Transformational Tools and Technologies (TTT) Autonomous System (AS) Sub-project was created to assist with the transition into higher levels of autonomy to enable new modes of air transportation, such as UAM. TTT-AS has identified HAT as a key research need to enable UAM while maintaining today’s ultra-safe aviation system safety levels. The latter challenge has been taken up by the NASA System-Wide Safety (SWS) Project, which recognizes that aviation safety, as it evolves, shall require new ways of thinking about safety to include integration of a wide-range of existing and new safety systems and practices, enhanced tools and technologies, increased access to data and data fusion, improved data analysis capabilities, enhanced in-time risk monitoring and detection, hazard prioritization and mitigation, safety assurance decision-support, and in-time integrated system analytics [3].The operational concept of UAM represents a variety of work that has been termed, “work-as-imagined” to characterize the idea that how people think that work is done and how work is actually done are often not the same [4]. To ensure design success and system safety, looking at “work-as-done” provides a comparative approach toward UAM concept and technology design through examination of corresponding analogs found today in aviation (e.g., on-demand operations) and other transportation domains (e.g., port operations). The paper shall discuss various alternative applications with specific focus on airline operation center (AOC) operations, and unmanned aerial system (UAS) command-and-control to inform scaled-versions of FAM and RSC, respectively, and with consideration of the national airspace system contextual environment. The tenets and principles of the HAT field and current NASA research efforts under the TTT-AS sub-project shall also be described. Finally, the SWS sub-project efforts to develop In-Time System-Wide Safety Assurance (ISSA) and In-Time Safety Management Systems (IASMS) are discussed in terms of how “in-time” safety assurance may be conceptualized for the on-demand mobility air taxi “work-as-imagined” operational concept [5]. As part of this effort, concepts from the emerging field of resilience engineering, are being studied. Traditional approaches to aviation safety have focused on what can go wrong and how to prevent it. Another approach to thinking about system safety should reflect not only “avoiding things that go wrong” (protective safety) but also “ensuring that things go right” (productive safety), that enables a system to exhibit the resilient performance [6] necessary for the success of the future aviation system emerging concepts of operations. The paper shall describe efforts focused on how productive safety and resilience may enable a more complete approach to system safety thinking and design of ISSA and IASMS for UAM. Future directions and research needs shall also be discussed.

resilience↗
NASA NTRS2018

The OpenSE Cookbook: A Practical, Recipe Based Collection of Patterns, Procedures, and Best Practices for Executable Systems Engineering for the Thirty Meter Telescope

The OpenSE Cookbook is an open-sourced collection of patterns, procedures, and best practices targeted for systems engineers who seek guidance on applying model-based and executable systems engineering (MBSE) using SysML. Its content has emerged from the system level modeling effort on the European Framework Program 6 (FP6) and the Thirty Meter Telescope (TMT). The TMT MBSE approach applied the Executable Systems Engineering Method (ESEM) and the open-source Engineering Environment (OpenMBEE) to specify, analyze, and verify requirements of TMT’s Alignment and Phasing System (APS) and the Narrow Field Infrared Adaptive Optics System (NFIRAOS). In these applications, implicit dependencies are made explicit in a formal model through the use of ESEM, OpenMBEE, and SysML modeling constructs. The value proposition for applying this MBSE approach was to establish precise requirements and fine-grained traceability to system designs, and to verify key requirements beginning early in development. The integration of ESEM and the OpenMBEE tooling infrastructure (providing linked-data and web-operability) is a significant added value for the MBSE approach. The APS is responsible for the overall pre-adaptive optics wavefront quality, using starlight to measure wavefront errors and align the TMT optics. In the formally integrated and executable SysML model, simulations are performed to analyze the impact of changed requirements and verify specified constraints for various operational scenarios. The APS team used several modeling patterns to capture information such as the requirements, the operational scenarios, involved subsystems and their interaction points, the estimated or required time durations, and the mass and power consumption. Adaptive optics systems are designed to sense real-time atmospheric turbulence and correct the telescope’s optical beam to remove its effect. The system model for the adaptive optics operational modes was developed to capture sequence behaviors and operational scenarios to run Monte-Carlo simulations for verifying acquisition time, observing efficiency, and operational behavior requirements. The model is particularly useful for investigating the effect of parallelization, identifying interface issues, and re-ordering sequence acquisition tasks. A former version of the Cookbook (which is now updated to MBSE challenges, goals, and lessons learned) included modeling guidelines and conventions for all system aspects, hierarchy levels, and views, which were developed during for the Active Phasing Experiment (APE), an opto-mechatronical system technology demonstrator for the Extremely Large Telescope (ELT). The Cookbook utilizes the above mentioned system models as real-world case-studies to demonstrate and document the applications of the recipes, providing also instructional examples and addressing the available tooling support. The Cookbook is accompanied by a number of SysML models and aodel libraries which facilitate model authoring and maintenance. The Cookbook covers the different aspects of Systems Engineering such as management of Requirements, Design (behavior and structure), Interfaces, Interdisciplinary Integration, Analysis, Trade Studies, and Technical Resources. This paper presents the background, motivation, architecture, and highlights some key content of the Cookbook. For example, interface management, error budget management, requirements verification, Monte Carlo driven analysis, and timing analysis of operational scenarios. The paper discusses how the capabilities of OpenMBEE contributed significantly to the adoption of executable systems engineering.

Brower, Eric↗
NASA NTRS1984

Report of the Panel on Propulsion

Propulsion, while conventionally included on the list of important aeronautical disciplines along with aerodynamics, structures, etc., is in itself a systems endeavor, analogous to the engineering of the entire vehicle; indeed propulsion encompasses important aspects of all the other disciplines. In recognition of this fact, the panel focused its discussion on those aspects of the key disciplines that are especially or uniquely important to propulsion. From the initial development of the airplane, the propulsion system has been recognized as one of the pacing technologies. It is perhaps because of the technological disparity between the reciprocating engine and the primitive airframe that the two remained relatively and separate, were developed somewhat independently, usually by different organizations. In recent years, the maturing of the gas turbine power plant and the advance in high-speed airframes have rendered this separation somewhat artificial. The power plant and the airframe now share common structural and aerodynamic elements; as the flight Mach number rises, the degree of interaction increases. By the year 2000, this interdependence will have increased in many respects to a point where independent design may not be practical or possible. During the period since the initiation of the aircraft gas turbine, the solid propellant rocket and the liquid propellant rocket, a vast array of other novel engines have been studied, covering the full spectrum of flight conditions from low subsonic to hypersonic and transatmospheric flight. In each instance, performance limits have been investigated under the assumption that current technology or reasonably foreseeable technology would be available for their development. Among the extensive list of advanced, high-performance concepts and cycles examined are the hypersonic ramjet, the variable cycle, runway-to-orbit airbreathing engine, the ram rocket (airbreathing and rich solid propellant rocket), and the air turborocket. At various times, these systems have come relatively close to meriting development and application. In many instances, limitations of materials and technologies curtailed development. As important and with almost equal frequency, the lack of commercial or military utility of the concept precluded the necessary funding. It is instructive to note that two former items on this list, the turbofan (bypass engine) and the high-speed turboprop, are respectively a mainstay engine and a promising development. In the case of the turbofan, its full potential could not be realized until turbine cooling technology had been developed and new materials developed to permit the construction of transonic fans. In the case of the highspeed turbopropeller engine, not only were the material and turbine technologies needed, but, in addition, the rise in fuel costs provided the impetus to take advantage of its favorable fuel consumption characteristic. As the basic technologies progress and as new missions become attractive, the engines in the foregoing list become candidates for new feasibility studies and further technology development. At the present time, the ram rocket is the prime contender to augment the range of small missiles. Of interest also is the hypersonic ram jet and its logical extension, the runway-to-orbit airbreathing engine. Much of this report deals with the development of current or near-future power plant concepts. First, the motivating factors for aeronautical propulsion research are reviewed as a reminder of the importance of continued effort in a field that has often been characterized as mature. Next, technical areas are discussed in which the panel feels additional research effort is warranted and would lead to the realization of the technological potentials between now and the year 2000. Under these guidelines, new cycles (e.g., isothermal energy exchange) were not considered by the panel. Finally, although facility requirements were not a prime consideration in the current projections, the panel believes that the increasing complexity of propulsion systems; the need for more refined interaction between propulsion system, airframe, and controls; and increasing operation in adverse weather will require test capabilities beyond those now available (see appendix). Enhanced test capability is needed in the areas of propulsion airframe integration and in largescale icing research with proper concurrent treatment of altitude, temperature, and speed.

Kerrebrock, Jack L.↗