MATREX Overview

5. Expanded Common Environment(Interoperable Components)

6. MATREX Tools Enable a Common Integrated Architecture Lowers the barrier to entry for utilization of MATREX High-Level Architecture (HLA) and widely used ATEC, RDECOM, and TRADOC M&S and tools

8. MATREX Tools Enable a Common Integrated Architecture Lowers the barrier to entry for utilization of MATREX High-Level Architecture (HLA) and widely used ATEC, RDECOM, and TRADOC M&S and tools

11. MATREX Tools Enable a Common Integrated Architecture Lowers the barrier to entry for utilization of MATREX High-Level Architecture (HLA) and widely used ATEC, RDECOM, and TRADOC M&S and tools

13. MATREX is the technical coordination agent for lower technical risks & cost! In 2005 The MATREX ended its ATO status. The challenges to the program resulted in the recognition of a need to stand up core program level technical management functions to address the many demands of enabling Army M&S Capability development. One of these core functions was a Program Level Systems Engineering Team. The Systems Engineering Team serves as a center of gravity for Capability Development and Planning for the program. The MATREX SE Team has two over-arching objectives: Support the MATREX Program in Capabilities Planning and Development to provide RDECOM a with an integrated Acquisition M&S Support Capability. Support the SOSI Enterprise IPT in implementing a common Systems and Software Engineering processes, tools and culture in RDECOM. SE Teams Core Activities: Vision Capabilities Decomposition Fiscal Year Technical Planning / Schedule Development Capabilities Planning & Road Map Development Enterprise Architecture Systems Architecture Description (SAD) Development Technology Insertion Systems Verification and Validation FOM Management and FOM Management Focus Group (FMFG) Support Systems Verification and Validation Systems Management Requirements Management / Content Management (IDE Support) Process Management Risk Management / Reporting MATREX is the technical coordination agent for lower technical risks & cost! In 2005 The MATREX ended its ATO status. The challenges to the program resulted in the recognition of a need to stand up core program level technical management functions to address the many demands of enabling Army M&S Capability development. One of these core functions was a Program Level Systems Engineering Team. The Systems Engineering Team serves as a center of gravity for Capability Development and Planning for the program. The MATREX SE Team has two over-arching objectives: Support the MATREX Program in Capabilities Planning and Development to provide RDECOM a with an integrated Acquisition M&S Support Capability. Support the SOSI Enterprise IPT in implementing a common Systems and Software Engineering processes, tools and culture in RDECOM. SE Teams Core Activities: Vision Capabilities Decomposition Fiscal Year Technical Planning / Schedule Development Capabilities Planning & Road Map Development Enterprise Architecture Systems Architecture Description (SAD) Development Technology Insertion Systems Verification and Validation FOM Management and FOM Management Focus Group (FMFG) Support Systems Verification and Validation Systems Management Requirements Management / Content Management (IDE Support) Process Management Risk Management / Reporting

16. FCS: a Key Collaboration Actual CY07 FCS-MATREX/RDECOM collaboration (selected highlights) C3Grid Software Development, Installation, Maintenance, Training, and Support Requirements CSAT Maintenance, Training, and Technical Support Requirements Integration and testing support Technical and Management meeting participation and support FOM collaboration and support On-site technical support Test and V&V requirements Documentation FCS funded MATREX M&S and tools for CY07 FOM (Co-chaired FCS-MATREX) RTI (HLA 1.3NGmatrex) ATC MATREX Reference Implementation versions CSAT/FCC C3Grid (OCS, MTS, SANDS, DOS, R2S) ARMS MSLS NVESD Suite (CMS, CMS2, UC, NVIG, 3D Viz) Proposed CY08 FCS-MATREX/RDECOM collaboration FCS Command and Control Interface Support Requirements LOE Armament Server (ARMS) Maintenance, Training, Integration and Testing Support LOE Missile Server (MSLS) Maintenance, Training, Integration and Testing Support LOE Provide Technical and Management Meeting Support Requirements Provide General Federation Object Models (FOM) Support Provide On-site Technical Support Test Specific Documentation Requirement Verification and Validation Specific Requirements Data Deliverables Option 1: Live, Virtual, and Constructive (LVC) FOM Changes Option 2: LVC Interoperable Tools Option 3: Scalability Option 4: Event Management Option 5: Static Weather

19. General MATREX OneSAF Update

20. MATREX OneSAF Update MATREX is an Official OneSAF Collaborative Developer FY07 focus was to “swap” OTB out & replace with OneSAF (i.e., maintain same interface functionality with MATREX components). All “Swap” interface work completed as planned & delivered to PM OneSAF in “Handover Package” on 31 Jul 07. All MATREX code changes were integrated into OneSAF (OF) v1.5 & remain part of OF baseline. Will be used with MATREX v3.0 release (due out 25 Jan 08). Training User: M-Prime personnel trained in May 07 Developer: 4 M-Prime & 15 lab personnel from most labs trained in March & June 07 (MATREX funded 5 in March & 10 in June)

21. MATREX OneSAFCollaborative Development

22. MATREX OneSAF Update (continued) FY08 Focus: MATREX SE Team will lead putting together an “Architecture Roadmap” for full integration of OneSAF Include addressing items currently designated as “Architectural Issues,” such as: Simulation initialization / Event Management synchronization with the MATREX paradigm Mixed resolution & mixed fidelity modeling SA/COP integration Behavior integration & orchestration with HC-NEBC etc. Address SSS Statements that OneSAF needs to meet, including via modifications to OneSAF On IDE: https://www.matrex.rdecom.army.mil/?q=se/sdd/sss

23. MATREX OneSAF Update (continued) FY08 Focus (continued): Possible “Facilitated Model Review” on priority basis w/ each individual RDECOM lab to examine tighter integration of their component(s) with/into OneSAF. Continue to support Cross-RDECOM OneSAF Collaborative Development Team (next slide) Weekly coordination telecons MATREX OneSAF developer resources will support individual RDECOM lab OneSAF developers as they start to develop OneSAF code Possible Advanced (Level 3) Developer’s Training Possible addition of OneSAF s/w development & CM tools to MATREX IDE to support coordinated cross-RDECOM development of OneSAF code as well as Handover Packages to PM OneSAF.

24. MATREX OneSAF TransitionCurrent Task Organization

25. MATREX is helping to advance simulation technology, infrastructure, and processes to enable better informed decision making. MATREX (RDECOM) is working with TRADOC, ATEC, and the PM FCS(BCT)/FCS LSI to build an Army solution for M&S experimentation applicable across the acquisition life cycle. MATREX is providing many of the tools and methodologies to help reduce technical, cost and schedule risk for PMs.

26. 3CE – Cross-Command Collaborative Effort ACS – Aerial Common Sensor AKO – Army Knowledge On-Line ALCES - Aggregate Level Communications Effects Service AMS – Aviation Mobility Service AMSWG – (OSD) Acquisition Modeling & Simulation Working Group ARMS – Armaments Service ATC – Automated Test Capability ATEC – Army Test and Evaluation Command ATIN – ATEC Test Integration Network AUTL – Army Universal Task List BCT – Brigade Combat Team BLCSE – Battle Lab Collaborative Simulation Environment C3HPM – Command, Control, & Communications Human Performance Model C3GRID – Command & Control, Computer GRID CES – Communications Effects Server CMS – Countermine Server CMS2 – Comprehensive Munitions & Sensor Server CSAT – C4ISR Static Analysis Tool C4ISR – Command & Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance DCARS – Data Collection, Analysis & Reporting System DCA – Data Collection & Analysis DCAT – Data Collection & Analysis Tool DES – Damage Effects Server DOTMLPF – Doctrine, Organization, Training, Materiel, Leadership, Personnel & Facilities DOS – Dynamic Organization Service DTC – Developmental Test Command DTE – Distributed Test Event DT&E – Developmental Test and Evaluation DVL – Distributed Virtual Laboratory EE – Effects Engine FCS – Future Combat Systems FOC – Full Operational Capability FOM – Federation Object Model MTS – Message Transceiver Service NCW – Network Centric Warfare NEC2 – Networked Effects Command & Control NVIG – Night Vision Image Generator OCS – Organic Communications Service OneSAF – One Semi-Automated Forces OOS – OneSAF Objective System OTB – OneSAF Testbed Baseline OTC – Operational Test Command PEO – Program Executive Office PM – Product, or Program or Project Manager R2S – Relative Roles Server RDECOM – Research, Development, & Engineering Command RDEC – Research, Development & Engineering Center S3E – Systems Engineering, Experimentation, and Enterprise SANDS – Situational Awareness Normalization & Dissemination Service SE – Systems Engineering Sim Init – Simulation Initialization SNE – Synthetic Natural Environment SoS – System of System SoSE – System of System Engineering SOSCOE – System of Systems Common Operating Environment STEM – Science and Technology Enterprise Management S&T – Science and Technology TENA – Test & Training Enabling Architecture TIE – Technical Integration Event TRADOC – Training & Doctrine Command UAV – Unmanned Aerial Vehicle UC – Universal Controller UJTL – Universal Joint Task List USAF – United States Air Force USMC – United States Marine Corps VDMS – Vehicle Dynamics & Mobility Service V&V – Verification and Validation VV&A – Verification, Validation & Accreditation WECM – Warfighter Electronic Collection and Mapping WI – Warfighter Interface

27. Backup

28. MATREX Personnel Completing OneSAF Developer’s Training Five M-Prime & 4 NVED personnel successfully completed 19-23 March @ NVESD: MATREX: John Vintilescu, Keith Snively, Dave Itkin, Tim Good NVESD: Mike Butler, Steve Webster, Brian Sohr, Joe Brazil MWTB/UAMBL (used NVESD slot): Paul Monday Ten MATREX/RDECOM personnel successfully completed Orlando course 18-22 Jun: AMRDEC: Daniel Flagg (contractor) AMSAA: Brian Kelly, (Government) vice ARDEC: Donnie Palmer, STTC (Government) ARL: Joshua Walters, (contractor) CERDEC: Art Lugo, (Government) ECBC: Derrick Briscoe, (contractor) NSRDEC: Von Ly (contractor) STTC: Bonnie Eifert (Government) TARDEC: Christina Kaniarz (Government) vice M-Prime: Joshua Combs, ECBC (Government) (vice Gallant)

29. The MATREX Paradigm To understand the scope and perspective of MATREX requires four views, physical network, or Distributed Virtual Laboratory (DVL); Distributed Systems Engineering over the Integrated Development Environment (IDE); the MATYREX composable M&S Environment (V2.2 depicted); and the collaborative MATREX M&S Event management 0process and tools. MATREX event management is being worked collaboratively with the M&S community. Functional Communications representation to model the network Human modeling to model the decision process Common Operating Picture (COP) information representation Multi-fidelity and multi-resolution functional services Interchangeable models (unmanned systems, sensors, mines, etc.) Environment Simulation Event management Centralized simulation initialization Data collection & analysis Quicker integration of new models Technical Data Distribution Management (DDM) Spatial DDM Message traffic segmentation Abstraction of the CES API to minimize impact of multiple CES models Access to information flow and fusion data at multiple points in the process Improved distributed simulation between networked labsTo understand the scope and perspective of MATREX requires four views, physical network, or Distributed Virtual Laboratory (DVL); Distributed Systems Engineering over the Integrated Development Environment (IDE); the MATYREX composable M&S Environment (V2.2 depicted); and the collaborative MATREX M&S Event management 0process and tools. MATREX event management is being worked collaboratively with the M&S community. Functional Communications representation to model the network Human modeling to model the decision process Common Operating Picture (COP) information representation Multi-fidelity and multi-resolution functional services Interchangeable models (unmanned systems, sensors, mines, etc.) Environment Simulation Event management Centralized simulation initialization Data collection & analysis Quicker integration of new models Technical Data Distribution Management (DDM) Spatial DDM Message traffic segmentation Abstraction of the CES API to minimize impact of multiple CES models Access to information flow and fusion data at multiple points in the process Improved distributed simulation between networked labs

30. Objectives: Leverage existing software investments and minimize impact Provide access to various network protocol efforts in near-term and minimize work Construct a common Object Model and Code-Generate connectivity to protocols Provide a forward path for legacy object models and component models into the future Design Overview: Capture common concepts in an Object Oriented API Use code generation to generate classes for user object model components Use plug-in architecture to allow applications using the ProtoCore API to interoperate over available infrastructure. Design Features: Object-Oriented High Level API. Easier to program Object lifetimes manage object lifetimes within the simulation. Provides strong type safety, allowing more errors to be caught at compile vice runtime Reduces menial tasks, such as encoding data Plug-in Architecture Runtime configuration. Efficient in process translation. Data is not encoded or written to the network multiple times Single process to launch and monitor in the simulation Current Plug-ins: HLA 1.3 Plug-in HLA 1516 Beta Plug-in (DLC API) Prototype of TENA MW Plug-in

31. Prior to “standing up” a federation, an HLA/RTI federation environment design must be established which involves the following: - A detailed description of the required scenario to include the organization, composition and tactical “lay down” of the forces, units and platforms required for testing. - A computer networking sufficient to support all required Linux and Windows based federates. - A plan for distributing scenario units and entities among systems and federates. - A series of MSO File command scripts for initializing the network/federation and directing scenario preplanned actions. Once the scenario and its supporting HLA federation have been designed, three software tools, MSDE, CSAT and hlaControl, are employed to first generate then instantiate, or “stand up,” the federation. While the federation is running, to include its executing unit or platform movements and actions required to test component federates, all scenario generated data is collected with a fourth software tool, hlaResults. Lastly, a final software tool, the MATREX-Prime Integration and Test Team developed Quick Look Analysis Tool, is used to confirm the viability of the federation generated data. Prior to “standing up” a federation, an HLA/RTI federation environment design must be established which involves the following: - A detailed description of the required scenario to include the organization, composition and tactical “lay down” of the forces, units and platforms required for testing. - A computer networking sufficient to support all required Linux and Windows based federates. - A plan for distributing scenario units and entities among systems and federates. - A series of MSO File command scripts for initializing the network/federation and directing scenario preplanned actions. Once the scenario and its supporting HLA federation have been designed, three software tools, MSDE, CSAT and hlaControl, are employed to first generate then instantiate, or “stand up,” the federation. While the federation is running, to include its executing unit or platform movements and actions required to test component federates, all scenario generated data is collected with a fourth software tool, hlaResults. Lastly, a final software tool, the MATREX-Prime Integration and Test Team developed Quick Look Analysis Tool, is used to confirm the viability of the federation generated data.