Engineering topics

Edwin Z Crues

Publications and source records attributed to Edwin Z Crues.

At least 19 records

NASA NTRS2025

South Pole Lunar Lighting Studies for Driving Exploration on the Lunar Surface

NASA’s Artemis lunar missions will face new exploration challenges due to inherently low sun angles in the lunar south pole region. Whereas the Apollo missions were afforded sunlight for approximately 8 to 50-degrees above the horizon, sunlight for the next lunar missions will only be 1 to 2-degrees about the horizon. With this low angle, long shadows and high contrasts of light and dark areas will be faced by the crew and remote teleop operators while exploring the lunar surface. With this in mind, NASA developed an integrated virtual Lighting and Navigation Simulation to understand these challenges. Two studies have been conducted in this Lunar South Pole environment to evaluate the effects of natural and artificial lighting on driving and navigating a lunar rover across the surface. Early NASA studies, such as this, are used to aid in developing techniques and explore concepts of operations to promote mission success and crew safety. In the Phase One development evaluation, six astronauts were teleported to ten different lighting conditions. For each location, drivers were to drive to an imaginary target approximately 200-meters straight ahead and provide subjective feedback on their ability to drive under the given lighting conditions. Phase Two, a more operational study, four astronauts and a remote operator tested five different Artemis lunar mission scenarios. Results indicated sun direction at such low angles, especially when driving a high speed, can severely impact the crew’s ability to safely drive the rover. In the up-sun situation, with the sun directly in the driver’s eyes and compounded long shadows, the consistent preference among drivers was to initiate a tacking strategy of approximately +/- 20 to 30-degrees to improve visibility. This maneuver does require more time and rover energetics. Conversely, driving down-sun required the crew to tack as well to avoid the shadow of rover blocking the terrain. Less appreciated is how the surrounding landscape is lit. Traveling into shadowed areas, especially while facing a lit terrain beyond the shadowed area, drivers enter at their own risk due to pupil contraction making artificial lights useless. Additionally, the constant transitioning between dark and light areas are mentally taxing to the crew and natural navigational references such as the stars are invisible and therefore unusable. Slope and depth magnitude are very difficult hazards to judge when approaching a shadowed crater. This naturally leads to slower driving speeds than originally anticipated. As for observing scientifically interesting features, assessing them accurately varies greatly by the lighting condition. In most cases, the task can be completed, but the strategy is to use the sun to one’s advantage. Crew workload distribution in the cockpit for driving operations was split amongst crew. The driver primarily focused attention on visual terrain (80%) but referenced displays approximately 20% of the time, while the co-pilot/navigator generally provided directional cues to the driver. These natural lighting conditions present significant challenges for safe rover operations; however, early studies having given investigators a “first-look” into understanding of how operating on the South Lunar Pole can be accomplished.

LTv↗

NASA NTRS2025

Evolving the SpaceFOM: Lessons Learned and Future Development

For over fifty years, simulation has been a cornerstone technology for space missions. In many cases, one single simulator, developed by one team, is not enough to meet the simulation objectives. Astronaut crew training, docking, vehicle testing and complex mission planning all require several simulations to be connected and to interoperate, in order to achieve the goal of the simulation. To facilitate the development of interoperable simulations, an open standard, the SISO SpaceFOM was developed in collaboration between government, industry and academia. The standard was released in 2020. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. The initial release of SpaceFOM focuses on the core interoperability topics for space simulation: (i) specifying spatial data using several, well defined reference frames, (ii) managing time (including real-time, hard real-time, and as-fast-as-possible execution), (iii) composition of systems with subsystems such as space vehicles, and (iv) execution control, such as initializing, running, pausing, and terminating simulations. A number of requirements for the next version of SpaceFOM have been identified and proposed solutions are already under development. One key area is the object classes used for data exchange, where a richer set of classes have been proposed, based on practical use cases. For time management, the use of variable time resolutions and variable time steps is also proposed. For execution control, save and restore of simulations is considered as well as improved robustness, to handle failing components. A number of clarifications are also under consideration. This paper provides both a forward-looking view of the technical developments underway and a retrospective on the standard's evolution. The authors emphasize that prioritizing core challenges and delivering a practical first version were crucial steps. While not every idea was implemented in the initial release, the timely delivery of a functional standard enabled real-world applications, the growth of a user community, and the collection of valuable insights to shape future versions. The authors look forward to working with the next version of SpaceFOM together with the growing user community.

Simulation Interoperability↗

NASA NTRS2024

Expansion of Check-Cases for 6DOF Simulation

This effort expands upon a previous NASA activity that developed flight simulation benchmark check-cases to include new check-cases for the Cislunar domain, comparing multiple NASA simulation tools. The results of this effort describe the benefits of standardizing inputs, simulation comparisons and describe an interactive website that enables comparison of externally provided simulation data. Participating simulations improved their software and identified implementation errors. This activity elevated simulation credibility and provided a measure of validation for the simulations actively in use for NASA’s Human Landing Systems (HLS).

Modeling↗

NASA NTRS2024

Expansion of Check-Cases for 6DOF Simulation: Appendix A

This is the Appendix containing figures of simulation output data plots for comparison from the assessment, “Expansion of Check-Cases for 6DOF Simulation”. This effort expands upon a previous NASA activity that developed flight simulation benchmark check-cases to include new check-cases for the Cislunar domain, comparing multiple NASA simulation tools. The results of this effort describe the benefits of standardizing inputs, simulation comparisons and describe an interactive website that enables comparison of externally provided simulation data. Participating simulations improved their software and identified implementation errors. This activity elevated simulation credibility and provided a measure of validation for the simulations actively in use for NASA’s Human Landing Systems (HLS).

Modeling↗

NASA NTRS2024

Expansion of Check-Cases for 6DOF Simulation

This is the Appendix containing a description of the solution for Case 1 in the assessment, “Expansion of Check-Cases for 6DOF Simulation”. For cases of spherical gravity, it is possible to provide a two-body solution without recourse to numerical integration and thus it is accurate to machine precision. Python code for a Keplerian Propagator (propagate.py) which produced a reference trajectory for Case 1 is provided in this appendix. There is also code for generating test cases which was used as an independent verification of the propagator. This is a high-level description of the algorithm employed. The documentation of each function includes implementation details, including equations for each task.

Modeling↗

NASA NTRS2024

A Distributed Simulation Framework Applied to Artemis Analysis, Studies, Integration, and Test

The National Aeronautics and Space Administration (NASA) established the Artemis Program, a series of missions to return humans to the Moon and explore further than before. To execute the Artemis missions, NASA is collaborating with commercial and international partners to create the necessary infrastructure and logistics plan that will establish a long term presence on the Moon ahead of exploring Mars. NASA and its partners are developing a collection of space and surface systems to support crewed missions to the lunar surface that will provide the mobility, habitation, logistics, and exploration support necessary for Artemis mission successes which includes robust scientific investigations. This paper details the design, capabilities, and uses of the Artemis Distributed Simulation (ADS) being developed by the NASA Exploration Systems Simulations (NExSyS) Team to support Artemis architecture studies. ADS utilizes international interoperability standards to connect a collection of independent vehicle and service simulations; these include but are not limited to elements such as rovers, landers, and habitation elements along with services like communications, environment, visualization, and data logging. ADS’s distributed nature allows for the complex aggregation of constituent Artemis elements; this includes efficient scenario modification with the addition or removal of individual simulations representing Artemis elements or services. This capability provides support for the rapid performance of various Artemis mission trade studies exploring alternate configurations. Currently, ADS uses NASA developed simulations for development and testing; however, through the use of international simulation interoperability standards, ADS provides an integration framework to incorporate dissimilar authoritative vendor simulations as Artemis systems mature and vendor simulations become available. Vendor simulations will be able to join ADS and interact with other Artemis elements and vehicles while limiting the exposure of proprietary data. This paper describes the expansion of an existing distributed simulation infrastructure to accommodate a collaborative and dynamic framework for the Artemis Program. This work includes updated federation designs, integration into existing NASA facilities, advancements in visualizations, and advancements in human driven inputs. This paper will also outline recently completed and ongoing support and collaboration with NASA studies and testing, namely results from energetics and Human-In-The-Loop (HITL) studies. The paper concludes with a plan for future developments and facility integration to enable enhanced studies in preparation for a return of humans to the lunar surface.

Artemis↗

NASA NTRS2024

Digital Lunar Exploration Sites (DLES) Terrain Crafting

Humans will soon be returning to the surface of the Moon with NASA’s Artemis program. The Artemis program is an international collaboration that will consist of a complex series of space systems and missions to explore the lunar surface and pave the way for the future exploration of Mars. NASA and its partners rely heavily on simulation for lighting and navigation studies as well as training astronauts, flight controllers, and mission support staff. The NASA Exploration Systems Simulations (NExSyS) team in the Simulation and Graphics Branch (ER7) in the Engineering Directorate at NASA’s Johnson Space Center has built up many simulation products to support this effort, one of which is the Digital Lunar Exploration Sites (DLES). DLES is a collection of products used to simulate and render the lunar surface in a digital environment. We discussed and presented an overview of the DLES products at the 2022 IEEE Aerospace Conference in Big Sky, MT with a paper titled "Digital Lunar Exploration Sites". This “DLES Terrain Crafting” paper will expand on the information previously provided in “DLES” paper and dive deeper into the details of the terrain crafting process and the toolsets used to support this task. The best digital data currently available of the lunar surface is provided by the Lunar Reconnaissance Orbiter (LRO). Its Lunar Orbiter Laser Altimeter (LOLA) achieves an impressive resolution of 5m per pixel at the Lunar South Pole (LSP) and can generate datasets covering a large continuous region near the LSP. There are a few additional methods, such as Shape from Shading which can infer higher resolution data (up to 1m per pixel) from the LRO Narrow Angle Camera (NAC) images. However, surface-based simulations require higher-resolution data, and this paper will discuss the process of enhancing the terrain to meet that need. The process begins with capturing statistical data of craters in the regions of interest using images provided by the LRO NAC. This data is then used to scatter artificial features which are not captured in the truth data, resulting in an enhanced DEM with a much higher resolution of 20cm per pixel. Many tools were built up to assist in the creation of these artificial Digital Elevation Models (DEM), which this paper will discuss in detail. DEMs themselves are a very powerful representation of a planetary surface, and many operations and tools can utilize the data they contain. This paper includes a description of the rendering of the lunar surface in a graphics engine, generation of contact patches to simulate tire to ground interaction, and ray tracing utilities to model Line of Sight (LOS) interactions with the terrain. This paper will also explore some new tool sets currently under development which aim to utilize Machine Learning (ML) to assist in the identification of craters from LRO NAC imagery. While this is not a novel idea, the NExSyS team is developing a unique approach which may result in more robust identification of crater characteristics.

Artemis↗

NASA NTRS2024

Design, Development, and Use of a Lunar Lander Simulation for NASA's Artemis Program

Edwin Z Crues↗

NASA NTRS2012

Integrated Simulation Design Challenges to Support TPS Repair Operations

During the Orbiter Repair Maneuver (ORM) operations planned for Return to Flight (RTF), the Shuttle Remote Manipulator System (SRMS) must grapple the International Space Station (ISS), undock the Orbiter, maneuver it through a long duration trajectory, and orient it to an EVA crewman poised at the end of the Space Station Remote Manipulator System (SSRMS) to facilitate the repair of the Thermal Protection System (TPS). Once repair has been completed and confirmed, then the SRMS proceeds back through the trajectory to dock the Orbiter to the Orbiter Docking System. In order to support analysis of the complex dynamic interactions of the integrated system formed by the Orbiter, ISS, SRMS, and SSMS during the ORM, simulation tools used for previous ‘nominal’ mission support required substantial enhancements. These upgrades were necessary to provide analysts with the capabilities needed to study integrated system performance. Prevalent throughout this ORM operation is a dynamically varying topology. In other words, the ORM starts with the SRMS grappled to the mated Shuttle/ISS stack (closed loop topology), moves to an open loop chain topology consisting of the Shuttle, SRMS, and ISS, and then, at the repair configuration, extends the chain topology to one consisting of the Shuttle, SMS, ISS, and SSRMS/EVA crewman. The resulting long dynamic chain of vehicles and manipulators may exhibit significant motion between the Shuttle worksite and the EVA crewman due to the system flexibility throughout the topology (particularly within the SRMS/SSRMS joints and links). Since the attachment points of both manipulators span the flexible structure of the ISS, simulation analysis may also need to take that into consideration. Moreover, due to the lengthy time duration associated with the maneuver and repair, orbital effects become a factor and require the ISS vehicle control system to maintain active attitude control. Several facets of the ORM operation make the associated analytical efforts different from previous mission support, including: (1) the magnitude of the SRMS handled payload (Le., Orbiter class), (2) the orbital effects induced on the integrated system consisting of the large Shuttle and ISS masses connected by a light flexible SRMS, (3) long duration environmental consequences due to the lengthy operational times associated with the maneuver and repair of the TPS, (4) active attitude control (as opposed to free drift) interacting with the SRMS and SSRMS manipulators (also due to the length of the maneuver and repair), (5) relative dynamics between the EVA crewman and thc worksite influenced by the extended flexible topology. In order to meet these analysis challenges, an ORM simulation architecture was developed leveraging upon numerous pre-existing simulation elements to analyze the various subsystems individually. For example, core manipulator subsystem simulations for both the SRMS and SSRMS were originally combined to provide the dual-arm dynamics topology simulation (in the absence of orbital dynamics and vehicle control). This capability was later merged with the simulation used to analyze SRMS loading with a heavy payload in the orbital environment with an active payload control system (in this case, the ISS Attitude Control System (ACS)), configured for the ORM. The resulting worksite dynamics simulation, based off of the modified ORM simulation, provided the extended topological chain of vehicles and manipulators, while taking into account the orbital effects of both the Shuttle and ISS (as well as its ACS). Verification and validation (V&V) of these integrated simulations became a challenge in itself. A systematic approach needed to be developed such that integration simulation results could be tested against previous constituent simulations upon which these simulations were built. General V&V categories included: (1) core orbital state propagation, (2), stand-alone SRMS, (3) stand-alone SSRMS, (4) stand-alone ISS ACS, (5) integrated Shuttle, SRMS, ISS (with active ACS) in the orbital environment, and (5) dual-arm SRMS/SSRMS dynamics topology. Integrated simulation V&V run suites were created and correlated to verification runs from subsystem simulations, in order to establish the validity of the results. This paper discusses the simulation design challenges encountered while developing simulation capabilities to mirror the ORM operations. The paper also describes the incremental build approach that was utilized, starting with the subsystem simulation elements and integration into increasing more complex simulations until the resulting ORM worksite dynamics simulation had been assembled. Furthermore, the paper presents an overall integrated simulation V&V methodology based upon a subsystem level testing, integrated comparisons, and phased checkout.

Thermal Protection System↗

NASA NTRS2006

Utilizing a Common Model Architecture for the Simulation of On-Orbit Human Spaceflight Operations

Advances in computing and simulation technology during the 1980 s promoted the development of multiple simulations for on-orbit human spaceflight operations at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC). By the late 1980 s, it became increasingly clear that redundancy risked leading to inefficiencies in dissemination and incorporation of models across simulations, institutional organizations, and spaceflight programs. Software development tools, such as the Trick Simulation Environment, began to emerge providing a generalized framework for the development, integration, and operation of simulations. Throughout the 1990s, engineering, operations, and training simulations began to migrate to Trick in order to take advantage of a common simulation environment. Due to forecasted reductions in funding to the Shuttle and International Space Station (ISS) programs in the early 2000s, the common framework that arose from this simulation migration was formalized as the Common Model Architecture (CMA). The CMA was established in order to further reduce redundancy, while promoting model sharing and enhancing model integrity. A minimal set of standards for data flows, functional interactions, and model organization based on Trick were defined for those features found to be most important in facilitating model interaction. Model-providing organizations within NASA JSC took ownership of models for their specific areas of expertise, and agreements were reached on common model sharing and usage. This paper describes the evolution of commonality enabled by the Trick Simulation Environment at JSC leading to the CMA, the standards defined by the CMA, a recent CMA simulation example, and potential application of the CMA to NASA s new Exploration program.

Leslie J Quiocho↗

NASA NTRSDate not supplied

SpaceFOM: An Interoperability Standard for Space Systems Simulations

There is a long history of simulation supporting space systems development. This includes relatively simple parametric simulations to more complex trajectory simulations to large scale integrated vehicle simulation. One area of relatively recent development is in the area of distributed or interoperable simulation. Distributed simulation has been in wide use by the US military for years but is being used more broadly in the aerospace community. To support large scale distributed simulation, the military community has developed a number of standards to support a-priori interoperability between large collections of disparate simulations. For example, the IEEE 1516 High Level Architecture (HLA) and the Real-time Platform Reference Federation Object Model (RPR FOM). While HLA is suitable for space systems, there are a number of design decisions made in the development of the RPR FOM that prevent it from working well for space applications. In order to address these deficiencies, the Simulation Interoperability Standards Organization (SISO) developed a new HLA-based interoperability standard to support the needs of complex space systems. This standard is the Space Reference Federation Object Model (SpaceFOM). This paper presents an overview of the SpaceFOM including the fundamentals of the SpaceFOM, the key features of the SpaceFOM, and how the SpaceFOM supports large scale distributed simulation of complex space systems.

SpaceFOM↗

NASA NTRSDate not supplied

Digital Lunar Exploration Sites (DLES)

After an almost 50-year absence, NASA along with a group of international and commercial partners will return humans to the surface of the Moon as part of the Artemis program. As with the preceding Apollo program, modeling and simulation (M&S) will be an enabling technology for achieving the Artemis mission objectives. Fortunately, M&S has advanced considerably in the past half century, permitting much more detailed and encompassing integrated representations of the Artemis systems. One modeling area of critical importance to simulating the Artemis elements and mission activities is the accurate and efficient modeling of the operational lunar environment. This is particularly challenging since the Artemis program is considering exploration sites in the area of the Lunar South Pole (LSP), far away from any previous surface exploration sites. Fortunately, we now have considerably more and better data from recent lunar sensing missions. A planetary science team and a human exploration simulation team at NASA’s Johnson Space Center are developing a suite of products called the Digital Lunar Exploration Sites (DLES). DLES is intended to provide some of the necessary lunar environmental data products. This paper describes the fundamental need for DLES, the science data sets that are going into DLES, some of the processes used to integrate this data into DLES products, the basic products that constitute DLES, and some examples of DLES in use.

DLES↗

NASA NTRSDate not supplied

Returning to the Moon: Plans for Distributed Simulation in the Artemis Program

Explore the source record for details and available documents.

Artemis↗

NASA NTRSDate not supplied

SpaceFOM: An Interoperability Standard for Space Systems Simulations

Explore the source record for details and available documents.

SpaceFOM↗

NASA NTRSDate not supplied

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↗

NASA NTRSDate not supplied

Design, Development, and Use of a Lunar Lander Simulation for NASA's Artemis Program

This paper describes the design, development, and initial use of a generalized and configurable lunar lander simulation to support NASA’s Artemis Program. This simulation is being developed for the Crew Compartment Office (CrewCo) in the Human Landing Systems (HLS) program and is called the HLS CrewCo Lander Simulation (HCLS). The HCLS provides insight into the challenges associated with returning humans to the Moon and the particular difficulties of operating at the Lunar South Pole. The simulation models a generalized integrated lunar landing spacecraft based on a government reference design but can and has been adapted to model vendor specific designs as well. The simulation architecture and tool sets provide a flexible framework that allows for quickly prototyping and evaluating various aspects of a piloted lunar landing system. This includes the modeling of all principal human controlled flight phases: rendezvous and docking with crew transfer systems; docked orbital outpost operations; undocking and lunar transfer; lunar orbital operations; lunar deorbit, descent, and landing (DDL); lunar surface operations; lunar ascent; and return to the orbital outpost. The flexibility of the simulation allows for the integrated evaluation of potential vehicle subsystems, crew displays, guidance and control modes, and trajectory designs. The purpose of the HCLS is not to design the ideal lunar lander, but rather to understand and the strengths and weaknesses of vehicle design choices. This paper describes the basic simulation architecture and discusses the tool sets used to develop the HCLS. This includes a number of open source tool sets and publicly available data sets. This paper also describes some of the early use cases and findings. The primary focus of early HCLS use has been on the manual piloting task to safely get the crew to the desired landing site in case of a failure in the automated guidance system. Several guidance modes and cues have been implemented which allow a pilot to manually fly the vehicle to the targeted landing site starting anywhere from powered descent initiation. It has been a valuable tool for understanding what is required to manually fly a lunar lander as well as giving a sense of the vehicle dynamics, which are much different than anything that is flown on Earth. A number of experienced test pilots have participated in manual piloting evaluations using the HCLS and provided valuable feedback on the piloting task which has been very beneficial to NASA and the HLS program.

James Michael Gentile↗

NASA NTRSDate not supplied

Development of the Artemis Distributed Simulation FOMs

The National Aeronautics and Space Administration (NASA) is formulating and developing the Artemis Program, a collaboration with domestic commercial and international partners that will establish a long term human presence on the Moon and extend human exploration beyond the Earth-Moon system ahead of exploring Mars. These Artemis partners are developing a portfolio of space and surface systems to support human missions to the lunar surface and beyond. The Artemis systems will provide the mobility, habitation, and logistics infrastructure that will support human exploration and foster robust scientific investigations. Each partner will contribute one or more elements to the Artemis Program with NASA having the overarching responsibility for defining the Artemis architecture and guiding the integration of this complex system of space systems. To successfully accomplish this audacious task, NASA will rely on the development and execution of many complex models and simulations. Many of these simulations will be provided by the Artemis partners. While each of these simulations will provide important insight into the characteristics and performance of an associated system, individually they will not provide insight into the integrated performance of the architecture and the system of systems working in concert to execute a given Artemis mission. To address this need, NASA is developing a distributed simulation capability called the Artemis Distributed Simulation (ADS). ADS’s distributed nature supports the complex aggregation of constituent Artemis element simulations. Artemis partner simulations will be able to join into an ADS-based distributed simulation and interact with other Artemis element simulations while limiting the exposure of proprietary designs and data. ADS is defining a distributed simulation capability built on international simulation interoperability standards, specifically the High Level Architecture (HLA) and the Space Reference Federation Object Model (SpaceFOM). While HLA and SpaceFOM provide the substantive necessary technology basis for ADS, additional common datatypes, message definitions, and execution protocols are required. These extensions constitute the ADS Federation Object Model (FOM). This paper describes the fundamental architectural elements of ADS and the FOM extensions needed to support the complex nature of the Artemis Program. This includes the examination of the ADS FOM modules, ADS base datatypes, ADS SpaceFOM Object Class extensions, new ADS Object Classes, and new ADS Interaction Classes.

HLA↗

NASA NTRSDate not supplied

A Discussion of Time Management Concepts and Time Constraint Equations for Multi-Rate Federation Executions

The High Level Architecture (HLA) is a simulation interoperability standard developed by the Simulation Interoperability Standards Organization (SISO) and published as the international standard IEEE 1516-2010 by the Institute for Electrical and Electronics Engineers (IEEE). HLA is a widely used standard for the development and execution of collaborative distributed simulations. HLA provides a number of Management Services to simulation developers: Federation, Declaration, Object, Ownership, Data Distribution, and Time. Of those services, Time Management Services is probably one of the least understood and least used. However, Time Management Services are critical to technical simulations like those created for space systems using the Space Reference Federation Object Model (SpaceFOM). Time Management can be used to insure data coherence and execution repeatability in distributed simulations. When combined with real time execution policies, Time Management is being used to support real time execution of mixed software and hardware in the loop integration, verification, and validation simulations for active space systems development. This paper starts by providing an overview of the HLA Time Management Services. This provides the background to discuss the challenges associated with Time Management and its use, starting with simple common rate frame scheduled simulations, then simple multi-rate simulations, and ending with complex mixed rate simulations. The authors then formulate the significant time constraint relationships between identified frame scheduling parameters. The intent of the paper is to provide a concise discussion of how to use Time Management in both simple cases and in more complex mixed frame rate federation executions.

Simulation Interoperability↗