U.S. Navy Threat/Simulation Validation Web Site
SimVal Home | Contact | Best Viewed
NAVAIR Logo

U.S. Navy Threat/Simulation Validation

U. S. NAVY AIR DEFENSE THREAT

SIMULATOR VALIDATION

PROCEDURES MANUAL

DoN.gif (11681 bytes)

by

Navy Threat Simulator Validation Coordinator

Threat / Targets Systems Department

MARCH 1995

 Distribution authorized to U.S. Government agencies and their contractors; administrative or operational use; 17 August 1993. Other requests for this document shall be referred to the Naval Air Warfare Center Weapons Division (Code 53C00D). This is an informal report of the Naval Air Warfare Center Weapons Division and is not part of the permanent records of the Department of Defense.

 

Naval Air Warfare Center

Weapons Division 53C000D

China Lake, California 93555-6001

 

DESTRUCTION NOTICE-Destroy by any method that will prevent disclosure of contents or reconstruction of the document.

FOREWORD

This NAWCWPNS TM 7489-3 is a revision of NAWCWPNS TM 7489-2. This document has been developed by and for the Navy Threat Simulator Validation Coordinator. Its purpose is to document the procedures necessary to validate Navy air defense and air defense-related threat simulators used for Test and Evaluation and/or Aircrew Training. It is to be considered a living document and the user is highly encouraged to mark and write in this manual to clarify or add new procedures. The Navy Threat Simulator Validation Coordinator will review this document annually with cognizant Naval Air Warfare Center and Naval Air Systems Command personnel to ensure its completeness and accuracy.

This report was reviewed for technical accuracy by Stephen D. Wireman.

This is an informal report of NAWCWPNS China Lake, California. and shall not be used as authority for action unless enclosed in official correspondence in which the purpose of the transmittal is made clear.

R. L. BALLENGER, Assoc. Head
Threat / Targets Systems Department
3 March 1995

NAWCWPNS TM 7489-3, published by Code 53C000D, 25 copies.


TABLE of CONTENTS

Introduction

Purpose
Background
Policy
Requirements

Organizational Responsibilities

Department of Defense Executive Committee on Threat Simulators
CROSSBOW-S Committee
Chief of Naval Operations (CNO)
Naval Air Systems Command
Naval Air Warfare Center Weapons Division
Navy Simulator Validation Coordinator
Navy Laboratories and Ranges

Validation Guidelines

          Validation Planning
          Threat Data Collection
          User Requirement Collection and TSCP Derivation
          Simulator Data Collection
          Deviations With Respect to TSCPs and Instrumentation
          Preparation and Submission of Validation Reports
          Review and Distribution Process
          Data Base Operation and Maintenance

Appendixes

A. Sample Correspondence
B. OPNAV Instruction 3960.15 B-1
C. NAVAIR Instruction 3960.00 C-1
D. Acronyms D-1
E. Acronyms E-1


INTRODUCTION

PURPOSE

This manual provides information and guidance to assist the Navy Threat Simulator Validation Coordinator in the support of independent verification, validation, and accreditation of air defense and air defense-related threat simulators used for Test and Evaluation (T&E) of weapon systems and training of Navy air crews. Air defense simulators are found both in laboratory and field versions and include hardware and software subsystems. Validation baselines the status of a simulator to represent a threat system. If a simulator contains embedded software, the validation process also incorporates applicable verification procedures. The Navy Threat Simulator Validation Coordinator (Naval Air Warfare Center, Weapons Division [NAWCWPNS], China Lake, Code 53C000D) is responsible for coordinating the development of verification and validation (V&V) procedures, compiling data, and documenting the results of individual V&V of threat simulators . Documents produced during the validation process provide a basis for accreditation of a simulator for specific uses by respective user agencies.

 

BACKGROUND

The threat simulator development programs of all Services were investigated by the Government Accounting Office (GAO) in 1983. The results of this investigation found that (1) simulators being developed were too costly; (2) too much unnecessary duplication of effort was occurring between the services; and (3) the simulators being developed were not very threat representative. The recommendation was made that the Services needed earlier definition of both test and simulator requirements.

The Executive Committee (EXCOM) was then formed in 1983 to provide management, policy, guidance and program approval for all Department of Defense (DoD) development and acquisition programs for threat weapon system simulators. In 1986, threat simulator development programs of all Services were again investigated by the GAO. The results of their investigation reflected the same findings as the investigation of 1983.

In October 1987 the House Committee on Government Operations reviewed the threat simulator development situation. The results of this investigation led to EXCOM rewriting the EXCOM and CROSSBOW-S charters. An Ad Hoc Committee on Validation was formed and led by the Navy to investigate the validation procedures of the services.

In February 1988 the Ad Hoc Committee recommended that simulators be validated both at the design and initial development phases, and then periodically. EXCOM directed the services to implement this action.

In July 1988 the CROSSBOW-S Subcommittee for validation was formed to develop standard criteria for validation and standard reporting of validation. This Subcommittee transitioned into a working group from July 1988 through April 1989, when these procedures were implemented.

The Navy submitted the first validation report in January 1990. By June of 1990 the Navy was the first to have validated a simulator under the Office of the Secretary of Defense (OSD) validation process. Since then more than 20 simulators have been validated under this process. These simulators fall in the RF, EO/IR, C3 spectrum and include emitter, emitter-receiver-processor, actual, and surrogate categories.

POLICY

The validity of air defense threat simulators shall be ensured throughout the lifetime of each simulator. The validity check includes a Design Specification Validation Review (DSVR) conducted at the specification review. A Critical Design Review (CDR) is conducted if a DSVR is not conducted. At a simulator's Initial Operational Capability (IOC), validation is conducted on-site at the applicable range or laboratory using measured data and factory acceptance test data, as appropriate. An operational validation (OPN) is conducted if the simulator is deployed and no prior validations were performed. OPN validation is also conducted if a simulator undergoes a major update or modification, or on a periodic basis.

Validation reports shall note and explain differences between simulators and current Defense Intelligence Agency (DIA)-approved threat data and shall describe the impact of the differences on testing and/or training.

REQUIREMENTS

DoD 5000.2-M requires that each threat simulator be subjected to validation procedures to establish and document a baseline comparison with it's associated threat to ascertain the extent of the operational and technical performance differences between the two throughout the simulator's life cycle.

The DoD Threat Simulator Program Plan (TSPP) addresses the management and planning aspects of the tri-Service efforts to coordinate and integrate the development and acquisition of threat simulators as test and training resources. The plan is issued under the authority of DoD Threat Simulator Program Guidelines, September 1991.

DoD 5000.59 establishes DoD policy, assigns responsibilities, and prescribes procedures for the management of modeling and simulation.

SECNAVINST 5200.38 establishes the Department of the Navy Modeling and Simulation Program, the Deaprtment of the Navy Modeling and Simulation Advisory Council, and the Department of the Navy Modeling and Simulation Management Office. SECNAVINST 5200.38 also assigns responsibilities and prescribes policies and guidance for the execution of the program.

OPNAVINST 3960.15 assigns Naval Air Systems Command Headquarters (NAVAIRHQ) as the Chief of Naval Operations (CNO) technical agent for Navy air defense simulator validation and tasks NAVAIR to implement validation procedures. OPNAVINST 3960.15 also requires that all Navy air defense threat simulators fielded during or after 1986, which are used for development and testing of weapon systems or training of Navy aircrew personnel, be validated simulators. All other simulators will be validated as required by major update or modification, or as funding permits in conjunction with routine operations and maintenance.

According to NAVAIRINST 3960.00, NAVAIRHQ, Tactical Aircraft Programs Manager (PMA 272), will fund NAWCWPNS, China Lake, to establish an independent Navy Simulator Validation Coordinator to coordinate the conduct of unbiased simulator V&V at all Navy laboratories and ranges.

Major acquisition and procurement decisions are based on the results of the testing of developmental hardware against air defense threat simulators. For those decisions to be informed and correct, the simulators must be valid representations of the threat. To be a validated simulator does not mean that every parameter of the simulator is identical to the equivalent parameter of the actual threat system. The parameters of the simulator will be compared to the threat to determine the potential use of the simulator in meeting test/training requirements. The parameters of the actual threat system are those stated or approved by the current DIA threat assessment.


ORGANIZATIONAL RESPONSIBILITIES

DEPARTMENT OF DEFENSE EXECUTIVE COMMITTEE ON THREAT SIMULATORS

The EXCOM on threat simulators is made up of flag rank officers and/or civilian equivalents, who are responsible for the management, policy, guidance, and program approval for all DOD simulator development and acquisition programs. The EXCOM has final authority to accept or reject all validation reports submitted by the services. N912R4 is the Navy member of EXCOM.

CROSSBOW-S COMMITTEE

CROSSBOW-S Committee members represent the three Armed Services and Intelligence Centers and as a group form the technical arm of EXCOM. The CROSSBOW-S Committee charter states its mission as reviewing and coordinating all aspects of the DoD development and acquisition program for both threat simulators and threat models (physical and digital models/ software simulations). The validating authority for threat models is DIA. DIA may, at its discretion, select a Science &Technical Intelligence (S&TI) center to perform threat model validation. The CROSSBOW-S Committee is responsible for establishing standard validation criteria (SVC) and reviewing all submitted threat simulator validation reports. CROSSBOW-S will then forward the reports to the EXCOM with recommendations. N912R4 is the primary Navy member of the CROSSBOW-S Committee. PMA-248D is the Navy's alternate member.

CHIEF OF NAVAL OPERATIONS (CNO)

CNO (N912) is the final Navy approval authority for Navy validation reports. N912R4 will request the Commander, Operational Test and Evaluation Force (COMOPTEVFOR), to review validation reports and submit recommendations for the use of simulators for operational testing and evaluation directly to CNO (N912). N912R4 will forward all Navy-approved reports to the CROSSBOW-S Validation Subcommittee for review and submission to EXCOM via the CROSSBOW-S Committee.

N912R4 will serve as the CNO technical agent for Navy air defense simulator validation. Joint-Service requirements for simulator validation shall be coordinated through the CROSSBOW-S Committee. Technical review of simulator validation reports will be coordinated with applicable user program offices for comment. Recommendations to approve simulators as valid for developmental testing shall be submitted to CNO (N912). Recommendations to approve simulators as valid for training of Navy combat personnel shall be submitted via CNO (N889) to CNO (N912).

As the Navy CROSSBOW-S Representative, N912R4 will support the Navy Simulator Validation Coordinator with regard to policy issues between the Navy and the CROSSBOW-S Committee.

NAVAL AIR SYSTEMS COMMAND

PMA-272/PMA-248 will:

1. Obtain funding for the air defense threat simulator validation process from CNO and/or the CROSSBOW-S Committee.

2. Fund NAWCWPNS, China Lake, to establish an independent Simulator Validation Coordinator to coordinate the conduct of unbiased simulator validation at all Navy laboratories and ranges.

3. Fund Navy laboratories and ranges to conduct validation of assigned simulators.

4. Coordinate NAVAIRHQ review of validation reports submitted by the Navy Simulator Validation Coordinator. Recommend to CNO (N912) approval of these simulators as valid for the purposes of developmental testing and the training of Navy personnel and, when appropriate, recommend waivers so that those systems not formally approved may continue to support limited operations.

5. Forward validation reports to COMOPTEVFOR for review and recommendations to CNO 912, concerning the use of simulators for the purpose of operational testing and evaluation. Training validation reports will be forwarded to PMA-248.

NAVAL AIR WARFARE CENTER WEAPONS DIVISION

Commander, NAWCWPNS, China Lake, will designate an independent Navy Simulator Validation Coordinator, who has technical expertise in both air defense threat simulator validations and electronic warfare. Care must be taken to ensure that the results of validation are purely objective and free from bias imposed by the simulator development programs.

NAVY SIMULATOR VALIDATION COORDINATOR

The Navy Simulator Validation Coordinator shall:

1. Operate independently from offices that are responsible for management of simulator development programs.

2. Manage Navy simulator validation programs for OPNAV, and NAVAIRHQ, coordinating with responsible Navy laboratories and ranges as required.

3. Develop and maintain a U.S. Navy Air Defense and Air Defense related Threat Simulator Validation Procedures Manual, defining validation procedures to be followed by Navy laboratories and ranges.

4. Review air defense simulator validation reports prepared by Navy laboratories and ranges, and forward the results to NAVAIRHQ (PMA-272/ PMA-248).

5. Develop and maintain the Navy Threat Simulator Validation Data Base, for Air Defense and Air Defense related Threat Simulators.

6. Participate in the DOD Subcommittee validation report review process

          7. Actively participate in the CROSSBOW-S and DOD Tri-Service Simulator Validation Working Groups             and the Navy Unique SVWG review of Navy Unique validation reports and approval process.

          8. Review air defense and air defense related simulator validation reports and documentation prepared             by Navy laboratories and ranges, and forward the results to NAVAIR (PMA-272 and PMA-248).

NAVY LABORATORIES AND RANGES

The Navy laboratories and ranges shall:

1. Designate a single point of contact to coordinate with the Navy Simulator Validation Coordinator regarding validation requirements for assigned air defense simulators and validation report format.

2. Coordinate with the Navy Simulator Validation Coordinator to:

a. Determine Threat Simulator Critical Parameters (TSCPs) from Navy T&E or training requirements for which the simulator was designed.

b. Collect and analyze simulator performance data using specification data in the case of a simulator in development or measured data in the case of an existing simulator.

c. Compare simulator performance data with the corresponding threat parameters from the current DIA threat assessment and the specific TSCPs.

d. Submit a validation report which analyzes the impact on specific testing or training requirements, and states any deviations from TSCPs to the Navy Simulator Validation Coordinator.


  VALIDATION GUIDELINES

The validation of Navy threat simulators and models is required by DODI 5000.2, DODI 5000.59, SECNAVINST 5200.38, OPNAVINST 3960.15, NAVAIRINST 3960.00, and applicable Navy instructions. The procedures for accomplishing validation is to be found and followed by the DOD Threat Simulator Program Plan (TSPP) Policy and Procedures Manual, and the DOD Threat Simulator Program Guidelines (TSPG) issued by the Deputy Director, Defense Research and Engineering for Test and Evaluation (DDDRE(T&E). Although this process continually evolves, the U.S. Navy Air Defense Threat Simulator Validation Procedures Manual NAWCWPNS TM 7489-3 written and updated by and for the Navy Air Defense Threat Simulator Validation Coordinator, NAWCWPNS (53COOOD), further describes the Navy Validation Process, Policy and Procedures for Air Defense and Air Defense related threat simulator valdation.

VALIDATION PLANNING

Validation plans with actions and milestones shall be prepared early in the acquisition cycle for each simulator requiring validation. Validation data requirements shall be provided to the simulator development program office. Factory and on-site acceptance test plans shall be tailored to provide for collection of validation data wherever practical.

Simulator validation will be conducted by the lead service at three events during the simulator's life cycle.

1. Design Specification Validation Review (DSVR). DSVR is performed at or before simulator development contract award. The resulting validation report requires DoD, CROSSBOW-S, and EXCOM review/approval.

2. Initial Operational Capability (IOC). IOC validation is performed prior to the simulator IOC at the range or laboratory facility, and the resulting validation report requires DoD, CROSSBOW-S, and EXCOM review/approval.

3. Operational Validation (OPN). OPN validation is performed whenever a major intelligence update/change occurs or a major modification to the simulator is made. This validation may also be performed at periodic intervals as specified by the Service. The resulting report requires DoD, CROSSBOW-S, and EXCOM review/approval if no prior DSVR or IOC validation report was previously produced.

Note: If a DSVR has not been performed, then a Critical Design Review validation report must be generated prior to IOC. This report should be accomplished at or after the simulator developer's CDR. This report requires DoD, CROSSBOW-S, and EXCOM review/approval.

CROSSBOW-S SVC shall be tailored for applicability to the simulator subject to validation and shall be adhered to when possible.

THREAT DATA COLLECTION

Threat Data

DIA-approved threat data shall be identified, provided, reviewed and approved by ONI, NGIC, NAIC, MSIC or other credible intelligence analyst, groups or agencies. All threat data should be reviewed by the validation agency to gain comprehensive threat system knowledge. It is extremely important to complete this up-front activity before entering threat data into the validation data base. The threat data shall be entered according to CROSSBOW-S SVC format. Data in the data base shall be verified with the source documents to ensure accurate transcription.

Data Request

Normally, intelligence support requests are transmitted to DIA from the CROSSBOW-S Management Office and are driven by a master simulator validation priority list compiled from the three Services' validation schedules. In addition, the requests are prioritized with DSVRs receiving the highest priority, followed by double-digit threat system validations as second priority, and IOC and OPN validations as third and fourth priority. It may be necessary to communicate directly with DIA to determine the latest available threat assessments and with the appropriate S&TI centers, to obtain an Electronic Warfare Integrated Reprogrammable (EWIR) data listing to maintain a workable validation schedule. A sample intelligence data request letter is presented in Appendix A.

Under the approved CROSSBOW-S/DIA communication process, the DIA will respond by tasking the S&TI centers to produce a Threat Definition Document (TDD) which is discussed below.

Data Base Structure

The data base structure and CROSSBOW-S validation criteria will be tailored to the particular threat. CROSSBOW-S guidance allows parameters to be deleted as required to address only those sections of the criteria which apply to a particular validation.

The CROSSBOW-S approved TDD's are developed through coordination between the CROSSBOW-S Validation Working Group, DIA, and the S&TI centers. The TDD was designed to provide sufficient detail on the threat, to be compatible with current DIA products, and to be easily updated. The TDD will contain all appropriate data associated with a specific threat and is an integral part of the CROSSBOW-S SVC, which is the basis for the validation report. The TDD can be requested in both hard-copy and magnetic media formats.

Threat data can be entered initially at the design phase and updated at each of the other phases, as required. Only DIA-approved data can be used. If DIA-approved threat data is not available, other intelligence source data must then be used. The source of the data used must always be clearly noted in the validation report.

USER REQUIREMENT COLLECTION AND TSCP DERIVATION

User requirements will be analyzed to determine operational and technical TSCPs. TSCPs shall be entered in the Navy's TADB in accordance with the CROSSBOW-S SVC format. Data in the TADB tables shall be verified to ensure accurate data entry.

Critical user requirements for simulator parameters and simulator operational characteristics shall be collected from principal user(s) including the electronic warfare (EW) equipment developers and applicable Developmental Test and Evaluation (DT&E)/Operational Test and Evaluation (OT&E) organizations.

The process for determining TSCPs (Figure 1) requires identification of potential test systems, such as deceptive electronic counter measures (DECM), radar warning receiver (RWR), antiradiation missile, stand-off jammer, decoy, etc., and their existing or projected requirements. Liaison will be conducted with DT&E personnel at NAWCWPNS, and NAWC-AD, for ECM technical knowledge, system understanding, and DT&E requirements; and with COMOPTEVFOR and/or Air Test and Evaluation Squadrons for OT&E requirements. Test and Evaluation Master Plans, will be researched for actual resource requirements and Critical Operational Issues for particular EW systems.

TSCPs are judged as those which interact critically with ECM equipment and are important in the resolution of test and training issues and satisfaction of test and training objectives. Deviations shall be analyzed with emphasis on critical parameters. Impacts of these deviations on the mission of the simulator will be determined using the validation process. Based on this analysis, informed decisions shall be made by the user committee regarding the validity of the simulators to support their respective testing or training.

Figure 1. TSCP Derivation/ECM Interaction.

Once the threat is understood and the T&E/training requirements are known, baseline TSCPs can be reviewed and modified as required for the particular system being validated. For example, data contained in the I-15/Missile Unit Validation Report of June 1990 provides the baseline for TSCPs related to T&E of deceptive ECM, RWR, and off-board jammer systems against the I-15 type radar simulator. Validation against other types of ECM systems and different radar configurations will require further analysis to determine appropriate TSCPs (Figure 2).

SIMULATOR DATA COLLECTION

If conducting a design validation, the specification data shall be provided by the simulator developer. If conducting an operational validation, measured performance data is collected on site, which includes factory acceptance test data and specified test requirements. In such cases where data is not available, it shall be provided by the facility responsible for the operation of the simulator. Design or measured simulator performance data shall be entered in the Navy TADB following the CROSSBOW-S standard validation guidelines, SVC. Data in the database shall be verified to ensure accurate data entry.

Figure 2. ECM Systems Versus Radar Subsystems.

Simulator Data

Simulator material is obtained from the simulator developing field activity, such as NAWCWPNS, China Lake, NAWC-AD, Patuxent River, or NAWCWPNS, Point Mugu. Appropriate material is required to ensure a full understanding of the simulator system and is especially helpful before detailed data collection begins. Data collection is accomplished by coordinating with the applicable point of contact for the simulator. Data will be available in the form of specifications, acceptance test plan records, operations and maintenance manuals, engineering notes, and through face-to-face discussions with simulator personnel. Specification data is applicable for design validation, and actual data is required when validating actual operating systems. A review of all simulator data to gain a comprehensive knowledge of the simulator is performed. It is extremely important to complete this up-front activity before entering simulator data. The simulator data shall be entered according to the CROSSBOW-S SVC. Data in the TADB shall be verified with the corresponding source documents, specifications, etc., to ensure accurate transcription.

All available simulator data can be entered into the Navy's TADB and tailored with emphasis on those parameters identified as TSCPs. At the design phase, data will be limited to specification data. At each successive phase, more data can be entered or updated as required. It has been necessary to interview technical personnel to obtain some of the data until the process developes to the point where specifications, acceptance test plans, and collection formats are standardized with the TDD/validation format.

DEVIATIONS WITH RESPECT TO TSCPs AND INSTRUMENTATION

Simulator data (specified or measured) shall be compared to the DIA-approved threat data. Parametric deviations shall be entered in the Navy's TADB in accordance with the CROSSBOW-S SVC. Specific engineering analysis of each deviation shall be conducted with respect to individual user requirements to determine the potential impact of the deviation on the test and/or training mission of the simulator.

Impact analysis is conducted to describe implications for testers when parametric deviations occur and provides the basis for the accreditation of the system. Because of the nature of the report format, the impacts are best discussed in the body of the report rather than in the parametric tables. If appropriate, an assessed level of impact may also be indicated in the Impact section. These assessed levels are defined below as:

1. None - No known impact.

2. Minimal - Given the known or estimated differences between threat and simulator, threat results may be interpreted for resolution/partial resolution of applicable test issues.

3. Moderate - Test modification and/or detailed analysis may be required for resolution/partial resolution of applicable test issues.

4. Major - Effectiveness results can not be determined or realistically estimated for applicable test issues.

PREPARATION AND SUBMISSION OF VALIDATION REPORTS

Formal validation report data sheets shall be prepared in the CROSSBOW-S SVC format and verified to ensure accurate transcription. A formal report cover letter summarizing results of the threat simulator validation, and making recommendations regarding validity of the subject simulator, shall be prepared. The finished report shall be reviewed and forwarded to COMNAVAIRSYSCOM, (PMA-272/PMA-248) via the Navy Simulator Validation Coordinator, (53COOOD) NAWCWPNS, China Lake.

Report Production

The CROSSBOW-S SVC, which includes a standard validation report format, is the approved model for subsequent validation reports. The validation report must include all elements described in Table 1.

 

Table 1. Standard Validation Criteria Table of Contents.

  • Executive Summary. This section is the last section written and is a condensed version of Sections I through VI. The major elements of the six sections should be covered. No material is provided here that is not provided in the other six sections in greater detail. Much of the detailed discussion is not included here, but is found only in the main body of the report. This section should be two to three pages in length, unless there are a very large number of differences and impacts to address. This should be a stand-alone section.
  • Section I, Introduction. This section should briefly state what threat this simulator is expected to represent, what portion of the threat is included, what is left out, and the relationship of this simulator to others if it is a portion of a larger system, or a modification of a larger system. It also should state whether the simulator is expected to represent multiple variants of the threat, if such variants exist. The purpose or objective of the validation report should be stated. This section should include a statement that the validation report describes the status of the simulator's ability to emulate the threat at that point in time, and that there may have been changes in the threat definition or in the simulator since the validation report was written. The introduction should identify a point of contact for users to gain additional information.
  • Section II, Validation Procedures. This section should identify the directives that apply to this report. It should identify the sources of data for both the threat and the simulator, along with the process of determining the impacts of the differences between the threat and the simulator that have been documented.
  • Section III, Threat Description. This section should provide a brief (3-10 pages) narrative description of the threat as it is currently defined. The section should also state that the data has been extracted from DIA documents or should identify the other documents used as source data for the threat information. State if the DIA has approved any or all of the data that was drawn from non-DIA documents. Generally, block diagrams should be placed in this section. Operational doctrine, time to sequence from acquisition to track to launch to intercept, type of system, etc., are appropriate in this section. Discussion that builds on the data provided in Appendix A, or provides additional explanation of the information in Appendix A, should be included.
  • Section IV, Simulator Description. This section should specifically identify all functions of the threat that are included, and any of the functions of the threat system that are not included, as part of the simulation. If some portions are simulated in hardware, for example, target tracker and missile seeker, while other portions are simulated in software, for example, missile fly-out, that too should be stated. It is preferred that a simulator system be fully addressed in one report, rather than breaking it apart into two or more reports, (for example, the target tracker in one report with the missile seeker and fly-out model in a separate report). In many cases the simulator is programmable in a number of areas and could be readily changed as the threat definition changes. Significant programmability should be covered in this section. If programmable features cover the current threat estimate, the report should include this information. If there are any special modes of operation, they should be described here.
  • Section V, Discussion of Differences and Impacts. This section is the most important of the validation report. With the data in Appendix A, this is the real meat of the report. This section should address all significant impacts on testing or training that may occur due to differences between the current threat and the simulator. These statements of impacts may be based on a significant difference between the threat and the simulator, or they could be based upon a group of differences. If there are differences which tend to counter-balance the impact each may have individually, they should be discussed together. Do not address each difference of the threat and the simulator, only those which individually or collectively could be expected to impact test or training results. While specific systems that have been designated to be tested against the simulator can be useful in identifying some of the impacts of differences, the validators should consider all types of systems that may undergo testing with the simulator when identifying the impacts of differences.
  • Section VI, Conclusions and Recommendations. This section should address the overall conclusions and recommendations that can be reached on the basis of the impacts of the differences between the current threat and the simulator. Several significant impacts may affect only one type of test, leaving the simulator well suited for other tests; this should be stated. In some cases, the simulator may be so different from the threat in several different areas that a modification is recommended.
  • Section VII. References. This section should list all references used in the report.
  • Section A1. This section should provide a key to the abbreviations used in the data entries in Section A2. All items, such as NA or N/A, NAp, NSm, should be explained. Whenever threat data has no confidence level associated with it, the report should state how the data in the Confidence Level column has been coded to show that fact.
  • Section A2. This section should contain the SVC from the appropriate Threat Simulator Program Plan Annex I Appendices, with all threat and simulator data. In cases where the simulator has been made programmable, do not simply state programmable. The range of programmability must be stated along with the fact that the function is programmable. If any of the programmable items have been programmed such that they do not match the current threat definition, this also must be stated. Validators' notes and threat analysts' comments should be identified in the Notes/References column and included at the end of the section. All portions of the SVC should be addressed; however for those portions which do not apply, such as Continuous Wave parameters for a pulsed radar system, simply state "______ Applicable" as the header entry for that group of parameters. Delete subordinate parameter numbers and names in the group from the report. The threat analyst should already have done this. Do not leave out a portion of the SVC without some explanation.

Tabular data is presented in report appendices. CROSSBOW-S desires a seven-column format table, which includes threat definition number, parameter/units, DIA value, confidence factor, notes, simulator value, and level of difference (Figure 3).

DIFFERENCE/

*TSCPs

YES

0

0

0

0

0

0

0

0

0

0

0

0

 

*0

0

0

1.5 TO 2

*0

0..02/0.0555

0

72

YES

72

*0

0

0

144

0

0

*0

SIMULATOR

DATA

NO NO NO NO YES NO NO NO YES YES YES 1 MOPA(CFA/TWT) SEE TEXT YES 2 125 3.0 TO 6.5 YES 2.1 TO 2.425 YES 80 2.5 80 YES YES YES 160 NO NO YES

CONFIDENCE

LEVEL/

REFERENCES

3

2

4

4

3

4

4

4

1

2

1

1

1

3

1

2

2

2

2

2

1

1

2

2

4

1

1

1

3

3

2

DIA THREAT

ESTIMATE

YES NO NO NO YES NO NO NO YES YES YES 1 MOPA(CFA/TWT) SEE TEXT YES 2 125 4.5 YES 2.12 TO 2.37 YES 8 9 TO 15 8 YES YES YES 16(8PAIRS) NO NO YES

UNITS

YES/NO YES/NO YES/NO YES/NO YES/NO YES/NO YES/NO YES/NO YES/NO YES/NO YES/NO INTEGER TEXT FIGURE YES/NO INTEGER MEGAHERTZ MICROSEC YES/NO GIGAHERTZ YES/NO INTEGER MEGAHERTZ INTEGER YES/NO YES/NO YES/NO INTEGER YES/NO YES/NO YES/NO

SUBSYSTEM/PARAMETER

ANTENNA ECCM POLARIZTION ECCM SIDELOBE BLANKING SIDELOWBE CANCELLER DIVERSITY TECHNIQUES ANGLE SCAN DIVERSITY SPAITAL DIVERSITY MONOPULSE TRANSMITTER PULSED FREQ GENERAL NBR OF TRANSMITTERS TRANSMITTER TYPE TANS BLOCK DIAGRAM, PULSED SIMULTANEOUS/MULITPLE RFS NBR OF SIMULTANEOUS RFS SIMULTANEOUS RF SEPARATION TIME DELAY BTWN RFS PULSED RF SONCATNAT RF LIMITS RF CHANNELIZATIN NBR OF CHANNELS CENTER TO ENCTER RF SEPARATION AVAIL PER SYSTEM LIMITED FREQ CHANGE CAPABILITY DISCRETE LIMITED FREQ CHANGE DISCRETE LIMITED FREQ CHANGE NBR OF RFS CONTINUOUS LIMITED FREQ CHANGE SMALL INTENTIOINAL RF VARIATOINS PULSED RF AGILITY

CROSSBOW

NUMBER

R3371.00

R

R3371.01 R337.02 R337.03 R3371.00 R33711.00 R33712.00 R3372.00 R4.00 R41.00 R411.00 R411.01 R411.02 R411.03 R4111.00 R4111.01 R4111.02 R4111.03 R4112.00 R4112.01 R4113.00 R4113.01 R4113.02 R4113.04 R4114.00 R41141.00 R41141.01 R41141.03 R41142.00 R4115.00 R4116.00

 

The Navy may include an additional appendix with an eight-column table that adds a TSCP column or simply indicate a TSCP by an asterisk in column seven, differences/TSCP. Substantiating T&E or Training data may be documented in the report body or within a separate appendix. Diagrams and figures are needed to complete the data requirements, as well as to describe the systems for the reader.

REVIEW AND DISTRIBUTION PROCESS

A formal DOD/EXCOM review and approval of the validation report will be conducted for DSVR and IOC validations (Figures 4 and 5). Formal review is not required at CDR and OPN validations. In these events, a notification letter will be submitted by the Navy CROSSBOW-S representative (N912R4) to the EXCOM via the CROSSBOW-S Management Office identifying the validating organization, results of the validation, the approval authority, and the date. Major systems may require a face-to-face review with the DOD Validation Subcommittee before being forwarded to EXCOM.

Prior to DOD Validation Subcommittee involvement, a Navy review process must take place. Preliminary technical data is reviewed by appropriate technical personnel in draft form. For example, threat data is reviewed by ONI, NGIC, NAIC or MSIC. Simulator data is reviewed by the agency developing the simulator, such as NAWCWPNS or NAWCAD. T&E or training related data is reviewed by test personnel, such as VX-9 or COMOPTEVFOR. The specific personnel to be involved are determined by the threat type (RF, EO, C3, etc.), the particular simulator being validated, and the ECM systems against which a simulator is being validated. Points of contact are listed in Appendix A of this document, although other personnel may be required.

Figure 4. Validation Report Review Process.

Figure 5. Validation Report Approval Process.

Following technical review by DT&E and OT&E personnel, the draft report is submitted by the Navy Simulator Validation Coordinator to NAVAIR. The report is reviewed, coordinated with program users, modified as required, and then forwarded to N912, the final Navy approval authority for Navy validation reports.

Distribution of the report is determined by the particular system. The minimum recipients are CNO, NAVAIR, the respective simulator developing/operating organization, and test agencies concerned with the particular systems covered by the validation. Ordinarily, copies are sent to COMOPTEVFOR Code 54, VX-9, NAWC-AD Code SY-04 EW, which encompasses a core of testers to typically use Navy simulators. This basic distribution will, in some cases, require modification. The distribution is tailored to the specific systems involved in the validation.

DATABASE OPERATION AND MAINTENANCE

The Navy validation data is contained in a Sun Sparc I Plus data base using Unix software and a commercial Macintosh data base package, 4th Dimension. The data format is structured to conform to the CROSSBOW-S developed SVC format which is described in detail in the Threat Simulator Program Plan.

Maintenance of data is accomplished by contractor support personnel in support of the Navy Simulator Validation Coordinator, 53COOOD. Data is promulgated through hard copy in the approved validation reports. Changes and updates are made at the contractor facility to ensure configuration control and consistency in data analysis. Interim corrections (such as, page changes or pen and ink changes) may be distributed as appropriate until a report is completely revised or updated.

~ Top ~

 

NAVAIR Logo   Site Map | E-Mail Webmaster | © Copyright 1998 - 2008 United States Navy