IMPRINT 2 2 System of Systems (SoS) Modeling Approach

1. IMPRINT22 System of Systems (SoS) Modeling Approach Micro Analysis & Design Nils D. LaVine Marc Gacy 7 December 2005

2. IMPRINT22 in action!

3. Overview • Background • IMPRINT22 Architecture • IMPRINT22 Software • IMPRINT22 SoS Modeling Approach • IMPRINT22 SoS Modeling Benefits • Future Efforts • ARL HRI ATO Effort • Summary

4. Background • Desire for a modular approach to building IMPRINT models • Develop an interoperability standard for IMPRINT models as suggested at ARL meeting. • Allow the integration of one or more platform models (e.g. FFW model, MCS platoon model, etc) with a common scenario • Allow development of large robust models by incorporating many smaller platform models into a common scenario

5. Scenario Model Platform Model 1 Platform Model 2 IMPRINT22 Architecture • Multiple networked computers, each one running an instance of IMPRINT • Each computer runs a different model • The models communicate via HLA compliant middleware • The scenario model acts as a delegateto the platform models • A change in the scenario will triggerdifferent tasks in the platform models to handle the change in the scenario • If all models adhere to common standards, they can be easily interchanged • This approach allows for several different platform models to be run with a single scenario model or a different scenario model to be run with a common set of platform models

6. Scenario Model Move to Waypoint Encounter Enemy Move to Waypoint Status Update Receive Enemy Loc Load Ammo Move Status Update Aim Fire Scan Area Report Enemy Engage Enemy Report BDA Crash Engage Again Platform Model 1 Platform Model 2 Platform Model 3 IMPRINT22 Architecture

7. IMPRINT22 Software

8. IMPRINT22 Software • IMPRINT Middleware provides communication protocol and synchronizes IMPRINT clock among all models • HLA Compliant

9. IMPRINT22 SoS Modeling Approach • At this time models are to be built using Goal Orientation in IMPRINT • Each model “listens” for a change in variables • When a variable value changes, a change in state is triggered in one or more of the models • Current SoS models will not be “plug and play” they will require modification

10. IMPRINT22 SoS Modeling Approach • Must designate model variables as “external” • Must map variables • Send, Send as Action, Receive, Receive as Event • Include who you will send to • Include who you will accept information from

11. IMPRINT22 SoS Modeling Approach • Scenario information must be removed from Systems models • A Scenario model will stimulate Systems models • Vigilance tasks may be required in Systems model to “notice” communications from other System models

12. IMPRINT22 SoS ModelingBenefits • Platform models can communicate directly with each other – A change in a variable value in one platform model can directly affect the state of another platform model • Additional shared variables may be necessary as a wider variety of platform models are developed for integration into SoS • Will facilitate the analysis of heterogeneous systems

13. Future Efforts • Modifications to IMPRINT • Identify and develop a common set of reports that can be presented regardless of the platform models • May require middleware modifications to consolidate reports from several different models • Identification of common data variables to be added to all models • Develop a distributable standards document that describes the process for developing an SoS model

14. Future Efforts • Modifications to IMPRINT Middleware • Middleware can be updated to automate some of the current modeler tasks • Add a list that displays all compliant SoS models so modeler can easily select those models for an analysis • Improve mapping capability so that is easier and more intuitive

15. ARL HRI STO Effort

16. Current accomplishments • Retrofitted two models provided by ARL HRED for integration into SoS demonstration • MCS Platoon Leader Vehicle model – Diane Mitchell: A driver, a gunner and a commander move an MCS with robotic assets through a series of waypoints and engage an enemy • FFW model – Charneta Samms: Soldiers launch a UAV and search an area with it • Modified these models to interact with a single scenario model • Minimal changes • Preserve validation

17. Step “0” – Original Model Step 1 – Separate scenario and operator components in same model Step 2 – Separate scenario and operator components in different models Step 3 – Independent scenario components from two models in single scenario model Step 4 – Single scenario model controlling multiple operator models Step 5 – Iterations for data collections Model Integration Approach

18. Retrofitting • Initial work performed on the MCS platoon • Tasks that comprise a scenario were identified and pulled out into their own IMPRINT function • The shared variables were added • A spinner task to listen for changes in the variables was added • All randomness was removed from the model • All standard deviations set to 0 and all probabilistic decisions were removed • Needed to demonstrate that results for model with the extracted scenario were identical to original model • Model was executed as a standalone in IMPRINT • Demonstrated that concept was viable

19. Retrofitting MCS-PLV Model Illustrated Step 2: Scenario extracted into single network Step 1: Separate scenario & platform elements Step 3: Added spinner task to platform model(not shown) Original Model New Models

20. Retrofitting HRI ATO models • Results of extracted scenario model were identical to results of original model • The extracted scenario was then copied to another machine and the middleware was configured to communicate with these models • Procedure was repeated for FFW model • Successful demonstration of three models interacting (scenario, MCS platoon, FFW) at ARL HRED

21. Lessons Learned • An unanticipated result was a significant increase in time to execute SoS model due to: • the spinner tasks added in each model • the synchronization algorithms of the middleware • Each model added to an SoS model will increase overall model execution time • Time increase in model execution offset by a reduction in development time and an increase in analysis flexibility (i.e. easier to experiment with several different combinations of platforms and scenarios) • Possible ways to improve model speed: • Modifications to IMPRINT • Increase Mean time on spinner tasks • Replace spinner tasks with interrupt approach

22. Future Directions • Address speed – remove spinner task • Build new scenario models • Easily swap in & out scenarios & platforms • Codify list of connections • Retrofit other HRI ATO platform models • Preserve Validation • Build new platform models using approach • Convert to IMPRINT PRO? • Multiple instances of a given model • Reports

23. Summary • IMPRINT22 architecture & software • IMPRINT22 modeling approach • Benefits • Future work • ARL HRI ATO Effort • POCs • Nils LaVine • Voice – (303) 442-6947 x125 • Email – nlavine@maad.com • Marc Gacy • Voice – (303) 442-6947 x118 • Email – mgacy@maad.com