Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “function as a service”

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 235 records · Page 13

System requirements

Requirements of future space systems, including large space systems, that operate beyond the space shuttle are discussed. Typical functions required of propulsion systems in this operational regime include payload placement, retrieval, observation, servicing, space debris control and support to large space systems. These functional requirements are discussed in conjunction with two classes of propulsion systems: (1) primary or orbit transfer vehicle (OTV) and (2) secondary or systems that generally operate within or relatively near an operational base orbit. Three propulsion system types are described in relation to these requirements: cryogenic OTV, teleoperator maneuvering system and a solar electric OTV.

Austin, R. E.↗

Uncrewed Lunar Surface Operations and Support Activities

Sustained human presence on the surface of the Moon and future missions to Mars require increased independence from surface crews and Earth-based mission control to operate efficiently, safely, and reliably. The time for surface crews to perform tasks will be limited. Extravehicular activities by surface personnel are burdensome and time-consuming, even when a continuous human presence on the surface occurs. Identifying and balancing human/automation roles and tasks and infusing automation and autonomy practices early in a system’s lifecycle will be essential to achieve mission objectives. Among these objectives are attaining a sustained human presence, improving performance and mission effectiveness, reducing operations and maintenance (O&M) costs, and ensuring operations that are robust to communication delays. To achieve these objectives, an operational shift toward increased automation and autonomy with less reliance on humans is needed. Uncrewed lunar surface operations and support activities occur when surface crews are not present or are independent of surface crew timeline activities requiring no surface crew oversight or intervention. These uncrewed surface opportunities can also be planned to minimize crew workload that avoids routine maintenance and support tasks, thus maximizing crew exploration time. Uncrewed preparations such as staging and prepositioning equipment and materials before the crew arrives could improve crew task efficiency. Additional opportunities exist to conduct uncrewed science, exploration, and utilization. Uncrewed surface architecture functions can include science and exploration; habitation; launch and landing support; surface communication and navigation; surface power generation and distribution; human surface mobility; lifting, handling, manipulating; excavation, construction, and site preparation; logistics management; maintenance and repair; surface resource utilization; integrated site operations and shared support services (e.g., site scheduling/prioritization, dust mitigation/contamination control, and surface safety). Early robotic lunar surface campaigns will provide information on the availability of resources, such as oxygen and water, and demonstrate surface-based technologies. After the Artemis III human lunar return mission, a series of landers will deliver surface systems, cargo, supplies, science packages, spare parts, and commodities. A balance of crewed and uncrewed surface operations will enable a sustained lunar surface presence at the South Pole of the Moon at a site that will be known as the Artemis Base Camp (ABC). It is envisioned that base camp operations on and around the Moon will then help prepare for the mission durations and activities needed to support the first human mission to Mars. Before long-duration crew missions to the base camp can occur, the necessary surface infrastructure will be pre-deployed and verified operational. Surface assets will be teleoperated and remotely managed from Earth. Additionally, robotic and short-duration crewed missions to the ABC will ensure the site’s merit to achieve long-term science objectives, availability of usable resources, and that terrain, seasonal variations, and illumination conditions are acceptable. ABC will consist of different areas where specific functions and services are rendered, including: • Launch and Landing Area • Habitation Area • Power Production Area • Resource Areas Launch and Landing Area—The launch and landing area will support associated functions for the arrival and departure of vehicles, such as crewed landing and ascent and uncrewed cargo deliveries and offloading. It will evolve from an unimproved site at the beginning of the exploration campaign to a more sustainable landing and launch area that can support repeated arrivals and departures. Initial uncrewed Lunar Terrain Vehicle (LTV) surface operations may include emplacement of navigation beacons and communication equipment, real-time video and photography of landing/liftoff events, and element repositioning, such as portable utility power (PUP) (applicable for other landed assets at other areas). Site preparations, such as surface leveling, soil compaction, and berm/path construction, may be needed for a more sustainable launch and landing area capable of accommodating vehicles that are increasingly more reusable and reduce the effects of plume surface interactions and ejecta impacts on nearby surface assets. During the ABC missions, cargo and logistics will be delivered to the lunar surface via robotic cargo landers before the crew arrives. These shipments, which can arrive in pressurized logistics carriers, will deliver the logistics necessary to support a crewed mission and include items such as food, water, equipment spares, etc. Providing the capability to retrieve, offload, and transport the logistics closer to the ABC site before the arrival of the crew will increase the overall efficiency of crew operations once they arrive. In the sustained phase of exploration, other supporting services may be needed, such as lander propellant servicing, surface power services, commodity refreshes, and additional inspection, maintenance, and repair capabilities, to sustain a cadence of extended personnel stays and cargo arrivals and departures. Habitation Area—Uncrewed support to surface habitation could involve supporting activation and pre-entry operations of the habitat while the crew is in orbit at the Gateway outpost preparing for a surface landing. Surface Habitat (SH) uncrewed operations may include bringing the cabin environment to a habitable temperature and air mix and activating other critical crew support systems. Potential crop production uncrewed tasks in the SH could also include autonomous watering and tending. Additionally, when the crew departs, the SH enters dormancy for the long period of uncrewed operation. A logistical staging area could also be collocated near the SH. If so, staging operations for crew supplies, waste re-location, and recycling operations may be opportunities for uncrewed operations. Power Production Area—The Fission Surface Power (FSP) element and its supporting distribution equipment provide power to surface elements as needed across the ABC to supplement day-to-day operations and survive lunar nights. Uncrewed support of this power system includes any initial LTV-assisted deployments of cables and other distributed equipment, associated electrical connections, and system testing and activation operations. Robotically performing some inspections, maintenance, or repair tasks on the power distribution equipment could reduce the surface crew workload. Resource Area— Uncrewed resource prospecting, mapping, and characterizing possible resource sites is likely to be time-consuming and represents an opportunity for uncrewed operations between crewed missions. Uncrewed mobile equipment operations will be needed in the extreme environments of permanently shadowed locations where resource extractions occur. As In-Situ Resource Utilization (ISRU) pilot plant operations begin, uncrewed surface support activities with available mobile and portable assets (LTV, PUP, etc.) will better support these operations. Any produced commodities can be stored at a centralized storage location for future use. Also associated with these operations is the use of mobile robotic excavators for resource acquisition and robotic/autonomous regolith processing. The waste tailings generated during excavation and regolith processing would also need to be transported and deposited at a dedicated location. Surface assets will continue operating between crew visits to maintain surface capabilities, conduct lunar surface science, technology demonstrations, and public outreach opportunities. Additionally, certain sustaining tasks that would consume valuable crew time could be performed before crew arrival, or after their departure. This capability may offer more affordable options to construct, activate, test, and maintain a broad set of surface assets. Telerobotically operated human surface mobility systems, such as the LTV and Pressurized Rover (PR), can be utilized for various tasks. Surface environmental conditions pose a distinct challenge for all these activities. Surface illumination and localized shadows are one such factor. Night-survival operations could consist of thermal management, battery pre-charging, and load shedding. Some surface systems may hibernate through the night and then awake and continue nominal operations. Uncrewed mobile assets may use a more adaptive approach to optimize their power and operations; one method is to follow the sunlight. Night-survival operations may be initiated remotely by teleoperation, automated, or accomplished by supervised autonomous operation. The ability to pre-deploy and control remote assets in orbit or on Mars before the arrival of the mission crew is a key capability that can be simulated on the moon. The base camp provides a venue where these advanced operational concepts, technologies, and autonomous methods and techniques, including the incorporation of time delays to simulate Earth-Mars latency can be replicated to help buy down future Mars mission risks. This paper will examine the evolution of uncrewed lunar surface operations and support activities. It will also discuss the lunar surface environmental conditions (thermal, lighting, terrain, topography, communications) along with the challenges they pose on uncrewed surface operations, and the performance of these activities with limited to minimal human interaction and/or teleoperation. Since lunar missions include Mars mission analogs, such investigation provides the framework for future uncrewed Mars mission support.

Mark E Lewis↗

Applying Reflective Middleware Techniques to Optimize a QoS-enabled CORBA Component Model Implementation

Although existing CORBA specifications, such as Real-time CORBA and CORBA Messaging, address many end-to-end quality-of service (QoS) properties, they do not define strategies for configuring these properties into applications flexibly, transparently, and adaptively. Therefore, application developers must make these configuration decisions manually and explicitly, which is tedious, error-prone, and open sub-optimal. Although the recently adopted CORBA Component Model (CCM) does define a standard configuration framework for packaging and deploying software components, conventional CCM implementations focus on functionality rather than adaptive quality-of-service, which makes them unsuitable for next-generation applications with demanding QoS requirements. This paper presents three contributions to the study of middleware for QoS-enabled component-based applications. It outlines rejective middleware techniques designed to adaptively (1) select optimal communication mechanisms, (2) manage QoS properties of CORBA components in their contain- ers, and (3) (re)con$gure selected component executors dynamically. Based on our ongoing research on CORBA and the CCM, we believe the application of rejective techniques to component middleware will provide a dynamically adaptive and (re)configurable framework for COTS software that is well-suited for the QoS demands of next-generation applications.

Wang, Nanbor↗

Applying Reflective Middleware Techniques to Optimize a QoS-enabled CORBA Component Model Implementation

Although existing CORBA specifications, such as Real-time CORBA and CORBA Messaging, address many end-to-end quality-of-service (QoS) properties, they do not define strategies for configuring these properties into applications flexibly, transparently, and adaptively. Therefore, application developers must make these configuration decisions manually and explicitly, which is tedious, error-prone, and often sub-optimal. Although the recently adopted CORBA Component Model (CCM) does define a standard configuration frame-work for packaging and deploying software components, conventional CCM implementations focus on functionality rather than adaptive quality-of service, which makes them unsuitable for next-generation applications with demanding QoS requirements. This paper presents three contributions to the study of middleware for QoS-enabled component-based applications. It outlines reflective middleware techniques designed to adaptively: (1) select optimal communication mechanisms, (2) man- age QoS properties of CORBA components in their containers, and (3) (re)configure selected component executors dynamically. Based on our ongoing research on CORBA and the CCM, we believe the application of reflective techniques to component middleware will provide a dynamically adaptive and (re)configurable framework for COTS software that is well-suited for the QoS demands of next-generation applications.

Wang, Nanbor↗

Executive and communications services to support the IPAD environment

The principal purposes of the prototype executive software are to provide a system independent interface to the underlying host system and to allow for extension to full IPAD executive services as described in the preliminary design. A basic set of functions is included in the prototype to meet the requirements of the other components of the prototype, principally IPID, the IPAD data management system. The functions were chosen so that they would be readily built on any of the proposed host systems with minimal redesign and execution overhead. The functions fall into five categories: access to host data, access to data files, access to communication services, data transformation, and instrumentation for performance measurement. Communication services provide message delivery between processes in a network of heterogeneous computers. Data transformation services and communication services ensure data type validity and data integrity of messages exchanged between processes.

Tanner, J. G.↗

Overview of NASA's Air Traffic Management - eXploration (ATM-X) Project

Projected increases in new vehicle types, new missions, and the continual growth in traditional (e.g., airlines, general aviation) aviation will require changes to the current air traffic system, particularly to accommodate the desire of operators to be more involved in air traffic decisions. To address these challenges, the National Airspace System needs to undergo a transformation to a more scalable, flexible, user-focused system that addresses safety and security requirements and resiliency for current and new users. A system designed to integrate modular software services, provided by users, third parties and government for air traffic management functions, will be scalable and more easily allow modernization and for collaboration between users and service providers. ATM-X is responding to NASA's pivot towards integrating projected new, diverse entrants into the NAS, while also leveraging NASA's prior ATM achievements that continue to improve traditional airspace operations. This project is a two-phased approach to conduct research and focused evaluations to assess the feasibility of a service-based approach and to identify critical design considerations to enable airspace access for new entrants, integrated with current traditional operations. Phase 1 research will be conducted to determine what is needed to reach the ATM-X goals based on specific use-cases to enable large-scale, passenger-carrying Urban Air Mobility operations in a metroplex environment, and also to improve traditional operations in the Northeast Region leveraging mature NASA technologies. Some of these evaluations will be conducted in simulations and field activities. Phase 2 will build upon Phase 1 towards more defined, focused research and field demonstrations in real-world environments to integrate multiple elements of a scalable, service-based ATM-X concept.

air traffic management↗

IsoWAN: A NASA Science and Engineering Information and Services Framework

We believe that the next evolutionary step in supporting wide-area application and services delivery to customers is a network framework that provides for collocation of applications and services at distinct sites in the network, an interconnection between these sites that is performance optimized for these applications, and value-added services for applications. We use the term IsoWAN to describe an advanced, isolated network interconnect services framework that will enable applications to be more secure, and able to access and be in use in both local and remote environments. The main functions of an IsoWAN are virtual localization of application services, an application service interface, coordinated delivery of applications and associated data to the customer, and supporting collaborative application development for customers. An initial pilot network between three NASA Centers: Ames Research Center, the Jet Propulsion Laboratory, and Marshall Space Flight Center, has been built and its properties will be discussed.

Korsmeyer, David J.↗

Servicing capability for the evolutionary Space Station

Since the beginning of the Space Station Freedom (SSF) program the concept of on-orbit servicing of user hardware has been an integral part of the program implementation. The user servicing system architecture has been divided into a baseline and a growth phase. The baseline system consists of the following hardware elements that will support user servicing - flight telerobotic servicer, crew and equipment translation aid, crew intravehicular and extravehicular servicing support, logistics supply system, mobile servicing center, and the special purpose dextrous manipulator. The growth phase incorporates a customer servicing facility (CSF), a station-based orbital maneuvering vehicle and an orbital spacecraft consumables resupply system. The requirements for user servicing were derived from the necessity to service attached payloads, free flyers and coorbiting platforms. These requirements include: orbital replacement units (ORU) and instrument changeout, National Space Transportation System cargo bay loading and unloading, contamination control and monitoring, thermal protection, payload berthing, storage, access to SSF distributed systems, functional checkout, and fluid replenishment. The baseline user servicing capabilities accommodate ORU and instrument changeout. However, this service is limited to attached payloads, either in situ or at a locally adjacent site. The growth phase satisfies all identified user servicing requirements by expanding servicing capabilities to include complex servicing tasks for attached payloads, free-flyers and coorbiting platforms at a dedicated, protected Servicing site. To provide a smooth evolution of user servicing the SSF interfaces that are necessary to accommodate the growth phase have been identified. The interface requirements on SSF have been greatly simplified by accommodating the growth servicing support elements within the CSF. This results in a single SSF interface: SSF to the CSF.

Thomas, Edward F.↗

Integrating Engineering Data Systems for NASA Spaceflight Projects

NASA has a large range of custom-built and commercial data systems to support spaceflight programs. Some of the systems are re-used by many programs and projects over time. Management and systems engineering processes require integration of data across many of these systems, a difficult problem given the widely diverse nature of system interfaces and data models. This paper describes an ongoing project to use a central data model with a web services architecture to support the integration and access of linked data across engineering functions for multiple NASA programs. The work involves the implementation of a web service-based middleware system called Data Aggregator to bring together data from a variety of systems to support space exploration. Data Aggregator includes a central data model registry for storing and managing links between the data in disparate systems. Initially developed for NASA's Constellation Program needs, Data Aggregator is currently being repurposed to support the International Space Station Program and new NASA projects with processes that involve significant aggregating and linking of data. This change in user needs led to development of a more streamlined data model registry for Data Aggregator in order to simplify adding new project application data as well as standardization of the Data Aggregator query syntax to facilitate cross-application querying by client applications. This paper documents the approach from a set of stand-alone engineering systems from which data are manually retrieved and integrated, to a web of engineering data systems from which the latest data are automatically retrieved and more quickly and accurately integrated. This paper includes the lessons learned through these efforts, including the design and development of a service-oriented architecture and the evolution of the data model registry approaches as the effort continues to evolve and adapt to support multiple NASA programs and priorities.

Carvalho, Robert E.↗

Work Function Matching Passive Lunar Dust Mitigation Coating Preparation for Lunar Flight Opportunity

With the Artemis program, NASA isplanning longer stays on the surface, with more activities that have the potential to put the astronauts and equipment in contact with greater quantities of lunar dust. The success of these missions will depend on our understanding of material interactions with lunar dust and the development of ways to mitigate dust effects. This is particularly truein cases where exposure to dust will lead to failure of components, unacceptable loss of power or thermal control, unacceptable loss of visibility, or health issues.Optically transparent, sputter deposited,work function matching coatings are being developed at NASA Glenn Research Center to reduce adhesion of dust to windows, lenses and display panels by matching the minimum energy to remove an electron from the surface to that oflunar dust in order to reduce adhesion due to charge transfer. One of these work function matching coatings will be tested as part of Aegis Aerospace Inc.’s Regolith Adherence Characterization experiment going to the lunar surface on a Commercial Lunar Payload Services (CLPS) lander in 2023. Preparation of the work function matching coating and initial characterization prior to delivery for flight integration will be discussed.

Lunar dust, passive mitigation, CLPS demonstration↗

A comparison of the Shuttle remote manipulator system and the Space Station Freedom mobile servicing center

The Shuttle Remote Manipulator System is a mature system which has successfully completed 18 flights. Its primary functional design driver was the capability to deploy and retrieve payloads from the Orbiter cargo bay. The Space Station Freedom Mobile Servicing Center is still in the requirements definition and early design stage. Its primary function design drivers are the capabilities: to support Space Station construction and assembly tasks; to provide external transportation about the Space Station; to provide handling capabilities for the Orbiter, free flyers, and payloads; to support attached payload servicing in the extravehicular environment; and to perform scheduled and un-scheduled maintenance on the Space Station. The differences between the two systems in the area of geometric configuration, mobility, sensor capabilities, control stations, control algorithms, handling performance, end effector dexterity, and fault tolerance are discussed.

Taylor, Edith C.↗

Asynchronous Message Service for Deep Space Mission Operations

While the CCSDS (Consultative Committee for Space Data Systems) File Delivery Protocol (CFDP) provides internationally standardized file transfer functionality that can offer significant benefits for deep space mission operations, not all spacecraft communication requirements are necessarily best met by file transfer. In particular, continuous event-driven asynchronous message exchange may also be useful for communications with, among, and aboard spacecraft. CCSDS has therefore undertaken the development of a new Asynchronous Message Service (AMS) standard, designed to provide common functionality over a wide variety of underlying transport services, ranging from shared memory message queues to CCSDS telemetry systems. The present paper discusses the design concepts of AMS, their applicability to deep space mission operations problems, and the results of preliminary performance testing obtained from exercise of a prototype implementation.

asynchronous message exchanges↗

What Do Our Users Want? Perspectives on Understanding and Meeting User Needs for Multi-Mission Data Services

The Sun-Earth Connection Active Archive (SECAA) project of NASA's Space Physics Data Facility operates a range of unique and heavily used multi-mission data services in support of the large-scale science objectives of the Great Observatory, including services such as CDAWeb, the CDAWeb Plus client, SSCWeb, OMNIweb and the CDF data format. In developing and operating these services, we have encountered and continue to struggle with a wide range of issues such as balancing scope and functionality with simplicity and ease of use, understanding the effectiveness of our choices and identifying areas most important for further improvement. In this paper, we will review our key services and then discuss some of our observations and new approaches to understanding and meeting user data service requirements. Some observations are obvious but may still have substantial implications; e.g. functionality without information content is of little user interest, which has led to our recent emphasis on development of web services interfaces, so the content and functionality we already serve is readily and fully available as a building block for new services. Some observations require careful design and tradeoffs; e.g. users will complain when they are offered interfaces with limited options but users are also easily intimidated and become lost when offered extensive options for customization. Some observations remain highly challenging; e.g. a comprehensive multi-mission, multi-source view of all data and services available easily produces a daunting list, but a more selective view can easily lead users to overlook available and relevant data. It is often difficult to obtain and meaningfully interpret measures of true productive usage and overall user satisfaction, even with a variety of techniques including statistics, citations, case studies, user feedback and advisory committees. Most of these issues will apply to and may even be more acute for distributed implementation architectures.

McGuire, Robert E.↗

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗

Gateway at the Crossroads of Sustainable Lunar Exploration

The Gateway Program has made substantial design and development progress toward delivering a small, human-tended lunar space station purposefully designed to enable sustainable human exploration. The Program integrates partners and providers organizationally and physically as part of the spacecraft. The Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO) with the European System Providing Refueling, Infrastructure and Telecommunications (ESPRIT) HALO Lunar Communications System (HLCS) have begun manufacturing the long lead components and will be launched first as a Co-Manifested Vehicle (CMV). The International Habitat (I-Hab) and ESPRIT Refueling Module (ERM) are passing life cycle milestones and include capabilities key for human crewmembers, such as windows, private sleeping quarters, and galley functions. The Logistics Module (LM) may provide a variety of services to Gateway depending on each mission. Requirements for the airlock have been developed, including requests that it support the integrated spacecraft with functions like augmenting heat rejection capabilities, and interfaces with new spacesuits will soon be developed in more detail. As a critical element of the architecture for solar system exploration, Gateway implements key tenets and features of international interoperability standards necessary to operate with multiple visiting vehicles and lunar assets, especially avionics, communications, and docking. Specific choices such as software architecture and standards, power standards, and robotics standards make it possible to utilize heritage or proprietary technology, yet still operate as one spacecraft. Engineering teams are evaluating many possible future missions to be executed at or utilizing the Gateway. The system architecture protects for an evolvable, extensible, and flexible capability. Designing systems robust enough to serve as a cornerstone of exploration activities for decades while remaining adaptable is not without its challenges. The detailed integration activities have revealed challenges and the need to mature key technologies. Refueling is a key component of achieving long life for Gateway, with unique operations to plan, safety concerns to mitigate, and risk reduction activities to conduct to better understand the system. The constraints and impacts of the design of visiting vehicles is also an important concern, with orientation constraints, control of attitude and orbit of the Gateway with docked visiting vehicles. Tradeoffs between robust maintainable systems and lightweight, compact systems must be balanced. Opportunities still exist for adding additional advanced capabilities to increase and extend Gateway’s benefits, such as intravehicular robotics, autonomous Guidance Navigation and Control (GN&C), and augmented control propulsion, heat rejection, or other services.

Molly S Anderson↗

Space Station crew workload - Station operations and customer accommodations

The features of the Space Station which permit crew members to utilize work time for payload operations are discussed. The user orientation, modular design, nonstressful flight regime, in space construction, on board control, automation and robotics, and maintenance and servicing of the Space Station are examined. The proposed crew size, skills, and functions as station operator and mission specialists are described. Mission objectives and crew functions, which include performing material processing, life science and astronomy experiments, satellite and payload equipment servicing, systems monitoring and control, maintenance and repair, Orbital Maneuvering Vehicle and Mobile Remote Manipulator System operations, on board planning, housekeeping, and health maintenance and recreation, are studied.

Shinkle, G. L.↗

Airspace Automation Flight Tabletop Exercise

Interconnections of new systems are needed for airspace automation capabilities required in Urban Air Mobility (UAM). FAA Concept of Operations (CONOPS) V1.0 shows Provider of Services for UAM (PSU) at the center of the notional architecture; however, the functional role of the PSU in data exchange and the path to get there is unclear. In partnership with Wisk Aero, Avision, ANRA, Collins Aerospace, OneSky, SkyGrid, and AURA, the NASA National Campaign held discussions and tabletop exercises to test the functional allocations and work flows between an aircraft operator, airspace providers, Command and Control Communication Service Providers (C2CSP), and FAA air traffic in a real-world scenario. The exercise included preplanning and execution of a passenger mission with nominal, contingency, and conflict management scenarios for initial UAM operations. This working paper describes initial conditions for the flight tabletop exercise, exercise summaries, lessons learned, and recommendations for future work.

National Campaign↗