3CE Methodology for Conducting a Modeling, Simulation, · PDF file2010 EURO SIW –...

2010 EURO SIW – 10E-SIW-037

3CE Methodology for Conducting a Modeling, Simulation, and Instrumentation Tool Capability Analysis

Mid Self

CACI Mission Systems, Fairfax, VA

Susan Harkrider

Night Vision and Electronic Sensor Directorate, Ft Belvoir, VA

Keywords: Systems Engineering, Live, Virtual, Constructive, LVC, Modeling and Simulation, DoD Architecture Framework, DoDAF

Approved for public release; distribution is unlimited. Case 10-1033. 6 May 2010.

ABSTRACT: The Cross Command Collaboration Effort

(3CE) was chartered to define and integrate common

Live, Virtual, and Constructive (LVC) processes as well

as a Modeling, Simulation, and Instrumentation (MS&I)

environment to support design, development,

experimentation, testing, and training of new capabilities

and systems across all stages of the acquisition lifecycle.

Over the past two years, 3CE systems engineers have developed a system engineering process that uses

analytical measures of performance and data elements to

derive the technical requirements for a modeling,

simulation, and instrumentation (MS&I) environment.

This methodology uses the DoDAF product set to

document operational and systems functions that are

subsequently translated into a simulation requirements

specification. The final product of this 3CE system

engineering process is the development of a structured

methodology to compare and evaluate available MS&I

tool capabilities against the analytically derived

requirements. The process was tested and refined in

order to increase responsiveness to M&S events such as the Spin Out IBCT LUT. Inefficiencies in the systems

engineering process were identified and resolved, such as

duplication of data elements derived from DoDAF

operational and system views used to support the process.

In addition, the analytical and systems engineering teams

began using System Architect, a COTS tool, in order to

streamline the development of operational and system

view products and facilitate reuse for customer sponsored

events. The refined process has recently been applied in

an end-to-end fashion to define an MS&I environment to

support the XM-25 counter-defilade target engagement

system. This paper will describe the improved systems

engineering process that responds quickly to event

planning and execution. The paper will then describe the

application of the methodology to complete the end-to-

end systems engineering process.

1. INTRODUCTION

The Cross Command Collaboration Effort (3CE) was chartered by the Army Test and Evaluation Command (ATEC); Research, Development, and Engineering Command (RDECOM); Training and Doctrine Command (TRADOC); and the Program Manager (PM) Future Combat Systems Brigade Combat Team (FCS (BCT))to develop an Army cross command modeling, simulation, and data collaboration environment to support design, development, integration, and testing of the FCS capabilities, systems, and prototypes.

Over the course of its chartered existence, the 3CE has extended these capabilities to other PMs and programs to support distributed Doctrine, Organizational, Training, Materiel, Leadership and Education, Personnel, and Facilities (DOTMLPF) development. Within the 3CE, specific capability development objectives were established to enable the collaborators to identify, define, integrate, and control a core set of Modeling, Simulation, and test Instrumentation (MS&I) tools, data management, and business processes that would satisfy the common required capabilities of the three Commands and the program of record’s materiel developer. These capability development objectives are to:

Identify the analytic requirements that enable and focus future MS&I and data integration.

Identify and document the common MS&I and data environment requirements through a system engineering process based upon an analytic focus.

Identify and document the common MS&I and data capability gaps in the environment that support all three commands and users.

Identify, prioritize, and develop capability gap solutions to evolve, control, and document a core set of MS&I tools and data that supports Army

Report Documentation Page Form ApprovedOMB No. 0704-0188

Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.

1. REPORT DATE MAY 2010 2. REPORT TYPE

3. DATES COVERED 00-00-2010 to 00-00-2010

4. TITLE AND SUBTITLE 3CE Methodology for Conducting a Modeling, Simulation, andInstrumentation Tool Capability Analysis

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

6. AUTHOR(S) 5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Army Night Vision and Electronic Sensor Directorate,10221 BurbeckRoad,Fort Belvoir,VA,22060

8. PERFORMING ORGANIZATIONREPORT NUMBER

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)

11. SPONSOR/MONITOR’S REPORT NUMBER(S)

12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited

13. SUPPLEMENTARY NOTES Presented at the Simulation Interoperability Standards Organization (SISO), EURO SIW conference, July12-14, 2010, Ottawa Canada

14. ABSTRACT The Cross Command Collaboration Effort (3CE) was chartered to define and integrate common Live,Virtual, and Constructive (LVC) processes as well as a Modeling, Simulation, and Instrumentation (MS&I)environment to support design, development, experimentation, testing, and training of new capabilities andsystems across all stages of the acquisition lifecycle. Over the past two years, 3CE systems engineers havedeveloped a system engineering process that uses analytical measures of performance and data elements toderive the technical requirements for a modeling, simulation, and instrumentation (MS&I) environment.This methodology uses the DoDAF product set to document operational and systems functions that aresubsequently translated into a simulation requirements specification. The final product of this 3CE systemengineering process is the development of a structured methodology to compare and evaluate availableMS&I tool capabilities against the analytically derived requirements. The process was tested and refined inorder to increase responsiveness to M&S events such as the Spin Out IBCT LUT. Inefficiencies in thesystems engineering process were identified and resolved, such as duplication of data elements derivedfrom DoDAF operational and system views used to support the process. In addition, the analytical andsystems engineering teams began using System Architect, a COTS tool, in order to streamline thedevelopment of operational and system view products and facilitate reuse for customer sponsored events.The refined process has recently been applied in an end-to-end fashion to define an MS&I environment tosupport the XM-25 counter-defilade target engagement system. This paper will describe the improvedsystems engineering process that responds quickly to event planning and execution. The paper will thendescribe the application of the methodology to complete the end-to-end systems engineering process.

15. SUBJECT TERMS

16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as

Report (SAR)

18. NUMBEROF PAGES

35

19a. NAME OFRESPONSIBLE PERSON

a. REPORT unclassified

b. ABSTRACT unclassified

c. THIS PAGE unclassified

Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18


acquisition decisions and enables the design, development, integration, and testing of Army and Joint programs.

To achieve these objectives, 3CE systems analysts and engineers have developed and evolved system engineering processes that use analytical measures of performance and data elements to derive the technical requirements for a prescribed MS&I environment. These requirements are then mapped to a common MS&I functional framework that enables a straight forward comparison of current and projected MS&I tool capabilities to those derived requirements. The comparison of capabilities to requirements, or gap analysis, enables specific recommendations for current or future MS&I development to eliminate or mitigate those gaps. These recommendations form the basis for a technical roadmap to guide development and integration of a composable MS&I framework that is responsive to the key analytic requirements established for the program of record.

Objectively, the outcome of this process is a valid, programmatically justified environment design for supporting DOTMLPF development across the program life-cycle. The process uses a structured approach of best practices and standards based on established systems engineering principles. The process, and resulting capabilities, leverage expertise across the commands, limit redundancy, foster consistency, and enable continuity throughout DOTMLPF development. The capabilities developed through this process have provided cross command network connectivity, a repository for requirements and engineering collaboration, and common hardware and software solutions for program test, evaluation, experimentation, and analysis.

2. REQUIREMENTS DEVELOPMENT PROCESS

The 3CE process for capability development is one that enables development and integration of technical solutions across the functional commands to support a program’s acquisition lifecycle. The foundation of the 3CE capability development process is a functional decomposition process, based on established systems engineering principles, that focuses on providing the necessary data to satisfy the analytical metrics established for the various program milestones. An overview of this process is provided in Figure 1.

The analytic metrics are described by the Measures of Effectiveness (MoE) and Measures of Performance (MoP)

that have been derived to evaluate the key performance parameters (KPPs) and other key operational and performance issues that have been identified for the applicable program of record. Underpinned by these analytic requirements, the 3CE functional decomposition process results in a cross command MS&I environment design and development model that can be directly traced to the analyst and evaluator requirements for evaluating the program KPPs and critical issues.

The system engineering processes and capabilities have been developed and have evolved during the course of practical application of modeling and simulation to support a large scale, and complex system-of-systems (SoS), such as the FCS. One primary task of this support effort is the integration and documentation of the overarching requirements for a composable MS&I environment that could support life-cycle applications for FCS, as well as other Army and Joint acquisition programs. To reduce the complexity of the task, the FCS operational space was decomposed into technical functional areas (TFA) that were aligned to TRADOC’s war-fighting integrated processes (since superseded by functional capabilities for the future modular force). For each TFA, the analytic issues were compiled and published to form the basis for defining and integrating the MS&I capabilities needed to address those issues. Once the analytic issues for the TFAs were documented, cross command integrated process teams (IPT) were chartered to:

Identify the current and future MS&I capabilities required to address the program’s analytic issues,

Develop technical roadmaps that documented the required MS&I capabilities, current capability

Figure 1 – 3CE Analytic Requirements Decomposition


gaps, and recommendations to redress those gaps.

The technical roadmap would assist the program manager and commands with MS&I development prioritization, leverage and provide focus area for MS&I developers.

2.1. Decomposition of the Analytic Requirements

Based on the program’s KPPs, a group of analysts and evaluators (from the commands, the PM, and other key stakeholders) will develop the various operational, supportability, and costs related MoEs that will provide the benchmarks for program success at each prescribed milestone. These MoEs, and the supporting MoPs, are sorted into categories aligned to operational or system performance issues identified by the evaluators and then documented in an Analytic Requirements Document (ARD). The MoPs are further decomposed down to specific data elements that are captured in a Data Collection Management Plan (DCMP). These analytic data requirements are subsequently used to construct a set of operational use cases that are intended to capture and illustrate key operational functions, sequences, and interfaces.

The use cases are documented through a set of DoD Architecture Framework (DoDAF) [1] products (Version 1.5), that includes the:

High Level Operational Context Graphic (OV-1),

Operational Node Connectivity Description (OV-2),

Operational Rules Model (OV-6a), Operational Event-Trace Description (OV-6c) Operational Activity to Systems Function

Traceability Matrix (SV-5a) Systems Rules Model (SV-10a) Systems Event-Trace Description (SV-10c)

Each set of DoDAF products is unique to the ARD or DCMP issue category containing the MoEs that are being illustrated for that use case. Each OV-2 graphical depiction contains a sequence of events that is unique from other OV-2 use case illustrations. The supporting OV-6a, OV-6c, SV-10a, and SV-10c provide similarly unique rules and event sequences for the respective doctrinal and technical tasks associated with that scenario use case.

Key data used to populate the DoDAF products are extracted directly from the DCMP and embedded in the diagram properties of the OV-2. This data includes the

MoE title, DOORS database tracking number, description, data elements, potential data sources, and calculation for each individual MoP. Metadata is re-used between views where possible and portions of the views are re-used, resulting in higher efficiency and a significant cost reduction. This process ensures that the resulting technical requirements can be directly traced to and justified by an analytic requirement.

Beyond the information that is useful and necessary to develop the MS&I technical requirements, these DoDAF use cases are populated with additional operational and interface data that can directly support integration of the use case systems into a live, virtual, and constructive (LVC) experimentation or test environment. For example, in the most recent case, if the user selects an operational node, the mission, next higher headquarters (owning organization); senior position in the node, platform(s), weapon(s), communication system(s), and sensor system(s) assigned to that node will be displayed. Each of these attributes is described using the official line item number and nomenclature so that the user can consult another military reference for more detail if desired. If the user selects an operational rule, the official statement of that doctrinal or technical task is displayed with the reference source and, if subordinate tasks exist, a link to those subordinate’s tasks.

By developing standard cross command analytic requirement documents and utilizing the DoDAF products, the 3CE process for decomposing the analytic requirements provides the basis for deriving a relevant and credible MS&I requirement set that is explicitly linked to operational use cases and is at a level of fidelity that supports specification and implementation of the environment.

2.2. Development of the MS&I Technical Requirements and Technical Roadmap

A typical System Requirements Specification (SRS) is written in text form and lists the functional requirements for a system, e.g. an unattended ground sensor system, its major subsystems, sustainment, and supportability. For 3CE, the system to be addressed in the SRS was the MS&I environment includes the developmental systems to be represented in that environment. The vetted and approved analytic requirements and supporting DoDAF products provides the source data for developing a SRS to guide development and integration of the MS&I environment that would satisfy the analytic issues established for the applicable system or program. Originally, three SRS were created by the TFA IPTs to address the Communications and Network; Intelligence, Surveillance, and Reconnaissance (ISR); and Unattended Ground Vehicle (UGV) functional areas. An additional


SRS was created to address specific near term needs for the Spin Out Early Infantry Brigade Combat Team.

Over the course of this process development, 3CE has examined and evaluated alternatives to this traditional means of deriving and documenting the MS&I system requirements. The objective is to leverage the program’s diverse expertise and to find a process that would allow the separate TFA SRS documents to eventually be consolidated into a cohesive SoS requirements document and enable the:

Linkage of each technical requirement to the analytic issue and data elements for that issue

Derivation and translation of requirements from the DoDAF products (such that a journeyman versus subject matter expert engineer could develop the SRS from the DoDAF products), and

Establish a methodology or format that allows one to easily identify the tools needed to meet an analytic requirement and identify requirements that cannot be met with the current tool-set (gap analysis)

2.3. Initial SRS Development Process

An approach to developing the SRS that links operational and analytical requirements to technical requirements was described in reference [2]. In that case, the SRS were derived using the OV-2 illustrations for each MoP category as the common, unifying framework. The requirements were previously captured within an Excel spreadsheet to facilitate the linkage of each requirement to an analytic MoP via the system function traceability matrix (SV-5a) and system event sequences (SV-10c).

This approach was both methodical and repeatable, maintained traceability to the source requirements, and conceivably could have been executed by a non-subject matter expert. However, this method proved to be highly inefficient. Although the DoDAF products for each MoP category were unique in a holistic sense, those illustrations contained numerous, redundant iterations of identical or very similar operational sequences. Since each sequence in the event chain was assumed to form the basis for a technical requirement, we generated numerous and redundant technical requirements. This output required considerable effort to organize and sort the

requirements into logical functional sections for subsequent MS&I development and integration. Subsequently, this method also failed to highlight the individual MoP data elements as critical inputs to the SRS.

2.4. Process Review and Alignment of the SRS Methodology to the 3CE M&S Architecture

In December of 2008, the 3CE analysts and system engineers conducted an end-to-end process review that captured the lessons learned from this initial SRS development, and resulted in a modified process that has been implemented for the ISR TFA, PEO-Soldier’s Counter Defilade Target Engagement (CDTE), and BCT Modernization Increment 1. This revised process more closely resembles a traditional system-oriented functional decomposition. However, the system context for the functional decomposition is the MS&I environment framework, rather than the systems that will be represented in that environment.

The framework is described by the 3CE M&S Architecture System Functionality Description (SV-4a). This framework provides a common, consistent hierarchy and taxonomy that facilitates meeting several of the capability objectives outlined at the beginning of this section. Most notably, this framework:

Enables the various TFA SRS to be more easily and logically integrated to represent the SoS problem space,

More readily facilitate the re-use of common requirements across TFAs and for other program applications, and

Provides functional divisions and vocabulary for describing the both requirements and capabilities of existing models to generate a gap analysis and technical roadmap.

The SV-4a describes the functions and functional hierarchies that represent a notional system or system under test (SUT) within an integrated LVC operational environment. The architecture is described by four (4) major functional areas: 1) Environment Management, 2) Simulation Applications, 3) System/Subsystem Representation, and 4) the Notional Forces and Environment. Figure 2 provides a diagram representation of the 3CE M&S Architecture SV-4a.


Environment Management describes a generic functional decomposition of the infrastructure necessary to manage the preparation, integration, execution, and data collection for an event within the LVC environment. Simulation Applications describes a generic functional decomposition of the physical simulation environment (simulators, stimulators, emulators, and models), to include the synthetic natural environment, necessary to replicate, supplement, and support the SUT within the LVC environment. System/Subsystem Representation describes a generic functional decomposition of the operational systems, subsystems, and supporting simulation and stimulation interfaces for a system under test (SUT) within the LVC environment. Notional Forces and Environment describes the objective capabilities of the live SUT within the projected force structure and war-fighting environment (to include threat, terrain, weather, etc). It provides context and constraints (force composition, order of battle, environment, etc) for the operational and system/subsystem representations and simulations described in Sections 2 and 3.

The outline below, from the 3CE ISR MS&I Requirements Specification, provides an example of the SRS content and shows the mapping to the M&S Architecture SV-4a functional categories.

1.0 Introduction 1.1 Purpose 1.2 Description of the ISR TFA 1.3 Assumptions 1.4 Requirements Tracking to Source Documents.

1.5 References 2.0 MS&I Requirements 2.1 ISR Functions and Interfaces 2.2 Forces and Systems Representation 2.3 Simulation Applications – Synthetic Environment 2.4 Simulation Applications – Observables and Signatures 2.5 Simulation Applications – Stimulation 2.6 Simulation Applications – Battlefield Truth 2.7 Federation Management and Constraints 3.0 Requirements Verification

Using much of the same source documentation as in the previous method, this SRS is generated by a traditional decomposition of the operational scenario into functions to be performed by the MS&I system. Systems, to include the SUT, other friendly forces, and threat, are derived from the OV-2. The

technical requirements by system are then derived from the SV-5a and SV-10c to address the key system and subsystem attributes, functions, and interfaces that will be evaluated. These requirements are sorted according to the system and subsystem functional categories from the M&S Architecture SV-4 to provide the initial outline and key functional requirements that will be captured by the SRS. The SRS is completed by conducting a detailed analysis of the MoP data elements to derive the additional detailed requirements for both the systems being represented and the supporting MS&I environment. An illustration of the decomposition of MoP data elements into MS&I technical requirements is provided in Figure 3.

3. APPLICATION OF THE MS&I CAPABILITY ANALYSIS PROCESS

Once the required MS&I capabilities for a given program application are established, a LVC MS&I environment to meet those requirements can be assembled, developed, and integrated. In some cases, we have conducted current inventory surveys to catalog the existing MS&I capabilities relative to one of the TFAs or a specific

Figure 3 – 3CE M&S Architecture System Functionality Description (SV-4a)

Figure 2 – Decomposition of MoP Data Elements into MS&I Technical Requirements


customer program. In other cases, the available MS&I capability has been prescribed. In all cases, the use of the SV-4a framework has provided a reliable and repeatable means to identify existing tools that meet the requirements, identify missing capabilities that must be developed, and ensure that all applicable LVC capabilities are considered.

During the summer of 2009, 3CE applied this end-to-end process to support a MS&I Capability Analysis for the PEO-Soldier Counter Defilade Target Engagement System (CDTE). This program application provided further validation for the requirements derivation and decomposition processes and provided the opportunity to fully implement and test the conceptual the MS&I tool capability and gap analysis process.

3.1. Counter Defilade Target Engagement System (CDTE).

3CE became involved with the CDTE system in January 2008, early in the systems acquisition life cycle and prior to Milestone B. Initial work concentrated on development of the CDTE Capability Development Document (CDD) and Operational Mission Summary – Mission Profile (OMS-MP). 3CE collected analytic requirements from the Objective Infantry Combat Weapon (OICW), and other programs that preceded the CDTE, to serve as the basis for future CDTE analytic requirements. These requirements formed the basis of the CDTE DCMP. In early 2009, the CDTE DCMP was finalized and approved by the program manager and evaluators. These analytic requirements were then mapped to the DoDAF operational and system views to further align and illustrate the requirements using mission threads from the CDTE OMS-MP.

Using the process described thus far, 3CE developed a set of functional requirements for a MS&I environment that could represent the CDTE in the LVC context and support CDTE use case applications over the program life cycle. In order to evaluate the current capability to meet those MS&I requirements, 3CE conducted a gap analysis that compared the capabilities of specified MS&I tools to those functional requirements. The tools specified by the program manager were the One Semi-Automated Forces (OneSAF), Infantry Warrior Simulation (IWARS), COMBAT XXI, and Modeling Architecture for Technology Research and Experimentation (MATREX) Battle Command Management Services (BCMS).

The capability and gap analysis was conducted by evaluating each of the specified tools against each of the MS&I requirements defined for the program application. Subject matter experts (SME), representing each tool proponent, were enlisted to support the evaluation of each

tool. 3CE engineers, with assistance from the tool SMEs, then consolidated those ratings to produce a composite evaluation of a MS&I federation consisting of those specified tools. The rationale for considering the federation versus individual tools was based on several factors.

OneSAF provides an environment that allows the XM-25 to be evaluated in the context of a complete war-fighting component, the Brigade Combat Team (BCT). This context is necessary to evaluate MoEs such as “the ability of the BCT to use firepower, Command and Control (C2), Reconnaissance, Surveillance, and Target Acquisition (RSTA) and maneuver to engage enemy forces at times and places of the commander’s choosing and achieve lethality overmatch.”

IWARS provides an environment that allows the XM-25 to be evaluated in the context of small unit performance and tactics and individual soldier and weapon performance. This context is necessary to evaluate MoEs such as “the probability of incapacitation per shot against unprotected personnel target in the proper posture associated with the given defilade/cover or stationary exposed (Threshold).”

BCMS provides for an improved representation of situational awareness and communications effects in the simulation environment. This will provide more realistic and reliable data associated with MoEs such as “the ability of the BCT to use firepower, C2, RSTA and maneuver to engage enemy forces at times and places of the commander’s choosing and achieve lethality overmatch.”

In most cases, the intent or need is to evaluate the SUT in the context of a complete war-fighting component with realistic and consistent representations of operational and technical capabilities associated with the forces involved. This reasoning should apply to most use case applications. Full scale combat simulations such as One Semi-Automated Forces (OneSAF) provide an environment that allows systems to be evaluated in a complete war-fighting context, but generally lack functional fidelity when representing new systems and capabilities. Specialized models and simulations are typically federated with the general combat simulation to provide higher fidelity representations of some new technology or operational components of the simulated environment, but generally lack fidelity across a broad spectrum of technologies and operations. The federation rating also considers the unique or specialized test


instrumentation or data collection requirements for each application.

Once we finalized the evaluation methodology, we implemented a rating scheme that was developed by the TFA IPTs. This scheme was devised to satisfy short-term and long-term event use cases. The scheme is intended to highlight those capabilities that are immediately available or can be adapted for the specific application within a one year event planning cycle that is typical of many TRADOC and ATEC sponsored events. The scheme also identifies capabilities that require a sustained or long term investment. The scheme uses a 0 – 5 scale as defined below:

5 - Fully capable: The federate, instrumentation, or tool fully meets the requirement within the context of the requirement understanding. Supporting documentation is sufficient to allow the user to integrate the product or make routine input data or configuration changes. 4 - Conditionally capable: The federate, instrumentation, or tool meets the requirement, but requires specialized support for integration with other federates or to implement event specific input data or configuration changes to mirror the System Under Test (SUT). 3 - Partially capable: The federate, instrumentation, or tool can meet the requirement, but requires minor functional and/or interface upgrades or requires modifications to a federation dependency. The modifications required specialized support, but can be implemented within a typical one year event planning cycle. 2 - Potentially capable: An investment plan has been developed and documented to upgrade existing federates, instrumentation, or tools to meet the requirement. 1 - Not capable: A multi-year investment is required to develop the capability to meet this requirement. 0 - Not applicable: The federate, instrumentation, or tool does not contribute to or impact the function.

An example of the tool rating worksheet used for the gap analysis is provided in Figure 4.

In developing a gap analysis report, we attempted to provide focused comments for those requirements capabilities that have been specifically prioritized as important by the event sponsor and for those that were rated 1 – 3. The comments characterize the primary

functional shortcomings of the federation or federation component with respect to a specific requirement or category of requirements. In the case that the MS&I federation has been prescribed by the event sponsor, the comments will note capabilities that are known to be available and attempt to assess the impact of adding that capability to the prescribed federation. The comments also attribute the gap to one or more of three categories that may help focus the resources to develop a solution.

a) Model – A model, modeling methodology, or algorithms must be modified or developed to represent the concept or phenomena. b) Data – Characteristics or performance data regarding the concept or phenomena must be generated, distributed, and validated. c) Integration – Available LVC components need to be integrated to provide the needed functionality.

An example from the CDTE Gap Analysis Report follows:

Simulation Applications – Soldier System and Subsystems.

Requirements Summary. These requirements address the capability to model or simulate detailed functions, characteristics, and performance of the XM-25 CDTE and other man-portable or individual Soldier equipment (i.e., hand-held, head-mounted, body-mounted, and soldier weapons-mounted). Gap Analysis. There is a limited capability to accurately model the impact of power usage. This deficiency could impact the evaluation of power consumption on XM-25 operations and operational availability. This deficiency can be resolved by near-term modifications to IWARS.

Figure 4 –Gap Analysis Tool Rating Worksheet


There is a limited capability to accurately model the performance of laser range finding devices. This is a critical component of the XM-25 TA/FC sub-system and is a capability that is necessary to evaluate XM-25 performance and operational effectiveness. This deficiency can be resolved by near-term modifications to OneSAF and IWARS. There is a limited capability to accurately model Radio Frequency (RF) electronic mapping. This could have some impact on evaluating TTPs, such as cooperative engagements. This deficiency can be resolved by integration of a communications effects server and near-term modifications to IWARS. There is a limited capability to accurately model magnetic sensors. There is no significant impact as a result of this deficiency. There is a limited capability to accurately model the impact of motion on sensor performance. This could have some impact on evaluating performance of XM-25 while its operator is moving. This deficiency can be resolved by updating performance data in OneSAF and modifications to IWARS.

4. PROCESS SUMMARY AND CONCLUSIONS

The original concept for the 3CE end-to-end process included development of an M&S environment inventory, a gap analysis process and report, and a technical capability road map.

The M&S Environment Inventory documents the applicable models, simulations, and supporting tools and their associated capabilities that are in use by the M&S community. The inventory includes, at a minimum:

Description of the M&S, Proponent and contact information, Functional area addressed by the M&S, and Characteristics or parameters used to describe

the capabilities in the inventory.

The Gap Analysis Report is a document that reports the gaps and aligned capability in the modeling and simulation environment inventory as compared to a set of requirements. The report includes:

How a gap was identified, Alignment, or the degree or level to which a

capability satisfies a requirement, and Analysis of potential solutions to the gaps.

The Technical Capability Road Map is produced after the gap analysis is complete and includes:

Description of the technology subsystems,

Interfaces with other functional areas and the interfaces within the functional area,

Customized SV-4a to further decompose the information included in that documentation,

Overall schedule to develop and/or integrate capabilities that were identified in the gap analysis report,

Evaluation of cost, schedule, risk, technology, dependencies, and

Rationale and recommendations for how to proceed.

The 3CE SE process has proven to be an efficient means to ingest analytical requirements to create a set of technical requirements that are valid and traceable to key analytical issues established for a program. To date, 3CE has executed all aspects of this end-to-end process except for development of a technical roadmap. Through each stage of the process and where appropriate, we have tried and evaluated alternative process approaches. At this point, the MS&I requirements development and gap analysis processes that have been described in this paper appear to be the most efficient and effective means to achieve the stated objectives for those processes.

There are aspects of or extensions to the process that could use further definition and refinement. These include developing of a common framework and content for an MS&I inventory, including methodology and metrics for verification and validation (V&V), and creating a System Design Description (SDD) for software development from the SRS. As of the writing of the paper, we are executing a streamlined version of this process for the BCT Modernization (BCTM) Increment 1 program. This modified version of the process forgoes development of the DoDAF products, but will produce a Technical Requirements Alignment Matrix (TRAM) that provides an extension of the SRS to include methodology and metrics for verification and validation (V&V) of the MS&I environment. In the future, we should be able to report on the utility of these efforts in support of BCTM Increment 1.

5. REFERENCES

[1] Department of Defense Architecture Framework, http://cio-nii.defense.gov/policy/eas.shtml

[2] Harkrider, Susan, Clegg Jon, & McDonnell, Joseph. (2008). Using the DoDAF to Create a System Requirements Specification. Spring 2008 Simulation Interoperability Workshop.

3CE Methodology for Conducting a Modeling, Simulation, and Instrumentation

Tool Capability Analysis

Mid Self

CACI Mission Systems, Fairfax, VA

Susan Harkrider

Night Vision and Electronic Sensor Directorate, Ft Belvoir, VA

Approved for public release; distribution is unlimited. Case 10-1033. 6 May 2010.

Outline

Cross Command Collaboration Effort (3CE)

Capability Development Process

Requirements Development Process

Decomposition Of The Analytic Requirements

Development Of The MS&I Technical Requirements

MS&I Capability Analysis Process

Process Summary And Conclusions

2Use or disclosure of data contained on the page is subject to restrictions on title page.

“Purpose Origin” of 3CE

• 3CE objective per the MOU (July 2003):

• Maximize the rapid availability of transformational technology to the field soldier by leveraging the synergy gained from integrating the activities of each of the three commands into a holistic cooperative effort.

• DUSA OR Task to PM FCS MSMO:

• Ensure compatibility among the respective M&Scapabilities of TRADOC, RDECOM, ATEC, and the FCS LSI in order to support concept exploration, systems integration, analysis, and acquisition of the FCS BCT SoS.

• 3CE purpose per the MOA (December 2004):

• Develop cross-command Army M&S and data environments that will be used in Systems of System (SoS) design, development, integration, and test of FCSFoS components, systems, and prototypes within a realistic FCS BCT context.


Mission: Define a common, cross-domain Army M&S and data environment for design, development, integration, and testing of systems and capabilities

Intent: Identify, develop, and maintain a core set ofM&S tools, data, and business processes that meet the common requirements of the three commands and Army PMs for conducting life-cycle DOTMLPF development

3CE Mission and Intent – Unique Capability

Operations & Support

Incremental Development

AProduction & Deployment O&S

TechnologyDevelopment

Engineering & ManufDevelopment

JCIDS Acquisition Process

B C

CDD CPD

User Needs

Joint Concepts

Capabilities - Based Assessment

OSD/JCS COCOM FCB

Strategic Guidance

MaterielSolutionAnalysis

ICD MDD

Technology Opportunities & Resources

AOA

LiveVirtualConstructive

Concept Dev

System Design

System Dev

DT&E IOT&E Operations

3CE – Core ProductsProcess &

ProceduresData Toolbox

3CE Network

TRADOC

RDECOMATEC

3CE


Capability Development Objectives

Identify the analytic requirements that enable and focus future MS&I integration

Identify and document the common MS&Ienvironment requirements through a system engineering process based upon an analytic focus

Identify and document the common MS&I capability gaps in the environment

Identify, prioritize, and develop capability gap solutions to evolve a core set of cross-domain MS&Itools


MS&I Requirements Pedigree

MS&I Environment linked to and justified by the cross-domain analytic requirements

Material solution must be capable of detecting a minefield 90% of the time

MOE/MOP# of minefields# of minefields

detected% of minefields

detected

The simulated SUT shall provide the capability to detect and geo-locate scattered and pattern minefields

CDD/ORDRequirements

AnalyticRequirements

CapabilityRequirements

UserRequirements

A/ERequirements

MS&IRequirements


Analytically Driven – A Unique Process

› Task› Sub-Task› Task› Conditions› Standards

METL

TrainingRequirements

› Task› Sub-Task› MoEs› MoPs› Data Elements

DCMP

Analytic andEvaluator

Requirements

Capability Packages (CPs)

UJTL / AUTL

A credible systems engineering process for designing, developing, and

integrating common LVC capabilities …

… enabling a programmatically and analytically justified MS&I environment

to support DOTMLPF development across the program life-cycle

DoDAF-Based

System Engineering

TrainingObjectives

Program (PoR)Development

ARDRIS


3CE Capability Development Process

KPPS, TEMP, FACTs,

M&S Community,PM/MAT DEV, DTE,

SIMEX, LUT, L-V-C, etc…

• Research Requirements•Test Requirements •Training Requirements

• PM Requirements

Source of Requirements

Requirements:• High Level• Analytical

Basis• Across

Domains

Analysis/Evaluation• Identify Requirements• Consolidate• Archive• Verify• Prioritize• Decompose• Refine

System Engineering• Assess and define MS&I

Requirements• Identify MS&I Capability

maturity levels and “gaps”• Refine Capabilities

Development Road Map• Update Knowledge

RepositoryList of MS&ICapability Gaps

Prioritized Requirements:• Analytical• Other

Prioritized List of MS&ICapability Gaps

Command Development• Identify Current Capabilities• Design MS&I Solutions• Develop MS&I Solutions• Develop Technical Solutions

Infrastructure, Integration, & Verification

• Validate and Verify Solutions• Integrate MS&I Solutions• Configuration Manage Solutions• Manage Current Capabilities

MS&ISolutions

• List of Configuration Managed MS&I Solutions• Technical Capabilities• Business Processes• Standards

Capability Development Process

User – Event Manager• Facilitate Event Planning• Facilitate Event Execution• Facilitate Accreditation &

Certification• Leverage 3CE Toolkit

through the 3CE KR

• Event Requirements


Requirements Collection & Definition

• ATEC Requirements• RDECOM Requirements• TRADOC Requirements• PM Requirements

Authoritative Source Documents for Requirements

Database of Categorized Requirements

• Requirements• Related

Requirements• Categorization• Characterization• Conditions• Operational &

Technical Parameters

Information Mined from Database

Decomposition of Requirements

Data Elements

Calculation

Potential Sources

Intended Use

Definitions

Scenario Requirements

Output sent to Use Case Development

for System Architecture products

Provide Output to & Collaborate

with Users

EvaluatorsPMs

Testers


Use Case Development & Event Requirements

Decomposed Metrics

FM 3-0Operations

ARTEP71-3-30

BCT Staff

STPSoldier’sManual

FM 71-5Army

UniversalTask List(AUTL)

Doctrinaland

TechnicalReview

andSynthesis

Identified from credible analytic source documents

Created from currentdoctrinal sources

Identified from credible technical source

documents

General use cases

Fusion of metrics, doctrine, and

operational elements, tasks,

and activitiesIntegrated use cases

AV-2from DCMP

OV-2

OV-5

OV-6

AV-2from FM/TM

Enables system engineering

to define a relevant and contextual

MS&I environment

OV-1

Data elementssources, &

calculations

AnalyticRequirements


Use Case Library – System Architect


t:a"" £rlit 'J[Pw Fa·.rnrii'Pc;. ! nr.lc;. !:[Pip

1} .. -;:z ~ AKOf DKO Webmail (MAP ... ~ &u.ydup~llics Hurr t: ~cl ... X Dl . !i}j ~ - ;;, ~;Jgc • 6 T.Qols • , . •

f-OCUS AvCI a.Y-2 CW-3 0\.·-4 0'1-f> SV-4 CAOSS co..-A'<?a i'bn- 0't'C fl"icW 'l')tegrated lnfotmatJon O·gO:nit.:::tft'ln 9Jsint~t s:r~:em

~pecifi: ond ':>ic-lioo.-.t) E~tchange Hi~ron.:hy Ae1Mte: ful'l"ltonitlrl)'

Products Sumna·y M~tnx 0HI)l.;f ,_,tun

(Att:tr.'1rtri Scpu;doy)

Fo.."'..s rN-1 OV-1 OV-E\11. c:v.oc S'Mi fN-111C ~ea

Spectnc High Gmphical OpcrotlonaJ EvenV Brot•m• ~~~·-Products LlVOI Oepictian Rules 1race flln;&an 1:•111111

Ovel'\'le-..r Model Ou1gram Ttocoa•dr.y Tra::e l>lltlrill Oest~lor ~M-25 Counter Defilade WeQPOn -

f-OClS LQih:d itt Accur~c-) S\'lldior T~rgct "'ovrQnmQ'kl -:t =!"!i:.brUyl Eiafety l..ogi~t!C$ M~npoNcr ,A,rbO'r'IO

'v1obdl1:~ kCUI$ft or/ ons1derahor AVill$blht"/ • nd Ooe'QUOn$ A,.;.a F re Co•C r t.~l lil(lli l ll oet r • ~llilll P~:r:,cn ntl

Ce>tegc<i es rnagra;lo,.. .ONPPINT)

(1 lJ (1 21 !131 1141 [' t1 [21 : 12:1 12 31 I~ •I !H l

f~c lrom~greti Soldi&• tJu'JP.;u No! USEd Not J'ed riot Used Not Jsec Nc•t 1Js3d Not Usod Not Used Nlt u~ed Env¥onn.et~ul 5.~rwn b1lrty aob9C31

EtT~t.;;-tj Chcn'lGill (x: )(1(1 )(.)( ~ J (>.XX( I>< X >:J (K. < )IJ ("t )( I( I (x x:~< l ( tl X tl j

(E5; .. rlamiJ)aU ::ilJ'VW3bltl1y

(~ .11 '32f [3 '1 Ill

8 lnternd I Protected \A ode: Off Ql. tno% •

JEOINOI.OGY DRIVEN. INARRGHIER FOCUSED.

OV-1 High Level Overview


lr h nlry C :nrrpAny H~E.oqua.1~~

, t' t. 1~ ."if~ IIUI

Sut :airr;&rt

ANAU''1"1C MCASUP.IS {OIPSTIC:<SI

Eng"g&men! T 11'\E

~*:tr 31. So.;Uii\J

O~oumed Soi:IC·~

---~2 u.l ~Ui:J'J

O-ccupied lreurgent EE.-ee

Daurt Building 1 M-" 1_11

,.!~=>:l_12

_.:fl! nreft _ _ ___ ___ _ _ _:T~o !1JIIie~cii)·t!!i"~Y~'1----------~ Te: nnl:al

ir.sure:ent ocou> Ill f'>atural De113de


OV-2 Graphical Depiction

Diagram Properties:


OV-6C Event Trace Diagram

Diagram Properties:


Embedded Metrics Data

15

Description: Probability of a threat target being incapacitated for each shot fired from the system for ranges from arming distance to 500 meters

DOORS Requirement No: 3CE-XXXX

Title: Probability of Incapacitation Given a Shot P(i/s)

Diagram Properties:

Use or disclosure of data contained on the page is subject to restrictions on title page.

Data Element Requirements Collection Method

Number of HEAB rounds shot at identified targets M&S output; observer; instrumentation

Number of targets meters incapacitated by system M&S output; observer; instrumentation

For each engagement, range to target M&S output; observer; instrumentation

For each engagement, number of targets M&S output; observer; instrumentation

For each engagement, number of munitions shot M&S output; observer; instrumentation

For each engagement, number of personnel incapacitated M&S output; observer; instrumentation

Calculation: Probability of Incapacitation Given a Shot P(i/s)

= (Number of targets incapacitated / number of rounds fired) (100)

3CE M&S Architecture Systems Functionality Description (SV-4a)


4 .l \ UDt/ Ur{?UI~l!C<t'l ~rru:wre I I

4.2 lndlg&nous lhhllbitants & Non· Coinhatarlt-8

'I Notional Fore•• and Environment 3.1 Subsystem •• 3.~ System •• 3.3 Distri buted Common Operating Ple1ure • 3.1 1 Su-vh.a~llty II

I ~ .• ~-eo"' I I 3. 1 0 Sl!l iula:lor{3tlmulatkonl

Emu.au on t.ltQffaCG

'"" .......

:JJ .2 Armament I -3.2.1 Survl\lablllt)" ::L2 . .2 A~tMmet'll I I ~.1.~ MCD!I!IY I

l w~m~ I 1 .. ~ •• 1 .... , I "" I ""'" 1 ,~ I

3 $ystom1Subsystom Roproscnt:stion

2. f force Representation •• 2. 1 • Aggregate li:'V4::'1

c~uv'V~-it1Mil1

AnMI'r'lenl

2 . 1.2 Dh~'t1twted S}·~lt~•• •

II:= :::::;:;::;;;r., :==: II MOOHit(

,---.,,..,=.,..=-c=,..=---,1 '[ --t;>"·'=""'""==-:---,

2 .2 S)'nth etic Natural Environment ~.~ 1 En•tironmontal

r~'-un=•=•o::,::-.,.::J, L..!._e.Trun I r1 •w:u.::,::;,h::, :-, ' I ~or:ants II Br.ody of Wsl!"r I 2 .2 .:.! O r:;eerv.ablee & Sig nalUrea

T\OOU&t!C Setem1c PIQtforn ~·D i '3·0 rAagl"!e:tc OVI

Ml:.od&l Rada: l.aoer

Cvllun:al uv Vo~ 2-0 1 :';-0 Mu:tul :;;1\R '"

2 Simulation Applications Functional Area

1.1 System Physical Interface (3y~leu/Sul~)~lt:r'll , h •~llumt:l i&lk>• l, O~lb /\(;i.:l!li:,iliu n)

1.2. 1 StitnJio!ion ~pplca11on;

1. 2 M&S Applications

t 2 .2 Emdotion/Prototypc Ap:l!ICSIIcns

1.2.3 Simulation App(k:atlons

1 .3 COIUJllOO Operath1g Env lronnHU11 (COE) SwvJces

t .4 . 1 N ff>tWork -OUI'Id4tion

l •"3.2 Monaj:!OTICT'lt SO?rvlces

1 A lnfmstl'liCture

1 4. ~ t:.ornpu:er liM '

1:3 a ~liooti·:m P~mmirlg SP.rvl..,;.s

I 4 4 C/S f'b~·vc:!IQ('I s ... rvlt'lii<S

' 1 s .;: Pr1o0p11~1lnn .&. tnlWiization

M~r-RUI:Irn"'n'

~ Dela ;)rF!flRmurn

I

F )T:Ir,tir)l! MCr)lto.-lng

DHin nttbli..'"Ollc:~

E,;m:a..liut .!,)'l'lt'Mn:l'lll.ll~

t Managemen t F unction a l Arem

1 .5 Toola

na ~:;.

I Dala I .\cq.JI:sltOf'l

I CatrlSh>rt'!ge

Data. nedudloo

Data :velu~:~~~

Repo<b

~ .• 3.2 lntE:-IIis;enoe Fusion

·~r~antte II ~e$01\IE!'

Identify II IntErpret

Correlate II Ceterme

ASXt$S~ II P1o.C!ta

2.3 Behavior

7:\ ? AtU''"!J04kl llnil

Aolivit,. I I lnlentlo,:~

•• Ill d,~;, ~ol»uc• I 2 . 5" Battlefield Trutl"l

5 . live En\lironmcnl

\'vE& bi:-'Wdl X

R""'ollm«> f'\l\llT

~""'~~V"""'o')

~~,.~Au;.-1

Kl'lf1Wiod9'1 Ri;)allf!OIY

::: .... ~ hl oo•<~U.·m~

1 .6 3CE'N"etwork

1 fi ? AT N

I '3.3 0 \IL

l R 4 OREN


SV-4A Category Descriptions

1) Event Management- Functional decomposition of the infrastructure necessary to manage the

preparation, integration, execution, and data collection for an event within the LVC environment

2) Simulation Applications- Functional decomposition of the physical simulation environment (simulators,

stimulators, emulators, and models), to include the synthetic natural environment, necessary to replicate, supplement, and support the SUT within the LVC environment

3) System / Subsystem Representation- Functional decomposition of the operational systems, subsystems, and

supporting simulation and stimulation interfaces for a system under test (SUT) within the LVC environment

4) Notional Forces and Environment- Description of the objective capabilities of the live SUT within the projected

force structure and war-fighting environment (to include threat, terrain, weather, etc)

- Provides context and constraints (force composition, order of battle, environment) for the operational and system/subsystem representations and simulations described in Sections 2 and 3


MS&I Requirements Derivation

18

MOP Description Data Element Requirements MOP Illustration Derived Requirements

MoP Probability of Incapacitation Given a Shot P(i/s)

= Probability of a threat target being incapacitated for each shot fired from the system for ranges from arming distance to nominal range

1. Number of HEAB rounds shot at identified targets

2. Number of engaged targets incapacitated by system

3. For each engagement, range to target

4. For each engagement,

number of targets

5. For each engagement, number of munitions shot

6. For each engagement, number of personnel incapacitated

OV – 2

OV – 6C

SV – 4A allocation

3.X1 The MS&I Federation shall provide the capability to model or simulate the CDTEcharacteristics, functions, subcomponents,

and their performance to include:

• Semi-automatic weapon system• Day/night full solution target acquisition

and fire control • Low velocity 25mm high explosive air-burst

(HEAB) ammunition

3.X2 The MS&I Federation shall provide the capability to accurately model or simulate the fly-out, ballistic, or non-ballistic trajectories of missiles and munitions.

3.X3 The MS&I Federation shall accurately and precisely model, simulate, and represent the terminal effects of weapons and the resultant battle damage to humans, platforms, systems, subsystems, other battlefield objects, man-made structures, and the environment.

3.X4 The MS&I Federation shall provide the capability to model or simulate the conduct, use, and effects of camouflage, concealment, and deception techniques.

Use or disclosure of data contained on the page is subject to restrictions on title page.

MS&I Requirements Hierarchy

TABLE OF CONTENTS 3

1.0 INTRODUCTION. 4

1.1 Purpose. 4

1.2 Assumptions. 4

1.3 References. 5

2.0 REQUIREMENTS. 6

2.1 Simulation Applications – Force Representation 6

2.2 Simulation Applications – Systems and Subsystems. 7

2.3 Simulation Applications – Soldier System and Subsystems 9

2.4 Simulation Applications – Synthetic Natural Environment. 11

2.5 Simulation Applications – Observables and Signatures. 12

2.6 Simulation Applications – Behavior 14

2.7 Simulation Applications – Stimulation 15

2.8 Simulation Applications – Battlefield Truth 16

2.9 Data Management 17

2.10 Federation Management and Constraints 18

3.0 REQUIREMENTS VERIFICATION. 21

APPENDIX A: CDTE MEASURES OF PERFORMANCE 29

APPENDIX B: 3CE SV-4A 37

APPENDIX C: LIST OF ACRONYMS 38

Requirements mapped to

SV-4A functional categories


MS&I Tool Capability Analysis Process

Each tool rated against each individual requirement

Tool SMEs support the evaluation of each tool

Tool ratings consolidated to produce a composite evaluation of the notional MS&I federation - Provide a complete war-fighting component with realistic and

consistent representations of operational and technical capabilities associated with the forces

- Full scale combat simulations (OneSAF) provide a complete war-fighting context, but generally lack functional fidelity when representing new systems and capabilities.

- Specialized simulations provide higher fidelity representations of some new technology or operational components, but generally lack fidelity across a broad spectrum of technologies and operations.

- Considers the specialized test instrumentation or data collection requirements for each application


Tool Rating Methodology

5 Fully capable The federate, instrumentation, or tool fully meets the requirement within the context of the requirement understanding. Supporting documentation is sufficient to allow the user to integrate the product or make routine input data or configuration changes.

4 Conditionally capable

The federate, instrumentation, or tool meets the requirement, but requires specialized support for integration with other federates or to implement event specific input data or configuration changes to mirror the SUT.

3 Partially capable The federate, instrumentation, or tool can meet the requirement, but requires minor functional and/or interface upgrades or requires modifications to a federation dependency. The modifications required specialized support, but can be implemented within a typical one year event planning cycle.

2 Potentially capable

An investment plan has been developed and documented to upgrade existing federates, instrumentation, or tools to meet the requirement.

1 Not capable A multi-year investment is required to develop the capability to meet this requirement.

0 Not applicable The federate, instrumentation, or tool does not contribute to or impact the function.


Sample Gap Analysis Worksheet


8 1.2

l t:t:l II .:~ pp.-op.-i.:~ te .sceMrio for .:~ n in font-y corrpu ,y coTpone1t of o Orig, de Cornbd T eorr

1cc,r duotn> open to1e againet conventional and Mn ~onv3nti::lnal ·:hreat •orcee..

The U~l Fe<!erdbn ~tall p.ro·td e th:- capabilitt lo repre~eot th:- fLit C·>nti'luLm of mittary ••••·atio.:S"l fmrn r.•1nfP..npnr~<ry ~~fl:lhiity In full .!::(l:!:r:frum h igt,.i'li~H.ity mn f irt o1pF!r fl fi'ln.$. flnrt .!::hfl ll inr lur!P.. 'hF!

reoresenunon or ar aoaltJVe. nMern eQlJilDeo con\·ennonll tnr.~at aM a osocns:1cateo noncorventoullnsuroert tnreat. Tht'-1.1$&1 ft:l.lt:~ t l iJn Sl l:lll ~IUJiJ t: Ill: l,;llj.•I:IIJilil·f lu l t:l'l t:-St'lll lll lC.J 111i11 Ul (it:., IIIUI.l t:l l:lrld , ;u.,lol' l.he $p~-cifc c?nfgJro:ic•n$ .,,, d P.~·r 'orn,nce} th~- tv -: $)'~tem Lndert~t (:3-Ul} o.nd ether li'oe $)'Sf:m , !o inch. de ttreat a.nd non align&:! fc.rcee, n tte eirnulsted en·t i·oo113nl. The U~l Fe<!erdbn ~tall p.ro·td e ~pecific ll.nd detaile-d eotity.te-ve-1 f Jnctioral re.>re;.errtd bns "f,, hP.. .. ~I JT mrnpr<nP..nf.~ (i F! . ~nld iP..n;., 1 oit.!t, ll-A · fn~Tl'f;., $.~1~11~. FQii;lmP..rrt. And nP..twnrk ir tF:r 'Ar.p-_o:;.)

so.eareo ror tne ooera11on11 evert scena.no.

Tht'-1.1$&1 f t:l.lt:l t l iJn $( 1:111 ~IUJiJ t: $j.<t:~.;ill.,; ·:IIIIJ c.1e::ll:lilt:l.l t'lllity ·lt'Vt:l rJnl:liUI I:II '"·""'" '''' 'jJU>til 3JT fr.e1dty •orce COT1,,one1b (i e., $>, l:li: l$ units, plolbrrr,$ $)'$:ems, equprner.t, on1

ioterfa~eoe) tha: w II di'ed:ly nte·ac: wtt or othe·w b e eLpport SUl fu1cti::lnatily or Oe n " '' SIUT • c••• o• ope: stiors du·ing execLtbn ofthe eve.1t sc:-narb. ThF: US/.1 FP..<!F!f'~<fhn $_t,AII. AI 11 mo rr1111 pr.w idf! l'!)!)rf!!)flf'!: f1 or.tinn.'ll rP..r•rp-_o:;.P.O IA 'iM~ nf

Yo rat~-arour.a or non-oroanc auam~ntato1 tc·rces ce-.. u:s . . :weo coa·lton. or mreao soecme.l rc-r oo.eratoul event scenano. Tht'-1.1$&1 ft:l.lt=~ t l iJn sl ~:~ll ~1wiJ t: t;L'II::t>ll u..:liYt'-$iluu l!l liJn~ u1 ~~• U!JI:Ih:, 1i tutl .;uullu l ~ltliJ i t::>

c.:~n tosk ' nd c?ntrol lv -: o.nd $imul.:~ ted 3Ul $)'"$le11s, $ee~ted other A.r:rr( o.nd .. oint .:~$$C-I$ ' nd !hrest ~yete--me ae oeceeearytc· exe:ute ·:he e-~tnt ~ceouio.

ThF: US!. I F P..<!F!f'~<fhn $_t,AII prn'J"i1P.. $.pP.r.ifi~ .'tnrl r!F!tAiiP..<! F:otity.IF:VP..I f 1nrtinMI "''""'"'••Jhn~ r>f tnrest. neural. aM ary otrer non-atiJneo rorce ·:ornco1ems (I.e. so101ers. u1r:s. o1atrorms. systems. ana eou P.n~nr. mat wtlt1teraCI wrn t1e ~Ul or ce tn t1e ~Ul ar~a or oo~ra:tc·ns OJrtna execu:tc·n or lilt: t:Yt:ll :::OI;t'lll:l l iL•. Th~- 1.13&1 f ederdbn st.oll :>ro·l"i:le specific o.nd detoiled ~-ntity·k-vet f Jnctior.ol re,resentd bn$ of the con t•o!oo: o.od oon~ont•o!oo: i1digcMU3 c·r o:hcr bcol i'lh c_bito rrt~. rcgordle3-3 •>f force o lcgOncc, tha: w II interact with ::he sur or be in ::he sur area of operdbns during exe.~utOn of t1e eve.1t

4 - Co1ditionaiV ~A(l'l biP.

Commertb

$.oli:ler and ·;mall Corrbat Uot p.rirnary •ocus at Pa:oon !e-.re-1 a.nd Cnrrpary IP..v~ pn!U.ihiP.. D nrP..rrtly r f!(l'P$ .. '!:nt A .!::ln'll .!tF.t of

Ot•erfli) OS.

IIIKJ

4 - Cv uJitiVI I II I~ ·, t:nc.fly lur l:t: UJIIII'L'IIt:nl-s k 'UJSttJ 1:11 Gt uu uJ SukJit:l 1:111d cop, ble ~~'mo iii U 'n~ llevel

:\ . PArtiAl!)·

C8D3Die

4 - Cv uJitiVI I II I~ cop, ble

4 - r:o,d"ilinnfi iV

C8D3Die

4 - Co1ditionally copJblc

Pl~<tnno IF:VP..I A0•1 hP..Inw Typir.A ly r!n on· U.!::F! Al)grP.gl'fP..

I'"'"'""""' o1s Dlt couo (s:ano .mne c-r a:s:route<~)


Sample Composite Analysis


lne lA~ e cent ) n s nt 1 ~-_,,. o:~ ::'le C3Dat 111v:: ' repr~senl ar'l }IMUit :t 31: ·:H e nllt\' t ',e l, s 1 B IUII ~ 31 :'IGI sp~ ·oorlt :t 3 ~~nsriC·IC 31n 1nrar1r, corr ' 31fl\' cc 'l'loor ~ 'It or s c.r ~see Co,.. ) 3t - e t M C)nGIUCIIno "~r811C·r 3 31Q31n~ :

·~~ 'l~i '" : ) 'l31s no r ) n-cor W!'niiH 01. ::'l 'e8110f~t 3.

Tile lA~ ~-ecent ) n s nt 1 1'._,,. o:~ ::'le C3p at 1~:;, repr~sen1 1nt n. ·~~ 'It 'lUurr _, .. 'I'IIIIUI'~"pert : : 'Is II' OM ·~) 'lterq:·)rsr;stat·ll~:;, • Jl }pe CfluM, 'I Jh ·lnl ~ '" ~lt1 r:ormn np~·ilnnn~ H :f ~MIIInNII\1~ · t :'! r~pl!! ~~n!Mir r , . il 'l il:'l:lplt..'i!, 'I'IM!' TI ~(jl . ;'):'lMMr~nllnn "'" 'MI $'1r :'l.'l ~Cipt ~·ri\'F-:t, Mn

(':N M''" ' .n :lllnt.u Je nl mrr ,'lt Tile lA~~ I ~=ec~~r:~t ,,n t.n:- 1 r ·:~,• 11:: -,.~ C'lp:ltA 1~ -., r~nr::t.~nl :~r .1 'l'llrr:-· (I ~ • 'IIU+h' ; '1:1 ~ :i n II , ; J:: 'It: ~ ;po '( ilio:u onligu ,d :11o:: : 11 :1 :lc:llul'lllll ll o·;o '1:: I ., , . :1 r o"u:; u1 :!::1 lr.:;l (~liT) : 11 ol :o '11:1 lk : :)T ::·u:;, lu iuo l11ol:: 'ITt:: II ; 1 :111(111

,, :JIIr.d fuu:::.; 'I 'lr. :;in o.l ,d::d r.INiUII l'lt:lll Tur. IA~~I ~=r.d+ :l.ll :on ~ ;lo: I pr :" ' ol:: :pr.o irir: ,nod + !+ ' •< ~ :·:1 l:nlil)' ::,•o·, (I, u:· : '•:d u :p•o· ;::nl:di<ol r ;, · ·1:: <::orub.;J, nol :n~+ ! 1: '' <lltl !MI:nd ill+ li!]::tiiiU:: o• :d·1r.1 :.".::1 ' ' IUbii<JII:i l::gUI:J:;; :; ufrUII.I..: ;.. :: ;,~i :JIIot:.UIUI Yrill 'IICIUd \YiUIUIC su- Ql b:: 'l l'l:: SVT ;.':;;J uf QI. I..:' UtiUII:i l}; •ing CJ.CUJtiUII ~' II ..: :;·l ..:r . ; •.:::nu1k Tn11 US61 F11d~:~ul :m ~:>he. I I." "'' dil l'11:1 ~"alv fil! l:.~ I IIIMI:>IIIII<II :J ; imulc..!:' J 1\l::lli~:>lit.:t.:>.lfi U 'I JIIi~tiUini !:'' 1Vii ;J 11rll!:'' ~t:.• -. •.;'; :J11 U111 ~:~H!idli ~ ' dJ . J a nd >o; -:JIIU 'E ~ds to th e vark;~ i 1di1• :1-Jal nodu ~nccrr ~31ssiro ::t ~ !>atl!e ccrr ·,1a nd n~tw-:>,._,

lne IA:.:I&J ;- ec:eut ' n s nc.1 ~-.,,. o~ n e capa t · 1ft':::> repr~senl a n ~lnlUii:t

:· --eat cap¢:> :•u n atart e~Pt:lto :::- h t: ve a r ::1 11ay :>e enco~ 1:~reo .r It~ ·; :Jre nrteer t' ~Jnau SIIT.Ul !IOO. j'~•ton6 - :!n tems and :!Uti6'16K-m6. Tnc IASal Fcdt:l:ll :.111 :;hU I.'" :.I>' U:; l'lc CJU<Jt<lil! l:.~ m ud:: :.11 :;in J :1l:: l'lc 'J'Ic ·. :.I 'll:> ::11 oJ :.1\llfUinan~"' d n Jnnt: oJ ·;,I uu1 :.1 J •. a nd H J :Jia1Juu ·1 ~.

Toe U361 F edeut )O 6hc. l , •. , ,. d~ n e capa t · lily:;, mod~ -:>r s iiT J ~h h e : J 'IC: :> 1s a r d =·~rfor -,lance c·f rE7Nt: 1o:~d. Unillt-je d ur!>31n un~rs. Qf)Und HOSCof~, 310<1 rr JOib00$ 11910:~

lne IA:.:I&J ;- ec:eut :>n s nc.1 , .•. , ,. o~ n e capa~ 1ft' :: ' moo~ -:>r s •IT J ~u ne • J 'IC: )16 a r o =·~rror ·,,ance c·l ~ • 11a rr ~<I ort: J 'l<l. a~r. a r ::1 ~ea Plai!Cor ll H~:t llS.

1 ne IA:.:I&J ;- ec:eut ' n s nc.1 '·., ,. o~ n e capa t · lito':::> moo~ -:>r SliT J ~u a 1011 : ~nt 1uum (1 ?. non-1 ~ : -~1 3100 ll!'lnu " llrecta no r :J: -ecth-e \~0'·~1~ a na ?-?cc~ ~\·~ :? llS.

lne IA:.:I&I ;- e oent )O s ni 1 ~-,,. o~ n e capa o 111v:;, accJratuvm"O~I )r 3 'I'IUI81t It ? · ·r~.: :·3111 n ~ ~-non-,31111 30 ~ :: ·311eaone~ -:· 'I'II SSII e~ t 'l 'l 'l'lunlllor ;;

A ~.: ~·;t, o.n ·J # 'JIJ. u.s.~J

~~.

• ~~)7, 04 ;..) -)~)9, 04-~)

~~.

A !=.A.17, R-l.:..:t .:t~1!l, R.!4·l l),U?,

• ll.A.17, R.l~:t .:t~1!l, R.l4~

l),U?,

c ~112

A l:'1:S.'.l::I•U:!I !11:S\J.l:SH •:J l:'1-1:!.

A ~-437. 84~"3 -3439. 844) ~142.

A ~13:'.8·1~3 -a-139.8-11·) ~1-12.

A l:'1:S.'.l::I•U:!I !11:S\J.l:SH •:J l:'1-1:!.

A l:'1:S.', l:S•U:!I !11:S\J, l:SH •:J l:'~.

A l:' ~·.s:. l::l4':.s # '.SIJ, l::I4-~J

l!~.

') · ll v >· Olio; ·~ :,3Cie C308t· li

s -n "! , _ ' . ·~=;.3Cie C~"'llt ) n311

J l"';'lf>l\:lli! r: lp::~r.t.:

• ~ .. y ·' :':J: r ,'1 :; :;:~r:- "! (: . • ;•:•blr. ·~•paU: · lf!:ll<l+

• ... r (: . • ;•:•blr. .:;, ~ :Iii :on:dl :II i ( ; ,!1 :: +";+I :li :no:dl)'

J I.;JI. ;,.bl:; ..:JV<Jl<l+.

3 - Pa1li:..11r 1 - 2 · ~ . ';}<II.¢ ' <.: : :Ja bl!l Cv :Jil :.~nall Pul¥111ic.llr ..: ~val<!+: ~UITIIUI .<.i•. H \!>,; · ~11\1"'~ : 'ld \1\'JIU:Jl\l lh+: ;; caNbh CO,·! ble i r·~act )f d.Jta or·.idH :<: 111n 1 ~l: )06 or X\ I-2G

~ - h '! 1 · ·:J - t- )t 1 . c ::~ac1e \.:t: - lit )0311 a,., :i:>' ~ o;.;r ll: )Oall}'

;; caN:>U Clpa t•le

4 ~ t- :.~1 Cuud liv Jll C v :Jib na ll a p:. ~c.b " C•. • :Ji . :.~nallr

r c Jpa blt: J I.4P¢blil .,; ~pal•l+:

·•· 1 - ·) - t- )t 1 . Cond tk - lll C t: - jit :>na il •:-:r jj: )nail}' '!ClPa t •lt ;; caN:>U ClPa t•le

·•· 1 · 1 . ..:onctl~t: - ~11 \.:t: - :Jit )0311 o;.;r ll: )Oall}' " C31Pa t •lt 't C3N:>I ~ ClPa Die

·•· 1 · 1 . L:onct11t:- l ll ;;~- lit )0 011 ~.:cr :1: )nOll\' v o pa t•le H ON DI? ClPa t•lf ·.s -t'an1a uv , _ ·:. - -'ar: i v

·~ :,3Cie ,·;~" 'lit ) n311 3,·: : t ) ? Cll)3t•li 11 ;; ~~n· :· "'lun1110r: ·; C3'·€)1? .: ~ : ~~ e,·~ Jabon 01) .1.1-:. :- )Oer;;: '~g s no

';;tow lnte In con~:r :1i l :Uft·li ' · .,II lQe '• i ~',ll.: ~'l'l~r:~


Capability and Gap Analysis Descriptions

Analysis provided for those requirements with a tool capability rating of 1 – 3

Analysis characterizes the primary functional shortcomings of the tool or federation with respect to the requirement

Attributes the gap to one or more of three categories:- Model – A model, modeling methodology, or algorithms must be

modified or developed to represent the concept or phenomena

- Data – Characteristics or performance data regarding the concept or phenomena must be generated, distributed, and validated

- Integration – Available LVC components need to be integrated to provide the needed functionality


Sample Gap Analysis Report Outline

TABLE OF CONTENTS

1.0 INTRODUCTION.

1.1 Purpose.

1.2 Gap Analysis Methodology.

1.3 References.

2.0 ASSESSMENT OF THE AS-IS MS&I CAPABILITY TO MEET THE XM-25 MS&IREQUIREMENTS.

2.1 Simulation Applications – Force Representation

2.2 Simulation Applications – Systems and Subsystems.

2.3 Simulation Applications – Soldier System and Subsystems

2.4 Simulation Applications – Synthetic Natural Environment.

2.5 Simulation Applications – Observables and Signatures.

2.6 Simulation Applications – Behavior

2.7 Simulation Applications – Stimulation

2.8 Simulation Applications – Battlefield Truth

2.9 Data Management

2.10 Federation Management and Constraints

3.0 MS&I TOOL DESCRIPTIONS

3.1. One Semi-Automated Forces (OneSAF).

3.2. Infantry Warrior Simulation (IWARS).

3.3. Modeling Architecture for Technology Research and EXperimentation (MATREX)

Battle Command Management Services (BCMS).

APPENDIX A: COMPOSITE RATING OF TOOLS VERSUS THE FUNCTIONAL

REQUIREMENTS

APPENDIX B: MEASURES OF PERFORMANCE MET BY MS&I FUNCTIONAL

REQUIREMENTS

APPENDIX C: 3CE SYSTEMS FUNCTIONALITY DESCRIPTION (SV-4A DIAGRAM)

APPENDIX D: STUDY TEAM PARTICIPANTS

APPENDIX E: LIST OF ACRONYMS

Reports the gaps in the MS&I environment inventory as compared to a set of requirements

Report includes - How a gap was identified

- Alignment, or the degree or level to which a capability satisfies a requirement

- Analysis of potential solutions to the gaps


Sample Analysis Content

3.1 Simulation Applications – Soldier System and Subsystems.

3.1.1 Requirements Summary. These requirements address the capability to model or simulate detailed functions, characteristics, and performance of the CDTE and …

3.1.2 Gap Analysis.

There is a limited capability to accurately model the performance of laser range finding devices.

This is a critical component of the XM-25 TA/FC sub-system and is a capability that is necessary to evaluate XM-25 performance and operational effectiveness.

This is a Model deficiency. It requires improvements in the laser transmission and extinction model. It can be resolved by near-term modifications to OneSAF and IWARS.

SRS section

SRS section summary

Specific gap or deficiency

Potential impact of gap

Gap characterization


Summary

Original intent for the 3CE MS&I Capability Development Process was to produce:- “As-is” M&S environment inventory

- Gap analysis process and report

- Technical capability road map

End-to-end process has been executed except for development of a technical roadmap- Alternative methodologies evaluated at each process stage

Process meets the stated capability development objectives

Enables MS&I design that is valid and traceable to key analytical issues established for a program


Date post:	22-Mar-2018
Category:	Documents
Upload:	nguyenkhanh
View:	226 times
Download:	1 times