System of Systems Modeling and Simulation

Department of Systems Engineering and Engineering Management, Stevens Institute of Technology

System of Systems Modeling and Simulation Sandia National Laboratories System Sustainment & Readiness Technologies Department P.O. Box 5800 Albuquerque, NM 87185-1176 Dr. James E. Campbell [email protected] Dennis J. Anderson [email protected] Craig R. Lawton [email protected] Donald Shirah [email protected] Dr. Dennis E. Longsine [email protected] Intera, Inc. 9111-A Research Boulevard Austin, TX 78758

Abstract Analyzing the performance of a complex System of Systems (SoS) requires a systems engineering approach. Many such SoS exist in the Military domain. Examples include the Army’s next generation Future Combat Systems “Unit of Action” or the Navy’s Aircraft Carrier Battle Group. In the case of a Unit of Action, a system of combat vehicles, support vehicles and equipment are organized in an efficient configuration that minimizes logistics footprint while still maintaining the required performance characteristics (e.g., operational availability). In this context, systems engineering means developing a global model of the entire SoS and all

© 2005 Stevens Institute of Technology, ISBN 0-615-12843-2 PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

component systems and interrelationships. This global model supports analyses that result in an understanding of the interdependencies and emergent behaviors of the SoS. Sandia National Laboratories will present a robust toolset that includes methodologies for developing a SoS model, defining state models and simulating a system of state models over time. This toolset is currently used to perform logistics supportability and performance assessments of the set of Future Combat Systems (FCS) for the U.S. Army’s Program Manager Unit of Action.

1. Problem Background Evaluating design concepts for a complex system of systems (SoS) is an immediate need for military systems like Future Combat Systems (FCS). This evaluation involves predicting SoS performance and identifying critical operational parameters across a broad trade space, presenting a multidimensional research challenge. Even for a single system, performance is characterized by several measures of effectiveness (MOEs). For FCS, the SoS level is defined to be a 1,000-platform Unit of Action (UA). Analyzing the performance of several design options for a complex SoS across external parameters and multiple MOEs generates a massive number of trade space combinations, producing extreme computational issues. Evaluation of performance at the SoS level is critical for FCS to achieve high performance objectives (e.g. minimum operational availability). SoS analysis requires predicting performance at the SoS level in contrast to the traditional platform-byplatform approach. SoS analysis must examine a multitude of design and technology options in order to optimize mission effectiveness across wide parameter spaces. The U.S. Army is facing the need to establish SoS performance requirements and translate these SoS requirements down to optimal or near-optimal individual platform requirements for system design and development. This challenge is further extended by the complexity presented with new technology. In this paper we will describe a set of tools used to address the complex needs of SoS analysis such as FCS. Section 2 describes the State Model Software and Section 3 describes the State Modeling Simulation.

2. State Modeling To develop an integrated modeling and simulation (M&S) environment, SyOp, a Sandia developed systems analysis and

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

optimization tool, was extended. Specifically, state modeling and time step simulation (described in the following section) capabilities have been added to the SyOp software. At the core of SyOp are fault trees, which are typically used to model a single system. State modeling provides an alternative approach to fault tree analysis that, while not replacing fault tree analsyis, will provide a more convenient way to model multiple system functions and a SoS. The new State Modeling Software (SMS) component of SyOp is comprised of a user interface and a state model interpreter. They act in concert to implement the concepts described in section 2.1. 2.1 Introduction and Background The State Modeling Software (SMS) component is based on traditional dynamic state modeling found in state charts (Harel and Naamad, 1996), also called activity charts. State charts are used to define a hierarchy of states and a means of moving from state to state. The status of systems and their functions can be determined based on which states are occupied. The design of the system can be such that if a command and control vehicle loses an axle, its mobility status moves from the mobile state to the immobile state, for example. If this latter state is occupied, the vehicle has no mobility. The SMS offers considerable flexibility for the design of state models. The user can provide as much or as little detail as desired for a system. Generally, the greater the number of detailed states the greater the potential flexibility. The mobility state for the command and control vehicle above can be broken down into states for axles, wheels, and engine parts. The finest level of detail is associated with failure events. When they occur, the failure events can trigger the move from one state to another. As required by SyOp, events must have numerical properties such as failure probabilities or failure rates.

The basics of state charts that are adopted by the SMS include: • A state model contains a hierarchical system of states. Each state is either a parent state or a leaf state, that is, one with no children. Each parent state is decomposed into its children either as an AND configuration or an OR configuration. If the system occupies an AND parent state, it must occupy each child state. If the system occupies an OR parent state, it must occupy exactly one of the children. So the OR in this case is an exclusive OR. If the system does not occupy a parent state, it cannot occupy any of its child states and vice versa. •

One state, called the root state, is the parent of every state. It is the only state in the model that does not have a parent.

•

The user must define a subset of the states as initial states. The system initially occupies each of these states, which cannot be conflicting. That is, for example, two children of an OR parent state cannot both be initial states.

•

The system transitions from one set of states to the next set one step at a time. It does so by taking user-defined transitions. Figure 2.1 shows a simple example. Transition X is characterized by a source state S, a destination state D, a guard G, and a trigger T. If at some step, the system occupies state S, the trigger T is true, and the guard G is true; then the system will transition from state S to state D. In general terms, a trigger activates a transition and a guard allows the transition. Both have to be true for the transition to fire. A transition can have a trigger, a guard, or both.

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

X(G, T) State S

State D

Figure 2.1 Transition from State S to State D •

The source state for a transition is the state from which the transition starts. It can be a parent state or leaf state.

•

Multiple destination states for a transition can exist, all of which must be leaf states. In traditional state charts, if a destination state is a parent state, the transition enters the destination state at a predefined default entry state. In the SMS, the default entry state is included as a destination state for the transition.

•

A trigger is a Boolean expression of events. The SMS determines which combinations of event occurrences cause the trigger to be true.

•

Events are at the level in the SMS that can be quantified. Currently, each event referenced in the trigger expressions must point to a failure mode in a SyOp data library. The failure mode must have either a failure probability or a failure rate and downtime.

•

A guard is a Boolean expression of states and external elements. If the system occupies a state in a guard expression, then effectively that state variable is set to true. The SMS determines which combinations of states will cause the guard to be true.

•

External elements are variables that can appear in guard expressions. They are assigned a Boolean value prior to the model run. An example might be a

sandstorm. For one run it could be assigned to true and another it could be assigned false. •

A goal state is a special state having particular meaning or consequence for reaching it. The primary function of the SMS is to determine what combinations of events had to occur for the system to reach a goal state.

The SMS adds the concept of functions to traditional state charts. Functions are linked to goal states so that each goal state indicates some degree of functionality of the systems in the state model. Each function is evaluated for a standard set of performance measures. It is the responsibility of the user to provide the interpretation of these performance measures in the context of the function. Figure 2.2 shows a simple system for a light. The parent states are blue and the leaf states are green. The decomposition of each parent is noted by the AND or OR to its immediate right. Transitions are labeled X1 through X4. Each transition either has a trigger T or a guard G. The Light state has two child states: it is providing illumination or it is not. Just one of these can be true. Illumination depends on the switch, the bulb, and the electrical power. All of these have a status at all times, so the Illumination state has an AND decomposition. The switch, bulb, and power components are either operable or inoperable. The three transitions on the right {X1, X2, X3} each have a trigger {T1, T2, T3}. Recall that a trigger can be any Boolean expression of events. A bulb could become inoperable if the filament fails, its contact point with the socket becomes corroded, the glass breaks, etc. At this level of detail, each of these events must be represented by a failure mode in a SyOp data library. If the event IDs are FILAMENT-FAILS, CONTACTCORRODED, and GLASS-BREAKS, then the trigger expression is

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

FILAMENT-FAILS ∪ CONTACTCORRODED ∪ GLASS-BREAKS Here the union symbol indicates the Boolean OR operator. It is the inclusive OR operator so if any of these events occur, the bulb becomes inoperable. Switch Operable OR

X1(T1)

Switch

Switch Inoperable

Bulb Operable

AND

Illumination OR OR

Light

X2(T2)

Bulb X4(G4)

Bulb Inoperable

No Illumination Power Operable Electrical Power

OR

X3(T3)

Power Inoperable

Figure 2.2 A State Model for a Light Alternatively there could be a single event named BULB-FAILS. It is associated with a failure mode in the data library and the trigger expression is simply BULB-FAILS. The level of detail is a user decision. Transition X4 has a guard, G4. Recall that a guard is a Boolean expression of states. It can also contain external element variables, but there are none in this simple example. The expression for the guard is Switch Inoperable ∪ Bulb Inoperable ∪ Power Inoperable The effect of this guard is that illumination will pass from its Illumination state to its No Illumination state if the light reaches any of its states Switch Inoperable, Bulb Inoperable, or Power Inoperable. There are four candidate goal states for this example: Switch Inoperable, Bulb Inoperable, Power Inoperable, and No Illumination. In the SMS the user can declare any subset of these as goal states. The SMS will evaluate each goal state specified in a

single run, i.e., for a single solution-build command. Results will include the probability of reaching each of the specified goal states (non-repairable model) or the frequency of reaching each of the specified goal states (repairable model). The complete set of results depends on the functions that are tied to the goal states. For a non-repairable analysis the user specifies what the probability of reaching the goal state means for its function. The No Illumination goal state is naturally linked to the operability function for the light. The probability of reaching this goal state is the probability that the light becomes inoperable. When this example is modeled as a repairable system, the standard performance measures would be interpreted as: • MTBF = mean time between those occurrences when the light becomes inoperable •

Downtime = the average downtime when the light becomes inoperable

•

Availability = the fraction of time that the light is operable

This interpretation can become more challenging for those cases when the function has intermediate levels. The static models developed using the SMS framework can be simulated over time using the System of Systems Simulation described in section 3. 2.2 Example Results The following example problem models three systems: a Non-Line-Of-Sight Cannon (NLOS-C), an unmanned aerial vehicle (UAV), and a forward spotter. They are linked by the fact that both the UAV and forward spotter can provide targeting information to the cannon. The potential targets for the cannon are on the order of 20km distant.

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

This example NLOS-C has the capability to fire smart bullets, similar to the 155mm Copperhead projectile, but smaller. The bullets have a guidance system and fins and they are capable of honing in on a target that has been painted by a laser. Thus if the target is marked by either the UAV or the forward spotter, it is assumed here that the target will be hit within 1m. This assumption implies, in part, that the bullet performs perfectly. Hence in this example we will not model the functionality of the bullet itself. The NLOS-C has five major functions that potentially affect its operability: Mobility, Sensing, Electrical, Lethality, and Communications. In this example, loss of mobility, electrical, lethality, or communications causes the NLOS-C to become inoperable. The sensing equipment is assumed to be passive (such as a glint detector) and is used for short-range targets. So even though the sensing function is included in the model for the NLOS-C, it does not affect its operability given the long range targets anticipated for this exercise. Also given the parameters of this exercise, the M240 machine gun that the NLOS-C carries does not affect the lethality of the NLOS-C. The UAV has four major functions that affect its operability: Mobility, Sensing, Electrical, and Communications. In this example, loss any of these four functions makes the UAV useless to the NLOS-C. Hence in this model, loss of any of the four functions causes the UAV to become inoperable. The UAV Inoperable state can then be incorporated into guard expressions for targeting transitions for the NLOS-C. Because of the high casualty risk involved, the army would prefer unmanned target detectors such as the UAV over the use of human spotters. The example problem will have states for spotter available and not available. If there is one available, the spotter will use a laser marker to pinpoint the target. If the laser marker is inoperable, the spotter

will use landmarks and a gridded map to estimate target coordinates. If precise targeting is unavailable the NLOS-C will fire dumb bullets. The circular error probable (CEP) for this case is estimated to be 150m. By incorporating all functions for each system into the model, the assumptions of the previous three paragraphs can be easily modified. In this case the required modifications are typically confined to guard expressions. Of particular interest in this example is the targeting function of the NLOS-C. The targeting function that falls under the lethality function for the NLOS-C has a special treatment in this example. The screen capture of the SMS displayed in Figure 2.3 shows the hierarchy of the states.

Figure 2.3 Targeting Function for the NLOS-C There are three transitions shown in the block of targeting states. Transition 58 originates in the Precise Targeting @ 20km state and points to the Targeting CEP 150m @ 20km state. The guard expression for the transition is UAV Inoperable & Spotter Operable & Laser Marker Inoperable. This implies that there is a spotter in place but his laser marker is inoperable and the UAV is inoperable so it cannot mark the target. Only in this circumstance will the model resort to the old-fashioned way of targeting. This

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

reduces targeting accuracy to a CEP of 150m at 20km. Transition 59 originates in the Targeting CEP 150m @ 20km state and points to the NLOS Targeting Inoperable state. The guard expression for the transition is Spotter Inoperable. So if the NLOS-C is already at reduced precision by relying on a spotter, it loses targeting totally if the spotter leaves the area or becomes disabled. Transition 63 originates in the Precise Targeting @ 20km state and points to the NLOS Targeting Inoperable state. The guard expression for the transition is UAV Inoperable & (No Spotter in Area OR Spotter Inoperable). This transition bypasses the reduced targeting state and goes straight to the no targeting state if the UAV becomes inoperable and either there was not a spotter in the area or the spotter was there and is now inoperable. In Figure 2.3 note that the Precise Targeting @ 20km state is marked as an initial state, whereas both the Targeting CEP 150m @ 20km state and the NLOS Targeting Inoperable state are marked as goal states. These two goal states are associated with the functions Targeting CEP 150m @ 20km and No Targeting. When the state model for the example problem is run the SyOp Results Viewer is automatically accessed. Figure 2.4 shows histograms for two of the functions.

to the multi-system simulation capability has been the development of a State Model Object (SMO) that enables a system, its elements, and its functionality to be encapsulated for use in the simulation. State Model Objects can be same objects that have been created in SMS or they can be created directly in the simulation application. The concept behind the multisystem simulation is illustrated in Figure 3.1.

State Model Object Controlling Simulation Software

Mobility Lethality Survivability Mission Probability ....

Environmental Conditions Terrain Use Conditions Supply Network

...

Figure 3.1 Concept

Figure 2.4 Histograms of Probability for the Targeting Functions The probability of operating at the CEP of 150m is much smaller than the probability of no targeting capability. Nominal probability estimates are summarized as follows: • Probability of operating at full accuracy ≅ 0.8749. •

Probability of operating at CEP 150m @ 20km ≅ 0.0041

•

Probability of no targeting ≅ 0.1210

3. System of Systems Simulation 3.1 Overview A major step toward performing complex SoS analysis has been the development of a multi-system time simulation capability. Key

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Multi-System

Simulation

Every system in the simulation is represented by an SMO which represents the system’s functionality while the controlling simulation software provides needed information on environmental conditions, terrain, use conditions, supply network information, etc. A simplified view of the SMO Simulation architecture is shown in Figure 3.2. The SMO is the central feature of the simulation with an SMO used to represent each system in the system of systems being simulated. There is a scenario model that describes the detailed scenarios that the systems will follow during the simulation. A combat damage model provides a mechanism to simulate the effects of combat damage including damage to individual system primary elements or completely disabling the system. Finally, a supplies and services model provides a means for spare parts and consumables to move from system to system in the simulation and makes maintenance services available to systems requiring repairs. The following sections discuss the components of the SMO Simulation.

Real Time Results System States Function States Scenario Completion Probability Status of Supplies ...

Scenario Model

Combat Damage Model

SMOs Representing Systems

Supplies and Services Model

Statistical Results Systems Availability by Platform Type Systems Availability in Force Structure Logistics Information ...

with two companies and each company has two platoons. The 99 systems are distributed throughout the force structure. System Type

Number

Command and Control (C2V)

7

Fuel Truck (FT)

8

Infantry Carrier Vehicle (ICV)

16

Figure 3.2 SMO Simulation Architecture

Non Line-of-Sight (NLOS-C)

3.2 The State Model Object

Reconnaissance and 16 Surveillance Vehicle (RSV)

The SMO can be configured to represent any of a very wide variety of systems. Examples of the types of systems that might be represented by the SMO include air vehicles, ground vehicles, manufacturing equipment, a soldier and the equipment he carries, etc. For modeling and simulation purposes, the SMO can be used to represent almost any system whose functionality can be described by the states of the system’s elements. The SMO is made up of a collection of elements that may be subsystems, components, failure modes, external conditions, or functional elements of other systems. The SMO can have multiple functions such as mobility, communications, sensing, lethality, etc. Furthermore, any function can itself have multiple states and is not restricted to success or failure. The state of any function is determined by the states of the elements that contribute to that function. Elements and functions of the SMO are described in the next two sections.

Unmanned Air Vehicle (UAV)

32

Parts Truck (PT)

2

Parts Depot (PD)

1

Forward Spotter (FS)

1

Table 3.1 Systems in the Example Problem Each system is represented as a state model object. The manned ground vehicles and the spotter all follow a scenario that consists of two segments – 72 hours of activity followed by a 432 hour replenishment interval. The UAVs have 2 hour flights every eight hours for the two 72 hour intervals of activity with a 24 hour replenishment interval in the middle. The parts depot has a single interval of 21 days of activity. All the manned ground vehicles have the following 5 functions: • Operability: This function includes all the capabilities considered necessary for the mission. •

Command and control: This function includes communications, computing, network and other control functions as appropriate to the platform.

•

Sensing: This includes all sensing capabilities available on the platform.

3.3 Example Results The results below pertain to a System of Systems simulation example problem consisting of a total of 99 systems with the types and numbers shown in Table 3.1. The force structure setup consists of a battalion

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Cannon 16

Mobility: This function includes every system element required for the platform to be able to move.

•

Lethality: This function takes into account any weapons on the platform and their control systems.

The UAVs have all the functions except lethality since they are assumed to have no weapons. The only consumable in the simulation is fuel which is used by all the manned ground vehicles. The next several figures illustrate the outputs that are currently available.

As systems fail, due to lack of operability, and are no longer available while awaiting repair, a measurement of the systems operational availability (Ao) can be computed. MGV Instantaneous Operational Availability 1

0.9 Instantaneous Ao

•

5th Percentile Mean 95th Percentile

0.8

0.7

0.6

0.5 0

3

6

9

12

15

18

21

Time (Days)

Figure 3.4 Operational Availability

Figure 3.3 Functions by System Figure 3.3 shows systems and their functions in real time as the simulation proceeds. The tree structure on the left side can be shown with the systems organized by system type as is the case in Figure 3.3 or the systems can be organized within the systemof-systems structure. All functions are shown for each system. When a system function fails, the green circle beside that function turns red. If the function is reduced to an intermediate state (partially operable), the circle turns yellow. The right side of the form shows the probability of successful operation of the selected function for the remainder of the mission. In Figure 3.3, we can see that the probability that C2V-001 will remain operable for the remainder of the mission is 0.74. Should C2V-001 lose operability, the most likely causes are shown in the Pareto chart.

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Figure 3.4 plots the instantaneous operational availability of the Manned Ground Vehicles after 200 replications. Systems fail during the 72 hour mission and are repaired steadily over the next three days. After three days, repairs are temporarily suspended while awaiting parts (e.g. a period of logistics delay time) and resume after delivery of parts. The plot is an estimate of how much time elapses until the MGV fleet returns to 100% operational availability.

4. Summary and Benefits of State Modeling The goal of this program was to develop an integrated modeling and simulation (M&S) environment that addresses the complex modeling and analysis needs of SoS like the FCS. The approach involves developing, enhancing and integrating state modeling methodologies and time simulation methodology for detailed concept and scenario analysis. The methodology has been applied to a FCS UA concept with significant programmatic success. State modeling and simulation offers several benefits:

•

•

A state model is quite flexible concerning the definition of states and transitions, in particular the trigger expressions for the transitions. In general the more states that are included the simpler the trigger expressions. On the other hand, the number of states can be reduced by defining more complex trigger expressions. If the detailed states are required because it is anticipated that they could be a goal state, it is important to include them in the state model detail. A state model can have multiple goal states. When the SMS builds a solution, the solution contains results for every goal state in the model. Results for all goal states can be displayed simultaneously using SyOp’s Results Viewer.

•

A state model can have different sets of initial states. Typically results are desired for the case when every system is initially in its fully operational state. On the other hand if some systems are inoperable or are partially operable, the user can define the initial states that way.

•

Goal states are not restricted to inoperable states. The state model can contain partially operable conditions.

•

A state model can contain multiple systems. Suppose a state model has 10 assault guns defined. What is the probability that 7 are operable at the end of a specified mission time? This question can be incorporated into a guard expression.

•

It is easy to incorporate dependencies between systems in a state model. Suppose that the targeting for an NLOS Cannon depends on coordinates fed to it from an unmanned aerial vehicle. If the UAV loses its mobility, its sensing capability, or its ability to communicate with the NLOS-C, it is no longer useful as

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

a targeting mechanism. By incorporating both systems into a single state model, it becomes easy to include the functions of the UAV into a guard expression for the NLOS-C. •

It is simple to incorporate external elements into a state model. The occurrence of bad weather, rough terrain, or turbulence, for example can be defined as an external element and incorporated into guard expressions.

References Akers, S. B., Binary Decision Diagrams, IEEE Transactions on Computers, Vol. c-27, No. 6, June 1978. Harel, D. and Naamad, A, The STATEMATE Semantics of StateCharts, ACM Trans. Soft. Eng. Method, 5:4, Oct. 1996. Helbig, J. and Kelb, P., An OBDDRepresentation of Statecharts, EDACETC-EUROASIC 1994, pp 142-149, 1994. Campbell, J. and Longsine, D. and Anderson, D.J. and Shirah, D., System of Systems Modeling and Analysis, SAND Report, SAND2005 0020, 2005

Biographies James E. Campbell, PhD Dr. Campbell is a Distinguished Member of the Technical Staff in the System Sustainment and Readiness Technologies Department at Sandia National Laboratories in Albuquerque, New Mexico. Prior to joining Sandia, Dr. Campbell was a vice president at a high technology consulting firm with offices in the United States, Canada, and Great Britain. Dr. Campbell received his PhD in physics from Virginia Polytechnic Institute and State University.

Dennis J. Anderson Mr. Anderson is a Principal Member of the Technical Staff in the Systems Sustainment and Readiness Technologies Department at Sandia National Laboratories in Albuquerque, New Mexico. He is currently the Principal Investigator for two Sandia projects: an internal research project developing systemof-systems (SoS) modeling and analysis methodology and a SoS Operational Availability Assessment project for the U.S. Army Future Combat Systems (FCS) program. He was the Principal Investigator on two previous FCS projects, a DARPA program and the Army’s Joint Virtual Battlespace (JVB) program, that involved reliability and sustainment modeling and analysis. Mr. Anderson is also one of the original developers of a state-space based modeling and analysis toolset currently being extended to model complex SoS and handle multiple measures of effectiveness (MOEs). Mr. Anderson received an M.A. in Mathematics (Applied Statistics option) from Arizona State University in Tempe, Arizona, and a B.A. in Mathematics from St. John’s University in Collegeville, Minnesota. Craig R. Lawton Mr. Lawton is a Senior Member of the Technical Staff in the System Sustainment and Readiness Technologies Department at Sandia National Laboratories in Albuquerque, New Mexico. Prior to joining this department Mr. Lawton was a member of the Operations Research and Computational Analysis group at Sandia for eight years. His primary experience base is simulation and optimization modeling in support of the Department of Energy. Mr. Lawton received his M.S. in Operations Research and Statistics from Rensselaer Polytechnic Institute. Donald N. Shirah Mr. Shirah is a Member of the Technical Staff in the System Sustainment and Readiness

PROCEEDINGS CSER 2005, March 23-25, Hoboken, NJ, USA

Technologies Department at Sandia National Laboratories in Albuquerque, New Mexico. Prior to joining Sandia, Mr. Shirah was a partner in Web Application hosting and design firm. Mr. Shirah received his BS Computer Information Systems from University of Maryland. Dennis E. Longsine, PhD Dr. Longsine is a Senior Scientist at INTERA, Inc headquartered in Austin, Texas where he has been an employee for the past 22 years. Prior to joining INTERA, Dr. Longsine worked for the Dikewood Corporation, then located in Albuquerque, New Mexico, as a consultant to Sandia National Laboratories. Dr. Longsine received his PhD in mathematics from Colorado State University in 1979.