Final Report

Location Enablement for Advanced Weapons Safety Systems
December 10, 2004
Sponsor: Sandia National Laboratories
Advisors: Dr. Lisa Brown, Dr. Jim Frenzel
Toney Jacobson
jaco1888@uidaho.edu
Devan Williams
will7639@uidaho.edu
Table of Contents
III. Abstract
3
IV. Main Section
4
1. Project Description
4
1.1 Background Information
4
1.2 Problem Statement
5
1.2.1 Objectives
5
1.2.2 Requirements
5
1.2.3 Constraints
6
1.3 Solution Method
6
1.3.1 Functions and Means
2. Status
6
8
2.1 What is Designed and Working
8
2.2 What is Designed but Not Working
9
2.3 What is Designed but Not Tested
9
3. Method of Solution
9
3.1 Technical Description
9
3.2 Theoretical Basis and Fundamental Relationships
16
4. Validation Procedure
17
4.1 Test Plan
17
5. Manufacturing and Support
19
5.1 Product Life Cycle
19
5.2 Failure Modes, Effects, and Criticality Analysis
21
5.3 Societal Concerns
24
V. Appendix
25
1. Specifications
25
2. Bill of Materials
27
3. PEN-X Controller
27
4. GPS Module
27
5. Palm Tungsten C Data Sheets
28
6. Garmin iQue 3600 Data Sheets
30
2
III. Abstract
Sandia National Laboratories wishes to enhance weapons safety systems by incorporating
GPS-monitored location enablement into current systems. The inclusion of a GPS system will
allow for a much greater degree of accuracy in the weapons system, which in turn will allow for
a much greater degree of safety in the event of an accident involving a hazardous environment to
the weapon. In the summer of 2003, we developed a preliminary application of this GPS system,
which stored entered target coordinates and characteristics into the software on our system.
Government standards require that all target information must be stored in hardware, or entered
manually via a user interface with the weapon.
The approach for this project was directly influenced by similar systems within the
military which require similar user interfaces. The user interface will be comprised solely of two
hand-held Palm-OS based PDAs. The PDAs selected are the Tungsten C model, which comes
equipped with both a full keyboard for text entry, and an infrared transmitter, and a Garmin iQue
3600, with infrared receiver and onboard GPS capabilities. The PDAs must act as a median
between the user and the weapon system they are associated with. This requires the Tungsten C,
or the Interface PDA, to accept the user’s target location input, generate parameters based on this
input, and then pass them into the Garmin iQue, or the Controller PDA. The Controller PDA
will compare the output of the GPS system to the received parameters, and create a unique
detonation signal based on this comparison. This will allow for either the enablement or the
locking of the weapon.
The software developed for this project is composed of a program which will allow a user
to input target location information, review this information, view the parameters developed
based on this information, pass the parameters to the Controller PDA, and begin the event
comparison tests. This software was written with Metrowerks CodeWarrior for Palm OS V9.0; it
is composed of several main forms, with dialog boxes, buttons, and fields associated with these
forms. In addition, the software includes error checking to ensure that the user does not input
incorrect target information, user-instruction to aid a user not familiar with the software, and
application information buttons which show the software version, author’s and most current
modification date. This completed project was demonstrated on December 2, 2004, and
performed without error.
3
IV. Main Report
1. Project Description
1.1 Background Information
As new technology has become available, Sandia National Laboratories has the
opportunity to enhance the safety of weapons safety systems. Current weapons safety systems
use trajectory information for enablement of the weapon, but do not take into account location
information to enable the weapon. Our project during the summer of 2003 was an initial study to
incorporate GPS information into one of the safety subsystems (see Figure 1), using a controller
and a Garmin VI commercial handheld GPS unit. This approach is called Location Enablement
(LE). Using LE along with intent enablement provides additional benefit to the safety
subsystem.
Currently, there are two devices within a weapons safety system that isolate the explosive
package of the weapon from the device that produces the energy required to detonate the
explosive. These devices, which act as physical barriers to the explosive package, are known as
stronglinks. The first stronglink is enabled by password; when the detonation is required,
someone must enter the password for detonation in order for the stronglink to open, allowing the
energy blast to pass through the outermost layer of the exclusion barrier of the weapon. This is
referred to as intent enablement. The second stronglink is currently enabled by trajectory; the
stronglink will open when the weapon experiences an environment similar to the weapon being
dropped. Unfortunately, this environment is easily simulated by undesirable circumstances, such
as during a crash by the airplane carrying the weapon. The weapon will experience the same
acceleration and trajectory as it would if it were dropped. It is because of this that the trajectory
process must be improved upon.
The incorporation of location enablement into the second stronglink will increase the
safety of the subsystem. Location enablement is a system that determines where the weapon is
currently located, and prevents it from detonating anywhere other than the target location.
Previously, the target location was stored within the software located on the controller (known as
the PEN-X controller, see figure 2) of the system. Military standards, however, forbid the
location to be stored within software on the controller in a stronglink system; this restriction
required us to create a system which allows the target location to be inputted by a system user.
This will prevent the target location from being stored within the controller software.
4
Figure 1. Function Block Diagram (Original Project).
1.2 Problem Statement
Our original system used information provided by a handheld GPS (see Figure 3) to
enable the system when the weapon was within the specified range of the target location. This
system was a good first step; however, we needed to improve the initial system for a more
realistic and usable system.
The initial system had target location stored in the controller software. For safety
concerns, the target location should not be stored on the controller. Sandia National Laboratories
requested that the target location be input and reset from a user interface. Our project is the
creation of software to supplement this; this was accomplished via an Interface PDA, which
accepts the target location as the inputs and produces the thresholds of acceptable range as
outputs, passing these ranges into the Controller PDA.
1.2.1 Objectives
The primary objective of our project was to design the user interface system and
controller that was used to demonstrate the feasibility of location enablement and replaces the
project developed during the summer of 2003.
1.2.2 Requirements
The requirements for the user interface system were that it must (1) accept target location
coordinates as user input; (2) produce the thresholds of acceptable range as output; and (3) store
the thresholds of acceptable range in the interface software rather than the controller software.
The requirements for the controller were that it must (1) accept a location event threshold string
as infrared input; (2) obtain GPS location information from satellites; (3) compare the event
thresholds to the GPS location information in various “event tests”; and (4) generate a unique
signal (UQS) to send to the stronglink simulator, based on the event tests.
5
1.2.3 Constraints
As previously mentioned, the target location cannot be stored in software. As a result,
the user interface system must allow a user to enter target location coordinates via a Personal
Digital Assistant (PDA) using the Palm Operating System (Palm OS). The PDA software must
generate thresholds of acceptable range for the given target location and send only the threshold
(not the location information) to the Controller PDA (see Figure 5) via an Infrared (IR) signal.
Figure 2. PEN-X Controller.
Figure 3. The Garmin VI GPS Unit.
1.3 Solution Method
1.3.1 Functions and Means
For this project we designed a user interface system to perform several different
functions. The bulk of these functions take place within the software on the interface and
Controller PDAs. The main functions (described below) consist of: allowing a user to enter the
desired target location in the Interface PDA, displaying the desired target location to the user for
verification, producing the thresholds of acceptable range (from the target location), converting
the thresholds into a data string, sending the thresholds to the Controller PDA, and comparing
the thresholds to the GPS information received by the Controller PDA.
The target location coordinates are selected or typed in by the user. Therefore, our
system collects data via a user interface. In order to accomplish this, our Interface PDA software
contains checkboxes for target selection (for hemispheres, altitudes, and velocity directions) and
text fields for specific location values (velocity magnitudes, acceleration magnitudes, and
location coordinates). The target information is entered either by stylus (since the PDAs are both
touch screen capable), or by keyboard.
6
Figure 4. Palm Tungsten C PDA.
Figure 5. Garmin iQue 3600.
Our system displays the data to the user for verification. We created a function (accessed
from the software’s main menu) that displays all user-entered location values if the location has
been entered. If all or part of the location has not been entered, or a location value has been
entered incorrectly, an error displays, indicating this is the case. Once the target location data is
verified by the user, the thresholds of acceptable range can be produced. These thresholds are
produced from the magnitudes and coordinates typed in by the user, and are determined by a
user-adjustable range.
Our system converts the thresholds into data that the Controller PDA can use. As a
result, we have included in our software a function that converts the location parameters into a
text string. This string is then passed to the Controller PDA by IR transmission. Once the
Controller PDA has received the parameters from the Interface PDA, the parameters can be
again checked by the user for authentication. Once the user determines the parameters are
correct, he can then verify the reception of the GPS signal through a function in the software
which checks both the integrity and strength of GPS reception. When a suitable signal is found,
the Controller PDA software can then compare the actual location with the parameters it has
received. The results of this comparison compose the UQS, which is outputted on the screen of
the Controller PDA for verification.
7
Figure 6. Function Block Diagram, current project (Interface PDA on the left)
2. Status
2.1 What is Designed and Working
The ability to enter a target location into the Interface PDA is the quintessential function
of Location Enablement. As mentioned previously, the target location cannot be stored in
software, so user-entry is required. Our system executes this ability perfectly; the included
software function that displays the entered target location provides ample testing and verification
of the correct performance of this ability.
Once the target location information is entered, the Interface PDA software creates
location ranges based around the target. Similar to the software function mentioned above, the
user can verify the location ranges are correct before they are sent to the Controller PDA. This
ensures proper operation of the software in creating the acceptable ranges, and again provides insystem testing of the ability to generate location parameters. The creation of the location string
based on these parameters is also operational, and likewise can be verified by the user through a
function which displays the string on the screen of the Interface PDA.
The software then allows for the transfer of the location parameter string to the Controller
PDA. Again, the string can be verified in the software by the user to verify that the IR
transmission/reception performed correctly. The comparison between the actual location
information (via GPS) and the location ranges also performs very well, the verification of which
is not readily available through software, and which requires physically walking a pre-designated
path, and checking the outputs of the test (see section IV-4.1).
8
2.2 What is Designed but Not Working
All aspects of this project are operational.
2.3 What is Designed but Not Tested
All aspects of this project have been tested.
3. Method of Solution
3.1 Technical Description
For the development of the Palm OS application, we have been using the development
environment “Metrowerks CodeWarrior for Palm OS V9.0” software. This builder, linker, and
compiler program takes C or C++ programming language code and generates a Palm OS
application file. The file generated contains all the necessary application details in a “.prc” file
that is ready to be loaded on to the Palm PDA or onto Palm OS Emulator software. We have
been using the Palm OS 5.2 Simulator to test our application, because it is more convenient to
load the application into the simulator software rather than the PDA itself. The simulator
software is simply a program on the computer that acts as a Palm PDA device running under
Palm OS. The simulator comes with the CodeWarrior for Palm OS V9.0, or it can be
downloaded for free from the Palm website. The emulator does not simulate GPS reception or
IR transmission, however, so conventional software uploading was necessary.
We have also been using the book “Palm OS Programming: The Developer’s Guide (2nd
Edition),” by Neil Rhodes, for help with Palm OS programming. Coding for the Palm OS
environment is quite different from coding for a typical personal computer, as previously
mentioned. Most coding on the Palm OS is graphically and spatially oriented, as the above book
illustrates, requiring much more attention to detail than typical C coding.
Without going into too much detail about the Palm OS, there are several important details
that should be mentioned. The Palm OS is an “event-driven” system. Every screen tap, button
press, and keypad press produces an event that must be handled by the system, the menu, or the
application itself. Each screen (called a “form” on the Palm OS) requires its own function for
event handling, and is typically contained in a separate “<form name>.c” file in the application
design project. Each pop-up dialog box requires its own function as well, typically contained in
the file of the form it “pops-up” from. The physical layouts of each form and dialog box are
9
described in a “Resources.rcp” file. This file will be described later in the “Included Files”
section.
Our design consists of Interface PDA Software and Controller PDA Software. The
software for both the Interface PDA and the Controller PDA are Palm OS applications written in
Palm OS modified C. The Interface PDA Software can accept user inputs for a target location,
generate parameters based on these inputs, and send the string of event thresholds to the
Controller PDA. The Interface PDA application currently consists of three primary sections (as
illustrated in Figure 7).
Figure 7. Interface PDA Sections.
Each section contains several different forms for different purposes. The Main Menu
section contains the initial starting form, the application information pop-up dialog box, the main
forms for the Target Location and Event Thresholds, and reset pop-up dialog boxes. The Target
Location section contains forms for entering the target location coordinates. The Review &
Submit section contains forms for checking the target location, reviewing the event thresholds,
and sending the string of target information or the string of event thresholds.
10
Figure 8. The Location Form.
Figure 9. The Hemisphere Target Form.
As is seen in Figure 8, the location form consists of ten buttons. The first button is the
Hemisphere/Altitude button. When tapped, a pop-up dialog box appears, consisting of three sets
of checkboxes, allowing a user to select which hemisphere (N/S, E/W) and what altitude sign
(+/-) he wants, and two buttons: a Save button and a Cancel button (see Figure 9).
Once the user selects the appropriate values, the user has two options. He can either tap
the Save button, which stores the values selected as global variables, or he can hit the Cancel
button, which will reset the values to their previously saved values. A similar dialog box exists
for the Velocity Direction Button on the Location Form. When this button is tapped, a dialog
box is displayed that allows the user to input the direction of velocity (using checkboxes similar
to Figure 9) in the E/W Direction, in the N/S Direction, and in the U/D Direction.
Five of the buttons on the Location Form (the velocity magnitude, acceleration
magnitude, and N/S Latitude, E/W Longitude, and +/- Altitude buttons) bring up dialog boxes
similar to the one of Figure 9. One primary difference, however, is that these location entries
require more than a binary input. To enter a viable velocity magnitude, the user must have
greater freedom when entering inputs. To compensate for this, text-entry fields have been
included to replace the checkboxes on the pop-up dialog boxes that appear when a button is
selected (see Figure 10 and Figure 11). For the Latitude/Longitude entry forms, location is
entered in degrees, minutes, and thousandths of minutes, and the range (which determines the
size of the thresholds developed by the Interface PDA) is entered in thousandths of minutes.
When creating the location string to send to the Controller PDA, all latitude/longitude
information is converted to thousandths of minutes.
11
Figure 10. The Velocity Magnitude Form.
Figure 11. The N/S Latitude Form.
When the user has finished entering the target location values, he can select the Submit
button to view either the entered target location or the event thresholds, based on the user’s
choice. If the location information is correct, the user can then submit the event thresholds to the
Controller PDA for review and testing.
The Controller PDA application currently consists of four primary sections (see Figure
12). Each section contains several different forms for different purposes. The Main Menu
section contains the initial starting form, the application information pop-up dialog box, and reset
pop-up dialog boxes. The Event Threshold section contains forms for displaying the event
thresholds. The GPS Data section contains forms for displaying the GPS Status & Info. The
Event Tests section contains forms for running the event tests.
Figure 12. Controller PDA Sections.
12
There is one main event form (see figure 13), which allows the user access to several
aspects of the project. The GPS Status & Info forms (see figures 14 and 15) allow the user to
both simulate and verify GPS reception. The quality of the signal is shown (whether 3
Dimensional, 2 Dimensional, or Unusable), as is the time (given in Military Time), the NS
Latitude and EW Longitude (given in either semicircles or 1000ths of minutes; the “toggle”
button allows toggling between the two), and altitude (in meters). In addition, axial velocity is
given in kilometers per hour (kph), as well as total overall speed. Finally, horizontal and vertical
margins of error are given in meters, as well as total position error. The “Next” button on form 1
brings up form 2. The “Back” button on form 2 returns the user to form 1. Additionally, the
“Main” button on each returns the user to the main form. The GPS data refreshes once every
second.
Figure 13. The Controller PDA Main form.
The View Event Thresholds form allows the user to review and verify the information
stored in the location string sent to the Controller PDA. When this string is transmitted from the
Interface PDA, the Controller PDA automatically detects it, and if the user chooses to accept the
string, the string is transferred onto the PDA. The location parameters are then displayed in a
separate form, which allow the user to see the acceptable ranges before the event comparisons
begin. If the parameters are not correct, pressing the “Reset Event Thresholds” button on the
main form of the Controller PDA will reset the string, and new information will have to be
transmitted by the Interface PDA.
13
Figure 14. GPS Data Form 1.
Figure 15. GPS Data Form 2.
Once the parameter ranges have been accepted and verified, the user can begin the event
comparison tests. This is executed by pressing the “Run Event Tests” button on the main form
of the program. Once this happens, the Event Tests form will appear (see figure 16). The Event
form is composed of three columns: an event # column, a description column, and a signal
column. The titles of these columns are followed by 8 rows of fields, which in turn are followed
by a field labeled “UQS”. There are four buttons on this form: one labeled Begin, Stop, Reset,
and Main. The Main button returns the user to the main form of the Controller PDA program.
The Reset button, when tapped, will reset all fields on the form and allow the user to restart the
event tests. The Stop button can be tapped at any time during the test to
Figure 16. The Event Tests Form.
Figure 17. Event Tests in Progress.
14
halt the system at any point during the test run. When the Begin button is pressed, the event tests
begin (see Figure 17); the “Event Tests” form cannot be accessed if a location string has not been
received and verified. Once the tests begin, the program cycles through the 24 events, one at a
time, every two seconds. The pre-designated events are as follows:
1) N/S Hemisphere
2) E/W Hemisphere
3) +/- Altitude Sign
4) N/S Latitude 1
5) E/W Longitude 1
6) +/- Altitude 1
7) N/S Velocity Direction
8) E/W Velocity Direction
9) U/D Velocity Direction
10) N/S Latitude 2
11) E/W Longitude 2
12) +/- Altitude 2
13) N/S Velocity Magnitude
14) E/W Velocity Magnitude
15) U/D Velocity Magnitude
16) N/S Latitude 3
17) E/W Longitude 3
18) +/- Altitude 3
19) Total Position Error
20) Horizontal Position Error
21) Vertical Position Error
22) N/S Latitude 4
23) E/W Longitude 4
24) +/- Altitude 4
If each event comparison occurs as desired, then the Controller PDA outputs the desired signal to
the “UQS” field located at the bottom of the Event Test form. For instance, if the desired (N/S)
hemisphere is “N” and the “N” field is transmitted to the Controller PDA, and the desired signal
is an “A”, then an “A” is outputted if the PDA is in the northern hemisphere and a “B” is
outputted if the PDA is in the southern hemisphere. Similarly, a range is selected for each
latitude/longitude coordinate entered into the Interface PDA, and the parameters developed based
on the latitude/longitude coordinate are multiples of this range. If the Controller PDA is within
the particular parameter being tested, then the desirable signal (“B”, say) is outputted; if not, the
opposite signal is outputted (“A”, in this case). This happens for all 24 events; once event 8 is
reached, event 9 displays in the first field of the Event Test form, replacing event 1. The
culmination of the outputs resulting from the comparison (again, the “A”s and “B”s) remain in
the “UQS” field until all 24 event tests have been made, and all 24 outputs are visible in a single
line. If all 24 signals match the desired UQS code, which is:
AAAB AABB ABAB
BAAA BBAB ABAB
then the desired trajectory was followed. In a weapons system, this would result in the
enablement of a warhead. If an event test did not produce the desired result, the UQS would be
different than the one shown above, and (in a weapons system) would result in the
locking/disabling of a warhead. Once all 24 event tests have taken place, the Event Tests form
can be reset by pushing the Reset button, or can be closed by pushing the Main button.
15
3.2 Theoretical Basis and Fundamental Relationships
Being primarily a software project, very little electrical engineering theory is applied,
outside of standard internal computer process theory (processing, memory control, etc.) which
was not manipulated in any way. The method of developing parameters is based on a simple
algorithm which satisfies the military requirement that all events have a 50% chance of
occurrence in an accident. To incorporate location enablement while concurrently satisfying this
stipulation, the parameters were developed using a “dividing” technique; given a specific target
and range, an initial parameter was developed. The next parameters are developed by splitting
the first parameter in half, then splitting those halves into half, and so forth (see Figure 18).
Figure 18. A typical parameter creation.
Once the parameters are established, a specific code is assigned to each parameter such
that if the Controller PDA lies within a particular parameter (for example, parameter 7), then the
PDA will output a particular UQS (in our case, “ABBA”). Dividing the range into halves in this
way allows for a 50% chance that a specific signal will be outputted (note that the ranges extend
far beyond what’s labeled in the diagram). Utilizing four splits per dimension gives a warhead a
1 in (24)3 or a 1 in 4096 chance of being in the correct location at any given time. The
combination of these parameters and the other location information (acceleration, position error,
velocity direction, velocity magnitude, hemisphere, etc) give the warhead an incredibly dismal
chance of accidentally detonating.
16
4. Validation Procedure
4.1 Test Plan
Our system is composed of two primary components (two different PDAs) each with a
series of subcomponents and systems which are relied upon heavily for system functionality.
The first PDA is the Interface PDA (model Palm Tungsten C), which relies on the operation of
its Palm OS, the software we created, and its IR transmitter. The second PDA is the Controller
PDA (model Garmin iQue 3600), which relies on the operation of its Palm OS, the software we
created, its IR receiver, and its GPS receiver. In order for the system to function correctly, the
software must be able to rely on each of the other PDA components. The system test plans, as
well as the methods which will be used to detect failure on both a system and component level,
are detailed below.
To demonstrate our system, we walk a “trajectory”; a three-dimensional trajectory is
simulated in two-dimensions, similar to orthogonal projection in linear algebra. We designate a
specific location (a section of Guy Wick’s field), and mark off a target and a starting location,
taking the GPS coordinates of each. We calculate a specific trajectory, including walking
velocity and direction. The target location is entered into the Interface PDA, which transmits the
event thresholds to the Controller PDA. Once the Controller PDA receives these thresholds, the
test can begin. Holding the Controller PDA in such a way that it receives sufficient GPS signals,
the trajectory is walked. The Controller PDA software compares the current location along the
trajectory to the thresholds, and a Unique Signal (UQS) is generated based on the comparisons.
If the system fails in any way, this signal will not match the enabling signal we are expecting.
Likewise, to ensure that the system works, we walk a differing trajectory (with the same target
location) to see if the comparison results in a different (and incorrect) UQS. If the UQS is
different, then we know that only for the desired trajectory will the Controller PDA output the
desired UQS, which is the goal and intent for our system.
We have several varying methods at our disposal to detect system failure on a component
level. A Palm OS failure would be detected by a PDA malfunction, characterized by the
inability to power up the PDA, the inability to load software, or freezing of the PDA during
software or data accessing. A Palm OS failure is highly unlikely, and would result in a complete
disabling of the system. If such a failure were to occur, the failing PDA would need to be
17
replaced. Because of the low probability of this happening, we do not anticipate any system
level failure as a result of an OS failure.
Since the effects of an IR failure, a GPS failure, or a software failure are all so
intertwined, the methods of detecting such failures are also conjoined. We included a function in
the software that displays the target information once it has been entered in the Interface PDA.
This allows a user to review the target information on a separate form to ensure that it is correct.
Once this is completed, and the information is checked by the user, the thresholds can then be
submitted to the Controller PDA (by IR transmission). Similar to the Interface PDA, the
Controller PDA has a function that displays the location information. If an IR failure occurs, the
information is not displayed correctly, or at all, or the PDAs lock up on transmission.
Once the thresholds are received and verified on the Controller PDA, the integrity of the
GPS system must be confirmed. A function was created to display the current GPS location
information and the GPS signal information in the software on the Controller PDA. GPS failure
is indicated on this form by a strong enough signal not being present, or no signal being present
at all. If the GPS signal reception is satisfactory, and the event thresholds are received by the
Controller PDA, then the major system components are operational, and the system can be used.
Once we have pre-designated a trajectory to walk, and determined suitable coordinates
for the start of the trajectory and the target, the system test can begin. The target coordinates are
entered into the Interface PDA. Then the thresholds are passed to the Controller PDA. The
system tester takes the Controller PDA and begins to walk the trajectory. As long as the tester
stays on the path of the trajectory, the comparison of the GPS information and the thresholds will
result in a desired signal output. Once all 24 comparisons are made, the tester receives a 24-bit
signal (the UQS). If the system is functioning, the UQS will be identical to the desired UQS. If
the UQS is not as expected, and the trajectory was walked correctly, then there is a software
error on the PDAs (assuming the IR test and GPS signal test pass). As mentioned previously,
several incorrect paths will be walked to ensure that only the correct path outputs the desired
signal.
18
5. Manufacturing and Support
5.1 Product Life Cycle
5.1.1 Introduction
5.1.1a Background Information
Our project is to demonstrate the feasibility of incorporating GPS information into one of
the safety subsystems of a weapons system via location enablement. Using LE along with intent
enablement provides additional benefit to a weapon’s safety subsystem. Our application of LE
utilizes IR data transmission, the Palm OS (with accompanying software), and GPS reception.
5.1.1b Background Technology
Although the premise of infrared communications has been around since the 1970’s, it
was not until 1994 that the IrDA (Infra-red Data Association) established the first IEEE-accepted
industry standards on IR transmission. IR today is implemented in products including (but not
limited too) handheld Palm OS and Pocket PC devices, calculators, laptop computers, dental
instruments, cameras, and watches. The website www.irda.org contains more information on
IrDA standards.
The Palm OS was developed by Jeff Hawkins for use on the original Palm Pilot by 3com
in 1994. Version 2 was introduced in 1996 for use with the Palm Personal and Palm
Professional, and was a very minimally incremental upgrade from Version 1. Versions 3 and
greater have been developed since, and have borne the innovations of color display, multiple
expansion ports, and faster processors. The Palm OS is an object-orientated language
emphasizing the importance of efficiency in programming due to display space constraints.
Approximately 80% of today’s PDA’s utilize the Palm OS. The website www.palmos.com
contains more information on the Palm OS.
The idea of a Global Positioning System (GPS) was first conceived by the Pentagon in
1973. In 1978, the first fully operational GPS satellite was launched. By the mid-90’s, the
system was fully operational with 24 satellites. The GPS is currently operated and maintained by
the US Department of Defense, which allows many commercial developers access to research
and produce products available to the public.
5.1.1c System Background
The single customer and user of this product is Sandia National Labs (SNL). Sandia will
use this system as a prototype to demonstrate the feasibility of LE. Various engineers and
19
managers within Sandia may use all or part of this product to demonstrate other aspects of LE.
This system will never be mass-produced or sold, and therefore will never be used to obtain
revenue. The total cost of this system is approximately $1000. The system has a Department of
Energy pre-designated useful life of 2-4 years, before being replaced by proprietary components
(Sandia-designed hardware).
5.1.2 Hardware Design
5.1.2a Component Overview
Our system is composed of two main components: an Interface PDA and a Controller
PDA. The Interface PDA is the Palm OS-based Tungsten C. The Controller PDA is also Palm
OS-based, but is a Garmin iQue 3600, with onboard GPS.
Figure 19. The Tungsten C (left), and the Garmin iQue,
5.1.2b Component Life
The PDA’s have a system life approximately equal to the usual life of our product.
According to William Hungerford of palmtops.about.com, the most likely component of PDA’s
to fail is the battery, which is typically easy and inexpensive to replace (see
http://tinyurl.com/6p9b9). Naturally, proper care/misuse can augment/diminish the system life
of the PDA’s; their use in this project will present no circumstances of harsh handling/behavior,
however, so there is no reason to assume they will fail for any reason except for faulty internal
components. In addition, the PDA’s carry a one-year manufacturer warranty and a three-year
vendor warranty. The Palm OS is backwards-compatible, so if either of the two PDA’s were to
20
become obsolete, the software will still function on a future version of Palm OS, as long as the
replacement PDA also had onboard GPS and IR reception/transmission.
5.1.2c Component Support
The use of the PDA’s requires only a very basic knowledge of Palm-based handhelds;
someone with a complete lack of experience with Palm products could figure out the general
functionality of the system within a few minutes of use. IR communication requires only a
minimal line of sight between PDA’s. All necessary instructions on PDA use will be covered in
an accompanying instruction manual. The use of the project software installed on the PDA’s
will require some instruction to use, but operation for the most part is self-explanatory. Included
in the software are various instructions on certain parts of the program, and the software will
continually check user activity to ensure no unacceptable inputs are entered. If unacceptable
data is inputted, the software will bring to the attention of the user the correct parameters for data
input.
5.2 Failure Modes, Effects, and Criticality Analysis
5.2.1 Potential System Failures
5.2.1a Physical Damage
Physical damage can occur if the system is handled roughly/exposed to any physical
contact. This damage is evident by the physical appearance (i.e. cracked PDA housing, missing
or damaged buttons, etc). If this failure were to occur, there would be about a 50% chance of the
system becoming inoperable.
5.2.1b Battery/Power Failure
A loss of power will be experienced if the battery in either of the PDAs fails. Indications
of this would be the “low-battery” indicator icon (present within the Palm OS interface), or a
failure to power-up the Palm OS software on a PDA boot. A battery/power failure would result
in complete inoperability of the system, but would pose no danger to the system operator.
5.2.1c Line of Sight Interference
Line of sight interference occurs if something obstructs the line of sight between PDAs,
or the PDAs are too far away to effectively communicate with each other. It is generally simple
to circumvent this problem by placing the PDAs closer to each other or removing the obstruction
between them. A sign that line of sight interference might be occurring is the PDAs would be
21
unable to send/receive data. The Interface PDA would present an error indicating that it was
unable to find a PDA to send to. Occurrence of line of sight interference poses no risk or danger
to the user, but will cause the system to not be able to transfer data between PDAs.
5.2.1d Operating System Failure
If the operating system (Palm OS) were to fail, the controller and interface software
would be unable to load.
This would cause the system to completely malfunction, as its
functionality is entirely dependent on the operating system. An operating system failure would
be evident by the lack of normal display on PDA power up. If this were to occur, no risk or
danger would be present to the operator of the system.
TABLE 1
LIST OF POTENTIAL FAILURE MODES
Failure Type
A)
B)
C)
D)
E)
F)
G)
H)
I)
Physical Damage to Components
Battery / Power Failure
Line-of-Sight Obstruction between IR Ports
Palm Operating System Failure
Memory Leak / Memory Full
Infrared Sending / Receiving Malfunction
GPS Failure / No GPS Signal
Interface PDA Software Failure
Controller PDA Software Failure
Table 1. The potential failure modes of the location enablement system.
5.2.1e Memory Leak
A memory leak occurs if the system’s RAM becomes tied up by a program and fails to
free itself after the program is terminated. When this occurs, there might be a shortage of
memory available for use with the controller/interface software. The error message “Fatal Error:
Memory Handler” appears within the Palm OS if this occurs. This problem can usually be fixed
by a system reset. A soft reset is usually possible, but if the memory shortage is great enough, a
hard reset must be performed. If a memory shortage occurs, there is no danger or harm posed to
the system operator.
5.2.1f Infrared Sending/Receiving Malfunction
An infrared malfunction would prevent the transmittal and reception of data between
PDAs. This problem would be difficult to detect, as the only warning the Palm OS offers for IR
malfunction is a “data not properly received” warning, which is somewhat ambiguous as this can
22
apply to several different things. An IR malfunction would prevent the threshold data from the
Interface PDA from being received, which would cause the entire system to fail. IR malfunction
poses no threat or danger to the system operator at any time.
5.2.1g GPS Failure/No GPS Signal
A GPS Failure would prevent the reception of location information from global
positioning system satellites. This problem would be fairly easy to detect, as the Garmin iQue
3600 would provide an error message in the event of an error. A GPS malfunction would
prevent the location information from being received by the Controller PDA and therefore
prevent the event tests from occurring, precluding system functionality. GPS malfunction poses
no threat or danger to the system operator at any time.
TABLE 2
FMEA TABLE OF RATINGS
Failure Type
Severity
Occurrence
Detection
RPN
GPS Failure
Palm OS Failure
PDA Software
Memory Failure
Infrared Failure
Line-of-Sight
Power Failure
Physical Damage
6
6
6
6
5
3
7
7
4
5
5
3
2
7
3
3
3
2
2
3
5
1
1
1
72
60
60
54
50
21
21
21
Table 2. The FMEA Table of Ratings for the location enablement system.
5.2.1h Interface PDA Software Failure
A failure of the Interface PDA software could occur in many different stages of user
input of the target location; the failure could occur as data is being entered, as the event string is
being compiled, or in the actual sending of the event thresholds. This problem would be fairly
easy to detect, as the Interface PDA would display a “Fatal Error” message indicating the
specific software failure. The ultimate result of this type of failure would be the prevention of
the sending of the event thresholds to the Controller PDA, preventing further system
functionality. Interface PDA software malfunctions pose no threat or danger to the system
operator at any time.
5.2.1i Controller PDA Software Failure
A failure of the Controller PDA software could occur in many different stages of event
23
testing; the failure could occur as data is being received, as the GPS information is being
received, or as the event tests are being run. This problem would be fairly easy to detect, as the
Controller PDA would display a “Fatal Error” message indicating the specific software failure.
The ultimate result of this type of failure would be the prevention of the event tests being
completed, preventing further system functionality. Controller PDA software malfunctions pose
no threat or danger to the system operator at any time.
TABLE 3
MEAN TIME BETWEEN FAILURES FOR COMPONENTS
Failure Rate
MTBF
Component
/million-hrs
(million-hours)
Palm OS Software×2
Interface Software
Controller Software
Intel PXA255 CPU
ARM CPU
Lithium-Ion Battery
320 x 480 pixel LCD
Tungsten C
Garmin iQue 3600
IR Connection
139.6343
69.8171
69.8171
0.01528
0.01528
20
4
0.5
0.5
0.56
0.007161564
0.014323139
0.014323139
65.44502618
65.44502618
0.05
0.25
2
2
1.785714286
Table 3. Failure rates and MTBF for each system component. The failure rates for the Lithium Ion Batteries, the
LCD Displays, the Tungsten C, and the Garmin iQue were estimated based on comparison with data sheets from
similar components found on www.digikey.com. The failure rates for the remaining components were given from
the Relex Reliability software package. MTBF was calculated by taking the inverse of the failure rate.
5.3 Societal Concerns
There are no societal concerns directly associated with our project, as it will not be a
commercially available product. The intention for our project is to increase the safety of our
country’s nuclear arsenal, which in turn is bettering the safety of society in general. In this
aspect, a societal concern might exist with the notion that our nuclear arms are not safe enough;
this is not the case however. Our arsenal is already incredibly safe with no accidental
detonations through history. With the advent of new technology, however, we have the
opportunity to increase this safety even more, and we as a country would be morally remiss if the
opportunity was not capitalized upon.
24
Appendix
1. Specifications
As mentioned previously, a Palm OS based PDA must be used to accomplish our
objectives. This PDA must have sufficient enough memory space to contain the application we
write. For security reasons, the PDA itself must have any means of recording audio, video, or
visual captures. The application stored on the PDA must accept user location information inputs,
and generate acceptable parameters based on these inputs. It must output these parameters via an
infrared transmitter to an infrared receiver built into the Controller PDA. The Interface PDA
software must allow the user to input the exact velocity and acceleration magnitudes and
latitude/longitude/altitude coordinates into it. The program must compile all user inputs and
parameters into a string for transmittal. The program must reject false or nonsense values, and
must check to see that all inputs have been given before passing the string to the Controller PDA.
1.2 Specifications for Each Program
1. Interface PDA Software – PDA
1.) File Name: LocationEnable.prc
2.) File Size: 44.0 KB
3.) Version: v9.0
4.) Date Last Modified: 10/30/2004
5.) Included Files:
25
6.) Description: Allows complete text entry for all target location specs, including
hemisphere selection, altitude selection, velocity magnitude/direction selection, acceleration
magnitude selection, NS Latitude, EW Longitude, +- Altitude entry. Error detection built in.
Sending/Receiving capability. Other features mentioned in report.
2. Controller PDA Software – PDA
1.) File Name: Controller.prc
2.) File Size: 36.0 KB
3.) Version: v5.0
4.) Date Last Modified: 10/30/2004
5.) Included Files:
6.) Description: Obtains GPS Data, Receives only the event thresholds from the Interface
PDA, Displays event thresholds, runs the event tests and displays the Unique Signal (UQS).
Other features mentioned in report.
26
2. Bill of Materials
Component
Model
Quantity
Price
Total
Salary
Devan Williams
720 hrs
$25.00 /hr
$18,000
Salary
Toney Jacobson
720 hrs
$25.00 /hr
$18,000
Interface PDA
Palm Tungsten C
2
$400.00
$800.00
Controller PDA
Garmin iQue 3600
1
$600.00
$600.00
PDA IDE
Metrowerks Codewarrior for PalmOS
2
$400.00
$800.00
Code Book
Palm OS Programming Book
1
$40.00
$40.00
Total
$38,240
3. PEN-X Controller
The PEN-X controller (Figure 2) was developed by a group of Sandia National
Laboratories personnel led by Laurence Mayer. The core of the controller is a Linux-based
processor, which contains code written by Toney Jacobson and Devan Williams that compares
data outputted from a commercial GPS unit and parameters of desired location stored within the
software. The processor then creates a unique signal based on this comparison and outputs it to
the stronglink. The controller has standard DB9 serial ports for communication between the
CPU and an external device (where the interface will connect), a modem (unused for this
project), a stronglink, and a power connector (to connect to the 12V battery and produce a 5V
signal across two terminals which protrude from the controller).
4. GPS Module
The GPS unit (Figure 3) is the Garmin VI commercial GPS unit, which receives data
location from a network of 48 satellites. The unit outputs a text string of location and velocity
information to the PEN-X controller with a sampling rate of 1s. This unit connects to the PEN-X
controller via a DB9 RS-232 serial port and provides the location information necessary for
location enablement.
27