Skip to Main Content
A network of radiation sensors for the protection of a military base against radiological/nuclear threats has been integrated in a testbed. Two key subsystems of this network are the array of sensitive radiation detectors and the subsystem for notifying the operators of radiation events. The alarm/alert notification subsystem automatically issues notifications to the command post in real-time, The resulting reporting to the command post appears to be adequate for non-technical operational personnel, The CONOPS for the protection system relies on the sensitive detection and identification of all radioactive sources well before the transporting vehicles reach the base gates. This is a unique feature of this protection system. Discriminating sodium-iodide detectors, in conjunction with plastic scintillators and neutron detectors comprise a high-performance detection subsystem. The use of various correlation techniques has permitted the demonstration of the detection of source strengths of tens of µCi moving at highway speeds and at several meters separation. A companion algorithm identifies the detected radioisotope when sufficient counts are available.
This paper will describe one alternative to rehosting TPS software to newer computer platforms. It will describe the solution that Southwest Research Institute (SwRI) used to solve a problem with re-engineering legacy software into a modern object-oriented language. The advantages gained by this method are more advanced instruction to the operator (such as pictures and movies), flexible reporting scheme to diagnose system problems, and ease of software maintenance. This solution uses commercially available products including National Instruments™ TestStand™ and LabVIEW™ and Microsoft® Visual Basic®. The system is a four-tiered architecture to drive all test execution. The user interface is written in Visual Basic and allows the user to interact with the test execution when needed. This user interface in turn calls tests that are written in TestStand, and finally the individual tests call driver functions written in LabView. A database serves as a repository for all test results, displays, and test limits. The use of this database allows for easy querying of measurement data to analyze trends in failures that help diagnose specific problems. By using this database, all test limits and test displays are contained in one central location that enables engineers to change these displays and limits on the fly without needing to change or even understand any test code. One other benefit of this data containment is that all Government classified data is separated out of the code and stored as one file, instead of in various locations as it was in the original source code.
This paper provides a technological evaluation of two Automatic Fingerprint Identification Systems (AFIS) used in forensic applications, Both are installed and working in Spanish police premises. The first is a Printrak AFIS 2000 system with a database of more than 450,000 fingerprints, while the second is a NEC AFIS 21 SAID NT-LEXS Release 2.4.4 with a database of more than 15 million fingerprints.
Our experiments reveal that, although both systems can manage inkless fingerprints, the latest one offers better experimental results.
Sustainment of legacy Automatic Test Systems (ATS) saves cost through the re-use of software and hardware. The ATS consists of the Automatic Test Equipment (ATE), the Test Program Sets (TPSs), and associated software. The associated software includes the architecture the TPSs run 00, known as the control software or test station Test Executive. In some cases, to sustain the legacy ATS, it is more practical to develop a replacement ATE with the latest instrumentation. often in the form of Commercial Off-the-Shelf (COTS) hardware and software. The existing TPSs, including their hardware and test programs, will then need to be transported, or translated, to the new test station.
In order to understand how to sustain a legacy ATS by translating TPSs, one must realize the full architecture of the legacy ATS to be replaced. It must be understood that TPS transportability does not only include translating the original TPS from an existing language (such as ATLAS) to a new language (such as “C”) to run on a new test station, but includes transporting the run-time environment created by the legacy ATS. This paper will examine the similarities and differences of legacy ATE and modern COTS ATE architectures, how the ATS testing philosophy impacts the ease of TPS transportability from legacy ATE to modern-day platforms, and what SEI has done to address the issues that arise out of TPS transportability.
Back to Top