Search NASA⌕ Search

SEARCH · Search NASA

Results for “contingency software”

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 91 records · Page 5

NASA's UAS Integration into the NAS: A Report on the Human Systems Integration Phase 1 Simulation Activities

In 2011 the National Aeronautics and Space Administration (NASA) began a five-year Project to address the technical barriers related to routine access of Unmanned Aerial Systems (UAS) in the National Airspace System (NAS). Planned in two phases, the goal of the first phase was to lay the foundations for the Project by identifying those barriers and key issues to be addressed to achieve integration. Phase 1 activities were completed two years into the five-year Project. The purpose of this paper is to review activities within the Human Systems Integration (HSI) subproject in Phase 1 toward its two objectives: 1) develop GCS guidelines for routine UAS access to the NAS, and 2) develop a prototype display suite within an existing Ground Control Station (GCS). The first objective directly addresses a critical barrier for UAS integration into the NAS - a lack of GCS design standards or requirements. First, the paper describes the initial development of a prototype GCS display suite and supporting simulation software capabilities. Then, three simulation experiments utilizing this simulation architecture are summarized. The first experiment sought to determine a baseline performance of UAS pilots operating in civil airspace under current instrument flight rules for manned aircraft. The second experiment examined the effect of currently employed UAS contingency procedures on Air Traffic Control (ATC) participants. The third experiment compared three GCS command and control interfaces on UAS pilot response times in compliance with ATC clearances. The authors discuss how the results of these and future simulation and flight-testing activities contribute to the development of GCS guidelines to support the safe integration of UAS into the NAS. Finally, the planned activities for Phase 2, including an integrated human-in-the-loop simulation and two flight tests are briefly described.

National Airspace System↗

ExaSGD: 2022 Kernel Thrust Activities

The Kernel Thrust milestone ADSE22-407 covers the development of device-capable optimization algorithms and solvers technologies required by the ExaSGD project’s software stack in order to solve security-constrained alternating current optimal power flow (SC-ACOPF) problems on emerging exascale architectures. To this extent, in FY22 the main objective of the Kernel Thrust was (i) provide sparse optimization solver that runs efficiently on hardware accelerator devices (i.e., NVIDIA and AMD GPUs) to perform intra-node computations, (ii) strengthen the reliability and increase the performance of the mixed-dense sparse (MDS) solver of HiOp for deployment on the FY22 target architectures, Summit and Crusher, and (iii) increase performance by improving the mathematical algorithm and refining the parallel MPI-based implementation of the coarse-grain parallel solver HiOp-PriDec for capabilities deployment on the FY22 target architectures, Summit and Crusher. This document presents the developments and contributions done by the Kernels Thrust Team in FY22 toward completion of the above-mentioned objectives. These contributions progressed along four main development (sub)thrusts: (1) Design and implementation of a sparse optimization solver for use on hardware accelerators; (2) Improvement of the mathematical algorithm and of the parallel implementation of HiOp-PriDec to ensure readiness and efficient coarse-grain parallelism for FY23 target exascale machine; and (3) Support Software and Application Development Thrusts of the exaSGD project in their deployment of the project’s software stack on AMD- and NVIDIA-based architectures. The development of the sparse optimization solver (thrust 1 above) was new in FY22 and resulted in a new sparse solver in HiOp (available as of version 0.6). The second development thrust was a continuation of the efforts from FY21 and improved the mathematical algorithm and the communication strategy of the HiOp-PriDec solver. The last developement thrust is a large collaborative effort. Namely, the project’s teams from multiple labs (LLNL, PNNL, ORNL, and NREL) performed large-scale demonstration of the ExaSGD software stack, namely the optimization solvers of HiOp interfaced with the modeling front-end ExaGO and the stochastic sampler PowerScenarios. These demonstration efforts solved large-scale instances of the SC-ACOPF challenge problem of medium network sizes (10, 000-bus system) and large number of contingencies on Summit (NVIDIA accelerators) and Crusher (AMD accelerators) systems at ORNL.

97 MATHEMATICS AND COMPUTING↗

Optimal Propellant Maneuver Flight Demonstrations on ISS

In this paper, first ever flight demonstrations of Optimal Propellant Maneuver (OPM), a method of propulsive rotational state transition for spacecraft controlled using thrusters, is presented for the International Space Station (ISS). On August 1, 2012, two ISS reorientations of about 180deg each were performed using OPMs. These maneuvers were in preparation for the same-day launch and rendezvous of a Progress vehicle, also a first for ISS visiting vehicles. The first maneuver used 9.7 kg of propellant, whereas the second used 10.2 kg. Identical maneuvers performed without using OPMs would have used approximately 151.1kg and 150.9kg respectively. The OPM method is to use a pre-planned attitude command trajectory to accomplish a rotational state transition. The trajectory is designed to take advantage of the complete nonlinear system dynamics. The trajectory choice directly influences the cost of the maneuver, in this case, propellant. For example, while an eigenaxis maneuver is kinematically the shortest path between two orientations, following that path requires overcoming the nonlinear system dynamics, thereby increasing the cost of the maneuver. The eigenaxis path is used for ISS maneuvers using thrusters. By considering a longer angular path, the path dependence of the system dynamics can be exploited to reduce the cost. The benefits of OPM for the ISS include not only reduced lifetime propellant use, but also reduced loads, erosion, and contamination from thrusters due to fewer firings. Another advantage of the OPM is that it does not require ISS flight software modifications since it is a set of commands tailored to the specific attitude control architecture. The OPM takes advantage of the existing ISS control system architecture for propulsive rotation called USTO control mode1. USTO was originally developed to provide ISS Orbiter stack attitude control capability for a contingency tile-repair scenario, where the Orbiter is maneuvered using its robotic manipulator relative to the ISS. Since 2005 USTO has been used for nominal ISS operations.

Bhatt, Sagar↗

A functional description of the Buffered Telemetry Demodulator (BTD)

This article gives a functional description of the buffered telemetry demodulator (BTD), which operates on recorded digital samples to extract the symbols from the received signal. The key advantages of the BTD are as follows: (1) its ability to reprocess the signal to reduce acquisition time; (2) its ability to use future information about the signal and to perform smoothing on past samples; and (3) its minimum transmission bandwidth requirement as each sub carrier harmonic is processed individually. The first application of the BTD would be the Galileo S-band contingency mission, where the signal is so weak that reprocessing to reduce the acquisition time is crucial. Moreover, in the event of employing antenna arraying with full spectrum combining, only the sub carrier harmonics need to be transmitted between sites, resulting in significant reduction in data rate transmission requirements. Software implementation of the BTD is described for various general-purpose computers.

Tsou, H.↗

Orion Exploration Flight Test-1 Contingency Drogue Deploy Velocity Trigger

As a backup to the GPS-aided Kalman filter and the Barometric altimeter, an "adjusted" velocity trigger is used during entry to trigger the chain of events that leads to drogue chute deploy for the Orion Multi-Purpose Crew Vehicle (MPCV) Exploration Flight Test-1 (EFT-1). Even though this scenario is multiple failures deep, the Orion Guidance, Navigation, and Control (GN&C) software makes use of a clever technique that was taken from the Mars Science Laboratory (MSL) program, which recently successfully landing the Curiosity rover on Mars. MSL used this technique to jettison the heat shield at the proper time during descent. Originally, Orion use the un-adjusted navigated velocity, but the removal of the Star Tracker to save costs for EFT-1, increased attitude errors which increased inertial propagation errors to the point where the un-adjusted velocity caused altitude dispersions at drogue deploy to be too large. Thus, to reduce dispersions, the velocity vector is projected onto a "reference" vector that represents the nominal "truth" vector at the desired point in the trajectory. Because the navigation errors are largely perpendicular to the truth vector, this projection significantly reduces dispersions in the velocity magnitude. This paper will detail the evolution of this trigger method for the Orion project and cover the various methods tested to determine the reference "truth" vector; and at what point in the trajectory it should be computed.

Gay, Robert S.↗

Testing of Advanced Capabilities to Enable In-time Safety Management and Assurance for Future Flight Operations

In order to refine an initial Concept of Operations, explore Concepts of Use, and expose/validate requirements for future In-Time Aviation Safety Management Systems (IASMS), testing architectures were created, along with a set of capabilities and underlying information exchange protocols. These systems were conceived and developed based on hazards associated with two envisioned urban area flight domains: (1) highly autonomous small uncrewed aerial systems (sUAS) operating at low altitudes, and (2) highly autonomous air taxis. The initial scope of this development is described in [1]; this report provides an update, focusing on the subsequent developments and test activities. As stated in [1], it is important to note that there are many capabilities already in use by the industry (or soon to be in use) that will play critical roles in future IASMS designs. Those reported here were developed to address a gap in the current state-of-the-art regarding specific hazards/risks, and/or to allow for investigation of the interplay between and across hazard types — particularly regarding how overall safety risk can be reduced or managed effectively. Results of testing and development activities are organized by the operational phase wherein a particular capability would be employed (i.e., preflight, in-flight, and post-flight/off-line). Pre-flight: A set of capabilities were developed to help mitigate safety risk prior to flight (e.g., during flight and mission planning). Results of testing summarize (1) validation activities to raise the Technology Readiness Level (TRL) and (2) evaluation activities where the capabilities were applied to flight/mission planning procedures and used by operators/pilots. For the latter, flight plans were automatically assessed, and operators/pilots were notified of hazardous flight segments so as to enable adjustment of the flight plan and re-evaluation, and/or to better inform go/no-go decisions. Capabilities addressed hazards associated with power consumption, third-party risk, wind, navigation system performance, radiofrequency interference, and proximity to geo-spatial threats (e.g., buildings, trees, and no-fly zones). In-flight: Flight experiments tested capabilities that detect and respond to hazards encountered during flight. In the first series, safety hazards were monitored and assessed onboard, and system-generated mitigation maneuvers were recorded (but not acted upon by the vehicle). In the second series, mitigation maneuver commands directed the aircraft in response to safety hazards (i.e., auto-mitigation). The sUAS used for testing is described in full, as is the test architecture, which included commercial avionics, research avionics, and onboard software designed to detect, assess, and respond to hazards. The onboard system was designed as a run-time assurance framework, consistent with [2] and supportive of both supervisory and automated modes. The primary functions included: real-time risk assessment (RTRA), auto-pilot monitoring, constraint monitoring, and contingency select/triggering. RTRA performs integrated risk assessment considering data from several hazard-related monitors (e.g., battery, motors, navigation, communications, population density, and loss-of-control). Post-flight/off-line: Data monitored and recorded during flights can enable IASMS capabilities that execute after flights have completed (or “off-line”). These include: (1) the ability to identify anomalies and trends that may only be observable when comparing data spanning a number of similar flights; (2) the ability to update and validate pre-flight and in-flight capabilities and any underlying models to improve their performance; (3) the ability to report anomalies/off-nominals that may indicate design changes or maintenance actions are needed; and (4) the ability for humans involved in operations to report safety-relevant observations to help in understanding the flight data and/or the operational context of a flight. Progress on three such capabilities is summarized; the first investigates anomaly detection given a limited set of flight logs and applies an approach previously used for space operations. The second explores what could be identified using a larger set of flight logs, including from web-based forums where flight logs are posted by sUAS autopilot users. The third creates a new means of collecting information on UAS incidents and accidents via the Aviation Safety Reporting System (ASRS).

sUAS↗

Autonomous Operating System (AOS)

The Autonomy Operating System (AOS) is a software system that enables core capabilities for the autonomous operations for an unmanned aircraft. It is based on the NASA cFS system and provides a higher-level layer of infrastructure and applications for the execution of flight plans, natural-language communication with Air Traffic Control, Diagnostics, Prognostics, and contingency planning.

Lowry, Michael R.↗

Work Experience Report

The NASA Platform for Autonomous Systems (NPAS) toolkit is currently being used at the NASA John C. Stennis Space Center (SSC) to develop the INSIGHT program, which will autonomously monitor and control the Nitrogen System of the High Pressure Gas Facility (HPGF) on site. The INSIGHT program is in need of generic timing capabilities in order to perform timing based actions such as pump usage timing and sequence step timing. The purpose of this project was to develop a timing module that could fulfill these requirements and be adaptable for expanded use in the future. The code was written in Gensym G2 software platform, the same as INSIGHT, and was written generically to ensure compatibility with any G2 program. Currently, the module has two timing capabilities, a stopwatch function and a countdown function. Although the module has gone through some functionality testing, actual integration of the module into NPAS and the INSIGHT program is contingent on the module passing later checks.

Guo, Daniel↗

Proximity operations considerations affecting spacecraft design

Proximity operations can be defined as the maneuvering of two or more spacecraft within 1 nautical mile range, with relative velocity less than 10 feet per second. The passive vehicle is nontranslating and should provide for maintenance of the desired approach attitude. It must accommodate the active (translating) vehicle induced structural loads and performance characteristics (mating hardware tolerances), and support sensor compatibility (transponder, visual targets, etc.). The active vehicle must provide adequate sensor systems (relative state information, field-of-view, redundancy), flight control hardware (thruster sizing, minimal cross-coupling, performance margins, redundancy) and software (reconfigurable, attitude/rate modes, translation and rotation fine control authority) characteristic, and adequate non-propulsive consumables such as power. Operational concerns must be considered. These include the following: (1) the desired approach trajectory and relative orientation; (2) the active vehicle thruster plume effects (forces, torques, contamination) on the passive vehicle; and (3) procedures for contingencies such as loss of communications, sensor or propulsion failures, and target vehicle loss of control.

Staas, Steven K.↗

AERCam Autonomy: Intelligent Software Architecture for Robotic Free Flying Nanosatellite Inspection Vehicles

The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.

Fredrickson, Steven E.↗

Computerized atmospheric trace contaminant control simulation for manned spacecraft

Buildup of atmospheric trace contaminants in enclosed volumes such as a spacecraft may lead to potentially serious health problems for the crew members. For this reason, active control methods must be implemented to minimize the concentration of atmospheric contaminants to levels that are considered safe for prolonged, continuous exposure. Designing hardware to accomplish this has traditionally required extensive testing to characterize and select appropriate control technologies. Data collected since the Apollo project can now be used in a computerized performance simulation to predict the performance and life of contamination control hardware to allow for initial technology screening, performance prediction, and operations and contingency studies to determine the most suitable hardware approach before specific design and testing activities begin. The program, written in FORTRAN 77, provides contaminant removal rate, total mass removed, and per pass efficiency for each control device for discrete time intervals. In addition, projected cabin concentration is provided. Input and output data are manipulated using commercial spreadsheet and data graphing software. These results can then be used in analyzing hardware design parameters such as sizing and flow rate, overall process performance and program economics. Test performance may also be predicted to aid test design.

Perry, J. L.↗

A launch window study for GEOTAIL's double lunar swingby trajectory

The GEOTAIL spacecraft of the International Solar-Terrestrial Physics Program will use a series of paired lunar swingbys to explore distant parts of the earth's magnetic tail. A 21-day launch window has been calculated for GEOTAIL, in July and August 1992, to start its distant-tail phase with a first lunar swingby (S1) on September 8, 1992. The main launch window in July utilizes 4.5 revolutions in a transfer orbit to S1, with a mid-August contingency window that uses 2.5 transfer-orbit revolutions before S1. Designing a good distant-tail trajectory, and then accurately matching it at S1 for every day in the launch window, seems to be the easiest and most reliable strategy. However, the total delta-V costs of the current designs can probably be reduced, possibly with the help of new interactive software that can be run on personal computers.

Dunham, David W.↗

Control of Technology Transfer at JPL

Controlled Technology: 1) Design: preliminary or critical design data, schematics, technical flow charts, SNV code/diagnostics, logic flow diagrams, wirelist, ICDs, detailed specifications or requirements. 2) Development: constraints, computations, configurations, technical analyses, acceptance criteria, anomaly resolution, detailed test plans, detailed technical proposals. 3) Production: process or how-to: assemble, operated, repair, maintain, modify. 4) Manufacturing: technical instructions, specific parts, specific materials, specific qualities, specific processes, specific flow. 5) Operations: how-to operate, contingency or standard operating plans, Ops handbooks. 6) Repair: repair instructions, troubleshooting schemes, detailed schematics. 7) Test: specific procedures, data, analysis, detailed test plan and retest plans, detailed anomaly resolutions, detailed failure causes and corrective actions, troubleshooting, trended test data, flight readiness data. 8) Maintenance: maintenance schedules and plans, methods for regular upkeep, overhaul instructions. 9) Modification: modification instructions, upgrades kit parts, including software

Jet Propulsion Laboratory (JPL)↗

ROAM: A Remotely Operated Accelerator Monitor

Monitoring accelerators in operation is a well known challenge due to the radiation environment. However, there are significant benefits in being able to deploy particular sensors in specific locations of accelerator enclosures for monitoring or troubleshooting purposes. Learning from experience at other labs, we used Commercial Off The Shelf (COTS) components and an open source robot control software framework (ROS) to build a remotely controlled robot platform including a standard suite of instruments such as cameras, LIDAR, and ultrasound, with the ability to incorporate other ad-hoc sensors for specific measurements, such as a Gamma radiation monitor. Special attention was given to the robot's ability to maintain safety in the high risk environment of an accelerator, with multiple failure contingencies in place to ensure collision free operation. Testing was performed to prove the platform's viability and showcase its capability for accelerator monitoring.

Thayer, Thomas C.↗

m:N ConOps/R&R Remote Simulation

This presentation details the experimental design of an investigation of small unmanned aircraft system (sUAS) operations involving multiple vehicle management by a remote operator. The study is part of an ongoing effort to explore multiple vehicle control by multiple operators, i.e., the control of N vehicles by m operators (m:N operations). For this effort, NASA and collaborators have developed prototypes of a concept of operations (ConOps), roles and responsibilities (R&R) for operators and supervisors, and a ground control station (GCS), including software displays and interfaces. Participants in this study acted as the pilot-in-command of twelve aircraft flying pre-approved routes in a simulation of a food delivery operation utilizing sUAS in the San Diego, CA area. Each participant experienced four experimental trials. Twice within the course of each trial, participants were responsible for responding to a sudden, unanticipated, and high-priority contingency: an airspace restriction for sUAS operations known as a UAS Volume Reservation (UVR). Upon issuance of a UVR, pilots were expected to reroute affected vehicles around the airspace. The level of automation (LoA) and workload of the flight rerouting task were varied. The LoA was manipulated by providing reroute suggestions ("auto" condition) for aircraft or by requiring pilots to manually reroute ("manual" condition) affected vehicles. Workload was varied as a function of the number of vehicles affected by the UVR contingencies: 2 vehicles ("low workload" condition) versus 4 vehicles ("high workload" condition). Additionally, some vehicles required pilots to adjust for terrain conflicts while avoiding the UVR region. Due to the COVID-19 pandemic, in-person data collection for this study was not possible. Researchers adapted to this circumstance through the development of remote data collection protocol. Participants were able to view adapted GCS displays using the Microsoft Teams teleconferencing platform and responded to events by using a verbal protocol developed for the experiment. Using this protocol, participants provided instructions for actions to a researcher, referred to as the surrogate, to carry out on their behalf. This presentation describes the experiment design, including special details for remote data collection via a subject-surrogate configuration, and concludes with planned data analysis and results to be presented at a later date.

multi-UAS↗

Statistical and Probabilistic Extensions to Ground Operations' Discrete Event Simulation Modeling

NASA's human exploration initiatives will invest in technologies, public/private partnerships, and infrastructure, paving the way for the expansion of human civilization into the solar system and beyond. As it is has been for the past half century, the Kennedy Space Center will be the embarkation point for humankind's journey into the cosmos. Functioning as a next generation space launch complex, Kennedy's launch pads, integration facilities, processing areas, launch and recovery ranges will bustle with the activities of the world's space transportation providers. In developing this complex, KSC teams work through the potential operational scenarios: conducting trade studies, planning and budgeting for expensive and limited resources, and simulating alternative operational schemes. Numerous tools, among them discrete event simulation (DES), were matured during the Constellation Program to conduct such analyses with the purpose of optimizing the launch complex for maximum efficiency, safety, and flexibility while minimizing life cycle costs. Discrete event simulation is a computer-based modeling technique for complex and dynamic systems where the state of the system changes at discrete points in time and whose inputs may include random variables. DES is used to assess timelines and throughput, and to support operability studies and contingency analyses. It is applicable to any space launch campaign and informs decision-makers of the effects of varying numbers of expensive resources and the impact of off nominal scenarios on measures of performance. In order to develop representative DES models, methods were adopted, exploited, or created to extend traditional uses of DES. The Delphi method was adopted and utilized for task duration estimation. DES software was exploited for probabilistic event variation. A roll-up process was used, which was developed to reuse models and model elements in other less - detailed models. The DES team continues to innovate and expand DES capabilities to address KSC's planning needs.

Trocine, Linda↗

Development of a Smart Release Algorithm for Mid-Air Separation of Parachute Test Articles

The Crew Exploration Vehicle Parachute Assembly System (CPAS) project is currently developing an autonomous method to separate a capsule-shaped parachute test vehicle from an air-drop platform for use in the test program to develop and validate the parachute system for the Orion spacecraft. The CPAS project seeks to perform air-drop tests of an Orion-like boilerplate capsule. Delivery of the boilerplate capsule to the test condition has proven to be a critical and complicated task. In the current concept, the boilerplate vehicle is extracted from an aircraft on top of a Type V pallet and then separated from the pallet in mid-air. The attitude of the vehicles at separation is critical to avoiding re-contact and successfully deploying the boilerplate into a heatshield-down orientation. Neither the pallet nor the boilerplate has an active control system. However, the attitude of the mated vehicle as a function of time is somewhat predictable. CPAS engineers have designed an avionics system to monitor the attitude of the mated vehicle as it is extracted from the aircraft and command a release when the desired conditions are met. The algorithm includes contingency capabilities designed to release the test vehicle before undesirable orientations occur. The algorithm was verified with simulation and ground testing. The pre-flight development and testing is discussed and limitations of ground testing are noted. The CPAS project performed a series of three drop tests as a proof-of-concept of the release technique. These tests helped to refine the attitude instrumentation and software algorithm to be used on future tests. The drop tests are described in detail and the evolution of the release system with each test is described.

Moore, James W.↗

The Essence of Cryptol: A Denotational Cryptol Interpreter in Coq for Foundational Assurances for Quantum Resistant Cryptosystems

Systems of the utmost consequence need a means to establish authenticity of software and data. Cryptosystems implement authentication, but can be vulnerable to cryptographic and implementation attacks. With the threat of quantum cryptographic attacks, “post-quantum” cryptosystems (PQCs) must be henceforth used in these systems. However, the new cryptography needs new ways to, rigorously and machine-checkably, prove systems free of vulnerabilities. We propose a retargetable capability to rapidly instantiate proven correct postquantum cryptosystems through novel proof-carrying synthesis and proof-automation technique, extending those proven successful on existing systems. This capability is crucial to meeting the cryptographic requirements for future high-consequence systems. Since specifications for high consequence cryptography are presently captured in a domain specific language known as Cryptol. While this can enable convenient fully automated reasoning about Cryptol specificaitons and implementations via the Software Analysis Workbench (SAW), Cryptol has expressivity gaps, so that cryptosystems with probabilistic programming features like Falcon cannot be fully expressed in the language. Moreover, SAW’s automation fails for programs and specificaitons with inductive and recursive structure, as in the Sphincs+ PQC. Finally, Cryptol and SAW together represent some 200,000 lines of unverified Haskell, so that the any guarantees about high consequence cryptography are presently contingent on a large, unverified, yet trusted computing base. The first step of the larger project of agile, assured crpytography is therefore to provide a formal, mechanized semantics for Cryptol, so that the specifications expressed by cryptographers in Cryptol can be reasoned about and compiled into performant implementations with a foundational, machine checkable certificate of correctness. This report describes our work on this first step, culminating in the design of a certified denotational interpreter, in Coq, for core Cryptol.

97 MATHEMATICS AND COMPUTING↗