Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “architect”

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 55 records · Page 3

Re-Architecting the NASA Wire Derating Approach

• Design of wiring for aerospace vehicles relies on an understanding of “ampacity,” which refers to the current carrying capacity of wires, individually or in wire bundles. • Designers rely on standards to derate allowable current flow to prevent exceedance of wire temperature limits due to resistive heat dissipation within the wires or wire bundles. Designers select wire sizing and circuit protective device settings/sizing based on the standards. • Exceeding the wire temperature rating can result in electrical, physical, and/or chemical degradation of the wiring insulation and conductor which could lead to a catastrophic failure. • These standards can add considerable margin, in some cases underestimate the margin and are based on empirical data that is no longer available for review.

Steven L Rickman↗

Principles for Architecting Autonomous Systems

This paper distills principles for developing autonomous systems based on experience and lessons learned from past efforts. The purpose of these principles is to establish a common understanding and knowledge of architectural elements to guide the development of next-generation multi-mission autonomous systems and ensure the safe and productive operation of space assets. An attempt has been made to ground these principles in fundamentals that should withstand the test of time while allowing for and enabling the advancement of technologies. They are not intended to prescribe a design nor a software representation. There may be multiple designs that can honor these principles. These principles are focused on autonomy for robotic assets. As such, they do not address autonomy for crewed assets nor autonomy that can collectively generate intelligent behavior without top-level system cognizance (e.g., intelligent swarm behavior). These areas would be a subject of future efforts.

Day, John↗

Deformable Mirror Technology Roadmap: Architecting A Path to TRL5 for Future Exoplanet Direct Imaging Space Missions

The Deformable Mirror Technology Roadmap (DMTR) is a working group tasked by NASA’s Exoplanet Program Office to study the path to bring deformable mirror (DM) systems to a Technology Readiness Level 5. DMs, and their drive electronics and harnessing, are the critical component of any exoplanet direct imaging coronagraph, and there is no device that exists today which can meet the ambitious performance goals expected for NASA’s Habitable Worlds Observatory (HWO). Here we present progress on surveying the field of DM technologies, defining a first cut set of device requirements, and recommending a development and verification maturation program.

Tyler D. Groff↗

NASA’s Use of MBSE and SysML Modeling to Architect the Future of Human Exploration

One of the key roles of National Aeronautics and Space Administration (NASA) is to help mitigate the risk and lower expenses associated with space exploration, science, and discovery to the point where industry and international partners are willing and able to profitably take on larger, more complex missions. To do this, the Agency must undertake a transformation to a more modern integrated Digital Engineering approach to mission definition and planning. This paper highlights NASA’s journey in understanding what this Digital Engineering Transformation means for the Agency, the benefits of this transformation to human exploration definition and planning, and the benefits to the current Artemis campaign engineering capability portfolio.

Engineering Digital Transformation↗

Building Specifications

The building in the top photo is the new home of the National Permanent Savings Bank in Washington, D.C., designed by Hartman-Cox Architects. Its construction was based on a money-saving method of preparing building specifications which derived from NASA technology developed to obtain quality construction while holding down cost of launch facilities, test centers and other structures. Written technical specifications spell out materials and components to be used on construction projects and identify the quality tests each item must pass. Specifications can have major impact on construction costs. Poorly formulated specifications can lead to unacceptable construction which must be replaced, unnecessarily high materials costs, safety hazards, disputes and often additional costs due to delays and litigation. NASA's Langley Research Center developed a novel approach to providing accurate, uniform, cost-effective specifications which can be readily updated to incorporate new building technologies. Called SPECSINTACT, it is a computerized - system accessible to all NASA centers involved in construction programs. The system contains a comprehensive catalog of master specifications applicable to many types of construction. It enables designers of any structure to call out relevant sections from computer storage and modify them to fit the needs of the project at hand. Architects and engineers can save time by concentrating their efforts on needed modifications rather than developing all specifications from scratch. Successful use of SPECSINTACT has led to a number of spinoff systems. One of the first was MASTERSPEC, developed from NASA's experience by Production Systems for Architects and Engineers, Inc., an organization established by the American Institute of Architects. MASTERSPEC, used in construction of the bank building pictured, follows the same basic format as SPECSINTACT and can be used in either automated or manual modes. The striking appearance of the bank building shows that, while MASTERSPEC saves time and money, its use involves no sacrfice in architectural design freedom. The Naval Engineering Facilities Command employs an automated specifications system based on SPECSINTACT. The Public Buildings Service of the General Services Administration used SPECSINTACT as a starting point in a plan to make its guideline specifications available to architects and engineers on a nationwide computer network. Public Technology, Inc., a NASA Technology Application Team, is working with Production Systems for Architects and Engineers, Inc., to promote widespread use of the system by state and local governments for cost benefits to taxpayers.

Source record↗

Space Architecture: The Role, Work and Aptitude

Space architecture has been an emerging discipline for at least 40 years. Has it arrived? Is space architecture a legitimate vocation or an avocation? If it leads to a job, what do employers want? In 2002, NASA Headquarters created a management position for a space architect whose job was to "lead the development of strategic architectures and identify high level requirements for systems that will accomplish the Nation's space exploration vision." This is a good job description with responsibility at the right level in NASA, but unfortunately, the office was discontinued two years later. Even though there is no accredited academic program or professional licensing for space architecture, there is a community of practitioners. They are civil servants, contractors and academicians supporting International Space Station and space exploration programs. In various ways, space architects currently contribute to human spaceflight, but there is a way for the discipline to be more effective in developing solutions to large scale complex problems. This paper organizes contributions from engineers, architects and psychologists into recommendations on the role of space architects in the organization, the process of creating and selecting options, and intrinsic personality traits including why they must have a high tolerance for ambiguity.

Griffin, Brand↗

Architectural design of the science complex at Elizabeth City State University

This paper gives an overall view of the architectural design process and elements in taking an idea from conception to execution. The project presented is an example for this process. Once the need for a new structure is established, an architect studies the requirements, opinions and limits in creating a structure that people will exist in, move through, and use. Elements in designing a building include factors such as volume and surface, light and form changes of scale and view, movement and stasis. Some of the other factors are functions and physical conditions of construction. Based on experience, intuition, and boundaries, an architect will utilize all elements in creating a new building. In general, the design process begins with studying the spatial needs which develop into an architectural program. A comprehensive and accurate architectural program is essential for having a successful building. The most attractive building which does not meet the functional needs of its users has failed at the primary reason for its existence. To have a good program an architect must have a full understanding of the daily functions that will take place in the building. The architectural program along with site characteristics are among a few of the important guidelines in studying the form, adjacencies, and circulation for the structure itself and also in relation to the adjacent structures. Conceptual studies are part of the schematic design, which is the first milestone in the design process. The other reference points are design development and construction documents. At each milestone, review and coordination with all the consultants is established, and the user is essential in refining the project. In design development phase, conceptual diagrams take shape, and architectural, structural, mechanical, and electrical systems are developed. The final phase construction documents convey all the information required to construct the building. The design process and elements described were applied in the following project.

Jahromi, Soheila↗

Architectural Analysis of Complex Evolving Systems of Systems

The goal of this collaborative project between FC-MD, APL, and GSFC and supported by NASA IV&V Software Assurance Research Program (SARP), was to develop a tool, Dynamic SAVE, or Dyn-SAVE for short, for analyzing architectures of systems of systems. The project team was comprised of the principal investigator (PI) from FC-MD and four other FC-MD scientists (part time) and several FC-MD students (full time), as well as, two APL software architects (part time), and one NASA POC (part time). The PI and FC-MD scientists together with APL architects were responsible for requirements analysis, and for applying and evaluating the Dyn-SAVE tool and method. The PI and a group of FC-MD scientists were responsible for improving the method and conducting outreach activities, while another group of FC-MD scientists were responsible for development and improvement of the tool. Oversight and reporting was conducted by the PI and NASA POC. The project team produced many results including several prototypes of the Dyn-SAVE tool and method, several case studies documenting how the tool and method was applied to APL s software systems, and several published papers in highly respected conferences and journals. Dyn-SAVE as developed and enhanced throughout this research period, is a software tool intended for software developers and architects, software integration testers, and persons who need to analyze software systems from the point of view of how it communicates with other systems. Using the tool, the user specifies the planned communication behavior of the system modeled as a sequence diagram. The user then captures and imports the actual communication behavior of the system, which is then converted and visualized as a sequence diagram by Dyn-SAVE. After mapping the planned to the actual and specifying parameter and timing constraints, Dyn-SAVE detects and highlights deviations between the planned and the actual behavior. Requirements based on the need to analyze two inter-system communication protocols that are representative of protocols used in the Aerospace industry have been specified. The protocols are related: APL s Common Ground System (CGS) as used in the MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) and the Radiation Belt Space Probes (RBSP) missions. The analyzed communications were implementations of the Telemetry protocol and the CCSDS File Delivery Protocol (CFDP) protocol. Based on these requirements, three prototypes of Dyn-SAVE were developed and applied to these protocols. The application of Dyn-SAVE to these protocols resulted in the detection of several issues. Dyn-SAVE was also applied to several Testbeds that have previously been used for experimentation earlier on this project, as well as, to other protocols and logs for testing its broader applicability. For example, Dyn-SAVE was used to analyze 1) the communication pattern between a web browser and a web server, 2) the system log of a computer in order to detect offnominal computer shut-down behavior, and 3) the actual test cases of NASA Goddard s Core Flight System (CFS) and automatically generated test cases in order to determine the overlap between the two sets of test cases. In all cases, Dyn-SAVE assisted in providing insightful conclusions about each of the cases identified above.

Lindvall, Mikael↗

Color Choice is Everything - Impacts Color makes to the Lighting Environment

When contracts are let out to design multiple systems in a vehicle, it is a challenge to maintain integration between system leads. Designers on niche systems, like lighting and control panel design, often get caught up in the challenge of designing the light source or visual interface and fail to include time in their schedule to work with system architects on how their lighting system will be integrated. Additionally, behavioral scientists, industrial designers, and materials engineers get caught up with the materials and look of the system, but often fail to consider how the selection of their materials could affect the certification or performance of electronic devices like lighting systems. Additionally, computer modeling of the system architecture often assumes a perfect environment without the clutter of actual human use (dirt, stowage, crowding). As a result, lighting systems, and backlit displays run the risk of being overdesigned or under designed. Engineers making the assumption that because they have no input or there is no requirement on work surface reflectance, make the assumption that they can t count on good material choices and thus may install more lighting than is necessary. While having more lights may seem better, for a vehicle that is trying to conserve power, more lights may not be a good option. On the other hand, designers who made the opposite assumption and designed a lighting system that only produced just enough light, often wind up with a system that did conserve power, but didn t produce enough light. These situations are exasperated when the system starts to be used and the models are not perfect anymore. The lack of coordination and iterative design not only can impact lighting levels within an environment, but also can affect color perception. This is because, if materials do not represent a gradation of white or black, the material unevenly absorbs and reflects light at different wavelengths of the visual spectrum. The lighting designer may have built a light that meets light spectra requirements, but the eventual light reaching the human user may not be the spectra of light architects intended, if materials near the light source change the spectrum just by how much color is absorbed or reflected. With the recent findings concerning Circadian rhythm, where the spectra of light is extremely important for addressing crew sleep and wake cycles, system architects should pay considerable attention on the impact material choices have in changing the light spectrum in an environment. This presentation will show examples of how material choices impact the resulting illuminance, color spectrum, and power usage of an illuminated space. Its goal is to encourage system designers and planners to use more care in development of requirements and the verification of systems intended for the human visual interface.

Clark, Toni A.↗

Certification-Based Process Analysis

Space mission architects are often challenged with knowing which investment in technology infusion will have the highest return. Certification-based analysis (CBA) gives architects and technologists a means to communicate the risks and advantages of infusing technologies at various points in a process. Various alternatives can be compared, and requirements based on supporting streamlining or automation can be derived and levied on candidate technologies. CBA is a technique for analyzing a process and identifying potential areas of improvement. The process and analysis products are used to communicate between technologists and architects. Process means any of the standard representations of a production flow; in this case, any individual steps leading to products, which feed into other steps, until the final product is produced at the end. This sort of process is common for space mission operations, where a set of goals is reduced eventually to a fully vetted command sequence to be sent to the spacecraft. Fully vetting a product is synonymous with certification. For some types of products, this is referred to as verification and validation, and for others it is referred to as checking. Fundamentally, certification is the step in the process where one insures that a product works as intended, and contains no flaws.

Knight, Russell L.↗

Future Homes in Space: Development of Concepts for Exploration Space Habitats

NASA’s Artemis campaign seeks to return humans to the moon and establish a sustained presence on the lunar surface. This session will emphasize how habitation capabilities on the moon and in cislunar space can potentially contribute to the sustainability objectives of Artemis. Habitable elements represent opportunities to enable longer duration stays, increase the number of crew members present, enhance science and utilization activities, drive technology development for future Mars exploration, perform analog missions, and fuel economic opportunities for US industry. Panelists include Paul Kessler (NASA Marshall Space Flight Center, deputy lead for lunar surface habitation); Andrew Choate (NASA Marshall Space Flight Center, Mars habitation lead); Krystofer Dudzinski (NASA Marshall Space Flight Center, a space architect within the MSFC Advanced Concepts Office); and Larry Toups (retired from NASA Johnson Space Center, currently an adjunct professor at University of Houston in space architecture). The panel is moderated by Tracie Prater (NASA Marshall Space Flight Center, Habitation Systems Development Office). The panel will begin with an overview of the history of habitation concepts and an academic perspective on general considerations in space habitat design (Larry Toups). Paul Kessler and Andrew Choate will introduce NASA’s principle of “architecting from the right” to help define objectives for Artemis missions, needs/characteristics, use cases, and functions (as published in the agency’s Architecture Definition Document) and provide perspective on how this principle informs habitation concept development work. NASA panelists will discuss key engineering challenges identified for developing, deploying, and operating habitable assets on the lunar surface and/or in deep space. These may include dust mitigation, outfitting of inflatable softgoods (for concepts which may use softgoods as a primary structural material), survival in lunar darkness, human health and performance considerations, maintenance/repair/sparing, and autonomy. These identified challenges represent risks for habitation systems development and relate closely to capability gaps identified by the agency. While the work of NASA Marshall Space Flight Center’s habitation development office is primarily focused on habitats which are launched from earth pre-integrated (referred to as Class I in the framework previously developed by NASA space architects Kennedy/Cohen) or launched from earth and deployed at the point of use (Class II), there is also extensive work in NASA, academia, and companies on constructed habitats, which would be built on a planetary surface using indigenous resources (Class III habitats). Panelist Krystopher Dudzinski will discuss potential evolutionary pathways from Class I and Class II habitats to Class III habitats, unique and common architectural challenges within each habitat class, and key gaps in implementing Class III habitats from an architectural perspective. NASA panelists and the moderator will also provide an overview of partnership opportunities and avenues for further engagement to advance habitation systems for the SpaceCom audience. NASA is currently developing notional concepts for a lunar surface habitat and Mars transit habitat, which will be discussed during this panel session and used as examples. These concepts represent options for habitation system design and are a point of departure. They do not represent a final plan or formal recommendation on the part of the agency. Based on the most recent analysis cycle, NASA’s lunar surface habitat (SH) concept nominally supports two crew members for 30 days, with the capacity to support four crew during a surge period where crew will swap between the SH and another surface asset, such as a pressurized rover. This example design has a metallic airlock for ingress/egress and the upper portion is an inflatable material system which serves as the habitation module. The notional interior of the habitat is a three-deck layout/configuration which supports all crew mission functions, including exercise, stowage, extravehicular activity (EVA), sleep, hygiene waste collection, maintenance and repair, and meal preparation. Under analysis assumptions for habitation, the Mars Transit Habitat (TH) concept would support four crew on an up to 1,200 day Mars mission. One option for the concept is to initially dock Transit Habitat at Gateway, where it can be used to increase the duration of crew stays in cislunar space and perform shakedown and analog missions prior to a Mars departure. One challenge in longer duration missions which involve both surface exploration and transit is understanding crew adaptation when transitioning between partial gravity and microgravity environments. TH at Gateway offers an opportunity to study this transition and in doing so reduce risks associated with future Mars exploration. Like lunar SH, the most recent analysis cycle concept of a Mars TH is a hybrid structure design, with a metallic section supporting EVAs, axial/radial docking, and Safe Haven capabilities, and an inflatable softgoods structure for the primary habitation function. Interior layouts to optimize crew usability and livability are currently under trade. The panel will include presentation material, but also seeks to engage the audience in a highly interactive conversation regarding the potential role for habitation in future exploration initiatives. Potential topics for discussion include the influence of the crew experience on habitation systems design and livability/usability considerations, the benefits of space habitation development in terrestrial applications, and challenges and opportunities in “feeding forward” lunar surface habitation systems development to Mars exploration.

space habitats↗

Fault tolerant system performance modeling

With the proliferation of complex digital systems on aircraft, the need to accurately predict system performance early in the system design cycle becomes imperative. In the past, system designers have relied on ad hoc methods for evaluating performance issues. This has produced systems that have not always worked as originally intended. To alleviate these design deficiencies, formal methods, with supporting tools, must be adhered to during the system design process. The use of performance modeling tools is becoming widely accepted as a way to address timing considerations of system design. An additional incentive for the use of these tools is that they allow the system architect to analyze system component interactions (i.e., bus contention, contention of functions for a processing site, and system repair activity on application performance). This inherent flexibility can result in an explicit specification of the system architecture. This paper addresses a method that supports performance modeling of fault tolerant systems using a discrete event simulation tool. An additional focus is on lessons learned from analyzing these classes of problems. The methodology and supporting work provide system architects with the capability to specify candidate architectures and accurately predict their performance in the early stages of design, where changes to system design is most cost effective. The work has been supported under NASA contract NAS1-18099. Integrated Airframe Propulsion Control System Architecture (IAPSA II). This contract addresses methodology, analysis, and detailed design of integrated control system architectures suitable for high-performance aircraft of the 1990's.

Discrete event simulation↗

Architecture in Mission Integration, Choreographing Constraints

In any building project the Architect's role and skill is to balance the client's requirements with the available technology, a site and budget. Time, place and resources set the boundaries and constraints of the project. If these boundaries are correctly understood and respected by the Architect they can be choreographed into producing a facility that abides by those constraints and successfully meets the clients needs. The design and assembly of large scale space facilities whether in orbit around or on the surface of a planet require and employs these same skills. In this case the site is the International Space Station (ISS) which operates at a nominal rendezvous altitude of 220 nautical miles. With supplies to support a 7 day mission the Shuttle nominally has a cargo capacity of 35,000 pounds to that altitude. Through the Mission Integration process the Launch Package Management Team choreographs the constraints of ascent performance, hardware design, cargo, rendezvous, mission duration and assembly time in order to meet the mission objective.

Jones, Rod↗