Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “execution architecture”

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 559 records · Page 31

A Low Cost Spacecraft Architecture for Robotic Lunar Exploration Projects

A program of frequent, capable, but affordable lunar robotic missions prior to return of humans to the moon can contribute to the Vision for Space Exploration (VSE) NASA is tasked to execute. The Lunar Reconnaissance Orbiter (LRO) and its secondary payload are scheduled to orbit the moon, and impact it, respectively, in 2008. It is expected that the sequence of missions occurring for approximately the decade after 2008 will place an increasing emphasis on soft landed payloads. These missions are requited to explore intrinsic characteristics of the moon, such as hydrogen distribution in the regolith, and levitated dust, to demonstrate the ability to access and process in-situ resources, and to demonstrate functions critical to supporting human presence, such as automated precision navigation and landing. Additional factors governing the design of spacecraft to accomplish this diverse set of objectives are: operating within a relatively modest funding profile, the need tb visit multiple sites (both polar and equatorial) repeatedly, and to use the current generation of launch vehicles. In the US, this implies use of the Evolved Expendable Launch Vehicles, or EELVs, although this design philosophy may be extended to launch vehicles of other nations, as well. Many of these factors are seemingly inconsistent with each other. For example, the cost of a spacecraft usually increases with mass; therefore the desire to fly frequent, modestly priced spacecraft seems to imply small spacecraft (< 1 Mt, injected mass). On the other hand, the smallest of the EELVs will inject approx. 3 Mt. on a Trans Lunar Injection (TLI) trajectory md would therefore be wasteful or launching a single, small spacecraft. Increasing the technical capability of a spacecraft (such as autonomous navigation and soft landing) also usually increases cost. A strategy for spacecraft design that meets these conflicting requirements is presented. Taken together, spacecraft structure and propulsion subsystems constitute the majority of spacecraft mass; saving development and integration cost on these elements is critical to controlling cost. Therefore, a low cost, modular design for spacecraft structure and propulsion subsystems is presented which may be easily scaled up or down for either insertion into lunar orbit or braking for landing on the lunar surface. In order to effectively use the approx.3 Mt mass-to-TLI of the EELV, two low cost spacecraft will be manifested on the same launch. One spacecraft will be located on top of the other for launch and the two will have to be released in sequence in order to achieve all mission objectives. The two spacecraft could both be landers, both orbiters, or one lander and one orbiter. In order to achieve mass efficiency, the body of the spacecraft will serve the dual purposes of carrying launch loads and providing attachment points for all the spacecraft subsystems. In order to avoid unaffordable technology development costs, small liquid propulsion components and autonomous, scene-matching navigation cameras may be adapted from military missile programs in order to execute precision soft landings.

Lemke, Lawrence G.↗

Initial OpenStudio Profiling Results

OpenStudio’s performance has not historically been an area of much work, but as it has successfully replaced ad hoc model generation solutions, the performance of the software is more and more central to continuing success. This report describes an initial effort to profile OpenStudio, describes the problems encountered, the solutions to those problems, and some early recommendations for further work should funding become available. The approach taken here is to use special software, referred to as profilers, to assess the code and how it executes. This approach is more appropriate for this kind of software than the checkpoint-style timing that is often done with numerical codes. Profiling was most successful on the MacOS platform, where Apple’s Instruments software was able to decipher the complexities of OpenStudio’s command line execution of a workflow. Even with the limited exploration of performance done here, the team quickly ran into limitations imposed on the code by the stateless architecture, and the team recommends an evaluation of this architecture as a good next step to improve performance.

97 MATHEMATICS AND COMPUTING↗

Towards an integral computer environment supporting system operations analysis and conceptual design

VITROCISET has in house developed a prototype tool named System Dynamic Analysis Environment (SDAE) to support system engineering activities in the initial definition phase of a complex space system. The SDAE goal is to provide powerful means for the definition, analysis, and trade-off of operations and design concepts for the space and ground elements involved in a mission. For this purpose SDAE implements a dedicated modeling methodology based on the integration of different modern (static and dynamic) analysis and simulation techniques. The resulting 'system model' is capable of representing all the operational, functional, and behavioral aspects of the system elements which are part of a mission. The execution of customized model simulations enables: the validation of selected concepts with respect to mission requirements; the in-depth investigation of mission specific operational and/or architectural aspects; and the early assessment of performances required by the system elements to cope with mission constraints and objectives. Due to its characteristics, SDAE is particularly tailored for nonconventional or highly complex systems, which require a great analysis effort in their early definition stages. SDAE runs under PC-Windows and is currently used by VITROCISET system engineering group. This paper describes the SDAE main features, showing some tool output examples.

Barro, E.↗

Agent Based Software for the Autonomous Control of Formation Flying Spacecraft

Distributed satellite systems is an enabling technology for many future NASA/DoD earth and space science missions, such as MMS, MAXIM, Leonardo, and LISA [1, 2, 3]. While formation flying offers significant science benefits, to reduce the operating costs for these missions it will be essential that these multiple vehicles effectively act as a single spacecraft by performing coordinated observations. Autonomous guidance, navigation, and control as part of a coordinated fleet-autonomy is a key technology that will help accomplish this complex goal. This is no small task, as most current space missions require significant input from the ground for even relatively simple decisions such as thruster burns. Work for the NMP DS1 mission focused on the development of the New Millennium Remote Agent (NMRA) architecture for autonomous spacecraft control systems. NMRA integrates traditional real-time monitoring and control with components for constraint-based planning, robust multi-threaded execution, and model-based diagnosis and reconfiguration. The complexity of using an autonomous approach for space flight software was evident when most of its capabilities were stripped off prior to launch (although more capability was uplinked subsequently, and the resulting demonstration was very successful).

How, Jonathan P.↗

Attitude Control System for a Balloon Based Telescope

The Balloon Experimental Twin Telescope for Infrared Interferometry (BETTII) is an 8-meter interferometer which operates on a high-altitude balloon. BETTII had its first successful engineering flight in June 2017. In this paper we discuss the design of the control system for BETTII, which includes the coarse pointing loop and the estimator controls algorithm (Extended Kalman Filter) implemented in FPGA. We will also discuss the different system modes that we defined in the controls system loop, which are used in different phases of the flight and are activated in order to acquire a target star in the science detector. The pointing loop uses different sensors and actuators in each phase to keep pointing at the desired target. The main sensors aregyroscopes, star cameras, and auxiliary sensors such as high-altitude GPS and magnetometers. The azimuth control is achieved with Compensated Controlled Moment Gyros (CCMG) and a Momentum Dump motor. For the elevation control, high-precision motors are used, which change the elevation of the siderostat mirrors. The combination of these instruments keep the baseline oriented within few arcseconds from the target star.In this paper, we will also present the software architecture relevant to the control system. This includes the description of the two flight computers present on the payload and the different control loops that are executed on them. Similarly, we will explain the importance of synchronization between all the sensors and actuators, which have to be referenced to a single master clock in order to obtain science data.

Vila Hernandez De Lorenzo, Jordi↗

Engineering a Solution to Jupiter Exploration

The Europa Jupiter System Mission (EJSM) would be an international mission with the overall theme of investigating the emergence of habitable worlds around gas giants. Its goals are to (1) explore Europa to investigate its habitability, (2) characterize Ganymede as a planetary object including its potential habitability and (3) explore the Jupiter system as an archetype for gas giants. NASA and ESA have concluded a detailed joint study of a mission to Europa, Ganymede, and the Jupiter system with conceptual orbiters developed by NASA and ESA. The baseline EJSM architecture consists of two primary elements operating simultaneously in the Jovian system: the NASA-led Jupiter Europa Orbiter (JEO), and the ESA-led Jupiter Ganymede Orbiter (JGO). JEO and JGO would execute an intricately choreographed exploration of the Jupiter System before settling into orbit around Europa and Ganymede, respectively. EJSM would directly address themes concerning the origin and evolution of satellite systems and water-rich environments in icy satellites. The potential habitability of the ocean-bearing moons Europa and Ganymede would be investigated, by characterizing the geophysical, compositional, geological, and external processes that affect these icy worlds. EJSM would also investigate Io and Callisto, Jupiter's atmosphere, and the Jovian magnetosphere. By understanding the Jupiter system and unraveling its history, the formation and evolution of gas giant planets and their satellites would be better known. Most importantly, EJSM would shed new light on the potential for the emergence of life in the celestial neighborhood and beyond. The EJSM baseline architecture would provide opportunities for coordinated synergistic observations by JEO and JGO of the Jupiter and Ganymede magnetospheres, the volcanoes and torus of Io, the atmosphere of Jupiter, and comparative planetology of icy satellites. Each spacecraft would conduct both synergistic dual-spacecraft investigations and stand-alone measurements toward the overall mission theme and goals.

Clark, Karla↗

Embedding triple-modular redundancy into a hypercube architecture

This paper describes an embedding of Triple Modular Redundancy (TMR) into a binary hypercube. The goal is to improve fault tolerance by masking any single-point faults. Each module of an application task is triplicated and executed in parallel on three nodes of a 2-dimensional subcube (Q2) of the hypercube. Each of these nodes also executes a voter process. The remaining node is used for message passing only. All outputs from the triplicated modules are voted on, and the voting results are transmitted to the appropriate destination. Thus, all interunit messages are also triplicated. We propose an embedding of TMR into a hypercube which can be implemented in a manner transparent to the application program. Subcubes are allocated so that the address space for the TMR units is also a hypercube. Hence, the subcube allocation and intermodule communication schemes are defined to be analogous to the schemes used in the nonredundant system. The embedded system is proven to mask all single-point faults.

Kiskis, Daniel L.↗

Executing CLIPS expert systems in a distributed environment

This paper describes a framework for running cooperating agents in a distributed environment to support the Intelligent Computer Aided Design System (ICADS), a project in progress at the CAD Research Unit of the Design Institute at the California Polytechnic State University. Currently, the systems aids an architectural designer in creating a floor plan that satisfies some general architectural constraints and project specific requirements. At the core of ICADS is the Blackboard Control System. Connected to the blackboard are any number of domain experts called Intelligent Design Tools (IDT). The Blackboard Control System monitors the evolving design as it is being drawn and helps resolve conflicts from the domain experts. The user serves as a partner in this system by manipulating the floor plan in the CAD system and validating recommendations made by the domain experts. The primary components of the Blackboard Control System are two expert systems executed by a modified CLIPS shell. The first is the Message Handler. The second is the Conflict Resolver. The Conflict Resolver synthesizes the suggestions made by the domain experts, which can be either CLIPS expert systems, or compiled C programs. In DEMO1, the current ICADS prototype, the CLIPS domain expert systems are Acoustics, Lighting, Structural, and Thermal; the compiled C domain experts are the CAD system and the User Interface.

Taylor, James↗

Automated Instrumentation, Monitoring and Visualization of PVM Programs Using AIMS

We present views and analysis of the execution of several PVM (Parallel Virtual Machine) codes for Computational Fluid Dynamics on a networks of Sparcstations, including: (1) NAS Parallel Benchmarks CG and MG; (2) a multi-partitioning algorithm for NAS Parallel Benchmark SP; and (3) an overset grid flowsolver. These views and analysis were obtained using our Automated Instrumentation and Monitoring System (AIMS) version 3.0, a toolkit for debugging the performance of PVM programs. We will describe the architecture, operation and application of AIMS. The AIMS toolkit contains: (1) Xinstrument, which can automatically instrument various computational and communication constructs in message-passing parallel programs; (2) Monitor, a library of runtime trace-collection routines; (3) VK (Visual Kernel), an execution-animation tool with source-code clickback; and (4) Tally, a tool for statistical analysis of execution profiles. Currently, Xinstrument can handle C and Fortran 77 programs using PVM 3.2.x; Monitor has been implemented and tested on Sun 4 systems running SunOS 4.1.2; and VK uses XIIR5 and Motif 1.2. Data and views obtained using AIMS clearly illustrate several characteristic features of executing parallel programs on networked workstations: (1) the impact of long message latencies; (2) the impact of multiprogramming overheads and associated load imbalance; (3) cache and virtual-memory effects; and (4) significant skews between workstation clocks. Interestingly, AIMS can compensate for constant skew (zero drift) by calibrating the skew between a parent and its spawned children. In addition, AIMS' skew-compensation algorithm can adjust timestamps in a way that eliminates physically impossible communications (e.g., messages going backwards in time). Our current efforts are directed toward creating new views to explain the observed performance of PVM programs. Some of the features planned for the near future include: (1) ConfigView, showing the physical topology of the virtual machine, inferred using specially formatted IP (Internet Protocol) packets: and (2) LoadView, synchronous animation of PVM-program execution and resource-utilization patterns.

Mehra, Pankaj↗

Semi-Empirical Shadow Molecular Dynamics: A PyTorch Implementation

Here, extended Lagrangian Born–Oppenheimer molecular dynamics (XL-BOMD) in its most recent shadow potential energy version has been implemented in the semiempirical PyTorch-based software PySeQM. The implementation includes finite electronic temperatures, canonical density matrix perturbation theory, and an adaptive Krylov subspace approximation for the integration of the electronic equations of motion within the XL-BOMB approach (KSA-XL-BOMD). The PyTorch implementation leverages the use of GPU and machine learning hardware accelerators for the simulations. The new XL-BOMD formulation allows studying more challenging chemical systems with charge instabilities and low electronic energy gaps. The current public release of PySeQM continues our development of modular architecture for large-scale simulations employing semi-empirical quantum-mechanical treatment. Applied to molecular dynamics, simulation of 840 carbon atoms, one integration time step executes in 4 s on a single Nvidia RTX A6000 GPU.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

XaaS: Acceleration as a Service to Enable Productive High-Performance Cloud Computing

High-performance computing (HPC) and the cloud have evolved independently, specializing their innovations into performance or productivity. Acceleration as a Service (XaaS) is a recipe to empower both fields with a shared execution platform that provides transparent access to computing resources, regardless of the underlying cloud or HPC service provider. Bridging HPC and cloud advancements, XaaS presents a unified architecture built on performance-portable containers. Here, our converged model concentrates on low-overhead, high-performance communication and computing, targeting resource-intensive workloads from climate simulations to machine learning. XaaS lifts the restricted allocation model of Function as a Service (FaaS), allowing users to benefit from the flexibility and efficient resource utilization of serverless computing while supporting long-running and performance-sensitive workloads from HPC.

97 MATHEMATICS AND COMPUTING↗

Secure API-Driven Research Automation to Accelerate Scientific Discovery

The Secure Scientific Service Mesh (S3M) provides API-driven infrastructure to accelerate scientific discovery through automated research workflows. By integrating near real-time streaming capabilities, intelligent workflow orchestration, and fine-grained authorization within a service mesh architecture, S3M enables secure and flexible programmatic access to high performance computing (HPC) resources. This framework allows intelligent agents and experimental facilities to dynamically provision resources and execute complex workflows, accelerating experimental lifecycles, and enabling AI-augmented autonomous science. S3M establishes a modern foundation for scientific computing infrastructure that significantly reduces traditional barriers between researchers, computational resources, and experimental facilities.

Skluzacek, Tyler [ORNL] (ORCID:0000000322424931)↗

Quantum Network Repeater Simulation Package (QNPack) v1.0.0

Existing quantum network testbeds and prototypes are typically implemented in laboratory experiments with limited functionality and operate in a tightly coupled manner. These characteristics make it difficult to evaluate the behavior of emerging quantum platforms and protocols beyond local resource limitations. The QNPack software enables full-stack modeling of quantum repeater networks that allows researchers to simulate new approaches, and understand emergent behaviors, from local to national scales. Novel capabilities include: (1) performant and accurate quantum models that can be executed as independent simulations, which will allow users to characterize specific analog quantum processes, quantum devices, and protocols, (2) a modular and extensible approach to the simulation architecture to accommodate new quantum technologies, protocols, and topologies as they are developed across the quantum repeater generations under evaluation, and (3) a focus on managing the interactions between the simulation framework sub-components so that they may be re-used and composed in flexible ways.

Kissel, Ezra [Lawrence Berkeley National Laborator↗

Portable Health Algorithms Test System

A document discusses the Portable Health Algorithms Test (PHALT) System, which has been designed as a means for evolving the maturity and credibility of algorithms developed to assess the health of aerospace systems. Comprising an integrated hardware-software environment, the PHALT system allows systems health management algorithms to be developed in a graphical programming environment, to be tested and refined using system simulation or test data playback, and to be evaluated in a real-time hardware-in-the-loop mode with a live test article. The integrated hardware and software development environment provides a seamless transition from algorithm development to real-time implementation. The portability of the hardware makes it quick and easy to transport between test facilities. This hard ware/software architecture is flexible enough to support a variety of diagnostic applications and test hardware, and the GUI-based rapid prototyping capability is sufficient to support development execution, and testing of custom diagnostic algorithms. The PHALT operating system supports execution of diagnostic algorithms under real-time constraints. PHALT can perform real-time capture and playback of test rig data with the ability to augment/ modify the data stream (e.g. inject simulated faults). It performs algorithm testing using a variety of data input sources, including real-time data acquisition, test data playback, and system simulations, and also provides system feedback to evaluate closed-loop diagnostic response and mitigation control.

Melcher, Kevin J.↗

Virtual Sensor Test Instrumentation

Virtual Sensor Test Instrumentation is based on the concept of smart sensor technology for testing with intelligence needed to perform sell-diagnosis of health, and to participate in a hierarchy of health determination at sensor, process, and system levels. A virtual sensor test instrumentation consists of five elements: (1) a common sensor interface, (2) microprocessor, (3) wireless interface, (4) signal conditioning and ADC/DAC (analog-to-digital conversion/ digital-to-analog conversion), and (5) onboard EEPROM (electrically erasable programmable read-only memory) for metadata storage and executable software to create powerful, scalable, reconfigurable, and reliable embedded and distributed test instruments. In order to maximize the efficient data conversion through the smart sensor node, plug-and-play functionality is required to interface with traditional sensors to enhance their identity and capabilities for data processing and communications. Virtual sensor test instrumentation can be accessible wirelessly via a Network Capable Application Processor (NCAP) or a Smart Transducer Interlace Module (STIM) that may be managed under real-time rule engines for mission-critical applications. The transducer senses the physical quantity being measured and converts it into an electrical signal. The signal is fed to an A/D converter, and is ready for use by the processor to execute functional transformation based on the sensor characteristics stored in a Transducer Electronic Data Sheet (TEDS). Virtual sensor test instrumentation is built upon an open-system architecture with standardized protocol modules/stacks to interface with industry standards and commonly used software. One major benefit for deploying the virtual sensor test instrumentation is the ability, through a plug-and-play common interface, to convert raw sensor data in either analog or digital form, to an IEEE 1451 standard-based smart sensor, which has instructions to program sensors for a wide variety of functions. The sensor data is processed in a distributed fashion across the network, providing a large pool of resources in real time to meet stringent latency requirements.

Wang, Roy↗

Small Microprocessor for ASIC or FPGA Implementation

A small microprocessor, suitable for use in applications in which high reliability is required, was designed to be implemented in either an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA). The design is based on commercial microprocessor architecture, making it possible to use available software development tools and thereby to implement the microprocessor at relatively low cost. The design features enhancements, including trapping during execution of illegal instructions. The internal structure of the design yields relatively high performance, with a significant decrease, relative to other microprocessors that perform the same functions, in the number of microcycles needed to execute macroinstructions. The problem meant to be solved in designing this microprocessor was to provide a modest level of computational capability in a general-purpose processor while adding as little as possible to the power demand, size, and weight of a system into which the microprocessor would be incorporated. As designed, this microprocessor consumes very little power and occupies only a small portion of a typical modern ASIC or FPGA. The microprocessor operates at a rate of about 4 million instructions per second with clock frequency of 20 MHz.

Kleyner, Igor↗

Autonomous Ocean World Exploration: Advancement of a Virtual Testbed

The search for life (extinct or extant) and potentially habitable bodies in our solar system and beyond is one of the 12 priority science questions outlined in the National Acadamies’ 2022 decadal survey [5]. Extraterrestrial destinations containing liquid water present an opportunity to search for life as we know it, and in recent years an increasing number of such locations have been discovered within our solar system. Several Jovian moons—Europa, Ganymede, and Callisto [10]—and the Saturnian moons Enceladus [8] and Titan [9] are known or suspected to harbor massive subsurface oceans. Of these "ocean worlds", Europa is the focus of at least one planned NASA orbiter mission, Europa Clipper [4], and an early lander mission concept, the Europa Lander [2, 3]. Whereas most robotic missions to the Moon and Mars (e.g. orbiters, rovers, landers) to date have had ground controllers on Earth tightly involved in mission operations, missions to more distant worlds will require a high degree of onboard autonomy due to long communication lags and blackouts, harsh environments (radiation, cold), and more limited battery and hardware life. The past decade has seen great advances in both AI technologies and computing scalability and performance that offer promising solutions for spacecraft autonomy and motivate the software system and research programs described in this paper. The Ocean Worlds Autonomy Testbed for Exploration, Research, and Simulation (OceanWATERS) [1], which has been in development at the NASA Ames Research Center since 2018, is a virtual environment for testing lander autonomy solutions. It is built on the Robot Operating System (ROS), runs on consumer-grade Linux workstations, and was released as open source in 2020. OceanWATERS provides a physical and visual simulation of a prototypical lander in a Europa-like environment (Figure 1). The lander was modeled after requirements and specifications made in JPL’s Europa Lander Study of 2016 [3]. Simulated lander systems include stereo cameras and spotlights mounted on an antenna mast that pans and tilts, a 6 degrees of freedom (DoF) robotic arm with a force-torque sensor and two interchangeable end effectors, and a battery pack power system. The environment consists of multiple terrain models including a highly detailed model sourced from the FROST dataset [11], simulation of surrounding planetary bodies based on an ephemeris model, and lighting from the sun with associated surface illumination, reflectance, and shadows. Operations supported by OceanWATERS include panoramic and directed imaging of the environment and lander workspace, Cartesian and joint-level arm commanding, grinding of the terrain surface (e.g. digging a trench), and scooping of ground material (Figure 2) which can be discarded or collected as science samples in a receptacle that can be emptied (science operations themselves are not simulated). These operations are realized as ROS Actions and are complimented by a wide selection of telemetry that is continually produced by each lander subsystem. The power system model is driven by the open-source Generic Software Architecture for Prognostics (GSAP) [11] that predicts the battery’s remaining useful life and other characteristics. As a testbed for high-level autonomy, OceanWATERS provides an execution framework based on PLEXIL [12], an open-source plan specification language and execution engine developed largely at Ames. NASA's initial development of OceanWATERS, as well the Ocean Worlds Lander Autonomy Testbed (OWLAT) [6], a complimentary physical testbed developed at JPL, was the first step in a plan for realizing candidate onboard autonomy solutions for such planetary landers. In 2020 NASA solicited applications for its Autonomous Robotics Research for Ocean Worlds (ARROW) program, and in 2021 the similar Concepts for Ocean worlds Life Detection Technology (COLDTech) program. Collectively six research teams, based in universities and companies across the United States, were awarded grants to develop and demonstrate autonomy solutions on OceanWATERS and OWLAT. These 1–2-year projects have now finished or are nearing completion, and a wide variety of autonomy challenges in ocean world surface missions were addressed. Prototyped and demonstrated solutions have included autonomous discovery, response and adaptation to system faults and unexpected environmental events, world model synthesis through perception, plan synthesis using learned models, methods to optimize sample target selection and prioritize science data transmission, extension of PLEXIL for stochastic decision-making, and an integration of a model of JPL’s mission-ready COLDArm [7]. Technologies used in these projects include many forms of machine learning, causal reasoning, automated planning, Markov decision processes, formal methods, and other advanced techniques. A more detailed summary of the ARROW and COLDTech projects is given herein. OceanWATERS has had significant enhancements since its open-source release in 2020. Many of its new features were driven or shaped by feedback from the ARROW and COLDTech teams and requirements of their projects. In support of enabling autonomous adaptation to spacecraft faults (a specific capability solicited by both programs), a fault injection and detection framework was developed that supports a wide and growing range of fault types such as locked joints, image loss, and battery failures. The power system model was completed and integrated into the simulator, starting as a single-cell battery model and later upgraded to a multi-cell model with associated faults such as cell disconnection. Arm/terrain interaction was improved by adding a force-torque sensor and associated faults, and an analytic dig force model based on the Balovnev bucket force equations. Environment fidelity was increased by modeling terrain deformation resulting from digging and scooping; visual improvements were made in textures, lighting, and shadows. To facilitate interoperation with OWLAT, a unified command and telemetry interface between the testbeds was developed at the ROS level, along with a PLEXIL interface. The number of lander operations was greatly expanded (e.g. with Cartesian-based arm and antenna movement), and a framework was designed for users to build their own lander actions. A GUI for PLEXIL plan selection was created (Figure 3), and an expansive set of plans were added, such as those that illustrate patterns for fault handling. This paper provides a self-contained high-level description of OceanWATERS, focusing on more detailed coverage of the aforementioned enhancements. It provides a high-level summary of the projects undertaken by participants in the ARROW and COLDTech programs and how these efforts have helped shape OceanWATERS. Finally, potential future work and directions for the testbed are listed, as likely informed by the recent planetary science decadal survey [5].

K Michael Dalal↗

OpenCGRA: An Open-Source Unified Framework for Modeling,Testing, and Evaluating CGRAs

Coarse-grained reconfigurable arrays (CGRAs),loosely defined as arrays of functional units (e.g, adder, sub-tractor, multiplier, divider, or larger multi-operation units, butsmaller than a general-purpose core) interconnected through aNetwork-on-Chip, provide higher flexibility than domain-specificASIC accelerators while offering increased hardware efficiencywith respect to fine-grained reconfigurable devices, such as FieldProgrammable Gate Arrays (FPGAs). The fast evolving fieldsof machine learning and edge computing, which are seeing acontinuous flow of novel algorithms and larger models, makeCGRAs ideal target architectures to allow domain specializationwithout loosing too much generality. They also generally offerquicker and more effective reconfigurability than FPGAs, po-tentially allowing adaptation during actual algorithm execution,and implement a dataflow programming paradigm that adaptswell to these emerging workloads. Designing and generating aCGRA, however, still requires to define the type and number ofthe specific functional units, implement their interconnect andthe network topology, and perform its simulation and validation,given a variety of workloads of interest.In this paper, we propose OpenCGRA, a Python-based unifiedframework that integrates generation, modeling, testing and eval-uation for CGRAs. OpenCGRA is the first open-source integratedframework able to support the full top-to-bottom design flow forspecializing and implementing CGRAs: modeling at different ab-straction levels (functional level, cycle level, register-transfer level),generation, simulation, testing at different granularities (unit test-ing, integration testing, property-based testing), and characteriza-tion (area, power, and timing). OpenCGRAs will be made availableon GitHub.

CGRA, synthesis↗