Search NASA⌕ Search

SEARCH · Search NASA

Results for “distributed operations teams”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2

New Human-Computer Interface Concepts for Mission Operations

The current climate of budget cuts has forced the space mission operations community to reconsider how it does business. Gone are the days of building one-of-kind control centers with teams of controllers working in shifts 24 hours per day, 7 days per week. Increasingly, automation is used to significantly reduce staffing needs. In some cases, missions are moving towards lights-out operations where the ground system is run semi-autonomously. On-call operators are brought in only to resolve anomalies. Some operations concepts also call for smaller operations teams to manage an entire family of spacecraft. In the not too distant future, a skeleton crew of full-time general knowledge operators will oversee the operations of large constellations of small spacecraft, while geographically distributed specialists will be assigned to emergency response teams based on their expertise. As the operations paradigms change, so too must the tools to support the mission operations team's tasks. Tools need to be built not only to automate routine tasks, but also to communicate varying types of information to the part-time, generalist, or on-call operators and specialists more effectively. Thus, the proper design of a system's user-system interface (USI) becomes even more importance than before. Also, because the users will be accessing these systems from various locations (e.g., control center, home, on the road) via different devices with varying display capabilities (e.g., workstations, home PCs, PDAS, pagers) over connections with various bandwidths (e.g., dial-up 56k, wireless 9.6k), the same software must have different USIs to support the different types of users, their equipment, and their environments. In other words, the software must now adapt to the needs of the users! This paper will focus on the needs and the challenges of designing USIs for mission operations. After providing a general discussion of these challenges, the paper will focus on the current efforts of creatin(y an effective USI for one specific suite of tools, SERS (The Spacecraft Emergency Response System), which has been built to enable lights-out operations. SERS is a Web-based collaborative environment that enables secure distributed fault management.

Fox, Jeffrey A.↗

A Virtual Mission Operations Center: Collaborative Environment

The Virtual Mission Operations Center - Collaborative Environment (VMOC-CE) intent is to have a central access point for all the resources used in a collaborative mission operations environment to assist mission operators in communicating on-site and off-site in the investigation and resolution of anomalies. It is a framework that as a minimum incorporates online chat, realtime file sharing and remote application sharing components in one central location. The use of a collaborative environment in mission operations opens up the possibilities for a central framework for other project members to access and interact with mission operations staff remotely. The goal of the Virtual Mission Operations Center (VMOC) Project is to identify, develop, and infuse technology to enable mission control by on-call personnel in geographically dispersed locations. In order to achieve this goal, the following capabilities are needed: Autonomous mission control systems Automated systems to contact on-call personnel Synthesis and presentation of mission control status and history information Desktop tools for data and situation analysis Secure mechanism for remote collaboration commanding Collaborative environment for remote cooperative work The VMOC-CE is a collaborative environment that facilitates remote cooperative work. It is an application instance of the Virtual System Design Environment (VSDE), developed by NASA Goddard Space Flight Center's (GSFC) Systems Engineering Services & Advanced Concepts (SESAC) Branch. The VSDE is a web-based portal that includes a knowledge repository and collaborative environment to serve science and engineering teams in product development. It is a "one stop shop" for product design, providing users real-time access to product development data, engineering and management tools, and relevant design specifications and resources through the Internet. The initial focus of the VSDE has been to serve teams working in the early portion of the system/product lifecycle - concept development, proposal preparation, and formulation. The VMOC-CE expands the application of the VSDE into the operations portion of the system lifecycle. It will enable meaningful and real-time collaboration regardless of the geographical distribution of project team members. Team members will be able to interact in satellite operations, specifically for resolving anomalies, through access to a desktop computer and the Internet. Mission Operations Management will be able to participate and monitor up to the minute status of anomalies or other mission operations issues. In this paper we present the VMOC-CE project, system capabilities, and technologies.

Medina, Barbara↗

Spread and SpreadRecorder An Architecture for Data Distribution

The Space Acceleration Measurement System (SAMS) project at the NASA Glenn Research Center (GRC) has been measuring the microgravity environment of the space shuttle, the International Space Station, MIR, sounding rockets, drop towers, and aircraft since 1991. The Principle Investigator Microgravity Services (PIMS) project at NASA GRC has been collecting, analyzing, reducing, and disseminating over 3 terabytes of collected SAMS and other microgravity sensor data to scientists so they can understand the disturbances that affect their microgravity science experiments. The years of experience with space flight data generation, telemetry, operations, analysis, and distribution give the SAMS/ PIMS team a unique perspective on space data systems. In 2005, the SAMS/PIMS team was asked to look into generalizing their data system and combining it with the nascent medical instrumentation data systems being proposed for ISS and beyond, specifically the Medical Computer Interface Adapter (MCIA) project. The SpreadRecorder software is a prototype system developed by SAMS/PIMS to explore ways of meeting the needs of both the medical and microgravity measurement communities. It is hoped that the system is general enough to be used for many other purposes.

Wright, Ted↗

Habitat Demonstration Unit (HDU) Pressurized Excursion Module (PEM) Systems Integration Strategy

The Habitat Demonstration Unit (HDU) project team constructed an analog prototype lunar surface laboratory called the Pressurized Excursion Module (PEM). The prototype unit subsystems were integrated in a short amount of time, utilizing a rapid prototyping approach that brought together over 20 habitation-related technologies from a variety of NASA centers. This paper describes the system integration strategies and lessons learned, that allowed the PEM to be brought from paper design to working field prototype using a multi-center team. The system integration process was based on a rapid prototyping approach. Tailored design review and test and integration processes facilitated that approach. The use of collaboration tools including electronic tools as well as documentation enabled a geographically distributed team take a paper concept to an operational prototype in approximately one year. One of the major tools used in the integration strategy was a coordinated effort to accurately model all the subsystems using computer aided design (CAD), so conflicts were identified before physical components came together. A deliberate effort was made following the deployment of the HDU PEM for field operations to collect lessons learned to facilitate process improvement and inform the design of future flight or analog versions of habitat systems. Significant items within those lessons learned were limitations with the CAD integration approach and the impact of shell design on flexibility of placing systems within the HDU shell.

Gill, Tracy↗

MODIS Land Data Products: Generation, Quality Assurance and Validation

The Moderate Resolution Imaging Spectrometer (MODIS) on-board NASA's Earth Observing System (EOS) Terra and Aqua Satellites are key instruments for providing data on global land, atmosphere, and ocean dynamics. Derived MODIS land, atmosphere and ocean products are central to NASA's mission to monitor and understand the Earth system. NASA has developed and generated on a systematic basis a suite of MODIS products starting with the first Terra MODIS data sensed February 22, 2000 and continuing with the first MODIS-Aqua data sensed July 2, 2002. The MODIS Land products are divided into three product suites: radiation budget products, ecosystem products, and land cover characterization products. The production and distribution of the MODIS Land products are described, from initial software delivery by the MODIS Land Science Team, to operational product generation and quality assurance, delivery to EOS archival and distribution centers, and product accuracy assessment and validation. Progress and lessons learned since the first MODIS data were in early 2000 are described.

Masuoka, Edward↗

Using Open Standards and NASA Open Source Simulation Tools to Model Artemis Base Camp Mission Timelines

The United States’ National Aeronautics and Space Administration (NASA) has announced that the Artemis Program will return humans to the Moon, establishing a persistent presence with the Artemis Base Camp (ABC), and extend human exploration to Mars. The NASA Exploration Systems Simulations (NExSyS) team at NASA’s Johnson Space Center is using internationally developed simulation interoperability standards and NASA open source simulation tools to support Artemis concept, analysis, designs, development, training, and ultimately operations. The NExSyS team has been tasked to support early ABC architecture and mission analysis using mission time lines developed by the crew operations mission planning team. The NExSyS team is developing a distributed simulation framework with initial Artemis element implementations to model the ABC mission timelines using the international simulation interoperability standard High Level Architecture (HLA), the Simulation Interoperability Standards Organization’s Space Reference Federation Object Model (SpaceFOM), the NASA open source Trick Simulation Environment, and another NASA open source interface package called TrickHLA. The ABC architecture is composed of a number of key surface elements and resources. Some examples of modeled elements (also known as entities) are landers, habitats, rovers, logistics carriers, and astronauts. Some examples of modeled transferable and consumable resources are power, water, oxygen, nitrogen, scientific samples, and food. These entities and resources are modeled in a collection of individual simulations called Federates. A coordinated collection of interoperable federates is called a Federation and when these federates are tied together in a coordinated simulation run, it is referred to as a Federation Execution. The federates communicate through HLA using data exchange formats defined by a collection of machine readable files called Federation Object Models (FOMs). These FOM files are based on extensions to the SpaceFOM. This enables the instantiation and sharing of objects and interactions between federates in the federation. These provide for entity and resource tracking, object transfer, and data collection. Federate interactions are used to trigger events and notify federates of entity or resource transfers. For the initial implementation, the constituent federates are Trick-based simulations that use TrickHLA to provide the required HLA-base interoperability. These Trick-based simulations provide the required modeling for the individual Artemis elements along with the associated element resources. These federates provide a means to explore traverses between surface elements and exploration sites as scheduled in a mission timeline and explore the affects traverse times have on the overall mission timeline. The mission time lines are modeled using a Trick input file event handling capabilities. Each timeline operation is handled as individual simulation events, and triggered based on previous event status, time of operation, and simulated task completions. In addition, the ABC Federation can be used to perform Monte Carlo analysis. The Monte Carlo tool can vary the inputs, timings, and malfunctions to show how various contingencies in the mission can affect the mission timeline.

Keaton Craig Dodd↗

The IRAS project organisation and mission operations

The project organisation of IRAS is described, showing the tasks assigned to each project group during post-launch operations. The satellite is described, emphasizing the detectors. In the task division, the role of the U.S. is to construct the telescope and survey instrument, launch the satellite, process final science data for the survey instrument, and provide certain standard satellite items. The Netherlands construct the spacecraft and three additional instruments, integrates and tests the overall satellite, and designs and participates in the development of the operational system. The U.K. provides the operational control center and primary tracking station, generates a system for preliminary science analysis of the survey data, provides housekeeping analysis software and science data distribution software, and staffs the control center operations. The teams involved in mission planning and operations, and their roles, are identified, and a block diagram of the operations organisation is presented.

Van Holtz, R. C.↗

Advancing Autonomy in Distributed Space Systems: Insights From on-Orbit Testing with the Starling 1.0 Mission

Autonomous decision-making is crucial for enhancing mission effectiveness in Distributed Space Systems (DSS), particularly in multi-spacecraft operations where communication constraints and mission complexity pose challenges. The Distributed Spacecraft Autonomy (DSA) team at NASA’s Ames Research Center is advancing autonomy in DSS through five key technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. The DSA experiment onboard the Starling 1.0 Mission showcases collaborative resource allocation for multi-point science data collection with four small spacecraft. Autonomy in decision-making is highlighted as a crucial factor for multi-spacecraft missions, enabling spacecraft to operate independently, reducing reliance on ground control. This capability is particularly significant for future deep-space missions, where communication delays and limited data transmission capacity make traditional command and control approaches impractical. This demonstration focuses on a GPS Channel Selection Experiment, leveraging emergent capabilities like "shared sampling" and "simultaneous sampling" to optimize channel selection across the spacecraft swarm. The experiment aims to capture ionospheric phenomena such as the Equatorial Ionization Anomaly and Polar Patches. The DSA system's autonomous reconfiguration ability is showcased, emphasizing its adaptability to natural phenomena without significant integration efforts. The GPS Channel Selection Experiment utilizes a dual-band GPS receiver to estimate plasma density in the ionosphere. Explorative and exploitative channel selections are employed based on the nature of observed phenomena. The performance of DSA algorithms is evaluated in terms of optimal channel allocations and responsiveness to changes in observed features. The DSA Flight Software utilizes the Core Flight System (cFS) framework, ensuring compatibility with the Starling 1.0 flight mission software. DSA showcases results from RTI’s Connext DDS Micro communication middleware, enabling message routing over the Ad-Hoc Network of Starling 1.0. This paper provides a comprehensive overview of the DSA experiment's initial results, emphasizing the advancements in autonomy for Distributed Space Systems and the successful collaboration with the Starling 1.0 mission.

Caleb Ashmore Adams↗

Content and Representation of Information Needed to Support Time-Constrained Problem Solving

NASA’s current mission-operations paradigm originated with Project Mercury and endured with minimum evolution through the Apollo Program, Space Shuttle Program, and ISS missions. At its foundation is a near-complete real-time dependence on a ground team to manage the combined state of the mission, vehicle, and crew. Utilizing many engineers and operators with broad and deep expertise; large, distributed datasets including extensive telemetry; and expansive analytical and computing power, this ground team has served as the safety net for crewed spaceflight missions over the past 60 years. This approach must change to address challenges associated with missions beyond low Earth orbit (BLEO), including infrequent resupply, reduced ability to evacuate, and delayed communications that prohibit real-time operational support. We anticipate that a necessary part of this change will be increased independence for the crew, as roles and responsibilities traditionally performed by ground teams move on board the vehicle. While many risks are associated with Earth-independent operations, one particular concern is ensuring that the crew will have adequate onboard support to perform urgent problem solving when communication with the ground is delayed or intermittent. A key resource that enables the ground team to respond to anomalies quickly and effectively is the extraordinary expertise and experience it possesses. It is comprised of 80+ experts on at any given time, with a combined 600+ years of system-specific experience across 22 unique console disciplines. A small crew will face the unprecedented challenge of independently responding to anomalies that have historically been handled by a team 20 times their size. Another important resource upon which the ground heavily relies to support procedure execution and anomaly response is data. The amount of telemetry data that each flight controller monitors is extensive. In addition, as the ground team works to further assess impacts, trouble shoot, identify workarounds, and oversee procedure execution, it accesses and synthesizes engineering and procedure information, as well as system build, test, and configuration documentation. It is not feasible nor useful to put all these data onboard as crews become more Earth independent. Each member of a small Mars mission small crew will have multiple roles beyond monitoring telemetry and data gathering, and multiple roles within anomaly resolution processes, thereby limiting their capacity for copious amounts of information. Moreover, while access is necessary, it alone is insufficient. Information will need to be compiled, refined, and represented appropriately to support the crew’s reduced attention and expertise. This work seeks to understand the content and representation of information needed to support time-constrained problem solving and decision making by the crew without real-time ground support. To build this understanding, we first surveyed the literature, focusing on how expert problem solvers construct and manipulate their mental models. Next, we interviewed expert problem solvers in spaceflight and analogous domains and surveyed industry solutions for data presentation. Finally, we analyzed current spaceflight operations by investigating flight controller anomaly resolution processes during ISS training simulations and real operational events. These methods led to creating a problem-solving framework that details common themes and features of attending to, assessing, analyzing, and acting on problems in complex, time-constrained domains. Using this framework and the results of our analysis, we identified conceptual data representations needed for crew-led problem-solving. Preliminary onboard user interface concepts to meet identified needs will be presented.

anomaly response↗

A Distributed Simulation-to-Flight Framework to Support Investigating Trust/Trustworthiness in Multi-Agent Systems

As autonomous systems continue to grow both in use and complexity, the necessity for robust and extensible simulation-to-flight frameworks is paramount for establishing an effective architecture for autonomous systems. Hardware test flights are time-consuming and cost prohibitive during early system design and development. Simulation environments can be useful tools to accelerate algorithm development and testing. However, transitions from simulation to flight (sim-to-flight) can be challenging, unless systems are designed with this transition in mind and with the necessary capabilities built into the architecture and framework. One of the objectives of Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability (ATTRACTOR) was to design and develop a distributed mixed-reality simulation environment to begin establishing a basis for certification of autonomous systems via research into trust and trustworthiness. ATTRACTOR’s objective was to construct computational concepts of trustworthiness and justifiable trust in multi-agent autonomous teams, to inform future certification of safety-critical and time-critical autonomous systems in aviation. In this paper, we present an autonomous systems architecture and development framework paired with a persistent distributed modeling and simulation (ModSim) environment for test and evaluation of autonomous systems. They were designed under ATTRACTOR in order to measure and establish trustworthiness and trust in single-and multi-agent human-machine systems whether these machines are fixed-wing general aviation, rotary-wing Unmanned Aerial Vehicles (UAVs), ground rovers, or even spacecraft. The Autonomous Entity Operational Network (AEON) framework enables autonomous system development with an easily extensible collection of libraries and plug-n-play nodes facilitated by the Data Distribution Service (DDS) communication protocol standard. The Baseline Environment for Autonomous Modeling (BEAM) simulation environment is a distributed mixed-reality Unity™-based environment built around the same DDS communication paradigm allowing for easy integration with AEON-based autonomous applications, enabling sim-to-flight with minimal configuration changes. Using AEON and BEAM, source code that runs in simulation ports directly to hardware and has successfully flown in the National Airspace System (NAS) at NASA LaRC many times over the lifetime of ATTRACTOR.

Benjamin N Kelley↗

The Virtual Mission Operations Center

Spacecraft management is becoming more human intensive as spacecraft become more complex and as operations costs are growing accordingly. Several automation approaches have been proposed to lower these costs. However, most of these approaches are not flexible enough in the operations processes and levels of automation that they support. This paper presents a concept called the Virtual Mission Operations Center (VMOC) that provides highly flexible support for dynamic spacecraft management processes and automation. In a VMOC, operations personnel can be shared among missions, the operations team can change personnel and their locations, and automation can be added and removed as appropriate. The VMOC employs a form of on-demand supervisory control called management by exception to free operators from having to actively monitor their system. The VMOC extends management by exception, however, so that distributed, dynamic teams can work together. The VMOC uses work-group computing concepts and groupware tools to provide a team infrastructure, and it employs user agents to allow operators to define and control system automation.

Moore, Mike↗

An Overview of Distributed Spacecraft Autonomy at NASA Ames

Autonomous decision-making significantly increases mission effectiveness by mitigating the effects of communication constraints, like latency and bandwidth, and mission complexity on multi-spacecraft operations. To advance the state of the art in autonomous Distributed Space Systems (DSS), the Distributed Spacecraft Autonomy (DSA) team at NASA's Ames Research Center is developing within five relevant technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. DSA is maturing these technologies - critical for future large autonomous DSS - from concept to launch via simulation studies and orbital deployments. A 100-node heterogenous Processor-in-the-Loop (PiL) testbed aids distributed autonomy capability development and verification of multi-spacecraft missions. The DSA software payload deployed to the D-Orbit SCV-004 spacecraft demonstrates multi-agent reconfigurability and reliability as part of an ESA-sponsored in-orbit technology demonstration. Finally, DSA's primary flight mission showcases collaborative resource allocation for multipoint science data collection with four small spacecraft as a payload on NASA's Starling 1.0 satellites.

Caleb Ashmore Adams↗

Identifying Human Factors Research for Unmanned Aircraft Systems and Advanced Air Mobility

This paper identifies some of the key human factors (HF) challenges when integrating Unmanned Aircraft Systems (UAS) and Advanced Air Mobility (AAM) into the civil airspace. Unique HF considerations—those which are derived from the key differentiating aspects of UAS/AAM compared to conventional aviation—are the primary basis for identifying HF research opportunities. By identifying what makes UAS and AAM fundamentally different from conventional aviation, from a human integration perspective, HF research can be targeted to effectively inform best practices, standards, policy, guidance, and regulations associated with aircraft and air traffic systems and operations. HF research areas are discussed within the following topic areas: Sustained low-altitude operations; loss of natural sensing; novel aircraft; novel operations; link management and lost link; link performance; distributed pilot teams; and increased automation. The identified research descriptions are intended to serve as illustrative examples of what research is fundamental, and why. They are not intended to prescribe, prioritize or exclude research.

AAM↗

Identifying Human Factors Research for Unmanned Aircraft Systems (UAS) and Advanced Air Mobility (AAM)

This paper identifies some of the key human factors (HF) challenges when integrating Unmanned Aircraft Systems (UAS) and Advanced Air Mobility (AAM) into the civil airspace. Unique HF considerations—those which are derived from the key differentiating aspects of UAS/AAM compared to conventional aviation—are the primary basis for identifying HF research opportunities. By identifying what makes UAS and AAM fundamentally different from conventional aviation, from a human integration perspective, HF research can be targeted to effectively inform best practices, standards, policy, guidance, and regulations associated with aircraft and air traffic systems and operations. HF research areas are discussed within the following topic areas: Sustained low-altitude operations; loss of natural sensing; novel aircraft; novel operations; link management and lost link; link performance; distributed pilot teams; and increased automation. The identified research descriptions are intended to serve as illustrative examples of what research is fundamental, and why. They are not intended to prescribe, prioritize or exclude research.

AAM↗

Robotic and Human-Tended Collaborative Drilling Automation for Subsurface Exploration

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. Human operators listen and feel drill string vibrations coming from kilometers underground. Abundant mass and energy make it possible for terrestrial drilling to employ brute-force approaches to failure recovery and system performance issues. Space drilling will require intelligent and autonomous systems for robotic exploration and to support human exploration. Eventual in-situ resource utilization will require deep drilling with probable human-tended operation of large-bore drills, but initial lunar subsurface exploration and near-term ISRU will be accomplished with lightweight, rover-deployable or standalone drills capable of penetrating a few tens of meters in depth. These lightweight exploration drills have a direct counterpart in terrestrial prospecting and ore-body location, and will be designed to operate either human-tended or automated. NASA and industry now are acquiring experience in developing and building low-mass automated planetary prototype drills to design and build a pre-flight lunar prototype targeted for 2011-12 flight opportunities. A successful system will include development of drilling hardware, and automated control software to operate it safely and effectively. This includes control of the drilling hardware, state estimation of both the hardware and the lithography being drilled and state of the hole, and potentially planning and scheduling software suitable for uncertain situations such as drilling. Given that Humans on the Moon or Mars are unlikely to be able to spend protracted EVA periods at a drill site, both human-tended and robotic access to planetary subsurfaces will require some degree of standalone, autonomous drilling capability. Human-robotic coordination will be important, either between a robotic drill and humans on Earth, or a human-tended drill and its visiting crew. The Mars Analog Rio Tinto Experiment (MARTE) is a current project that studies and simulates the remote science operations between an automated drill in Spain and a distant, distributed human science team. The Drilling Automation for Mars Exploration (DAME) project, by contrast: is developing and testing standalone automation at a lunar/martian impact crater analog site in Arctic Canada. The drill hardware in both projects is a hardened, evolved version of the Advanced Deep Drill (ADD) developed by Honeybee Robotics for the Mars Subsurface Program. The current ADD is capable of 20m, and the DAME project is developing diagnostic and executive software for hands-off surface operations of the evolved version of this drill. The current drill automation architecture being developed by NASA and tested in 2004-06 at analog sites in the Arctic and Spain will add downhole diagnosis of different strata, bit wear detection, and dynamic replanning capabilities when unexpected failures or drilling conditions are discovered in conjunction with simulated mission operations and remote science planning. The most important determinant of future 1unar and martian drilling automation and staffing requirements will be the actual performance of automated prototype drilling hardware systems in field trials in simulated mission operations. It is difficult to accurately predict the level of automation and human interaction that will be needed for a lunar-deployed drill without first having extensive experience with the robotic control of prototype drill systems under realistic analog field conditions. Drill-specific failure modes and software design flaws will become most apparent at this stage. DAME will develop and test drill automation software and hardware under stressful operating conditions during several planned field campaigns. Initial results from summer 2004 tests show seven identifi distinct failure modes of the drill: cuttings-removal issues with low-power drilling into permafrost, and successful steps at executive control and initial automation.

Glass, Brian↗

A Distributed Simulation-to-Flight Framework to Support Investigating Trust/Trustworthiness in Multi-Agent Systems

As autonomous systems continue to grow both in use and complexity, the necessity for robust and extensible simulation-to-flight methods is paramount for establishing an effective architecture for autonomous systems. A fundamental objective of the ATTRACTOR (Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability) project was to design and develop a distributed mixed-reality simulation environment to begin establishing a basis for certification of autonomous systems via research into trust and trustworthiness. In this paper, we present an autonomous systems architecture and development framework paired with a persistent distributed modeling and simulation environment for test and evaluation of autonomous systems. The Autonomous Entity Operations Network (AEON) framework enables autonomous system development with an easily extensible collection of libraries and plug-n-play nodes facilitated by the Data Distribution Service (DDS) communication protocol standard. The Baseline Environment for Autonomous Modeling (BEAM) simulation environment is a distributed mixed-reality Unity™-based environment built around the same DDS communication paradigm allowing for easy integration with AEON-based autonomous applications. They were designed under ATTRACTOR in order to measure and establish trustworthiness and trust in single- and multi-agent human-machine systems whether these machines are fixed-wing general aviation, rotary-wing Unmanned Aerial Vehicles (UAVs), ground rovers, or even spacecraft. Together AEON and BEAM enable sim-to-flight with minimal configuration changes. By using AEON and BEAM, source code that runs in simulation ports directly to hardware and has successfully flown in the lab and in the National Airspace System (NAS) at NASA LaRC many times over the lifetime of ATTRACTOR.

Benjamin N Kelley↗

A Distributed Simulation-to-Flight Framework to Support Investigating Trust/Trustworthiness in Multi-Agent Systems

As autonomous systems continue to grow both in use and complexity, the necessity for robust and extensible simulation-to-flight methods is paramount for establishing an effective architecture for autonomous systems. A fundamental objective of the ATTRACTOR (Autonomy Teaming and TRAjectories for Complex Trusted Operational Reliability) project was to design and develop a distributed mixed-reality simulation environment to begin establishing a basis for certification of autonomous systems via research into trust and trustworthiness. In this paper, we present an autonomous systems architecture and development framework paired with a persistent distributed modeling and simulation environment for test and evaluation of autonomous systems. The Autonomous Entity Operations Network (AEON) framework enables autonomous system development with an easily extensible collection of libraries and plug-n-play nodes facilitated by the Data Distribution Service (DDS) communication protocol standard. The Baseline Environment for Autonomous Modeling (BEAM) simulation environment is a distributed mixed-reality Unity™-based environment built around the same DDS communication paradigm allowing for easy integration with AEON-based autonomous applications. They were designed under ATTRACTOR in order to measure and establish trustworthiness and trust in single- and multi-agent human-machine systems whether these machines are fixed-wing general aviation, rotary-wing Unmanned Aerial Vehicles (UAVs), ground rovers, or even spacecraft. Together AEON and BEAM enable sim-to-flight with minimal configuration changes. By using AEON and BEAM, source code that runs in simulation ports directly to hardware and has successfully flown in the lab and in the National Airspace System (NAS) at NASA LaRC many times over the lifetime of ATTRACTOR.

Benjamin N Kelley↗

What Makes Hybrid Concurrent Engineering Teams Work and Not Work: A Theoretical Analysis

Aerospace concurrent engineering teams (CETs) have been around since 1995 and have evolved into various shapes and forms. Historically, CETs have been designed to function with all team members physically collocated. In order to continue operating during the coronavirus pandemic, these teams have had to become fully distributed in 2020. Previously, distributed CETs were predicted to be considerably less efficient than traditional CETs. However, at JPL studies are being successfully run at peak rate in a distributed mode. As nominal working conditions resume after the pandemic, a major question is whether these teams must go back to being fully collocated or if they can become successful hybrid teams, with half or more of the engineers working remotely. In order to address this question, it is important to understand the key characteristics that make a CET more likely to be successful in a remote mode. This paper revisits a framework for characterizing concurrent engineering teams, providing a means to describe and compare the behavior of concurrent engineering teams in various settings [1], and uses the framework to make recommendations for future hybrid teams.

Chattopadhyay, Debarati↗