Using Math to Defeat the Enemy

Preface

Many of the criticisms directed towards military simulations derive from an incorrect application of them as a predictive and analytical tool. The outcome supplied by a model relies to a greater or lesser extent on human interpretation and therefore should not be regarded as providing a ‘gospel’ truth. However, most game theorists and analysts generally understand this, it can be tempting for a layman—for example, a politician who needs to present a 'black and white' situation to his electorate—to settle on an interpretation that supports his preconceived position. Tom Clancy, in his novel Red Storm Rising, illustrated this problem when one of his characters, attempting to persuade the Soviet Politburo that the political risks of war with NATO were acceptable, used as evidence the results of a simulation carried out to model just such an event. It is revealed in the text that there were in fact three sets of results from the simulation; a best-, intermediate- and worst-case outcome. The advocate of war chose to present only the best-case outcome, thus distorting the results to support his case (Clancy, 1988).

There have been many charges over the years of computerized models being unrealistic and slanted towards a particular outcome. Critics point to the case of military contractors, seeking to sell a weapons system. For obvious reasons of cost, weapons systems (such as an air-to-air missile system for use by fighter aircraft) are modeled extensively on computers. Without testing of their own, a potential buyer must rely to a large extent on the manufacturer's own model. This might well indicate a very effective system, with a high kill probability (Pk). However, it may be the model was configured to show the weapons system under ideal conditions, and its actual operational effectiveness will be somewhat less than stated. The US Air Force quoted their AIM-9 Sidewinder missile as having a Pk of 0.98 (it will successfully destroy 98% of targets it is fired at). In operational use during the Falklands War in 1982, the British recorded its actual Pk as 0.78 (Allen T. B., 1987).

Human factors have been a constant thorn in the side of the designers of military simulations. Whereas political-military simulations are often required by their nature to grapple with what modelers refer to as "soft" problems, purely military models often seem to prefer to concentrate on hard numbers. While a warship can be regarded, from the perspective of a model, as a single entity with known parameters (speed, armor, gun power, and the like), land warfare often depends on the actions of small groups or individual soldiers where training, morale, intelligence, and personalities (leadership) come into play. For this reason, it is more taxing to model—there are many difficult-to-formulate variables. One valid criticism of some military simulations is these nebulous human factors are often ignored (partly because they are so hard to model accurately). Other perplexing issues include aggregation-disaggregation, communication networks, attrition, and end-game modeling.

“Using Math to Defeat the Enemy: Combat Modeling for Simulation” is intended to provide a foundation in the underlying combat modeling issues of military simulations. Of course, this is just a background, and a more rigorous treatment can be found in my book, Mathematical Modeling of Warfare and Combat Phenomenon (2011), Lulu.com, ISBN 978-1-4583-9255-8. Ultimately, this is a resource/reference book covering a wide gambit of military modeling issues.
This book is organized in two parts: Simulation (Part I) and Modeling (Part II). There are numerous practical applications and example models used in past and current military simulations.

This book is a result of about 25 years of use, application, research, and teaching military modeling and simulation. Much of the material in this book based on practical experience with modeling and simulation and extraction of my course notes from PowerPoint presentations.

Jeffrey S. Strickland, Ph.D.
CMSP, ASEP
President
Simulation Educators
Colorado Springs, Co
www.simulation-educators.com

Missile Flight Simulation - Preface

I recently published a new book, Missile Flight Simulation - Surface-to-Air Missile. The following is the preface fro the book.



In 1993, while teaching at the United States Military Academy, I was engaged in a post-Desert Storm reliability analysis of the Patriot missile system. My understanding of the dynamics of missile flight was limited, so I endeavored to educate myself. From 1994 through 2007, I began working on missile defense studies for the Department of Defense (DoD). In 2008, I began work for the Missile Defense Agency (MDA) on verification and validation of missile flight simulations and threat missile modeling. Over the course of the last five years, I have been compiling what I have learned into this book.
Chapter 1 provides background information is furnished regarding the need for missile flight simulations, and brief descriptions are given of their character, purpose, and implementation. The purpose, scope and organization of the book are described.
Chapter 2 describes in general terms the missile subsystems and functions that are important to the simulation of missile flight. These include in section 2-2 the subsystems of the physical missile-seeker autopilot, control, warhead and fuze propulsion, and airframe; in section 2-3 the various types of guidance; and in section 2-4 specific considerations of missile launch that are applicable to missile flight simulation.
An overview of missile flight simulation is given in Chapter 3. The four primary objectives of flight simulations-establishing requirements, designing and operating missiles, assessing missile performance, and training—are discussed. The essentials of simulating missile guidance and control and the motions of the missile and target are described; a discussion of the role of coordinate systems is included. Appropriate levels of simulation detail, to match simulation objectives, are discussed.
Chapter 4 begins development of the specific mathematical techniques employed in missile flight simulations. The approach discussed in the previous chapters includes calculating the forces and moments acting on the missile and substituting them into the equations of motion to yield vehicle accelerations. Chapter 4 expands on this approach by beginning with a more general statement of Newton’s second law of motion and proceeds through development of equations for translational and rotational motions, for expressing these equations relative to rotating reference frames, and for handling the gyroscopic moments of internal rotors.
Simulation of missile flight requires calculation of the forces and moments that act on the missile. The particular forces and moments contributed by aerodynamics are addressed in detail in Chapter 5. The various sources of aerodynamic data are discussed; representation of aerodynamic data in the form of force and moment coefficients is presented; and stability derivatives are defied. Methods and equations for employing the data in the calculation of the aerodynamic force vector F ?_A and the aerodynamic moment vector M ?_A are described. Effects of atmospheric properties-density, pressure, viscosity, and speed of sound---and of airflow parameters—Mach number and Reynolds number—on the aerodynamic forces and moments are discussed. Methods used to simplify the calculations are presented and special methods applicable to rolling airframes are described.
Chapter 6 briefly describes various types of missile propulsion systems and gives the detailed methodology for determining these force and moment vectors at each computational time step for solid propellant rocket motors. Consideration is given to the effects of initial propellant grain temperature, ambient atmospheric pressure, changes in mass and moments of inertia, and tube launch.
Chapter 7 describes mathematical techniques employed in missile flight simulations to calculate the motion of both the missile and the airborne target. Methods of combining the gravitational, aerodynamic, and propulsive forces (described in Chapters 4, 5, and 6) with the vehicle equations of motion (described in Chapter 4) are presented. Variations in the methodology for treating different numbers of degrees-of-freedom are described; and the equations for simulating simple target evasive maneuvers are given. A method of calculating the closest approach vector and the time of closest approach is provided.
Methods of simulating the guidance and control functions of a missile are described in Chapter 8. Since simulation methodology depends on the type of missile guidance system being simulated and on the objectives of the simulation itself, specific computational methods are given to meet different modeling requirements. The guidance and control functions considered are seekers, guidance processors, autopilots, and control systems.
Methods of modeling optical and radio frequency (RF) seekers are given for a wide range of fidelity levels. Lower levels of seeker fidelity are represented by perfect tracking and by accurate tracking but with a time lag. An intermediate fidelity seeker model—useful for analyzing the effects of multiple track points within the seeker field of view—is described. And for simulations that require the highest seeker fidelity, employment of actual missile seeker hardware in the simulation loop is described.
Equations are presented for modeling the guidance system processor at various levels of fidelity for both missile borne and ground-based target trackers. The types of guidance laws considered are proportional navigation, command, and command to line-of-sight. A method of employing a transfer function to simulate the control system response to guidance commands is described.
Missile hardware-in-the-loop simulations are discussed for two basic approaches to hardware substitution—missile seeker in the loop and missile electronics in the loop. Also employment of actual missile autopilot and control system hardware in the simulation loop is described. A checklist of special considerations of laboratory procedures for using hardware in the simulation loop is provided.
Requirements for simulating target scenes are described in Chapter 9. Three types are addressed: mathematical scenes for purely mathematical flight simulations, physical scenes for simulations that use seeker hardware in the simulation loop, and electronic scenes for simulations that use seeker electronic hardware in the simulation loop. Methods and equipment used to simulate the scene elements —target, background, and countermeasures—are described for both optical and radio frequency (RF) sensors.
Chapter 10 addresses (1) selection of a computer system suitable for implementing the equations and algorithms, (2) selection of a computer language to develop the simulation, (3) application of numerical techniques required for digital solutions, and (4) special instructions to operate missile flight simulations that contain missile hardware in the simulation loop.

Chapter 11 gives an overview of the processes required to ensure that a simulation represents actual missile performance to an acceptable level of confidence. Usage of the terms associated with verification and validation within the simulation community are discussed; and the need to tailor the validation effort to meet simulation objectives is emphasized, A range of possible methods of validating simulations is presented.
Chapter 12 employs an example to illustrate how the level of detail in a simulation is selected to satisfy simulation objectives, and to show how to synthesize a complete flight simulation by combining the subsystem models. MATLAB® and SimulinkTM are used to implement the model and execute the necessary simulation runs. Simulation results are presented and analyzed.

Shooter Games Part 3: Networked Virtual Simulation

America’s Army is a shooter game (or virtual simulator) that uses the User Datagram Protocol (UDP) protocol over Local, Metropolitan, or Wide Area Network (LAN, MAN, or WAN). This blog discusses various simulation and network protocols, and introduces America's Army. I taught a course for M&S professional development in 2006 entitled "Networked Virtual Simulation using America's Army." The notes for this course may be downloaded at Simulation Educators.

Networked Virtual Simulation
Networked Virtual Simulations typically cooperatively simulate real-world entities or systems. Each simulate some portion of "real-world." They exchange data via network messages using standardized protocols:

• Simulation, e.g., SIMNET, DIS, ALSP, HLA (see notes)
• Network, e.g., TCP/IP, VoIP, UDP (see notes)

Notes:

• SIMNET: Simulation Networking
• DIS: Distributed Interactive Simulation
• ALSP: Aggregate Level Simulation Protocol
• HLA: High Level Architecture
• TCP/IP: Transmission Control Protocol over Internet Protocol
• VoIP: Voice over Internet Protocol
• UDP: User Datagram Protocol

Distributed simulation protocol
A simulation protocol is the format and procedure that governs the transmitting and receiving of data. The term comes from the Greek "protokollon," which was the cover page to a manuscript that provided a description of the contents. Proto means “the first” and kolla means “to glue together.”

In order for computers to exchange information, there must be a preexisting agreement as to how the information will be structured and how each side will send and receive it. Without a protocol, a transmitting computer, for example, could be sending its data in 8-bit packets while the receiving computer might expect the data in 16-bit packets. Protocols are established by international or industry-wide organizations.

TCP/IP and Ethernet
The Transmission Control Protocol (TCP) is a virtual circuit protocol that is one of the core protocols of the Internet protocol suite, often simply referred to as TCP/IP. Using TCP, applications on networked hosts can create connections to one another, over which they can exchange streams of data. The protocol guarantees reliable and in-order delivery of data from sender to receiver. TCP also distinguishes data for multiple connections by concurrent applications (e.g., Web server and e-mail server) running on the same host.

Steel Beast is a highly accurate simulator of the US M1A1 and German Leopard 2A4 tanks designed to let you create and play scenarios of modern warfare. Scenarios can be played in either single-player mode against the computer, or in a multiplayer-mode against (and with) other players over a network. Steel Beast uses TCP/IP over a LAN. In 2002, I used Steel Beasts to train teams of US Military Cadets in Heavy/Mechanized Platoon tactics.

The TCP/IP Protocol
Are you there? Yes, I am. Are you ready to receive? Yes, I am. Here comes the message--blah, blah, blah-- did you get it? Yes, I did. Here comes the next part--blah, blah, blah-- did you get it? No, I didn't - resend it. Here it comes again-- blah, blah, blah-- did you get it? Yes, I did. There is no more. Goodbye. Goodbye.

The Ethernet Access Method
Is the network busy? Yes, it is. Wait random amount of time. Is the network busy? Yes, it is. Wait random amount. Is the network busy? No, it isn't. Here goes the frame... did it collide with another packet on the line? No, it didn't. Is the network busy? Yes, it is. Wait random amount. Is the network busy? No, it isn't. Here goes the next frame... did it collide? Yes, it did. Wait random amount. Is the network busy? No, it isn't. Here goes the frame again... did it collide?

User Datagram Protocol (UDP)
UDP, documented in RFC 768, provides users access to IP-like services. UDP packets are delivered just like IP packets, except they are connectionless datagrams that may be discarded before reaching their targets. UDP is useful when TCP would be too complex, too slow, or just unnecessary. UDP provides a few functions beyond that of IP:

• Port Numbers. UDP provides 16-bit port numbers to let multiple processes use UDP services on the same host. A UDP address is the combination of a 32-bit IP address and the 16-bit port number.
• Checksumming. Like IP, UDP does checksum its data, ensuring data integrity. A packet failing checksum is simply discarded, with no further action taken. However, in UDP the checksum is not required.
  

UDP protocol only has a length of eight bytes to be exact. That is twelve bytes less then TCP. Due to this, UDP is much faster as there is less to transmit. An extra twelve bytes may not sound like a lot, but multiply it by thousands of packets, and you will quickly notice a difference on your network. Seen as an UDP header is that much smaller, exactly what does it look like? See below for a diagram of what a UDP header looks like. So we can see from the above that not having the extra twelve bytes of overhead in the UDP header does indeed make a substantial difference. This would account for the lack of “connection orientation” for UDP. You may note, that we also have a checksum in the header for UDP. All of the four core protocols, those being; IP, TCP, UDP, ICMP all have checksums. In all of the four core protocols the checksum will cover the protocol header and any data, if present. One of the last things I would like to mention about UDP and its checksum is that its use is optional. In essence, it does not have to be used, whereas in TCP, ICMP, and IP, it does.

This protocol is connectionless, meaning when the server sends information to a connected player it does not wait for a confirmation that the information was received. This prevents the server from worrying about whether a connected player is receiving information or not. Have you ever played an online shooter game and found yourself eliminated before you knew you where threatened. Welcome to UDP--fast but unforgiving.

America's Army
America's Army (also known as AA or Army Game Project) is a tactical multiplayer first-person shooter owned by the United States Government and released as a global public relations initiative to help with U.S. Army recruitment.


Since July 4, 2002, America's Army has published 9 game releases; offering new game features and simulated training and missions. Each release has provided the America's Army community a virtual Army experience with a careful balance between authentic realism and virtual gaming fun.

The PC version, subtitled "Recon", was first released on July 4, 2002. Subsequently "Operations" was first released on July 12, 2002. Interim versions are listed below. The Xbox version was released in November, 2005. Version 2.8, "Coalition", debuted Dec 21, 2006 and has had many upgrades since Recon. It was financed through U.S. tax dollars and distributed for free. The latest version 3.0 "Special Forces" was released on June 17, 2009.

The Unreal Engine
The Unreal Engine is a widely-used game engine developed by Epic Games. First illustrated in the 1998 first-person shooter game Unreal, it has been the basis of many games since, including Unreal Tournament , Tom Clancy's Rainbow Six 3: Raven Shield, Red Steel , and Gears of War. Although primarily developed for first-person shooters, it has been successfully utilized in a variety of genres, including 3rd-person stealth (Tom Clancy's Splinter Cell) and MMORPG (Vanguard: Saga of Heroes).

Its core written in C++, the Unreal Engine features a high degree of portability, supporting a plethora of platforms including the IBM PC compatibles (Microsoft Windows, GNU/Linux), Apple Macintosh (Mac OS, Mac OS X) and many consoles (Dreamcast, Xbox, Xbox 360, Playstation 2, Playstation 3). A great deal of the gameplay code is written in UnrealScript, a proprietary scripting language, and as such large parts of the gameplay can be modified without delving deep into the engine internals. Additionally, as with other middleware packages, the Unreal Engine also provides various tools to assist with content creation, both for designers and artists.

Unreal Engine 2 (America’s Army v1.0 ~ v2.x)
The sophomore version of the Unreal Engine got off to a rocky start with the mixed reviews for Unreal Tournament 2003. This generation saw the core code and rendering engine completely re-written and the new UnrealEd 3 integrated. It also integrated the Karma physics software development kit (SDK), which powered the vehicles in Unreal Tournament 2004. Many other engine elements were also updated, with improved and added support for the PlayStation 2 and the Xbox, respectively.

Unreal Engine 3 (America's Army v 3.x)
In America's Army 3, Every Detail Counts and as a result, the game has more authentic military elements including training, technology, weapons, and audio than any other military game. Built on Unreal Engine 3, AA3 delivers stunningly realistic environments, lighting effects, animations, and team-based experiences so that America's Army players can experience how Soldiers train, live, and advance in the Army. Players are bound by Rules of Engagement (ROE) and gain experience as they navigate challenges in team-based, multiplayer, force-on-force operations. In the game, a player's actions and demonstrated Army values are integral to successful mission accomplishment and affect a player's career progression.


Version History

• America's Army 3: (version 3.0.7) 18 FEB 2010
• AA3.0.6 Hot Fix Released (v3.0.6 Hot Fix) 17 SEP 2009
• AA3.0.6 Update Released (v3.0.6) 07 SEP 2009
• AA3.0.5 Update Released (v3.0.5) 13 JUL 2009
  
• America's Army 3: Patch (Version 3.0.4) 03 JUL 2009
  
• AA3.0.3 Hot Fix Released (v3.0.3) 24 JUN 2009
  
• AA3.0.2 Hot Fix Released (v3.0.2) 19 JUN 2009
  
• AA3.0.1 Hot Fix Released (v3.0.1) 18 JUN 2009
  
• America's Army 3 PC Action Game (v3.0.0) 17 JUN 2009
  
• America's Army : Special Forces (Overmatch) (Version 2.8.5) April 30th 2009
  
• America's Army : Special Forces (Overmatch) (Version 2.8.4) October 6th 2008
  
• America's Army : Special Forces (Overmatch) (Version 2.8.3.1) March 25th 2008
  
• America's Army : Special Forces (Overmatch) (Version 2.8.3) January 31st 2008
  
• America's Army : Special Forces (Overmatch) (Version 2.8.2) Septmber 6th 2007
  
• America's Army : Special Forces (Overmatch) (Version 2.8.1) March 22nd 2007
  
• America's Army: Special Forces (Coalition) (version 2.8) December 21st 2006
  
• America's Army: Special Forces (Overmatch) (Version 2.7.0) September 14th 2006
• America's Army: Special Forces (Link-Up) (Version 2.6.0) February 8th 2006
• America's Army: Special Forces (Direct Action) (Version 2.5.0) September 6th 2005
• America's Army: Special Forces (Q-Course) (Version 2.4.0) May 18th 2005
• America's Army: Special Forces (Firefight) (Version 2.3.0) February 18th 2005
• America's Army: Special Forces (Vanguard) (Version 2.2.1) November 18th 2004
• America's Army: Special Forces (Vanguard) (Version 2.2.0) October 19th 2004
• America's Army: Special Forces (Downrange) (Version 2.1.0) June 1st 2004
• America's Army: Special Forces (Sandstorm) (Version 2.0.0a) December 21st 2003
• America's Army: Special Forces (Version 2.0) November 6th 2003
• America's Army: Operations (Medics) (v1.9.0)) 08 AUG 2003
• America's Army: Operations (Bridge SE) (v1.7.0) 21 APR 2003
  
• America's Army: Operations (Radio Tower) (v1.6.0) 16 MAR 2003
  
• America's Army: Operations (Weapons Cache SE) (v1.5.0) 23 DEC 2002
• America's Army: Operations (River Basin) (v1.4.0) 25 NOV 2002
  
• America's Army: Operations (Mountain Pass) (v1.3.0) 10 OCT 2002
  
• America's Army: Operations (Map Pack) (v1.2.1) 03 OCT 2002
• America's Army: Operations (Airborne Pack) (v1.2.0) 22 AUG 2002
• America's Army: Operations (Marksmanship Pack) (v1.1.1) 01 AUG 2002
  
• America's Army: Operations (v1.0.1b) 05 JUL 2002
  
• America's Army: Recon (v1.0.0) 04 JUL 2002
  

Deer Valley Ranch

Deer Valley Ranch 07/24/2010

0 Comments

Edit | Settings | Delete

Are you sure you want to delete this post? This action is permanent. Yes, delete postNo, keep post

I just returned from a week at Deer Valley Ranch, Colorado. While there I started my latest book, "Discrete Event Simulation with ExtendSim8". I am now sitting in my living room on the prairie of Colorado's eastern slopes of the Rocky Mountains. As I look out at my unobstructed view of Pike's Peak, I ask myself, "How could anyone ever simulate this?". I would never try. Nevertheless, I hope this new book will help with simulation of those things that we can simulate.

SIMNET

SIMNET was a wide area network with vehicle simulators and displays for real-time distributed combat simulation: tanks, helicopters and airplanes in a virtual battlefield. SIMNET was developed for and used by the United States military. SIMNET development began in the mid-1980s, was fielded starting in 1987, and was used for training until successor programs came online well into the 1990s.

At the time SIMNET was fielded in 1987, I was the commanding officer of K Troop, Second Armored Cavalry Regiment (2ACR) in Amberg, Germany, during the Cold War. My tank platoons were the first to train in SIMNET at Grafenwohr, Germany. Surprising me, the white cell (or controller) hardware consisted of Macintosh Plus computers (I bought my first Mac in 1986). Our SIMNET experience was followed by a successful tank platoon live fire exercise.

SIMNET was developed by three companies: Delta Graphics, Inc.; Perceptronics, Inc.; and Bolt, Beranek and Newman (BBN), Inc. There was no prime contractor on SIMNET; independent contracts were let directly to each of these three companies. BBN developed the vehicle simulation and network software, as well as other software such as artillery, resupply, and semi-automated forces often used for opposing forces. Delta Graphics, based in Bellevue, Washington, developed the graphics system and terrain databases. Delta Graphics was eventually bought by BBN. Perceptronics, based in Los Angeles, was responsible for the actual SIMNET simulators; the company's engineers, human factors personnel and manufacturing team designed, developed and built over 300 full-crew simulators, integrating the controls, sound systems and visual systems into the special simulator shells; they also installed the simulators in a number of facilities in the US and Germany, trained the operators and supported the system for several years.

The major software components of SIMNET have become almost standard fare among distributed simulators today:· The Network Interface allows the software to interoperate with other simulators on a computer network.· The Image Generator Software creates the beautiful full-color images that present the scenario to the training audience.· A Controls & Displays Interface covert digital information from the computers into information that can be displayed on instruments in the vehicle. They also transform trainee input into digital signals that can be processed by the simulation computers.· The Other-Vehicle State Table tracks the state data on the other vehicles in the scenario.· Own Vehicle Dynamics software is used to model the vehicle in which the trainee is sitting. This software generates vehicle movement, firing, and communication.· The Sound Generator recreates the deafening sounds of combat - the roar of tank engines, the clanking of tracks against the terrain, the firing of munitions, and the explosions of incoming rounds.

SIMNET, along with the tank crew trainer UCOFT simulator, helped make K Troop, 2ACR, one of the top two tank units in the United States Army Europe.

Foreword to Fundamentals of Combat Modeling

As an assistant professor of mathematics at the United States Military Academy at the turn of the century, I was teaching applied mathematics for systems engineering and systems engineering management majors. I really had thought a great deal about the complexities of combat modeling, other than the applications I had used in teaching calculus and differential equation and applied as an Army Operations Research Analyst. That changed in the summer of 2002 when I began writing a curriculum and teaching combat modeling at the Army's premier entry level Operations Research course, and started developing a set of course notes for combat modeling.

As I transitioned from the military and moved into chief scientist and engineer roles in the defense industry, I was continually challenges to expand my understanding of combat modeling, as I supported the Army’s Future Combat Systems program. I also continued to expand the course notes I had started in 2002. When I finally found a way to move to Colorado (God’s country), it was as a contractor supporting the Missile Defense Agency (MDA), providing technical direction for the Ballistic Missile Defense System (BMDS) Threat Modeling Center.

A little over 18 months ago I started out on the adventure of compiling my course notes into a published textbook. I was recovering from a pulmonary embolism and had a lot of time to reflect on issues in combat modeling. As I write this foreword, I am recovering from a second pulmonary embolism, and I have lots of time to reflect on the people who helped me arrive to this point in my life.

First and foremost, I could not have written this without my Lord and Savior Jesus Christ. I know that may sound corny to those untouched by His hand, but I literally would not be here without His miraculous intervention. When I was in the valley, he lifted my eyes to the hills. The most prominent person on the hills was my bride of 28 years. Laurie is my best friend, my biggest supporter, and my greatest critic. When I look back, I see that she was right behind me in those valleys, helping me along my way. Thanks!

Dr. Bob Simmonds hired me to be the director of the Operations Research and Systems Analysis Military Application Course (ORSA MAC) I, without having met me. He took a chance on me and my wild ideas about operations research and teaching. He is a dear friend and supporter to this day.

Kent White and Skip Songy were fellow Spartans (now Cobham Analytics), intelligent colleagues and endearing friends. They had faith in me when others did not understand me.

Dr. Mikel Petty is the Director of the Center of Modeling, Simulation and Analysis (CMSA) at the University of Alabama in Huntsville (UAH). He likewise took a chance on me and I was employed by him for a short time. He remains a colleague and supporter.

John Pace and Wayne Grissom are friends, colleagues, and mentors in the BMDS Threat Modeling Center. They have allowed me to bring my experience to bear and have supported my every breath.

Dr. Roger Smith is a colleague whom I greatly respect. Roger encouraged me to publish my writings.

Joe Kier is my best friend and mentor. Joe showed me what right looks like.

Mariah and Evie are two little joys in my life. Together with Laurie, they provide my inspiration.