Search NASA⌕ Search

SEARCH · Search NASA

Results for “protocol processing hardware”

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 73 records · Page 4

High Energy/LET Radiation EEE Parts Certification Handbook

Certifying electronic components is a very involved process. It includes pre-coordination with the radiation test facility for time, schedule and cost, as well as intimate work with designers to develop test procedures and hardware. It also involves work with radiation engineers to understand the effects of the radiation field on the test article/setup as well as the analysis and production of a test report. The technical content of traditional ionizing radiation testing protocol is in wide use and generally follows established standards (ref. Appendix C). This document is not intended to cover all these areas but to cover the methodology of using Variable Depth Bragg Peak (VDBP) to accomplish the goal of characterizing an electronic component. The Variable Depth Bragg Peak (VDBP) test method is primarily used for deep space applications of electronics. However, it can be used on any part for any radiation environment, especially those parts where the sensitive volume cannot be reached by the radiation beam. An example of this problem would be issues that arise in de-lidding of parts or in parts with flip-chip designs, etc. The VDBP method is ideally suited to test modern avionics designs which increasingly incorporate commercial off-the-shelf (COTS) parts and units. Johnson Space Center (JSC) developed software provides assistance to users in developing the radiation characterization data from the raw test data.

Reddell, Brandon↗

Flight Avionics Hardware Roadmap

The Avionics Technology Roadmap takes an 80% approach to technology investment in spacecraft avionics. It delineates a suite of technologies covering foundational, component, and subsystem-levels, which directly support 80% of future NASA space mission needs. The roadmap eschews high cost, limited utility technologies in favor of lower cost, and broadly applicable technologies with high return on investment. The roadmap is also phased to support future NASA mission needs and desires, with a view towards creating an optimized investment portfolio that matures specific, high impact technologies on a schedule that matches optimum insertion points of these technologies into NASA missions. The roadmap looks out over 15+ years and covers some 114 technologies, 58 of which are targeted for TRL6 within 5 years, with 23 additional technologies to be at TRL6 by 2020. Of that number, only a few are recommended for near term investment: 1. Rad Hard High Performance Computing 2. Extreme temperature capable electronics and packaging 3. RFID/SAW-based spacecraft sensors and instruments 4. Lightweight, low power 2D displays suitable for crewed missions 5. Radiation tolerant Graphics Processing Unit to drive crew displays 6. Distributed/reconfigurable, extreme temperature and radiation tolerant, spacecraft sensor controller and sensor modules 7. Spacecraft to spacecraft, long link data communication protocols 8. High performance and extreme temperature capable C&DH subsystem In addition, the roadmap team recommends several other activities that it believes are necessary to advance avionics technology across NASA: center dot Engage the OCT roadmap teams to coordinate avionics technology advances and infusion into these roadmaps and their mission set center dot Charter a team to develop a set of use cases for future avionics capabilities in order to decouple this roadmap from specific missions center dot Partner with the Software Steering Committee to coordinate computing hardware and software technology roadmaps and investment recommendations center dot Continue monitoring foundational technologies upon which future avionics technologies will be dependent, e.g., RHBD and COTS semiconductor technologies

Some, Raphael↗

Packet communications in satellites with multiple-beam antennas and signal processing

A communication satellite with a multiple-beam antenna and onboard signal processing is considered for use in a 'message-switched' data relay system. The signal processor may incorporate demodulation, routing, storage, and remodulation of the data. A system user model is established and key functional elements for the signal processing are identified. With the throughput and delay requirements as the controlled variables, the hardware complexity, operational discipline, occupied bandwidth, and overall user end-to-end cost are estimated for (1) random-access packet switching; and (2) reservation-access packet switching. Other aspects of this network (eg, the adaptability to channel switched traffic requirements) are examined. For the given requirements and constraints, the reservation system appears to be the most attractive protocol.

Davies, R.↗

International Space Station environmental control and life support system. Phase 3: Water Recovery Test Stage 9

A test has been completed at NASA's Marshall Space Flight Center (MSFC) to evaluate the latest water recovery system design for the United States On-Orbit Segment (USOS) of the International Space Station (ISS) with higher fidelity hardware and integration than has been achieved in previous Water Recovery Test (WRT) Stages. This test is referred to as WRT Stage 9. Potable and urine processing assemblies were integrated with end-use equipment and operated for 116 days. The overall integrated configuration of the test system included a single water recovery loop that was automated and controlled from a central computer. This report summarizes the test objectives, system design, test activities and protocols, significant results, anomalies and lessons learned throughout the WRT Stage 9.

D L Carter↗

Tests characterizing bioprocessor hardware for analytical modeling

The tests outlined in this paper were used to characterize the hardware components of the Salad Machine, a small NASA-developed bioprocessor. The data from these tests are presented, and the methods by which this data can be integrated into system mathematical models are briefly discussed. The subsystems and physical processes discussed include the lighting system, the air loop (condensing heat exchanger and the blower), heat transfer to the surroundings, and leakage. Through this effort it was learned that in the development of a test protocol, care should be taken to order the tests such that environmental parameters, particularly humidity, require as few large adjustments as possible. Sensor calibration and installation take a substantial amount of time, which should be built into the test schedule. Two properties were particularly hard to quantify: the air flow rate and the energy from the lighting system entering into the growth volume. Flow rate can be measured using the appropriate device for the system configuration and airflow. Lighting system radiation level was measured using three methods. The results of these methods varied substantially, putting off conclusive quantification of this value.

Gustavino, S.↗

Reusable Rack Interface Controller Common Software for Various Science Research Racks on the International Space Station

The purpose of the EXPRESS (Expedite the PRocessing of Experiments to Space Station) rack project is to provide a set of predefined interfaces for scientific payloads which allow rapid integration into a payload rack on International Space Station (ISS). VxWorks' was selected as the operating system for the rack and payload resource controller, primarily based on the proliferation of VME (Versa Module Eurocard) products. These products provide needed flexibility for future hardware upgrades to meet everchanging science research rack configuration requirements. On the International Space Station, there are multiple science research rack configurations, including: 1) Human Research Facility (HRF); 2) EXPRESS ARIS (Active Rack Isolation System); 3) WORF (Window Observational Research Facility); and 4) HHR (Habitat Holding Rack). The RIC (Rack Interface Controller) connects payloads to the ISS bus architecture for data transfer between the payload and ground control. The RIC is a general purpose embedded computer which supports multiple communication protocols, including fiber optic communication buses, Ethernet buses, EIA-422, Mil-Std-1553 buses, SMPTE (Society Motion Picture Television Engineers)-170M video, and audio interfaces to payloads and the ISS. As a cost saving and software reliability strategy, the Boeing Payload Software Organization developed reusable common software where appropriate. These reusable modules included a set of low-level driver software interfaces to 1553B. RS232, RS422, Ethernet buses, HRDL (High Rate Data Link), video switch functionality, telemetry processing, and executive software hosted on the FUC computer. These drivers formed the basis for software development of the HRF, EXPRESS, EXPRESS ARIS, WORF, and HHR RIC executable modules. The reusable RIC common software has provided extensive benefits, including: 1) Significant reduction in development flow time; 2) Minimal rework and maintenance; 3) Improved reliability; and 4) Overall reduction in software life cycle cost. Due to the limited number of crew hours available on ISS for science research, operational efficiency is a critical customer concern. The current method of upgrading RIC software is a time consuming process; thus, an improved methodology for uploading RIC software is currently under evaluation.

Lu, George C.↗

Replication of Space-Shuttle Computers in FPGAs and ASICs

A document discusses the replication of the functionality of the onboard space-shuttle general-purpose computers (GPCs) in field-programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs). The purpose of the replication effort is to enable utilization of proven space-shuttle flight software and software-development facilities to the extent possible during development of software for flight computers for a new generation of launch vehicles derived from the space shuttles. The replication involves specifying the instruction set of the central processing unit and the input/output processor (IOP) of the space-shuttle GPC in a hardware description language (HDL). The HDL is synthesized to form a "core" processor in an FPGA or, less preferably, in an ASIC. The core processor can be used to create a flight-control card to be inserted into a new avionics computer. The IOP of the GPC as implemented in the core processor could be designed to support data-bus protocols other than that of a multiplexer interface adapter (MIA) used in the space shuttle. Hence, a computer containing the core processor could be tailored to communicate via the space-shuttle GPC bus and/or one or more other buses.

Ferguson, Roscoe C.↗

Digital Multicasting of Multiple Audio Streams

The Mission Control Center Voice Over Internet Protocol (MCC VOIP) system (see figure) comprises hardware and software that effect simultaneous, nearly real-time transmission of as many as 14 different audio streams to authorized listeners via the MCC intranet and/or the Internet. The original version of the MCC VOIP system was conceived to enable flight-support personnel located in offices outside a spacecraft mission control center to monitor audio loops within the mission control center. Different versions of the MCC VOIP system could be used for a variety of public and commercial purposes - for example, to enable members of the general public to monitor one or more NASA audio streams through their home computers, to enable air-traffic supervisors to monitor communication between airline pilots and air-traffic controllers in training, and to monitor conferences among brokers in a stock exchange. At the transmitting end, the audio-distribution process begins with feeding the audio signals to analog-to-digital converters. The resulting digital streams are sent through the MCC intranet, using a user datagram protocol (UDP), to a server that converts them to encrypted data packets. The encrypted data packets are then routed to the personal computers of authorized users by use of multicasting techniques. The total data-processing load on the portion of the system upstream of and including the encryption server is the total load imposed by all of the audio streams being encoded, regardless of the number of the listeners or the number of streams being monitored concurrently by the listeners. The personal computer of a user authorized to listen is equipped with special- purpose MCC audio-player software. When the user launches the program, the user is prompted to provide identification and a password. In one of two access- control provisions, the program is hard-coded to validate the user s identity and password against a list maintained on a domain-controller computer at the MCC. In the other access-control provision, the program verifies that the user is authorized to have access to the audio streams. Once both access-control checks are completed, the audio software presents a graphical display that includes audiostream-selection buttons and volume-control sliders. The user can select all or any subset of the available audio streams and can adjust the volume of each stream independently of that of the other streams. The audio-player program spawns a "read" process for the selected stream(s). The spawned process sends, to the router(s), a "multicast-join" request for the selected streams. The router(s) responds to the request by sending the encrypted multicast packets to the spawned process. The spawned process receives the encrypted multicast packets and sends a decryption packet to audio-driver software. As the volume or muting features are changed by the user, interrupts are sent to the spawned process to change the corresponding attributes sent to the audio-driver software. The total latency of this system - that is, the total time from the origination of the audio signals to generation of sound at a listener s computer - lies between four and six seconds.

Macha, Mitchell↗

Some issues related to simulation of the tracking and communications computer network

The Communications Performance and Integration branch of the Tracking and Communications Division has an ongoing involvement in the simulation of its flight hardware for Space Station Freedom. Specifically, the communication process between central processor(s) and orbital replaceable units (ORU's) is simulated with varying degrees of fidelity. The results of investigations into three aspects of this simulation effort are given. The most general area involves the use of computer assisted software engineering (CASE) tools for this particular simulation. The second area of interest is simulation methods for systems of mixed hardware and software. The final area investigated is the application of simulation methods to one of the proposed computer network protocols for space station, specifically IEEE 802.4.

Lacovara, Robert C.↗

IONAC-Lite

The Interplanetary Overlay Net - working Protocol Accelerator (IONAC) described previously in The Inter - planetary Overlay Networking Protocol Accelerator (NPO-45584), NASA Tech Briefs, Vol. 32, No. 10, (October 2008) p. 106 (http://www.techbriefs.com/component/ content/article/3317) provides functions that implement the Delay Tolerant Networking (DTN) bundle protocol. New missions that require high-speed downlink-only use of DTN can now be accommodated by the unidirectional IONAC-Lite to support high data rate downlink mission applications. Due to constrained energy resources, a conventional software implementation of the DTN protocol can provide only limited throughput for any given reasonable energy consumption rate. The IONAC-Lite DTN Protocol Accelerator is able to reduce this energy consumption by an order of magnitude and increase the throughput capability by two orders of magnitude. In addition, a conventional DTN implementation requires a bundle database with a considerable storage requirement. In very high downlink datarate missions such as near-Earth radar science missions, the storage space utilization needs to be maximized for science data and minimized for communications protocol-related storage needs. The IONAC-Lite DTN Protocol Accelerator is implemented in a reconfigurable hardware device to accomplish exactly what s needed for high-throughput DTN downlink-only scenarios. The following are salient features of the IONAC-Lite implementation: An implementation of the Bundle Protocol for an environment that requires a very high rate bundle egress data rate. The C&DH (command and data handling) subsystem is also expected to be very constrained so the interaction with the C&DH processor and the temporary storage are minimized. Fully pipelined design so that bundle processing database is not required. Implements a lookup table-based approach to eliminate multi-pass processing requirement imposed by the Bundle Protocol header s length field structure and the SDNV (self-delimiting numeric value) data field formatting. 8-bit parallel datapath to support high data-rate missions. Reduced resource utilization implementation for missions that do not require custody transfer features. There was no known implementation of the DTN protocol in a field programmable gate array (FPGA) device prior to the current implementation. The combination of energy and performance optimization that embodies this design makes the work novel.

Torgerson, Jordan L.↗

Design and implementation of a medium speed communications interface and protocol for a low cost, refreshed display computer

The design and implementation of hardware and software systems involved in using a 40,000 bit/second communication line as the connecting link between an IMLAC PDS 1-D display computer and a Univac 1108 computer system were described. The IMLAC consists of two independent processors sharing a common memory. The display processor generates the deflection and beam control currents as it interprets a program contained in the memory; the minicomputer has a general instruction set and is responsible for starting and stopping the display processor and for communicating with the outside world through the keyboard, teletype, light pen, and communication line. The processing time associated with each data byte was minimized by designing the input and output processes as finite state machines which automatically sequence from each state to the next. Several tests of the communication link and the IMLAC software were made using a special low capacity computer grade cable between the IMLAC and the Univac.

Phyne, J. R.↗

ML–Enabled FPGA Framework for Fast Quantum State Discrimination in Mid-Circuit Measurement Regimes

Accurate and low-latency quantum state discrimination is essential for protocols involving mid-circuit measurement (MCM) and conditional feed-forward. In superconducting quantum systems, conventional readout pipelines transfer measurement data to host processors for post-processing, introducing millisecond-scale delays that far exceed qubit coherence times. To overcome this bottleneck, we present an in-situ machine learning (ML) inference engine implemented on an FPGA for real-time quantum state discrimination. Our design performs inference directly on digitized readout signals with 40 ns latency, supports both qubit and qutrit readout, and enables conditional operations without host-side intervention. This capability is critical for MCM and for feedback-driven protocols such as quantum error correction. We validate the system on superconducting transmon hardware, demonstrating robust discrimination fidelity across multiple qubit and qutrit channels. We further demonstrate conditional qutrit logic driven by FPGA-resident classification, highlighting the potential of low-latency ML-on-FPGA control for NISQ applications and scalable fault-tolerant quantum computing.

Vora, Neel [Lawrence Berkeley National Laboratory ↗

Multi‐Material Gradient Printing Using Meniscus‐enabled Projection Stereolithography (MAPS)

Light‐based additive manufacturing methods are widely used to print high‐resolution 3D structures for applications in tissue engineering, soft robotics, photonics, and microfluidics, among others. Despite this progress, multi‐material printing with these methods remains challenging due to constraints associated with hardware modifications, control systems, cross‐contamination, waste, and resin properties. Here, a new printing platform coined Meniscus‐enabled Projection Stereolithography (MAPS) is reported, a vat‐free method that relies on generating and maintaining a resin meniscus between a crosslinked structure and bottom window to print lateral, vertical, discrete, or gradient multi‐material 3D structures with no waste and user‐defined mixing between layers. MAPS is compatible with a wide range of resins shown and can print complex multi‐material 3D structures without requiring specialized hardware, software, or complex washing protocols. MAPS's ability to print structures with microscale variations in mechanical stiffness, opacity, surface energy, cell densities, and magnetic properties provides a generic method to make advanced materials for a broad range of applications.

bioprinting↗

Evolution of the SLATE linear algebra library

SLATE (Software for Linear Algebra Targeting Exascale) is a distributed, dense linear algebra library targeting both CPU-only and GPU-accelerated systems, developed over the course of the Exascale Computing Project (ECP). While it began with several documents setting out its initial design, significant design changes occurred throughout its development. In some cases, these were anticipated: an early version used a simple consistency flag that was later replaced with a full-featured consistency protocol. In other cases, performance limitations and software and hardware changes prompted a redesign. Sequential communication tasks were parallelized; host-to-host MPI calls were replaced with GPU device-to-device MPI calls; more advanced algorithms such as Communication Avoiding LU and the Random Butterfly Transform (RBT) were introduced. Early choices that turned out to be cumbersome, error prone, or inflexible have been replaced with simpler, more intuitive, or more flexible designs. Applications have been a driving force, prompting a lighter weight queue class, nonuniform tile sizes, and more flexible MPI process grids. Of paramount importance has been building a portable library that works across several different GPU architectures – AMD, Intel, and NVIDIA – while keeping a clean and maintainable codebase. Here we explore the evolving design choices and their effects, both in terms of performance and software sustainability.

Gates, Mark↗

The X-43A Flight Research Program: Lessons Learned on the Road to Mach 10

During an aerospace engineer's undergraduate studies, he or she will attend classes in aerodynamics, thermodynamics, structures, stability and control, dynamics, design, propulsion, and computer science, along with the related courses in mathematics, physics, statistics, and chemistry required to understand the material. Upon graduation, the new engineer will have acquired a basic knowledge of how to build an aerospace vehicle. What only comes through experience, however, is the understanding of the inevitable imperfect process through which an aerospace vehicle is built. This is the adventure of turning a basic concept into functional hardware. Engineers working on a project must often deal with ambiguous situations. They are routinely asked by management to provide risk assessments of a project, yet even after careful analysis uncertainties remain. The project must be accomplished within finite limits of time and money. The question an engineer answers is whether the solution to potential problem is worth the cost and schedule delay, or if the solution might actually be worse than the problem it is meant to solve. Review protocols are established to ensure that an unknown has not been overlooked. But these cannot protect against an unknown unknown. Examples of these situations can be found in the history of the X-43A Hyper-X (Hypersonic Experiment) program. In this NASA project, a supersonic combustion ramjet (scramjet) engine was flight tested on a subscale vehicle. The X-43A Hyper-X Research Vehicle (HXRV) was launched from a B-52B mothership, then boosted to the test speed by a modified Pegasus rocket first stage, called the Hyper-X Launch Vehicle (HXLV). Once at the proper speed and altitude, the X-43A separated from the booster, stabilized itself, and then the engine test began. Although wind-tunnel scramjet engine tests had begun in the late 1950s, before the Hyper-X program there had never been an actual in-flight test of such an engine integrated with an appropriate airframe. Thus, while the scramjet had successfully operated in the artificial airflow of wind tunnels, the concept had yet to be proven in real air. These conditions meant changes in density and temperature, as well as changes in angle of attack and sideslip of a free-flying vehicle. A wind tunnel is limited in its ability to simulate these subtle factures, which have a major impact on almost any vehicle, but especially that of a scramjet's performance. The Hyper-X project was to provide a real-world benchmark of the ground test data. The full scale X-43A engine would be operated in the wind tunnel, and then flown, and the data from its operation would then be compared with projections. If these matched, the wind tunnel data would be considered a reliable design tool for future scramjet. If there were significant differences, the reasons for these would have to be identified. Until such information was available, scramjets would lack the technological maturity to be considered for future space launch or high-speed atmospheric flight vehicles.

Peebles, Curtis↗

PACT Center: Perovskite PV Accelerator for Commercializing Technologies (Final Technical Report)

The Perovskite PV Accelerator for Commercializing Technologies (PACT) center was established in July 2021 as a national resource to accelerate the commercialization of perovskite photovoltaic (PV) technology in the United States. Since its inception, PACT has been led by Sandia National Laboratories (Sandia) in partnership with the National Laboratory of the Rockies (NLR), formerly known as NREL. From FY20-FY23, Los Alamos National Laboratory (LANL), CFV Labs, Black & Veatch (B&V), and the Electric Power Research Institute (EPRI) were part of the project team. LANL brought expertise in perovskite PV device designs and processing, CFV Labs (now GroundWork Renewables) provided initial indoor and outdoor measurement hardware technology, B&V led the initial effort on perovskite PV bankability, and EPRI worked on reviewing testing standards, identifying commercialization gaps, and helping to run PACT’s Industry Advisory Board, a group including representatives from commercial testing labs, independent engineering firms, insurance companies, state regulators, and electric utilities. To source perovskite PV module samples, PACT contracted with the University of North Carolina (UNC), the University of Toledo, the University of Washington, and SLAC/Stanford University to provide a steady stream of research-grade perovskite mini modules, enabling protocol development in advance of commercial module availability. The project period ran from July 1, 2021, through December 31, 2025, including a No Cost Extension. Starting in FY25, the project was continued as a Core Capability in the Lab Call portfolio and continues at a reduced budget with only Sandia and NLR as funded recipients. Notably, starting in FY25 PACT expanded its scope beyond MHP modules to accept all emerging PV mini module technologies for testing, including organic PV (OPV) and all-thin-film tandems, with the aim of supporting commercialization across the broader emerging PV ecosystem. With this change in scope the program was renamed the PV Accelerator for Commercializing Technologies, dropping perovskite from the name.

14 SOLAR ENERGY↗

Model Checking - My 27-Year Quest to Overcome the State Explosion Problem

Model Checking is an automatic verification technique for state-transition systems that are finite=state or that have finite-state abstractions. In the early 1980 s in a series of joint papers with my graduate students E.A. Emerson and A.P. Sistla, we proposed that Model Checking could be used for verifying concurrent systems and gave algorithms for this purpose. At roughly the same time, Joseph Sifakis and his student J.P. Queille at the University of Grenoble independently developed a similar technique. Model Checking has been used successfully to reason about computer hardware and communication protocols and is beginning to be used for verifying computer software. Specifications are written in temporal logic, which is particularly valuable for expressing concurrency properties. An intelligent, exhaustive search is used to determine if the specification is true or not. If the specification is not true, the Model Checker will produce a counterexample execution trace that shows why the specification does not hold. This feature is extremely useful for finding obscure errors in complex systems. The main disadvantage of Model Checking is the state-explosion problem, which can occur if the system under verification has many processes or complex data structures. Although the state-explosion problem is inevitable in worst case, over the past 27 years considerable progress has been made on the problem for certain classes of state-transition systems that occur often in practice. In this talk, I will describe what Model Checking is, how it works, and the main techniques that have been developed for combating the state explosion problem.

Clarke, Ed↗

COnfirmation using Gamma-ray Non-Imaging Zero-knowledge ANti-mask Time-encoding (COGNIZANT) Final Summary Report

In potential future arms reduction treaties in which the numbers of nuclear warheads may approach small numbers, using delivery systems as a proxy for the warheads themselves may be insufficient. Therefore, a technical means of verifying the presence of a nuclear warhead may become necessary. Verifying that a declared item actually is a warhead is technically challenging within a verification regime: providing assurance to the monitoring party that a presented item is a warhead while protecting sensitive information about that warhead may be required. It is generally believed that strong assurance will require the confirmation of key attributes that may reveal closely-guarded critical design information. This provides high confidence to the monitoring party, but presents a risk of information loss to the host. A verification system must overcome this hurdle. Over the last several decades, systems have been developed that balance host and monitoring partner needs by using sensitive information to confirm treaty accountable items (TAI) as warheads while sequestering that information behind an information barrier (1). These are designed to meet the needs of the host but places the onus on the monitor to authenticate the hardware, firmware, and software. Authentication requires that the monitor confirm that all components of the system have not been modified and work as intended. In 2014, Glaser et al. proposed applying the concept of “zero knowledge protocols” (ZKP) from the field of cryptography to the problem of warhead verification (2). In mathematical cryptography, ZKP is accomplished by challenging one party to solve a problem that is only possible if that party possesses the information being authenticated. After repeated challenges, the party provides confidence that it possesses this information without revealing any details about the information itself. Systems have been in development based on this idea at both Princeton and MIT (2) (3) (4). The final measurement results produced by these systems can be viewed by both the host and the monitoring party without the worry of revealing sensitive information. However, in both of these physical implementations, there remains an information barrier within the system. The need for a digital information barrier to protect a measurement result is eliminated, but it has been replaced with the need to sequester physical components of the system, potentially obfuscating the measurement process itself. Both implementations physically insert information into the system that requires protection to prevent undesired disclosure of sensitive information: in the Princeton method, one must physically load the complement of the expected image of a true warhead into the system, and in the MIT technique, one loads a collection of spectator foils whose thicknesses physically encrypt a measured spectrum. This complicates authentication of the hardware and measurement process. The CONFIDANTE/COGNIZANT concept developed in this project do not load sensitive information into the system at any time, and could therefore open the possibility of allowing the inspector to not only view the final data but also the measurement as it is being performed and all associated equipment.

98 NUCLEAR DISARMAMENT, SAFEGUARDS, AND PHYSICAL P↗