ASUG_v4.1_Final.pdf.pdf

Advanced Joint Effectiveness Model (AJEM) Standard Usage Guidance (ASUG) for JTCG/ME Studies

Revision 4.1

November 2011

DISTRIBUTION STATEMENT C: Distribution authorized to U.S. Government agencies and their contractors; operational use; 30 April 1999. Other requests for this document must be referred to Director, AMSAA, Attn: AMXSY-J, Aberdeen Proving Ground, MD 21005-5071.

DESTRUCTION NOTICE: For unclassified, limited documents, destroy by any method that will prevent disclosure of contents or reconstruction of the document.

Table of Contents

1.0 Introduction

2.0 Overview

2.1 AJEM Description

2.2 AJEM Analysis Process Overview

2.3 Using this Document

2.4 Guidance Overview

2.5 Analysis Process Perspective

3.0 AJEM Input Files

3.1 AJEM Basics

3.2 Target Related Files

3.2.1 BRL-CAD File

3.2.2 Geometry File

3.2.3 Region Map (regions) File

3.2.4 Package (pack) File

3.2.5 Component Category Map (ccmap) File

3.2.6 Damage Evaluation Selection (des) File

3.2.7 Evaluation Curve (ecurve) File

3.2.8 Blast Model Interpolation Table (bcurve) File

3.2.9 Interaction Module Interpolation Table (icurve) File

3.2.10 Parameters (params) File

3.2.11 Material Properties (matprop) File

3.2.12 Component Properties (prop) File

3.2.13 System Definition (sysdef) File

3.2.14 States File

3.3 Weapon Related Files

3.3.2 Penetration (pen) File

3.3.3 Profile Hole Diameter (phd) File

3.3.4 Perforation (perf) File

3.3.5 Range File

3.4 Auxiliary Files

3.4.1 Indirect-fire Module Select (IFMSelect) File

3.4.2 IFMData Interpolation Table File

3.4.3 View File

3.5 Session (or Controls) Files

3.5.2 Session File

4.0 Environment Variable Settings

5.0 Modkey Settings

6.0 AJEM Output Requirements for JTCG/ME Vulnerability Analyses

6.1 Introduction

6.2 General Guidelines for JTCG/ME Outputs

6.3 Target Presented Area (Ap)

6.4 Total Target Vulnerable Area (AV) and Probability of Exposure (Pe)

6.5 Shielded Component AV

6.6 Vulnerability Centroids

6.7 Cell-by-Cell Probability of Kill Given a Hit (Pk|h)

6.8 JGEM Pk|h Curves

6.9 SFW-P3I Average Pk|h

7.1 Execution Overview

7.2 General Project Guidance

7.3 Weapon Specific Summary

7.3.1 Generic Fragment Weapon Input

7.3.2 HEI Weapon Input

7.3.3 AP/API Weapon Input

7.3.4 SC Weapon Input

7.3.5 KE Weapon Input

7.3.6 EFP Weapon Input

8.0 Revision History

Appendix A: References Appendix B: Glossary

Figure List

Figure 2.2-1: AJEM/MUVES-S2 Analysis Process Figure 2.4-1: Analysis Domains Figure 2.4-2: Analysis Domains Figure 3.1-1: Basic AJEM Inputs Figure 3.1-2: Relationships of Target Inputs to Vulnerability Analysis Process Figure 3.1-3: Relationships Between Threat, Auxiliary, and Session Files Figure 3.2-1: Input File Organization Figure 6.7-1: Sample Target Cell-by-Cell Pk|h Results for Target Technical Reports

Table List

Table 3.2.1-1: ID Numbering Convention for Rotary Aircraft Table 3.2.1-2: ID Numbering Convention for Fixed Wing Aircraft Table 3.2.1-3: ID Numbering Convention for Ground-Mobile Vehicles Table 3.2.1-4: ID Numbering Convention for Small Boats Table 3.2.2-1: Geometry File Settings Table 4.0-1: Environment Variable Settings Table 5.0-1: Modkey Settings Table 7.3.1-1: Generic Fragment Execution Summary Table 7.3.2-1: HEI Execution Summary Table 7.3.3-1: AP/API Execution Summary Table 7.3.4-1: SC Execution Summary Table 7.3.5-1: KE Execution Summary Table 7.3.6-1: General EFP Execution Summary for Most Targets Table 7.3.6-2: SFW-P3I EFP Execution Summary for Small Boats

1.0 Introduction

The objective of this document is to provide guidance for Joint Technical Coordination Group/Munitions

Effectiveness (JTCG/ME) funded production analysis teams to execute Advanced Joint Effectiveness Model

(AJEM) in support of JTCG/ME production analysis efforts. This document is intended to serve as a product-focused "best practices" guide for AJEM Lethality/Vulnerability (L/V) analyses of light, medium, and heavy ground mobile targets; boats; and fixed- and rotary-wing aircraft targets. It includes guidelines for conducting

AJEM analyses, a matrix of standard analysis inputs, direct and post-processed analysis outputs, and suggested reporting formats. In addition, a quick-start section is provided for use as a reference or to jump-start the guidance application for JTCG/ME analyses.

The JTCG/ME continues to fund a number of production vulnerability analyses each year using AJEM. To accomplish this effort the JTCG/ME distributes work among several production analysis teams. Considering that AJEM is being used for these production analyses and that multiple independent teams are being used to conduct the analyses, the JTCG/ME recognizes that establishing a means of ensuring the consistent, credible, and cost-effective production of AJEM inputs and results is critical. As such, the JTCG/ME plans to ensure that the tasks are conducted in a consistent manner using standardized methods for generating and using input data and consistent approaches for the conduct of the assessments. The JTCG/ME also plans to ensure that requirements and standards for conducting data reviews (for both inputs and outputs) and for the production of reports and assessment products are clearly defined and followed. These elements are essential for quality assurance and consistency in the results.

The guidance provided in this document represents a broad coordinated effort within the JTCG/ME community.

Key participants include representatives from the JTCG/ME Coordinator's Office, JTCG/ME Working Groups, Government AJEM users, Oklahoma State University (OSU), and JTCG/ME contractors responsible for the development and configuration management of AJEM.

This document is not intended to be a standalone reference for all analysis requirements, or a substitute for specific direction from a task sponsor or statement of work. This document is intended to be used in conjunction with guidance from the Joint Service Target Data Standardization Group (JSTDSG), the JTCG/ME publication 61 JTCG/ME 1-8, and the AJEM User/Analyst Manual. Additional guidance shall be provided on the Joint Product and Information Access System (JPIAS) site being maintained by OSU that is available via the SIPRNET.

In cases where deviations from the guidance provided herein are necessary, coordination of these deviations through the task sponsor to the JSTDSG is important. Documentation, including rationale for deviations, is required for program reviews, program approval procedures, and for inclusion in the task final report.

This document will evolve as circumstances arise that are not currently addressed and as AJEM capabilities are enhanced. Modifications and additions are also anticipated as new weapons, targets, and weapon/target pairings are introduced that are of interest to the JTCG/ME. It is recommended that JTCG/ME production analysis teams access the JPIAS site for the most up-to-date guidance, modifications, and additions. Additional recommendations for additions and/or modifications should be coordinated through the JTCG/ME Analytical

Models & Methodology Group by submitting Software Change Requests (SCRs) through the AJEM website at www.ajem.com (under the "Documentation" module).

It is assumed the reader has a reasonable knowledge of vulnerability analysis techniques and concepts using

AJEM. Therefore, this reference will not discuss the details of conducting a vulnerability analysis or serve as a duplicate of the AJEM manual. Rather, it will provide guidelines specific for JTCG/ME analysis using AJEM.

Although the guidance is driven by a combination of target and weapon considerations, the weapon considerations tend to exert the greatest influence over the input and post-processing requirements. Therefore, the guidance is segregated according to weapon categories. The following categories are intended to facilitate the skimming of this document.

Required: identifies JTCG/ME mandated guidance. These are objective settings which will be confirmed by the JSTDSG during analysis review. Some items, such as behind armor debris, are only required in specific situations.

Recommended: identifies a recommended practice. Typically, this implies there are multiple correct ways of accomplishing the same thing. Recommended practices are intended to introduce consistency across all JTCG/ME analyses.

Optional: identifies an optional feature for which there is no specific JTCG/ME guidance but is included for the user to be aware that the option exists.

Note: identifies an important note. These may highlight items that are not intuitive or discuss some of the potential AJEM “gotchas”.

2.0 Overview

2.1 AJEM Description

AJEM was designed to be a DoD standard computer simulation for evaluating the lethality and terminal effectiveness of munitions and the vulnerability of a single rotary-wing aircraft, fixed-wing aircraft, missile, small boat, or ground-mobile system, to include battle damage assessment and repair (BDAR). It combines elements of target modeling, weapon modeling, encounter kinematics, generation of weapon burst points, propagation of damage mechanisms to the target, evaluation of damage (penetration, fire, blast, etc.), target and sub-system response (functionality, redundancies, etc.). AJEM produces results that are designed to be applicable during all phases of weapon system acquisition - from research, design, and development to production test and evaluation. AJEM is capable of producing results which are observable and measurable for testing and real-world events such as component and system loss of function, and can also produce more abstract metrics such as vulnerable area. For more information, reference the Software Development Plan

(SDP) [Ref. 1] and the System Requirements Specification (SRS) [Ref. 2].

AJEM is designed to run in conjunction with Ballistic Research Laboratory Computer-Aided Design (BRL-

CAD) and the MUVES-S2 environment [Ref. 3], capitalizing on work already performed by the Army Research

Laboratory (ARL)/Survivability/Lethality Analysis Directorate (SLAD).

2.2 AJEM Analysis Process Overview

In order to analyze the probable outcomes of an encounter between a target and a weapon, AJEM uses a series of data files to describe the target, weapon, and initial conditions of the interaction as shown in Figure 2.2-1.

For kinetic energy weapons, this means defining the impact direction, weapon speed, etc.

Figure 2.2-1: AJEM/MUVES-S2 Analysis Process

A weapon input file (or series of files, depending on the system) contains a description of the initial condition of the weapon in terms of its physical characteristics, such as mass, velocity, length, diameter, etc. The weapons are referred to as threats in AJEM, and the two terms used interchangeably throughout this document. Several target input files are used to describe the geometry, criticality, and functionality of the combat system (i.e., target) being analyzed. The geometry is stored in BRL-CAD format. The BRL-CAD file is accompanied by a text file that assigns physical characteristics such as material type, density, hardness, etc., to each geometric region in the target description. Geometric regions are grouped into components, which are themselves grouped into categories. A component's category (e.g., component, fluid, etc.) determines how the component is analyzed. Combinations of critical components compose target system definitions (i.e., fault trees), which are used to measure the resulting target response to a weapon.

Each weapon is initially assigned a weapon path which contains an origin, direction, and weapon packet, which describes the current weapon conditions. The weapon path is passed to the raytracer to compute intersections with the target geometry. If the weapon path interacts with a target component, the component's category determines an appropriate Interaction Module (IM) to be used. An IM is responsible for calculating the results of the interaction, which could be a degraded (or defeated) weapon, a redirected weapon path, a damaged component, or the production of secondary weapons (i.e., spall, broken weapon pieces, etc.). Unless defeated, a degraded or redirected weapon continues to interact with subsequent target geometry until it exits the target. If secondary weapons are created, they are assigned initial conditions and a weapon path and likewise passed to the raytracer. This recursive process continues until the weapon and all subsequent weapons it has created have been exhausted. Note: There are several differences in how MUVES propagates the weapon through the target description when compared to COVART 4.0. First, MUVES performs shotlining on-the-fly, and is capable of altering the trajectory of the weapon as it penetrates into the target. Second, MUVES can generate and trace additional weapons such as spall or broken projectile pieces. Third, MUVES traces all of the damage-producing weapons before calculating the results of the damage.

An IM records damage to a component in a damage packet for later evaluation after all weapon interactions have been exhausted. Damage packets are expressed in terms of physical parameters, such as the hole diameter of the impacting weapon, energy deposited, hit location, etc. When damage evaluation occurs, the damage packets are sorted by component and an Evaluation Module (EM) is called. An EM is responsible for combining multiple damage packets to produce a user-defined metric of the functionality of the component.

Possible metrics (as defined in the states file) include probability of kill (Pk), hit/not-hit, and binary kill states

(killed/not killed). This process can be represented by a damage vector (list of damaged components), which can be used with a system definition (fault tree) to produce a degraded capability vector (result).

The results from each weapon/target interaction are stored in a final results file. This file is generally post-processed into tables, cell plots, and other formats suitable for review, for inclusion within an analytical report, or for use in endgame and/or force-level models.

2.3 Using this Document

This document provides guidance to assist in the consistent use of AJEM in support of JTCG/ME analyses. The report is divided into the following subsections:

Input Files

Environment Variable Settings

Modkey Settings

Assessment Parameters

Output Requirements

Execution Guidelines

The Input Files section provides a brief overview of every AJEM input file, and identifies specific inputs, and recommended practices (where possible/practical) that should be used when constructing these inputs.

The sections on Environment Variable Settings and Modkey Settings provide a listing of every environment variable and modkey option available within AJEM and identifies recommended values (where possible/practical) to use within the AJEM/MUVES-S2 session file. These environment variable and modkey settings should be used unless otherwise directed by JTCG/ME.

The Assessment Parameters section identifies the encounter-specific guidance for JTCG/ME analyses, to include velocities, attack aspects/views, and grid cell sizes.

The Output Requirements section identifies the various outputs to be generated to support JTCG/ME analyses, and the format of this data. These requirements have been coordinated with the JTCG/ME Working

Groups. Specific AJEM post-processors are identified that can be used to automatically (or semi-automatically) generate these outputs.

The Guidance Summary section acts as a reference as well as a quick start guide for conducting JTCG/ME vulnerability analyses.

2.4 Guidance Overview

The AJEM usage guidance that has been developed for JTCG/ME production analyses and is presented in this document was based on three important principles.

A. The guidance is intended specifically for the weaponeering domain.

Modeling and Simulation can be applied to a number of weapon effectiveness domains. For example, Figure

2.4-1 illustrates that AJEM may be used to support both weaponeering and Live Fire Test and Evaluation

(LFT&E) activities.

Figure 2.4-1: Analysis Domains

AJEM can easily be used to support either of these two domains. However, since the end usage of the results varies, the selection of execution options and the rationale for selecting these options also varies. While much of the guidance presented in this JSTDSG document may also be appropriate for other domains, the intended use of this guidance is for weaponeering analyses.

B. The guidance is intended to provide objective checkpoints for the JSTDSG.

The JSTDSG is tasked with reviewing and approving the JTCG/ME L/V analyses. Therefore, this guidance is intended to provide concise guidance to both the JSTDSG and the responsible analysis organizations as illustrated in Figure 2.4-2. Deviations from this guidance would need to be coordinated and justified with the

JSTDSG.

Figure 2.4-2: Analysis Domains

C. The guidance will be modified in the future.

The guidance rationale was first considered from the perspective of identifying the ideal analysis techniques for weaponeering purposes. The guidance was translated into AJEM specific options. In some cases, AJEM does not currently support the ideal techniques. In these cases, the best available solution was identified to support immediate analyses. If the desired technique is later implemented in AJEM the guidance will also be modified.

Similarly, there were certain options for which an ideal setting could not be determined without detailed sensitivity studies. In these cases, either the default value or a historically used value may have been recommended; guidance of this nature may also be modified in the future.

Note: Analyst should check JPIAS for latest guidelines before beginning any analysis for JTCG/ME.

2.5 Analysis Process Perspective

The L/V activity, for which this guidance is intended, is a part of the larger weapon effectiveness estimation process. Therefore, an understanding of how the L/V data is applied is necessary to define the AJEM guidance.

The transition toward a target-centric analysis process, in which all targets are analyzed consistently for all weapons, has not been extended to delivery accuracy simulations. Therefore, a variety of weapon-dependent methodologies are currently used to estimate effectiveness metrics, and the L/V results must be tailored to the appropriate requirements. The L/V analysis results will be used to produce effectiveness estimates for

JTCG/ME using the following tools:

Joint Mean Area of Effects (JMAE)

Passive Vehicle Target Model (PVTM)

Joint Surface Endgame Model (JSEM)

Joint Gun Effectiveness Model (JGEM)

Joint Smart Weapons Module (JSWM)

3.0 AJEM Input Files

3.1 AJEM Basics

There are four basic types of inputs required by AJEM as illustrated in Figure 3.1-1 below. They are:

Targets – The target input is comprised of several files which provide physical, functional, and criticality descriptions.

Threats – The threat (weapon) inputs are used to describe the damage mechanism characteristics for each weapon system. The number of files required varies according to the weapons(s) to be analyzed.

Auxiliary – The auxiliary input files generally provide additional information on the weapon and target orientation / interaction. This includes the definition of attack aspects (azimuths and elevations), range and/or velocity bins, and special damage mechanism / component interactions to be evaluated.

Sessions – The session input file describes the specific AJEM execution parameters for the analysis.

These include the specific system, component, and target damage metrics to be reported. The session file also defines the specific methodologies or methodology options to use.

Figure 3.1-1: Basic AJEM Inputs

Figure 3.1-2 below expands on the AJEM target inputs and relates their function to a conceptual target vulnerability analysis process. The AJEM User Manual contains documentation on these inputs for an experienced analyst to understand their usage and development. It is important to note there are several means of achieving the same end in describing the target inputs. Section 3.2 provides the recommended practices for consistent JTCG/ME analyses.

Figure 3.1-2: Relationships of Target Inputs to Vulnerability Analysis Process

The remaining inputs elements (threats, auxiliary, and session files) are all related and depend on the nature of each individual weapon to be analyzed. This is illustrated in Figure 3.1-3 below. Therefore, the individual weapons are the driving force behind the AJEM guidance that is presented in this document. For this reason, the individual weapons are grouped into classes according to their AJEM requirements in later sections of this document and the specific instructions are provided for each weapon class or individual weapon.

Figure 3.1-3: Relationships Between Threat, Auxiliary, and Session Files

3.2 Target Related Files

There are a number of input files required for an AJEM analysis, the organization of which is shown in

Figure 3.2-1. Some are required and some are not. Others are required only if specific methodologies are being used. The following subsections briefly describe each input file, typical use, and recommendations for specific input values and/or other areas for standardization (if practical).

Figure 3.2-1: Input File Organization

Orientation /

Execution

Orientation /

Execution

TargetTarget

Component Component Component

Functional Description Files sysdef states

Physical Description Files mged databasegeometry regions matpropprop

Criticality Description Files ccmap des pack ecurve / bcurve params

Weapon/Threat Description Files initial phd perf frags range

Analysis Description Files sessionIFMSelect encounter

IFMData view weapon_encounter target_encounter

Weapon/ThreatWeapon/Threat

Not used for JTCG/ME

Ground Mobile Analyses

Required (Generally)

Threat/Target Dependent

Orientation /

Execution

Orientation /

Execution

TargetTarget

Component Component Component

Component Component Component

Functional Description Files sysdef states

Physical Description Files mged databasegeometry regions matpropprop

Criticality Description Files ccmap des pack ecurve / bcurve params

Weapon/Threat Description Files initial phd perf frags range

Analysis Description Files sessionIFMSelect encounter

IFMData view weapon_encounter target_encounter

Weapon/ThreatWeapon/Threat

Not used for JTCG/ME

Ground Mobile Analyses

Required (Generally)

Threat/Target Dependent

3.2.1 BRL-CAD File

The Target Geometry Model (TGM) file contains the binary .g file in BRL-CAD format. Each component is represented by one or more geometric primitives that are grouped together into "regions." Each region is assigned an identification number. This ID can be referenced by AJEM much like other vulnerability models.

Guidelines for developing a Target Geometry Model (TGM) are provided in Target Description Standards for

Ballistic Survivability, Lethality, and Vulnerability Analyses of Ground Mobile Vehicles and Aircraft [38].

Guidelines from that document that are specific to JTCG/ME are provided below.

Required:

A reference point, or origin, must be defined in the target description and is (0, 0, 0). All target descriptions created with MGED use the X, Y, Z right-handed coordinate system (RCS), which states that +X is “forward,” + Y is “left,” and +Z is “up.” Logically following, –X is “backward,” –Y is

“right,” and –Z is “down.” The RCS is the default coordinate system utilized throughout this document, unless otherwise noted, and should be considered the standard coordinate system to use in target describing.

The origin of a ground vehicle should be the intersection of the ground surface at the midpoint along the left-right midplane of the vehicle. Origin along the x-axis should be placed at a convenient location such as the front bumper, rear bumper, center of turret ring, or overall center of vehicle. The origin for aircraft should be located on the front nose at the midpoint along the left-right midplane of the aircraft.

The origin for small boat targets should be along the left-right midplane of the boat. Origin along the x-axis and z-axis should be placed at a convenient location such as the bow or stern along the keel.

Special consideration must be given to components that have interior and exterior areas such as water lines, fuel lines, hydraulic lines, radios, and engine blocks. These components should represent the actual components in one of the following two ways:

o The exterior and interior are described as separate components.

o The item is described as one solid component, with the line of sight percentage modified to represent the effective density of the item.

The individual sections of large, discontinuous items of the actual target (i.e., armor and skin) should be modeled as separate components. Non-homogenous sections of an item must be modeled as separate components. For small boat targets, the hull should be modeled as two separate regions above and below the waterline. Long components such as electrical lines should be modeled into shorter segments for flexibility in SLV analysis.

Checks for overlaps should be processed using the following „gqa‟ command to ensure that no overlaps exist:

gqa -Ao -t0.3mm -g40mm-10mm all where o -Ao: check for overlaps (two regions that occupy the same space) o -t0.3mm: overlaps less than 0.3mm will not be reported (JTCG standard) o -g40mm-10mm: specifies the initial spacing between rays in the grids and the limit on how far the grid can be refined o "all" is the name of the top level object in the target geometry that you want checked

For armored targets, the interior of a target description must be separated into several compartments, such as crew, engine, and passenger. Many SLV models require that this internal space contain continuous regions of air because the SLV models use the air component to determine, for a given shotline, when a penetrator enters and exits the interior of the vehicle. The interior air component is also used to determine which interior compartment the penetrator has entered. All internal space must be filled with the appropriate air type. Interior air must be contained within the structure of the vehicle.

The AJEM Audit Sheet requires an entry in the “title” field, which can be input in the TGM using the title command. The title should specify descriptive information about the target model such as the target name, classification, and date.

Recommended:

The hierarchical structure of the target description groups regions into components and components into systems and subsystems. The hierarchical structure should be logical and easy to understand because the target description will be used by a diverse audience. Ease of use is achieved by grouping the objects in the target description in a consistent and logical manner. The hierarchical structural should reflect the real-world systems and subsystems of the actual system being modeled. The top level of the target description should be a combination which includes all of the geometry contained in the file such as hull, turret, suspension, and air.

When developing a new TGM, components in various subsystems (i.e., hydraulics, propulsion, etc.), should be grouped by ID numbers (or "thousand" series). Tables 3.2.1-1, 3.2.1-2, 3.2.1-3, and 3.2.1-4 provide conventions to use when constructing target descriptions (unless otherwise specified/directed).

These conventions, where applicable, are consistent with TGM development standards currently established within the JTCG community. Note that neither AJEM nor BRL-CAD is limited to any particular range of ID numbers. It is recommended that ID numbers 111 and 9999 not be used as these are reserved ID numbers used by other analysis codes.

Table 3.2.1-1: ID Numbering Convention for Rotary Aircraft

ID Number Category

0001-0999 Airframe

1000-1999 Propulsion

2000-2999 Personnel

3000-3999 Flight Controls & Hydraulics

4000-4999 Fuel

5000-5999 Drive Train

6000-6999 Armament

7000-7999 Rotor System

8000-8999 Electrical

9000-9999 Miscellaneous

Table 3.2.1-2: ID Numbering Convention for Fixed Wing Aircraft

0001-0999 Skin

1000-1999 Propulsion

2000-2999 Personnel

3000-3999 Flight Controls

4000-4999 Fuel

5000-5999 Armament

6000-6999 Hydraulics

7000-7999 Structure

Table 3.2.1-3: ID Numbering Convention for Ground-Mobile

Vehicles

ID Number Category

0001-0199 Crew/Passengers

1000-1499 Hull Armor/Structure

1500-1999 Turret Armor/Structure

2000-2999 Fuel

3000-3999 Armament & Ammunition

4000-4999 Engine & Drive Train

5000-5999 Suspension

6000-6499 Hull Electrical, Hydraulics, Communications

6500-6999 Turret Electrical, Hydraulics, Communications

7000-7499 Hull Fire Control, Computers, Radars

7500-7999 Turret Fire Control, Computers, Radars

8000-8499 Hull Exterior Miscellaneous

8500-8999 Turret Exterior Miscellaneous

9000-9499 Hull Interior Miscellaneous

9500-9999 Turret Interior Miscellaneous

Table 3.2.1-4: ID Numbering Convention for Small Boats

0001-0999 Hull

1000-1999 Power Plant

2000-2999 Personnel

3000-3999 Drive Train

4000-4999 Fuel

5000-5999 Armament

6000-6999 Radar and Optics

7000-7999 Structure

Optional:

Each region can be assigned a material code and a line-of-sight (LOS) percentage in the TGM to allow it to emulate the properties of the component.

Note: AJEM does not make use of the material code or LOS specified in the TGM. Instead, AJEM uses the material and thickness_factor defined in the AJEM prop file.

3.2.2 Geometry File

Required:

The geometry file must be named "geometry" and must reside inside of the target description directory.

When specifying a target description for use with an analysis, a target description directory is specified

(instead of specifying a specific TGM filename). The actual TGM file to use is specified within the geometry file. Table 3.2.2-1 provides an overview and recommended settings for the geometry file.

Table 3.2.2-1: Geometry File Settings

Keyword

Options

(Default in

BOLD)

Recommendation Comments method brlcad6 brlcadDb5 brlcad5 brlcadDb4 mged brlcad5 or brlcad6 (See Comments)

Use brlcad 6 when component names are specified by the MUVES_Component attribute in the BRL-CAD database.

Otherwise, use brlcad5.

mged_database - See Comments Specify name of BRL-CAD file. It should be in same directory as the geometry file.

root_object - See Comments Must match name of top-level object in BRL-CAD file.

region_map -regions

(See Comments)

Not required if method is set to brlcad6 and component names are stored in the MUVES_Component attribute.

If used, region map file should be in same directory as the geometry file.

rel_thin_tolerance 1.0e-5 - Do not set/use. This value is "relative" to the bounding radius of the target description.

abs_thin_tolerance - 0.001 Shotline traces less than specified amount are ignored.

(units = mm) thin_debug warn Warn Identifies where thin traces affect shotline.

overlaps silent Silent Suppresses overlap reporting in run log file. Overlaps are still eliminated by shotline.

fix_normals kludge kludge Suppresses warnings when reversed normals are detected. Reversed normals are always corrected.

z_waterline - Small Boat Target

Dependent

Only use for small boats.

Required only for zero and negative elevations.

The following is a sample geometry file with the recommended settings:

# geometry file

# required inputs method brlcad5 mged_database m1a1.g root_object all # must match name of top-level object in BRL-CAD file region_map regions # optional input when using BRL-CAD6.0 formatted database abs_thin_tolerance 0.001 # raytracing tolerance (mm) thin_debug warn # default thin trace reporting overlaps silent # suppresses overlap reporting fix_normals kludge # ignore reversed normals

3.2.3 Region Map (regions) File

Optional:

The region map file (or regions file) is now an optional input file. It is required when using a pre-

BRL-CAD 6.0 formatted database file. With the advent of BRL-CAD 6.0, component names can be stored in the MUVES_Component attribute.

The AJEM user interface has the ability to import and export a region map file to/from a BRL-CAD target description database (invoked by right-clicking on a target description in "Object View" identified by the geometry file as a BRL-CAD 6 formatted TGM). Thus, even if the new

MUVES_Component attribute feature is being used to store the component names directly within the

BRL-CAD file, the region map file can still be used, if convenient. The AJEM user interface also has a region editor that provides a spreadsheet-like interface for reviewing/editing MUVES_Component attributes.

The following is a sample region map file showing the recommended format:

# region map file

# component MGED ID hyd_pump 3001 hyd_reservoir 3002 hyd_accumulator 3003 hyd_actuator_port 3004 hyd_actuator_stbd 3005 passenger_1 0100:0120 passenger_helmet 121 & 123

3.2.4 Package (pack) File

Optional:

The package file (or pack file) is an optional file which provides a means of assembling multiple components (i.e., BRL-CAD regions) into a single "package" or virtual component. There are currently no JTCG/ME recommendations for this file. Refer to the AJEM manual for more information on the pack file.

3.2.5 Component Category Map (ccmap) File

The component category map file (or ccmap file), is used to associate every component name in the target description with a pre-defined category. Note that region ID numbers are mapped to component names using the MUVES_Component attribute, or in the region map file. The category determines what Interaction Module

(IM) will be called when a weapon impacts the component.

Required:

Armor components that will produce BAD need to be placed in the armor category in the ccmap file.

The behind armor debris model is called for components in the armor category if the armor component is followed by a component in the air or spall_liner category or any component with its density set to zero.

The „water_shielding‟ category is required for the water region surrounding submersible small boats.

Recommended:

The recommended practice is to only use the following categories unless absolutely necessary:

o components o fluids o armor o track o air o water_shielding

Note that in AJEM/MUVES-S2, fluid components must be mapped to the fluid category. The „armor‟ category is used when a component is going to generate spall and the „track‟ category is needed for tracks to use the appropriate EM.

Thus, the generic form of the ccmap file becomes:

# recommended practices for ccmap file

# category components components component1 # Put everything in "components" category except ...

component2 component3 fluids fluiditem1 # items defined as fluids in the prop file fluiditem2 air air_region # air required for BAD armor hull_armor # special armors roof_armor water_shielding water # water surrounding submersible small boats target_gap MUVES_target_gap exit_paint MUVES_exit_paint

3.2.6 Damage Evaluation Selection (des) File

The damage evaluation selection file (or des file) identifies the EM to use for each critical component or categories of components that are defined in the ccmap file. Each line in the des file contains two entries.

Required:

A standard set of qualifiers shown in the example below are required for the internal_blast EM. Refer to Section 3.2.8 for additional information on using the internal_blast EM.

Crew and passengers for ground mobile and small boat targets must be evaluated using the

Sperazza_Kokinakis EM. A single qualifier should be listed in the des file. In-flight aircraft do not use the Sperazza_Kokinakis EM.

Recommended:

The recommended practice is to forgo using component names and built-in category names (whenever possible) and use qualifiers exclusively. The names one defines in the des file are then used as Pk table names in the bcurve and ecurve files (where appropriate). Qualifiers are also then used in the sysdef file to qualify component names within the fault tree.

# recommended practices des file

# Qualifier Evaluation Module

:[PkTableName1] mass_velocity_table

:[PkTableName2] mass_velocity_table

:[PkTableName3] fluid_leaker

:[crewPk] Sperrazza_Kokinakis # Required for Sperrazza_Kokinakis EM

:[Soft] internal_blast # Required for internal_blast EM

:[Medium_Soft] internal_blast # Required for internal_blast EM

:[Medium] internal_blast # Required for internal_blast EM

:[Medium_Hard] internal_blast # Required for internal_blast EM

:[Hard] internal_blast # Required for internal_blast EM

:[Hard_PLUS_1] internal_blast # Required for internal_blast EM

:[Hard_PLUS_2] internal_blast # Required for internal_blast EM

:[Hard_PLUS_3] internal_blast # Required for internal_blast EM

:[Hard_PLUS_4] internal_blast # Required for internal_blast EM

:[Hard_PLUS_5] internal_blast # Required for internal_blast EM

:[Hard_PLUS_6] internal_blast # Required for internal_blast EM

3.2.7 Evaluation Curve (ecurve) File

The evaluation module interpolation table file (or ecurve file) contains the component Pk tables (also known as

Pcd|h curves) for critical components using a standard table format. The type of look-up table (i.e., 1D, 2D, index table, etc.) is dependent on the particular EM being used. Not all EMs require the use of Pcd|h curves to determine the probability of functional loss.

Required:

When using the limit option with the pktable EM, the Pk for the smallest mass is required to be zero for all velocities and the Pk for the lowest velocity of each mass is required to be zero.

Recommended:

There are several options that can be set for individual tables within the ecurve file. It is recommended that the limit and warn options be used for the tables as shown in the example below. Extrapolating beyond the table domain is not recommended, and the analyst should be warned if the table domain has been exceeded. Instead of using table options to limit interpolation, it is recommended that the bounds of the curve be explicitly defined. The step option can be also be used when it makes sense to do so, as this does away with potential issues resulting from interpolation.

The analyst should consider the fragment material type when assigning the Pcd|h curves to the target critical components. Historic Pcd|h curves were calibrated for steel fragment weapons. It is anticipated that these curves will be applied in some circumstances to evaluate Tungsten and Titanium fragments. However, as new curves are developed they should be calibrated and documented for all fragment weapon materials. An ideal solution is to use component criticality descriptions that are weapon independent (such as the perforation EM).

In order to support databasing efforts and to avoid name "collision" the following naming convention should be used for JTCG/ME analyses:

[Target][System]Component[DamageMode][.parameter_ID][_bcurve] where;

[Target]is the optional prefix identifying the target for which the component Pk curve was developed, [System]is the optional prefix identifying the target subsystem for which the component Pk curve was developed, Component is the name of the component for which the Pk curve was developed, [DamageMode]is the optional damage mode identifier (recommend ALL CAPS), [.parameter_ID]is the parameter and Pk table ID number tag (only required when using pktable EM), and

[_bcurve]is the blast/fireball ignition table (only required if using pktable EM and fireball methodology).

The following are examples of ecurve table names using the aforementioned naming convention:

Actuator - Simplest example of ecurve name that meets convention.

Actuator.wgt_1 - Simplest example of ecurve name that meets convention using pktable EM.

F18FuelCenterTankFIRE.airgap_4001_b4001 - Complex example using pktable EM with airgap and blast curves.

Note: The pktable EM requires a very specific use of periods and underscore characters. Only use periods and underscores as previously directed. Reference the pktable EM documentation for more details.

Component Pk tables must be formatted according to the syntax of the ecurve file. The AJEM user interface has an ecurve file form that allows these tables to be developed, viewed, and edited using a spreadsheet-like interface. The ecurve form embeds special comments within the ecurve file. The EM:

tag is followed by the EM name and associated parameter (if used). This allows the user interface to identify which EM the particular ecurve is designed to support. This is important since the number of tables and units are generally specific to the EM that accesses the table. It is recommended that this special comment be included with every ecurve.

Another special comment is the COMMENT: tag. Essentially, everything following this tag -including subsequent comment lines (up to the table dimension line which starts with an exclamation point) - is treated as a comment field within the ecurve form. Since rationale can be developed for each Pk table in a separate file, it is not necessary to include text-based comments in the ecurve file itself. If the table is classified the comment line may be used.

AJEM ecurve files generally use metric units (e.g., grams and meters per second). However, most analyses use (and are documented in) English units (e.g., grains and feet per second). Thus, it is important to include units (and appropriate conversions) in the ecurve file.

Note: The ecurve form within the AJEM user interface automatically includes units and appropriate conversions for selected EMs.

The following is a sample ecurve file:

# sample ecurve

Sample.wgt_1

# EM: pktable(wgt)

# COMMENT: Rationale documented in Sample.wgt_1.doc

! 4 limit warn

#mass(grms) index

0.259 1 # 4.0 gr

0.324 2 # 5.0 gr

0.972 3 # 15.0 gr

1.944 4 # 30.0 gr

Sample.wgt_1:1 # Pk for all velocities of first mass are required to be zero

! 4 limit warn

# vel(m/s) Pk

76.2 0.00 # 250.0 ft/s

152.4 0.00 # 500.0 ft/s

457.2 0.00 # 1500.0 ft/s

762.0 0.00 # 2500.0 ft/s

Sample.wgt_1:2 # Pk for first velocity is required to be zero

# vel(m/s) Pk

76.2 0.00 # 250.0 ft/s

152.4 0.00 # 500.0 ft/s

457.2 0.10 # 1500.0 ft/s

762.0 0.25 # 2500.0 ft/s

Sample.wgt_1:3 # Pk for first velocity is required to be zero

# vel(m/s) Pk

76.2 0.00 # 250.0 ft/s

152.4 0.25 # 500.0 ft/s

457.2 0.50 # 1500.0 ft/s

762.0 0.50 # 2500.0 ft/s

Sample.wgt_1:4 # Pk for first velocity is required to be zero

# vel(m/s) Pk

76.2 0.00 # 250.0 ft/s

152.4 0.30 # 500.0 ft/s

457.2 0.60 # 1500.0 ft/s

762.0 0.75 # 2500.0 ft/s

3.2.8 Blast Model Interpolation Table (bcurve) File

The blast model interpolation table file (or bcurve file) contains the component Pk tables (also known as Pcd|h curves) for critical components using a similar table format as that used in the ecurve file. This file is used by the internal_blast EM.

Required:

Detailed instructions for implementing the internal_blast EM are provided on the JPIAS site along with a standard bcurve file to use for all JTCG/ME analyses.

The following is a sample format of the standard bcurve file:

Note: This format is only compatible with AJEM 2.17 or later.

# sample bcurve file format

# actual bcurve file is provided on JPIAS

Medium

! 2 index

# CHG_WT(kg) index

0.2 1

0.4 2

Medium:1

! 2

# axial(mm) radial(mm) pk

1000.0 1000.0 1.00

1500.0 1500.0 0.00

Medium:2

# axial(mm) radial(mm) pk

2000.0 2000.0 1.00

3000.0 3000.0 0.00

Hard

! 2 index

# CHG_WT(kg) index

0.2 1

0.4 2

Hard:1

# axial(mm) radial(mm) pk

100.0 100.0 1.00

150.0 150.0 0.00

Hard:2

# axial(mm) radial(mm) pk

200.0 200.0 1.00

300.0 300.0 0.00

3.2.9 Interaction Module Interpolation Table (icurve) File

Optional:

The interaction module interpolation table file (or icurve file) is an optional file which contains supplemental interpolation tables required by some Interaction Modules. This file is used to provide additional information regarding interactions with special armor types. There are currently no

JTCG/ME recommendations for this file. Refer to the AJEM manual for more information on the icurve file.

3.2.10 Parameters (params) File

The Parameters file (or params file) is a file which provides a means of entering parameters for certain

Evaluation Modules, and target-weapon debris model characteristics. For JTCG/ME, the params file is used for the Sperrazza-Kokinakis EM. It is also required for Behind Armor Debris (BAD) characterizations for heavy ground vehicles (and light ground vehicles with any type of armor).

Required:

The params file is required for ground mobile vehicles and small boats when using the Sperrazza-

Kokinakis EM. Analysts should use the Sperrazza-Kokinakis.params file distributed with AJEM 2.24 or later.

For each component that generates behind armor debris, the ARMOR_PKG_NAME component property must be set in the prop file. The ARMOR_PKG_NAME maps to a data set in the params file, by using the specified armor package name. Each armor component may be mapped to multiple data sets based on threat type.

Note: The JTCG/ME provides common BAD inputs for Explosively Formed Penetrator (EFP) weapons and is currently investigating the standardization of additional BAD inputs.

The following line is required when running the Sensor Fuzed Weapon Pre-Planned Product

Improvement (SFW-P3I) against small boats:

SFW_P3I SALVO { }

The following is a sample params file:

# params - sample parameters file

ArmorPackageName:WeaponName MassVelocityDebrisModelV2 target_thickness = 32.45 # mm fragment_mass_exponent = 2.0 fragment_mass_median = 0.0316228 # gm fragment_mass_sigma = 7.95271 fragment_max_velocity = 3500 # m/s fragment_size_exponent = 3.0 fragment_velocity_exponent = 3.0 virtual_origin_distance = 30 # mm

3.2.11 Material Properties (matprop) File

The material properties file (or matprop file) is provides the material properties for the various component materials listed in the prop file.

Required:

Unless otherwise directed, the standard matprop file distributed with AJEM should be used. An updated standard matprop file will be distributed with a future version of AJEM. The standard matprop file is included as part of the AJEM User/Analyst Manual and a copy is also located in the ajem/database directory (reference the matprop.std file). A copy of the standard matprop file is automatically copied into an AJEM project directory when the project is created. Every time a project is opened, this file is compared to the matprop file contained in the ajem/database directory. If the file in the ajem/database directory is newer than that contained in the project directory, the user will be prompted to update the file contained in the project directory.

If the target contains a material type that is not the standard matprop file, a new material name with associated properties may be defined in the matprop file. Refer to the AJEM User‟s Manual for more information.

3.2.12 Component Properties (prop) File

The component properties file (or prop file) identifies the material associated with each component in the target description. Other component attributes that may be specific to a particular Interaction Module and/or

Evaluation Module can also be assigned. The AJEM User/Analyst Manual goes into specific details. The component names used in the prop file are defined by the MUVES_Component attribute in the BRL-CAD file or in the region map file.

Required:

Crew and passengers for ground mobile and small boat targets must be evaluated using the

Sperazza_Kokinakis EM with the following body regions:

o head_neck o thorax o abdomen o pelvis o arms o legs

These body regions are only valid using AJEM 2.24 or later. Each body region must be defined in the prop file and assigned a material of water. For ground mobile targets, the tactical role should be assault with an incapacitation time of 5 minutes. For small boat targets, the tactical role should be defense with an incapacitation time of 30 seconds. In-flight aircraft do not use the

Sperazza_Kokinakis EM.

For each component that generates behind armor debris, the ARMOR_PKG_NAME component property must be set in the prop file.

The FIRST_HIT_ONLY option must be used for hollow components to prevent "double counting" the

PK when a shotline passes through a hollow component.

Although a default component properties can be specified using the built-in DEFAULT component, it is recommended that the DEFAULT component not be used, since it can lead to inadvertent component property settings. The recommended practice is to explicitly define component properties.

It is recommended that units be included as comments for component attributes whenever practical.

It is recommended that the THICKNESS_FACTOR be explicitly defined for every component, even for components with a THICKNESS_FACTOR of 1.0.

Note: AJEM does not make use of the material code or LOS specified in the TGM. Instead, AJEM uses the MATERIAL and THICKNESS_FACTOR defined in the AJEM prop file.

The following is a sample prop file:

# prop - component properties file

MUVES_target_gap MATERIAL Air crew_head MATERIAL water

THICKNESS_FACTOR 1.0

BODY_PART head_neck

INCAPACITATION_TIME t5mins

TACTICAL_ROLE assault crew_left_arm MATERIAL water

BODY_PART arms

INCAPACITATION_TIME t5mins

TACTICAL_ROLE assault hyd_pump MATERIAL Aluminum_2024 fuel_cell MATERIAL Fuel_JP4

VOLUME_INTEGRAL 609.6 # shotline grid (mm)

CONSUMPTION_RATE 0.00 # grams/sec

FLUID_DISCHARGE 0.67 # dimensionless Cd

FLUID_CAPACITY 0.75 # 75% full initially

MINIMUM_CAPACITY 0.10 # minimum needed

PRESSURE 0.00 # tank pressure (Pa)

3.2.13 System Definition (sysdef) File

The system definition file (or sysdef file) is where the target fault tree is defined. Systems are defined (and/or system capabilities) from previously defined component names and new subsystem names (defined in the sysdef file) to construct the fault trees for analysis. Expressions in the sysdef file can use a number of operators and built-in functions. In addition to these capabilities, user-defined functions can also be created to process repetitive calculations. System behavior, or response to damage, is defined by creating expressions similar to the following:

# sysdef- sample sysdef file port_hyd_reservoir = port_reservoir[pk_leakage] | port_reservoir[Medium] port_hyd_pump = port_pump[impact] | port_pump[Hard] port_hyd_system = port_hyd_pump | port_hyd_reservoir strbrd_hyd_reservoir = strbrd_reservoir[pk_leakage] | strbrd_reservoir[Medium] strbrd_hyd_pump = strbrd_pump[impact] | strbrd_pump[Hard] strbrd_hyd_system = strbrd_hyd_pump | strbrd_hyd_reservoir hyd_system = port_hyd_system & strbrd_hyd_system

The overall hydraulic system…