Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “runtime”

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 325 records · Page 18
All sourcesNASA NTRSDOE OSTI
NASA NTRS2022

pyCRTM: A Python Interface for the Community Radiative Transfer Model

The Community Radiative Transfer Model (CRTM) is a powerful and versatile scalar radiative transfer model for satellite data assimilation and remote sensing applications. It is implemented as an object-oriented Fortran library, enabling flexible code development and optimal runtime performance on clusters. The downsides of the Fortran interface are a steep learning curve for students and the reduced productivity of users that is typical for static compiled languages, in contrast to dynamic interpreted languages like Python. pyCRTM is a new software framework that directly interfaces the CRTM Fortran data structures and procedures in Python, leveraging both the simplicity and ease of use of Python syntax as well as the flexibility arising from the vast contemporary Python ecosystem. The goal of pyCRTM is to lower the barrier of entry for university students to learn and use the CRTM and to boost the productivity of researchers seeking to create new methods in radiative transfer and data assimilation, or seeking to apply the CRTM to study atmospheric phenomena without having to go through the pre-existing complexity of the CRTM Fortran interface.

Python↗
NASA NTRSDate not supplied

CropManage Application for Vineyard Irrigation Decision-Support

CropManage is a free web-application developed by U.C. Cooperative Extension to support evapotranspiration based irrigation scheduling and nutrient management for major specialty crops. Prescribed phenology curves are used to develop daily estimates of canopy cover within a given field, based on days since planting (annual crops) or budbreak (trees, vines). These curves are modulated by a MaxCan parameter representing seasonal maximum canopy cover. Crop development observations can be used to adjust for such factors as weather anomalies or non-standard agronomic practice, as needed. Canopy cover is converted to crop coefficient and combined with reference evapotranspiration to derive daily water consumption. Guidance on crop water requirement is then conveyed to users in terms of system runtime issued on-demand for a given date, largely based on total evapotranspiration since last irrigation event. In this study, CropManage was adapted to vineyards by adding modules accounting for early-season soil moisture depletion and cover crop presence. A crop stress parameter was added to accommodate deficit irrigation practice, allowing the user to specify percentage departure from full water requirement along with start/stop dates. An initial verification exercise was performed on three winegrape vineyards located in California’s Central Coast (2020), North Coast (2020) and Central Valley (2019). Daily crop evapotranspiration was monitored by eddy-covariance fluxtowers. MaxCan was measured by ground and satellite observation. Stress regime was specified by grower practice where available, otherwise stress levels were inferred from applied water records. Mean absolute error and mean bias error of modeled cumulative evapotranspiration were computed with respect to the eddy covariance measurements collected throughout the growing season. Results indicate the modified CropManage water management module performs reasonably well for winegrape. Additional effort is planned to modify the nutrient module for vineyard use.

CropManage↗
NASA NTRSDate not supplied

Overview of Model-Based Systems Engineering Efforts to Evolve the Airspace Research Roadmap

NASA’s Air Traffic Management-Exploration (ATM-X) UAM Airspace Subproject is conducting research that evolves UAM airspace towards a highly automated and operationally flexible system of the future. The complexity of UAM airspace evolution requires a plan to effectively organize, integrate, and communicate NASA’s research and development. The planning tool, called the UAM airspace research roadmap, or just roadmap, is key to the execution of NASA’s UAM airspace research over the next ten years. Implemented through Model-Based Systems Engineering (MBSE) methodology, the roadmap will help to prioritize and coordinate research efforts, and to integrate results that build towards NASA’s research goals of evolving UAM airspace for integration of UAM operations into the National Airspace System (NAS). This paper presents an overview of on-going MBSE efforts to meet these overarching goals. Note: Included mp4 video of presentation included in record, runtime 9 mins 57 secs.

Model-Based Systems Engineering↗
NASA NTRS2022

Chile Disasters: Automating Wildfire Risk and Occurrence Mapping in Google Earth Engine to Improve Wildfire Detection and Response Time Efforts

Wildfires in Chile in the last decade were the worst on record, destroying homes and livelihoods, polluting the air, and displacing whole towns. To predict locations where wildfires were likely to start, the Corporación Nacional Forestal (CONAF) created a wildfire risk model within ArcGIS Pro and Google Earth Engine (GEE) that utilized the NOAA Global Forecast System (GFS) and the NASA Shuttle Radar Topography Mission (STRM) 90-meter datasets. The previous CONAF model was very resource-heavy and time-intensive to run. NASA DEVELOP, in partnership with CONAF, automated the previous model and transferred it fully into GEE where all Earth observation datasets could be used without downloading. The new model substantially reduced the runtime. The final model was used to create a near real-time wildfire monitoring application as well as fire severity maps. The end products will be used by CONAF for wildfire prediction and management to prevent more destruction in the future.

Maria De Los Santos↗
NASA NTRSDate not supplied

Capturing and Analyzing Requirements with FRET

FRET is an open source tool, developed at NASA Ames, for writing, understanding, formalizing, and analyzing requirements. In practice, requirements are typically written in natural language, which is ambiguous and consequently not amenable to formal analysis. Since formal, mathematical notations are unintuitive, requirements in FRET are entered in a restricted, natural language, called FRETish with precise unambiguous meaning. FRET helps users write FRETish requirements both by providing grammar information and examples during editing, but also through English and diagrammatic explanations to clarify subtle semantic issues. For each requirement, FRET automatically produces formalizations and supports interactive simulation of produced formalizations to ensure that they capture user intentions. Through its analysis portal, FRET connects to analysis tools by exporting verification code. Currently FRET connects to (1) the CoCoSim automated analysis tool for the verification of Simulink and Stateflow models, and (2) the Copilot runtime monitoring tool for the analysis of C programs. FRET also supports the consistency/realizability analysis of requirements for identifying conflicting requirements. In this tutorial, we introduce FRET and learn to speak and analyze FRETish through several examples.

FRET↗
NASA NTRSDate not supplied

FRET Tutorial

In this tutorial, we present the FRET tool for writing, understanding, formalizing and analyzing requirements. In practice, requirements are typically written in natural language, which is ambiguous and consequently not amenable to formal analysis. Since formal, mathematical notations are unintuitive, requirements in FRET are entered in a restricted, natural language, called FRETish with precise unambiguous meaning. This tutorial explains how requirements can be captured in FRETish and subsequently formalized in temporal logics and in the synchronous data flow language Lustre. We show, through multiple examples, how FRET assists users in understanding FRETish requirements and clarifying subtle semantic issues through English and diagrammatic explanations as well as interactive simulation. FInally, this tutorial describes how FRET can be used to perform realizability checking for identifying conflicting requirements and the connection of FRET with (1) the CoCoSim automated analysis tool for the verification of Simulink and Stateflow models, and (2) the Copilot runtime monitoring tool for the analysis of C programs.

FRET↗
NASA NTRSDate not supplied

Open Data Integration (ODIN): A Concurrent, Distributed Message-Based Architecture and Framework for Disaster Response

The Runtime for Airspace Concept Evaluation (RACE) is an open-source software architecture and framework to build configurable, highly concurrent and distributed message-based systems that offer scalable, low-latency performance on commodity hardware. RACE was used in commercial aviation applications to rapidly build systems that span several machines (including synchronized displays), interface existing hardware simulators and other live data feeds, and incorporate sophisticated visualization components such as NASA WorldWind. These RACE applications validated elements of the FAA’s System Wide Information Management (SWIM) Program, handling up to 1000 messages/sec from diverse sources (SFDPS, TFM-DATA, TAIS, ASDE-X, ITWS and local ADS) for 4,500 simultaneous flights tracked in the next-generation air transportation system’s digital backbone. We have since generalized RACE to support Open Data Integration (ODIN) applications outside aviation. Systems built with RACE/ODIN can be deployed in the field, on commodity hardware, and operate with limited or intermittent connectivity to the outside world. Our primary use case is a web-server with local/persistent data storage that runs within and only serves the stakeholder network (e.g. an incident command post). We are tailoring the RACE/ODIN system to support wildland fire management for the upcoming NASA Wildland Fire Safety Demonstration Series. RACE-ODIN is under consideration for application in the Scalable Traffic Management for Emergency Response Operations project, or STEReO, which aims to create a system that can be deployed during emergencies, to coordinate multiple elements of disaster response. Such data sources predominantly come from existing services on the internet (e.g. weather and satellite data, imported from so called "edge servers") but can also include dynamic (real-time) data from computer simulations and within the stakeholder network (such as aircraft and personnel tracking information). We will present the architecture and ODIN system demonstration incorporating local data from instrumented power-line towers, interpolated weather data and geospatial data from space-based platforms.

Joseph C Coughlan↗
NASA NTRSDate not supplied

An Overview of the Patch Integral Method (PIM), a New Heat Transfer Analysis Tool for Hypersonic Wind Tunnel Facilities at NASA Langley

NASA Langley’s hypersonic wind tunnels are heavily leveraged for planetary missions. The data collection method in these tunnels is thermography, and surface temperature measurements of the model surface are collected and reduced to produce surface heating data, as seen in Fig 1. However, during model injection, no temperature data are collected, and thus conventional, integral heat transfer methods cannot be used to solve for surface heating. A method was developed in the 1990’s to reduce this data despite the data gap, known as the step approximation method. The method assumes that the film coefficient behaves as a step function, the model is semi-infinite, and thermal properties are constant. With these simplifying assumptions, a Laplace transform can be performed to result in an equation that takes the initial temperature of the model and a temperature at some point in time to back out the film coefficient at that time. This is the method that is used in the current thermographic data reduction software, IHEAT. While computationally light-weight, the step approximation has several issues associated with it. The time-history of temperature is not accounted for, which is vital as heat transfer is an integral process. Additionally, the required semi-infinite assumption is unnecessary and might be violated during runtime. Thermal variation of material properties can have a sizeable impact on heating results and are not modeled by the method. This method also takes multiple seconds to “collapse” to a steady state, which is undesirable from both a facility and data reduction standpoint. The method is also very sensitive to the “effective time” approximation, an approximation of when heating instantaneously starts (which is a nonphysical simplification), and a small variation in this value can result in an error in heating results.

J. S. Cheatwood↗
NASA NTRSDate not supplied

New Features of the NEQAIR Radiation Code

The longest-lived code for predicting shock layer radiation, NEQAIR, is now in its 5th decade of service. Substantial changes to the code have been made over the previous decade, the most recent report of which was at the 5th Workshop on Radiation in High Temperature Gases in 2014, for the version referred to as NEQAIR14. This paper will review some of the improvements made to the NEQAIR code since then, which is now at v15.2. Some of these features are discussed briefly below. NEQAIR15 and subsequent versions have enabled parallel evaluation of multiple lines of sight. This is accomplished by utilizing the HDF5 file format and placing multiple lines into a single file, LOS.h5, which is used for both input and output. This approach enables straightforward parallel execution both over the number of lines of sight and the number of points per line. For large problems, runtime reduces linearly with the number of nodes deployed since each line is processed independently by a subset of MPI ranks. Three applications of the multi-line solver are discussed. The first has to do with performing loosely coupled radiation-flowfield solutions. In this case the computed absorption and emission coefficients are used to evaluate the total energy absorbed or emitted at each point, allowing evaluation of the volumetric source term in the flowfield. The second computation is for obtaining heat flux from nonuniform flows, which require integration over spherical co-ordinates. These are of particular interest for evaluating radiation on the vehicle backshell. This 3D option improves the angular integration scheme and allows adaptive line selection that together reduce the number of lines required by about an order of magnitude. The final application is for remote observation, which is essentially the 3D integration problem over a small solid angle. For all three of these computations, data can be stored in the HDF5 file which allows a NEQAIR run to be restarted when it times out, or to add atmospheric absorption or instrument scan functions. An additional level of parallelism is enabled in NEQAIR15.2 using GPU routines. The GPU parallelism has realized up to 8x speed-up when running on a single core but diminishes as CPU parallelism is increased. For running multi-line simulations, it may be easier to reserve a large number of CPU nodes than to obtain the number of GPU nodes required for similar performance. A GUI, known as NEQTPY, allows for reading and creating input files, running NEQAIR, and displaying results. A significant feature of NEQTPY is the ability to perform spectral fits to data. The fits can operate on a single line spectrum (radiance vs. wavelength) or a 3D input file with multiple columns of data. Other new features include improved constants, additional species, more detailed non-Boltzmann modelling, advanced user controls, the ability to read and calculate spectra from HITRAN datafiles, photodissociation and photoionization cross-sections. A “fast” automatic grid option may reduce the size and time of spectral calculations while still maintaining good accuracy for total heat flux.

Brett A Cruden↗
NASA NTRS2022

Launch Complex 34, SWMU Cc054 2021 DNAPL Source Zone Operations, Maintenance, and Monitoring, and Hot Spot 6 Air Sparge System Annual Performance Monitoring Report Cape Canaveral Space Force Station, Florida

This Annual Performance Monitoring Report (PMR) for the Dense Non-Aqueous Phase Liquid (DNAPL) Source Zone (DSZ) and Hot Spot 6 (HS 6) Air Sparge (AS) System presents the results of Year 12 operation of the hydraulic containment (HC) Interim Measure (IM), the results of performance monitoring direct-push technology (DPT) sampling and monitoring well sampling conducted in the DSZ, and the results of operations and performance sampling of the HS 6 AS IM at Launch Complex 34 (LC34), located at Cape Canaveral Space Force Station (CCSFS), Florida. Site-wide biennial LTM sampling was not conducted during this reporting period and is scheduled to be conducted in December 2022. The timeframe for activities documented in this PMR extends from April 1, 2021 to March 31, 2022. LC34 has been designated Solid Waste Management Unit CC054 under the Kennedy Space Center (KSC) Resource Conservation and Recovery Act Corrective Action Program. The objective of the HC IM at LC34 is to contain the DSZ and deep dissolved-phase trichloroethene (TCE) high concentration plume via operation of a hydraulic containment system (HCS). The pre-IM design 300 micrograms per liter (μg/L) TCE groundwater contour was used to establish the deep zone capture area for deep recovery wells, and the shallow zone capture area was defined by the DSZ. The system began operating in 2010, and in 2015, the system was expanded to provide HC for areas within the 300 μg/L TCE groundwater isocontours of HS 3 and 4. In 2018 and 2019, an investigation was conducted to re-characterize the DSZ, which included investigating TCE mass in Layer 7. This data was subsequently used to optimize the pumping rates of the HCS to more adequately capture residual contaminant mass. The operational period for Year 12 of the HCS was from April 1, 2021 to March 31, 2022. Operational runtime for the system was 94 percent during Year 12, with downtime events attributed to planned maintenance, system repairs, and power outages. As of March 31, 2022, a total of 285,712,801 gallons of groundwater containing 84,933 pounds of VOCs have been removed by the HCS. Influent concentrations of TCE have decreased since startup from approximately 280,000 µg/L (January 2010) to 12,000 µg/L (March 2022). During the reporting period, all effluent concentrations from the HCS (aqueous and vapor) were below regulatory reporting limits, indicating the system continues to operate as intended. Performance monitoring was conducted in December 2021 within the DSZ to evaluate TCE contamination. Groundwater samples were collected via DPT at nine locations, consistent with previous events in 2017, 2018, 2019, and 2020. Full vertical profile sampling was completed at each DPT from 8 to 98 ft bls, at 5 foot intervals. The DPT performance monitoring results are summarized in this PMR. The results revealed TCE remains at concentrations greater than 11,000 µg/L in the DSZ (1-percent solubility, indicative of DNAPL) at eight of the nine DPT locations at depths ranging from 8 to 98 ft bls. An overall increasing trend of TCE concentrations was observed in DPT samples during this reporting period, which may be due to several recovery wells that were turned off during the AS Pilot Study in the DSZ that operated from July 2021 to February 2022 (documented separately from this report). The maximum TCE concentration in 2021 was 15,400,000 µg/L in the 58 ft bls depth interval at DPT597 (previous maximum result in 2020 was 1,690,000 at 48 ft bls at DPT596). During the 2021 DPT event, the overall majority of TCE contamination was identified in the 58 ft bls interval (below Layer 4), where in the previous year the majority of mass was observed in Layer 4. This trend appears to indicate continued mass discharge from Layer 4 (fine-grained unit). In addition to DPT sampling, monitoring well samples were collected from deep wells in the DSZ area (Layers 7 and 8) to verify vertical delineation. All monitoring well results were non-detect or below cleanup levels, with exception of one well (IW0162, screened 105 to 115 ft bls, which is below the existing recovery well capture zone) where TCE was identified above cleanup target levels. The HS 6 AS system remained operational during the reporting period covered under this report. The HS 6 AS IM was initiated in 2018 with 160 AS wells, and expanded in 2019 with an additional 140 AS wells. Quarterly performance monitoring was reduced to semi-annual prior to this operational period. The results of the HS 6 system operation and semi-annual performance monitoring are summarized in this report. Semi-annual monitoring results collected in April and October 2021 show concentrations of contaminants of concern (cis-1,2-dichloroethene, trans-1,2- dichloroethene, and vinyl chloride) are generally decreasing and not impacting the surface water drainage canal, indicating the HS 6 IM is meeting objectives. Overall, the tasks associated with Year 12 operation of the HC IM and operation of the HS 6 AS IM were performed in accordance with the recommendations of the 2020 LC34 (Year 11) Operations, Maintenance, and Monitoring Report for DNAPL Source Zone, Site Wide LongTerm Monitoring, and Hot Spot 6 Air Sparging System PMR (NASA, 2021c). Evaluation of results from the HC IM and HS 6 IM show that these systems are operating as designed and meeting performance objectives.

trichloroethene↗
NASA NTRSDate not supplied

Open Data Integration (ODIN): A Concurrent, Distributed Message-Based Architecture and Framework for Disaster Response

The Runtime for Airspace Concept Evaluation (RACE) is an open-source software architecture and framework to build configurable, highly concurrent and distributed message-based systems that offer scalable, low-latency performance on commodity hardware. RACE was used in commercial aviation applications to rapidly build systems that span several machines (including synchronized displays), interface existing hardware simulators and other live data feeds, and incorporate sophisticated visualization components such as NASA WorldWind. These RACE applications validated elements of the FAA’s System Wide Information Management (SWIM) Program, handling up to 1000 messages/sec from diverse sources (SFDPS, TFM-DATA, TAIS, ASDE-X, ITWS and local ADS) for 4,500 simultaneous flights tracked in the next-generation air transportation system’s digital backbone. We have since generalized RACE to support Open Data Integration (ODIN) applications outside aviation. Systems built with RACE/ODIN can be deployed in the field, on commodity hardware, and operate with limited or intermittent connectivity to the outside world. Our primary use case is a web-server with local/persistent data storage that runs within and only serves the stakeholder network (e.g. an incident command post). We are tailoring the RACE/ODIN system to support wildland fire management for the upcoming NASA Wildland Fire Safety Demonstration Series. RACE-ODIN is under consideration for application in the Scalable Traffic Management for Emergency Response Operations project, or STEReO, which aims to create a system that can be deployed during emergencies, to coordinate multiple elements of disaster response. Such data sources predominantly come from existing services on the internet (e.g. weather and satellite data, imported from so called "edge servers") but can also include dynamic (real-time) data from computer simulations and within the stakeholder network (such as aircraft and personnel tracking information). We will present the architecture and ODIN system demonstration incorporating local data from instrumented power-line towers, interpolated weather data and geospatial data from space-based platforms.

Guillaume P Brat↗
NASA NTRSDate not supplied

Rapid Spacecraft Payload Development: In-Orbit Demonstration of Flight Software Reuse, Scalability, and Dependability

As space mission design trends towards shared, multi-mission platforms and high-performance onboard computing architectures, the number of spacecraft launched into operation is also steadily rising. Through ridesharing, spacecraft miniaturization, and other cost-reduction measures, the barriers to space are lowering, resulting in compounded growth in the amount of flight software being deployed. To meet the needs of both the growing quantity and evolving nature of spacecraft, flight software design must accordingly adapt to support more efficient development, solutions to computational resource-sharing, and software reusability. This paper focuses on a software payload demonstrating several core technologies that improve the state-of-the-art in these identified areas. Launched into low-earth orbit in January 2022, our software payload was conceived, designed, and delivered in a span of merely two months. It was developed on top of the NASA core Flight System (cFS) framework and the Distributed Spacecraft Autonomy (DSA) Comm cFS application, which translates cFS software bus messages across a Data Distribution Service (DDS) network. The flight software, packaged in Linux container images, was deployed as one of 18 flight applications managed through the Unibap SpaceCloud Framework. The applications were run on a Unibap iX5-102 radiation-tolerant payload computer, hosted on the D-Orbit SCV-004 spacecraft as part of an ESA-sponsored in-orbit technology test. Our payload, referred to as the DSA D-Orbit software, demonstrates the reusability of the DSA Comm app in a substantially different context and purpose as its original mission. Comm’s original design goal was to reliably distribute messages between spacecraft swarms of arbitrary size and dynamic network topology. However, we leverage this same functionality to introduce redundancy and opportunistic parallel data processing in the context of a representative onboard image processing workload. This adaptive mission architecture was enabled in part by the SpaceCloud Framework’s use of container virtualization as the payload integration interface. By using a base container image with common high-level language runtimes and libraries, we were able to rapidly design, develop, and validate our image processing application without many of the technological barriers common to flight software development. We present details the goals, approach, results, and lessons learned through this technology demonstration experiment and contextualize those observations against present and future challenges in spacecraft software development.

computer programming↗
NASA NTRS2023

Framework for Extensible, Asynchronous Task Scheduling (FEATS) in Fortran

Most parallel scientific programs contain compiler directives (pragmas) such as those from OpenMP, explicit calls to runtime library procedures such as those implementing the Message Passing Interface (MPI), or compiler-specific language extensions such as those provided by CUDA. By contrast, the recent Fortran standards empower developers to express parallel algorithms without directly referencing lower-level parallel programming models. Fortran’s parallel features place the language within the Partitioned Global Address Space (PGAS) class of programming models. When writing programs that exploit data-parallelism, application developers often find it straightforward to develop custom parallel algorithms. Problems involving complex, heterogeneous, staged calculations, however, pose much greater challenges. Such applications require careful coordination of tasks in a manner that respects dependencies prescribed by a directed acyclic graph. When rolling one’s own solution proves difficult, extending a customizable framework becomes attractive. The paper presents the design, implementation, and use of the Framework for Extensible Asynchronous Task Scheduling (FEATS), which we believe to be the first task-scheduling tool written in modern Fortran. We describe the benefits and compromises associated with choosing Fortran as the implementation language, and we propose ways in which future Fortran standards can best support the use case in this paper.

Modern Fortran↗
NASA NTRSDate not supplied

Certification Concepts for AI/ML Systems

This presentation goes over some of the tools developed at NASA Ames in the Robust Software Engineering group for the assurance and certification of autonomous systems. The research themes presented include improving safety and risk assessment as early as possible in the lifecycle, elicitation and formalization of requirements to facilitate traceability throughout the lifecycle, especially when formal methods are used, algorithms, tools and techniques for the V&V of ML-enabled systems, advanced testing, use of runtime monitoring to ease use of untrusted components, and contribution to draft regulatory standards and assistance in producing and presenting certification evidences.

Autonomy↗
NASA NTRSDate not supplied

Cloud Computing Option for Modeling the Debris Environment

NASA’s Digital Transformation Initiative aims to promote the agency’s adoption of current and evolving digital technologies. Through agency-wide collaboration with other NASA teams, the Office of Safety and Mission Assurance (OSMA) has directed the Orbital Debris Program Office and the Meteoroid Environment Office to integrate cloud computing technologies in their publicly released software models: the Orbital Debris Engineering Model (ORDEM) and the Meteoroid Engineering Model (MEM). Decoupling the user interface from the backend processor was key for the software packages to run on a cloud computing framework. Benefits to this design include horizontal scaling of computing resources, user authentication and authorization, and automated deployment. Both models are hosted on a cloud computing platform supported by the NASA authorized IT security and compliance framework. This paper focuses on the new ORDEM web application, which includes the current features of the publicly released ORDEM software with an upgraded frontend design. The underlying ORDEM processor is run on a cloud container, allowing the user to run multiple spacecraft and telescope/radar mode simulations. Featuresexclusive to the ORDEM web application, such as importing multiple TLEs, auto-generated plotting, and the ability to check runtime progress are discussed. Comparisons between the current ORDEM software and the web application are summarized.

Andrew Vavrin↗
NASA NTRSDate not supplied

Trustworthy Autonomy for Gateway Vehicle System Manager

This webinar will present techniques for achieving trusted autonomous operations that are being pioneered on the NASA Lunar Gateway Vehicle System Manager (VSM). The challenges of achieving trusted autonomy faced by the VSM project are similar to challenges in underwater autonomous systems. The webinar will describe the overall approach to verification and present in detail the use of design-time (development) assume-guarantee contracts using model checking and runtime (operational) assume-guarantee contracts. The webinar will conclude with a summary of lessons learned to date and future challenges.

Assume-guarantee contracts↗
NASA NTRSDate not supplied

APRES Prototype Mission Planner System Demonstration

Activity Planning with Resources for the Exploration of Space (APRES) is a mixed-initiative mission planning system for ground operations. APRES has been designed to support multi-spacecraft missions. The APRES Interface is browser-based and includes a plan editor, a timeline plan display, a temporal constraint editor, display of the state and numeric chronicles, and a violation resolution manager. Automation support is supplied by the APRES Service, which includes components that provide the following capabilities:(1) plan simulation, which determines the state and numeric chronicles (values of the model variables over time) and determines when "processes" are triggered and terminated based on world states in the execution trace, (2) violation detection of constraints and flight rules encoded in the domain model, and of the temporal constraints created by the user, (3) violation resolution suggestions as to how to fix the plan's violations via rescheduling. The user controls when and how to utilize the automation support. Demo video included with paper, runtime 8:54 in color with sound.

John L. Bresina↗