IMPRINT 2 2 System of Systems (SoS) Modeling Approach

IMPRINT22 System of Systems (SoS) Modeling Approach

Micro Analysis & DesignNils D. LaVine

Marc Gacy7 December 2005

IMPRINT22 in action!

Overview

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

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

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

ScenarioModel

Platform Model 1

Platform Model 2

IMPRINT22 Architecture

Move to Waypoint

Encounter Enemy

Move to Waypoint

Scenario Model

Receive Enemy

Loc

Platform Model 1 Platform Model 2 Platform Model 3

MoveLoad Ammo

Aim Fire

BDA

Status Update

Engage Enemy

Report

Engage Again

Scan Area

Status Update

Report Enemy

Crash

IMPRINT22 Software

IMPRINT22 Software

• IMPRINT Middleware provides communication protocol and synchronizes IMPRINT clock among all models

• HLA Compliant

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

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

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

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

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

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

ARL HRI STO Effort

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

Model Integration ApproachStep “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

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

Retrofitting MCS-PLV Model Illustrated

Original Model New Models

Step 2: Scenario extracted into single

network

Step 3: Added spinner

task to platform model(not shown)

Step 1: Separate scenario & platform elements

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

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

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

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