A National Laboratory Is Charged with Designing and Maintaining Weapons to Support National

MO T

Problem Statement

for

Detonator Acceptance Test Data

Submitted by:

MO T

Valerie Stanton and Nick Monge

Abstract

A national laboratory is charged with designing and maintaining weapons to support national security. One of the weapon systems was originally designed and built with an anticipated life span of 10 years. The weapon system has now reached the end of its life span, but instead of being retired, the decision has been made to upgrade the existing system in lieu of designing and building a new weapon system to replace it. To complete the necessary upgrade, the weapon system will have to be disassembled and then reassembled. The detonator is a critical component that will likely suffer a high attrition rate during this process. Due to the anticipated attrition, identical detonators will need to be manufactured to serve as replacements for any damaged units. The detonators were last manufactured more than 10 years ago and the original manufacturing facility no longer exists. The new manufacturing facility would like to review the old manufacturing data including design specifications, process manuals, and test data. While the original design specifications and process manuals are easily accessible, all of the test data is stored on CDs in raw data form. The test data resulted from ten successive armings of each detonator. The collected data points were compared against a set of acceptance criteria and reviewed on a pass/fail basis. No further analysis of the data was performed.

In the advent of new production, the manufacturers would like a more comprehensive way of analyzing the test data. They would like to have access to the historical data with the ability to incorporate new data. There should be a way to review the data for trends and to see how the data changes over the course of the ten armings as opposed to just relying on the pass/fail criteria.

Description of Domain

The detonator is a mechanical device (see Figure 1) that is part of a weapon’s complete initiation system.

Figure 1. Detonator assembly

The detonator houses a high explosive (HE), which is maintained out-of-line from the charge. Arming the detonator involves rotating the HE from an out-of-line to an in-line position. The HE is set in a wheel assembly made up of two parts, a code wheel and a ratchet wheel, which are welded together. The code wheel is rotated by an actuator driven fork, while a pawl is used in conjunction with the ratchet wheel to hold the entire wheel assembly in place. All of these parts are shown in the above figure. The test data is obtained with the use of a diagnostic, a Hall sensor, installed in the detonator assembly. The Hall sensor helps determine mechanism performance by measuring the displacement of the pawl moving over the ratchet wheel teeth as the wheel rotates around during the arming process. The Hall sensor actually measures the displacement using the changing voltage potential as a magnet within the pawl moves back and forth over the sensor. The voltage is recorded every 0.1 msec. By plotting the recorded voltage versus time, an electronic waveform referred to as a Hall trace is created (see Figure 2).

Figure 2. Actual waveform

The complete data set is run through an existing program to select a subset of points taken at defined locations (see Figure 3).

Figure 3: Simplified waveform with selected data points

These selected points are stored in an Access database (see Figure 4) and then used to compute numerous time- and ratio-based metrics (see Table 1). There are 35 teeth on the wheel assembly, with numerous points selected as the pawl moves over each tooth. The Point ID values listed in Figure 4 correspond to the data points displayed on the waveform in Figure 3.

Figure 4. Access database with selected point values

The metrics defined in Table 1 are calculated using the data points stored in the Access database. The new system will require a means of both performing the calculations and storing the results. The subscript, n, represents the tooth number to be used in the calculation. Measurement T1n corresponds to the time difference between points Dn and point En. It is important that the correct tooth number(s) is used for each calculation.

Table 1: Definition of time- and ratio-based metrics

While the time-based metrics utilize the time associated with each of the defined data points, the ratio-based metrics utilize the voltage values recorded for each point. The metric R1n represents the ratio associated with two sets of data points, the difference in voltage between points Bn and Cn divided by the difference in voltage between point En+1 and Cn.
Block Diagram

The complete set of data resides on a set of CDs and will continue to be supplied in that manner. The data will be run through the point selection software and stored in an Access database. The data will need to be transferred into the data management system and an interface provided for data manipulation and query operations. Consideration is being given to bypassing the Access database and loading the data points directly in to the data management system. This is displayed as a possible option in the diagram.

Program Description

Large quantities of historical data have been available, but were never comprehensively studied. With manufacturing of the detonators being renewed, an improved method for studying the data will provide valuable insight and help distinguish subtle changes. A data management system must be developed to both effectively and thoroughly study the data. The primary goal of this system will be to significantly improve the ability to study trends in the performance metrics by more closely evaluating their level of acceptability. In addition to creating a means to search for subtle changes and trends, the system should allow data from a single detonator to be compared with the average performance of the whole population. The system should be able to accommodate additional metrics that may need to be added during manufacturing. Finally, the system should include a user-friendly interface that will allow engineers to perform both simple and complex queries on the complete set of data or on data resulting from testing an individual mechanism.

Detailed Requirements

The amount of data that will be generated with the calculation of the performance metrics will be immense. Currently over 10,000 Hall traces exist as part of historical production with an equal number expected during new production. The system will need to accommodate and efficiently manipulate millions of data records. While the initial points extracted will be output to an Access database by the existing software, Access is not robust enough to serve as the actual data management system.

Because Access will not be used for the permanent storage of the data, the process of transferring the data must be addressed. Two options exist for populating the data management system with the select data points. The existing software could be altered to output the data into this new system directly, or the program could remain unchanged with the development of an automated process for transferring the data. The new data management system will utilize the same fields that currently exist within Access, which should simplify this transition. The new system will require the addition of numerous other fields to accommodate the calculated performance metrics, but that should not impact the implementation of either transition method.

To calculate the performance metrics, standardized scripts will need to be developed. These scripts will be run as new data is brought into the system. The calculations required for the performance metrics are included in Table 1 of the Description of Domain section. While these scripts will be created as part of the system for the standard set of calculations, the user should also be able to create and perform customized calculations. In addition, the user should be able to perform a variety of queries on the data. Performing these operations will require the development of a fairly complex user interface with options for outputting the results as well. When a query or customized calculation is performed, the user should be prompted with a set of output options: display to the screen, output to an excel spreadsheet, or add to data management system.

The system will be accessed by engineers at both the manufacturing facility and the national laboratory overseeing the process. A web-based interface would allow users at both facilities to easily access the data. Depending on each engineer’s job responsibilities and needs, different levels of access should also be provided to limit the number of people that can modify system data.

Use Cases and User Context

Use Case 1 – Provide Web-based GUI

The most important aspect of the data management system is to provide a means to access the data so it can be comprehensively studied. A web-based GUI will provide the most efficient means for users to access the data from any location. At the very least, the user will be able to view the stored data. Additional functionality should be available through the GUI that will provide a means of modifying, sorting, and performing queries on the data.

Use Case 2 – Import Data Points

A data management system will be established to store the selected data points. The historical data can be imported all at once, but as new data is generated, the user will need a way to bring it into the system. The existing software that selects the defined data points outputs the data into an Access database. The user will require a method to either transfer the data from Access into the data management system, or a direct interface can be developed.

Use Case 3 – Calculate and Store Metrics

After the data points have been brought into the system, the user will need to be able to calculate and store the various performance metrics. The user should also be able to add additional metrics as necessary to further evaluate mechanism performance. The user should be given the option to output any new calculations or actually save the resulting data in the data management system. The user should also be offered the option of performing calculations on one mechanism, a group or mechanisms, or the entire population.

Use Case 4 – Perform Trend Analysis

In original production, the metrics values were checked against a set of acceptance limits. If any metric fell outside of its respective limits, the mechanism was rejected. A mechanism was only accepted if all values fell within the set limits. The metrics were never evaluated beyond the pass/fail distinction. The user will need a method to evaluate how the metric values change for a given mechanism over the course of ten armings.

Use Case 5 – Perform Both Simple and Complex Queries

The user should be able to perform both simple and complex queries on the data. For example, the user should be able to create a query that display all values that fall outside of the acceptance limits along with the corresponding mechanism information.

1