# Presentation: 598868

## James W. Hollenbach
Simulation Strategies, Inc.
jimh@simstrat.com, (703) 360-3902

- James W. Hollenbach
- Simulation Strategies, Inc.
- jimh@simstrat.com, (703) 360-3902

**JSF Modeling Information Management**International Workshop on Aerospace Product Data ExchangeNational Institute of Standards and Technology, Gaithersburg,, MDApril 2003

## LOCKHEED MARTIN MULTI-SERVICE DESIGN

**LOCKHEED MARTIN ****MULTI-SERVICE DESIGN**

**Lift Fan**

**Roll Nozzle**

**3-Bearing**
**Swivel **
**Duct**

## Simulation Based Acquisition (SBA):Shared Information is the Hub of IPPD

**Simulation Based Acquisition (SBA):****Shared Information is the Hub of IPPD**

_**JSF Program Commitment:**_
*** ******Availability of complete consistent digital product data***
*** ******24/7 access and navigation of digital product data by the entire team***
*** ******Traceability of digital product data***
*** ******Data interoperability between team and suppliers***
*** ******Configuration management and publishing in-progress designs***

- Configuration-managed            Web-accessible           Coherent

## Consistent, AuthoritativeInformation Sources Are Vital

**To ensure M&S-derived answers are correct**
- Reduce the confusion and bad analysis that arise if operating on wrong or logically inconsistent information
- Establish validity by tracing analyses back to authoritative information
**To conserve resources, improve efficiency**
- Avoid having to repeatedly find, produce and/or translate the same information
- Provide more timely analyses, resulting in shorter decision cycles, more efficient systems engineering
- Avoid the costs of correcting mistakes discovered late in program (the “fix” phase)

## GOVERNMENT & INDUSTRY PARTNERSHIP

**GOVERNMENT & INDUSTRY PARTNERSHIP**

**Lockheed Martin provides a Distributed Product Description (DPD) of the Joint Strike Fighter**
- Includes all authoritative information needed to represent the JSF’s operational performance, logistical characteristics, and cost
- Spans the engineering, engagement, mission, and campaign levels
**Government provides the simulation environment in which the DPD-based JSF will operate**
- Threat systems, friendly systems, logistics resources and infrastructure, Blue & Red C4I, multi-spectral databases, terrain & atmosphere representations

***Government and Industry in a closer M&S partnership than ever before!***

## Components of theJSF Modeling & Simulation Toolset

- JSF Suite of Models and Simulations (SoM&S)

- JSF Strike Warfare

- Collaborative Environment

- (SWCE)  Toolset
- (~28 models & sims)

- JSF Engineering and Manufacturing

- Collaborative Environment

- SWCE

- SoM

- &S

- EMCE

- SoM

- &S

- JSF Distributed Product

- Description (DPD)

**MSDB**

**Scenarios**

- Databases

- Authoritative Systems Data Base (ASDB)

**MSDB**

**Scenarios**

- Databases

- JSF Resource Access System (RAS)

- (EMCE)  Toolset
- (100+ models & sims)

## 3 Paths to System Representations

- Compile

- Load

- Develop a
- software component

- Develop a simulation
- application

- Input data sets

- Input data sets

- Input data sets

**Executable**
**applications**

- Model or simulation
- modified to represent
- a battlespace

- Model or simulationdeveloped to representa system

- Model or simulationinitialized to representa battlespace

- (Federate)Execute

- (Federate)Execute

- (Federate)Execute

- Load

- Load

- Compile

**Data-driven system representation in another’s tool (e.g., Thunder, JIMM)**

**Software representation within another’s tool (e.g., ESAMS, Brawler)**

**System representation as a dedicated application (e.g., JSF Virtual Simulator) **

- Information mapping, translation, pre-processing

**Authoritative info****in its original form**

**DIFs**

**Most**
**authoritative**
**system****information**

**Information in****application-specific****form**

## Information Types

**Parametric data**
- includes sets, tables, grids, graphs
**Algorithms**
**Software code**
**Publications**
**Subject Matter Expert knowledge**

**Initial focus has been on parametric data**

## Modeling InformationCharacterization

**Regardless of its subject, data may be characterized by its:**
- _Trustworthiness_:  “authoritative” or “non-authoritative”
- _Evidence_ in the real world:  “empirical” or “derived”
- _Context dependency_:  “context-independent” or “context-dependent”
- _Granularity_:  “primitive” or “aggregated”
- _Structure_:  “atomic” or “complex”
- _Source_ (relative to the enterprise):  “external” or “internal”
**Above characterizations are orthogonal**
- A data item could be described by any combination

## Context Dependency

**“****Context-independent” data**
- Characteristics that remain stable regardless of system use or environment
- Examples: structure, empty weight, transmission characteristics, cost, system composition, interfaces
**“****Context-dependent” data**
- Attributes determined by how the system is employed and/orits external environment
- Two sub-categories:
- Conditional performance/behaviors
- Examples:  takeoff distance, range, turn performance, signatures, physical impact
- Dynamic interactions with other systems
- Examples: engagement range, Ps, Pk, exchange ratio, targets killed

## Data Inputs to Models & Sims

**Engineering**

**Campaign**

**Mission**

**Engagement**

**Context-independent data****Externally or internally generated**

## Example Thread(Surface-to Air Missile Vulnerability Analysis - simplified)

**Example Thread****(Surface-to Air Missile Vulnerability Analysis - simplified)**

***ENGINEERING***

***ENGAGEMENT***

***MISSION***

***CAMPAIGN***

**ACQUIRE**

**COVART**

**FASTGEN**

**FLIR 92**

**HITRAN**

**MODTRAN**

**RCHEM**

**SPIRITS**

**ESAMS**

**ASM**

**DIADS**

**BRAWLER**

**SHAZAM**

**MIL-AASPEM**

**RADGUNS**

**MOSAIC**

**JSF Virtual Simulator**

**JIMM**

**GIANT**

**EADSIM**

**LCOM**

**CFAM**

**THUNDER**

** ****AFMSS **
**(CLOAR)**

- JSFPO-provided
- M&S
- (SWCE)

- LM Aero-provided
- M&S
- (EMCE)

**ACAD**

**CATIA**

**NASTRAN**

**Suppressor**

**WINFIRE**

**Live Fire Test**

## Inverse Abstraction Relationship

**Engineering level**
**simulations**

**Campaign**
**level****simulations**

**Mission level**
**simulations**

**Engagement level**
**simulations**

**Context-dependent****data item**
**alternatives**

**Degree of abstraction**

**Number of instances**

**Number of instances**

-   Data applicability narrows as context dependencies increase
-   Must be carefully tracked to guard against inappropriate use

## Standardizing Contexts

**Engineering level**
**simulations**

**Campaign**
**level****simulations**

**Mission level**
**simulations**

**Engagement level**
**simulations**

**Degree of abstraction**

**Number of instances**

**Number of instances**

- Defining a set of standard/reference contexts reduces the number of data instances that must be managed

**Context-dependent****data item****alternatives**

## Operational Context DB Scope(Enterprise-wide standards for analysis; in priority order)

**Scenarios**
- Road to war
- Blue TPFD
- Orders of battle (UOB, EOB, etc.)
- Geographic area
- Infrastructure targets, location
**Mission Groups**
**Missions**
**Vignettes ***(created by JSFPO)*
**Use Cases ***(created by JSF IPTs)*
- Initiating inputs, required actions, MOPs
**Natural environment conditions**
- Time of day, weather
**Concept of Operations (CONOPS)**
**Force doctrine**
**Tactics**
**Rules of engagement (ROE)**
**Firing doctrine**
**Infrastructure lay down **(other than targets)

- _Not_ in Operational Context DB:
- Study-specific archives
- Input data sets
- Raw execution outputs
- Discretionary analyst decisions
- e.g., Blue mission routes
- System C&P data
- Natural environment instance data
- Infrastructure C&P

## JSF Authoritative Modeling Information System (JAMIS) Architecture - Operational View

- Version 16, 31 Jan 03

**DSMs / relevant info****in tool-specific form **

**Analyst action**

**Threat & ****friendly****systems**
**[ASDB]**

**Operational****context**

**Natural**
**environment,****infrastructure**

**JSF**
**[DPD]**

- Linking & translation services (mapping, semantics/syntax)

**Resource Access****System (RAS)**

**NIMA,****DTRA,**
**NRO, etc.**

**Program****Offices**

**Intel**
**Centers**

**Services,**
**JFCOM,****etc.**

**Threat C&P**
**information**

**Operational****context info**

**Natural**
**environment &**
**infrastructure****C&P info**

**Blue system****C&P info**

**Register****authoritative**
**data (JSFPO)**

- Color key:
-                  JSFPO provided
-                  LM Aero provided

**Digital System Models**

**Register****proposed****designs**
**(LM Aero)**

## JSF AuthoritativeModeling

- Version 12, 30 Jan 03

**Review data & metadata**
**Register data**
**Author metadata**

**View data & metadata**
**Assess & mark (in metadata)**

_**JSF SORA & LM Aero Tier III IPT directors**_**: Grant privileges**

_**Consumers**_** :  JSF Enter- prise, others TBD**

**Analyses and****testing**

**Technology****development**

**JSF Authoritative****Modeling**
**Information System**

**External**
**references**
**(e.g., Intel****Centers)**

**View data & metadata**
**Download & use data**

**Implement privileges**
**Provide training and  technical support**

_**Manager**_** :  LM Aero, in****cooperation with JAMIS****database managers**

_**Examiners**_** :  VV&A Action****    Team, others**

_**Producers**_** :  Designers,****JSFPO, analysts, testers**

## JAMIS Architecture – System View

***Information model as means to locate, navigate, and access distributed data***

**Resource**
**Access System**

**Metaphase**

**MASCOT**

**PVCS**

**Other **
**databases**

_**Information Model**_
**(info taxonomy and decomposition, interrelationships)****& data locations**

**ASDB**

**DOORS**

**RAS application server**

**Web Browser (RAS GUI)**

**Database servers**

## Technical Standards View

**Web-based, led by XML**
**Still being defined; standards adopted thus far:**
- Hyper-text Transport Protocol (HTTP)
- Hyper-text Markup Language (HTML)
- Simple Object Access Protocol (SOAP)
- Secure Authorization Mark-up Language (SAML)
- XML Schemas; XDF (for structured data sets), XMI (for UML models), X3D (for 3D geometry), XSLT (for translations)
**Use of ISO 10303/AP203 is under discussion**

## Challenge: Information Mapping

**    ****Model and simulation developers use information in widely differing ways**
- Conceptual models (ways of thinking about what’s represented)
- Semantics and syntax (of individual information items)

## Rationale for aIntegrated Information Model

**Rationale for a****Integrated Information Model**

**Data**
**source 1**

**Data**
**source n**

**Data**
**source 2**

**Data**
**source 3**

**Simulation**
**format 1**

**Simulation**
**format 3**

**Simulation**
**format 2**

**Simulation**
**format n**

**Data**
**source 1**

**Data**
**source n**

**Data**
**source 2**

**Data**
**source 3**

**Simulation**
**format 1**

**Simulation**
**format 3**

**Simulation**
**format 2**

**Simulation**
**format n**

**Integrated****Info Model**
**(common**
**semantics**
**& syntax)**

**Many translators (~N****2**** for N tools)**
**Difficult configuration management**

**Fewer, less fragile translators**
**Easier configuration management**

- If a business case exists!

## Data Engineering ProcessReverse Engineering for Data Integration and Sharing (REDIS) - simplified

**Data Engineering Process****Reverse Engineering for Data Integration and Sharing (REDIS) - simplified**

**Data Interchange**
**Format specs**

**Integrated Database**

**Integrated Information Model**

**Information****model**

**Information**
**model**

**Information**
**model**

**Information**
**model**

**Information**
**model**

**Source 1**
**data files**

**Simulation 1**
**data files**

**Simulation 2**
**data files**

**system n**
**data files**

**Source 2**
**data files**

**Reverse**
**Engineering**

**Integration/Synthesis**

**Forward**
**Engineering**

**Data Dictionary**

**...**

**...**

## Some Challenges

**Mapping data flows to authoritative data sources is tedious work**
**Synthesizing an integrated information model requires an intimate understanding of the producing and consuming tools (models, simulations)**
- Usually a time-consuming task
**Conceptual model & assumptions of the tools are often unclear**
- Developer may not have documented this
- May be a function of the analysis to be performed
**REDIS process only works in domains with high semantic similarities**
- Similar ways of looking at the world

## JSF Product Development Information Model (top-level)

**Blue**
**systems **

**Threat**
**systems**

**Natural**
**environment**

**Civil/military****infrastructure**

**Operational**
**Context**
**(scenarios, etc.)**

**Government**
**provided**
**context**
**information**

**LM Aero provided Product Information Model (DPD)**
**(Variants = layered instance values)**

- Functional allocationtrade studies

- Manufacturing/supplier capabilities

- Mobility

- Specialized views:
-  OML, Cost, BOM, mass properties, etc.

- _Coherency & completeness cross-checks_
-  Solid lines = primary
-  Dashed lines = secondary

**Transportation capabilities**

-  Assemblies &  components
-  Software
-  Spatial   relationships
-  Wire harnesses
-  Part records

-  System/  subsystem  topology
-  Functional  allocation
-  Technologies
-  Interfaces

-  Air vehicle performance
-  Mission systems capabilities
-  Self-diagnosis capabilities
-  Stress analysis
-  Signatures
-  Reliability

**JSF Product Development Information Model (top-level)**

-  Lethality/  effectiveness
-  Survivability

- Manufacturingprocess

**Physical****architecture**
- (from IPT designers)

- Support infrastructure

- Maintainability

**Behaviors***
- (from IPT analysts,with gov’t review)

- Personnel rqmts

- Interactions
- (from Kr/gov’t analysts)

**Logical****architecture**
- (from SE/IPT designers)

- (Requirements are recorded in appropriate information domain)

## Sample Aircraft Performance Attributes

| Lift coefficient vs. angle-of-attack
Temperature vs. mach, altitude, throttle
Post-stall maneuver capability
Min and Max g capacity
Max mach number and calibrated airspeed
Afterburner delay time
Turbine spin-up and spin-down times
Correlation factor for turbine to afterburner thrust
Max mach number with a drag device
Constraints on thrust reversal employment
Time to max thrust reversal
Thrust reversal efficiency
Damping ratio for angle-of-attack response
Roll acceleration factor due to angle-of-attack
Stability axis roll rate limits by AOA and dynamic pressure
Roll acceleration increment for positive AOA acceleration. limit
Radar cross section by azimuth, elevation and wavelength
Infrared signature characteristics
Physical attributes
Weapons quantities, operating modes and locations
Sensor quantities, operating modes and locations |
| --- |

## Data Derivation Traces

***CATIA***
***files ***

***Outer Mold******Line conversion***
***process ***

***Facet***

***file***

***Xpatch ***

***/***

***3D ***

***MoM***

***Material ***

***assignment ***

***process***

**...**

**RCS Values**

**...**

**Brawler Aircraft**

**Char. And **

**Perf**

**.**

**Parameters**

***Materials ***

***database***

***Facet file***

***with material IDs***

- If an attribute changes (e.g., Outer Mold Line), can determine what downstream attributes (e.g., RCS) are affected and notify owners
- Where different data items trace back to common sources, can provide an automated coherency check

- ...can be used for coherency checking and change impact management

***Frequency***
***Polarization***
***Azimuth***
***Elevation***

## JPO TOP LEVEL SCHEDULE

**Version 8a – current as of 28 Feb 03**

**DISTRIBUTION A – Approved for Public Release; Distribution is Unlimited**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**1  2  3  4**

**CY**

**2002**

**2003**

**2004**

**2005**

**2006**

**2007**

**2008**

**2009**

**2010**

**2011**

**Pre-SDD**

**SDD**

**SDD**

**PAC**

**ASRR**

**IBR**

**AS****CDR 1**

**AS****CDR 2**

**AS ****CDR 3**

**Blk 1****FTR**

**Block 2**

**           ****Blocks 0 & 1**

**Block 3**

**0A**

**0B**

**0C**

**ISR**

**Development and Qualification**

**CTOL**

**STOVL**

**CV**

**Blk 1      RFT**

**Blk 2 RFT**

**Blk 3 RFT**

**LRIP I  (10)**

**LRIP II  (22)**

**LRIP III  (54)**

**LRIP IV  (90)**

**LRIP V  (117)**

**LRIP VI  (166)**

**Multi Year**

**Production**

**6 CTOL****4 STOVL**

**14 CTOL****  8 STOVL**

**DAE**** IPR 1**

**DAE**** IPR 2**

**DAE**** IPR 3**

**DAE**** IPR 4**

**DAE**** IPR 5**

**DAB****Review**

**ORD IOC   USMC**

**ORD IOC USN**

**ORD IOC USAF**

**PDR**

**FETT**

**AS****PDR**

**Blk 2****FTR**

**Blk 3****FTR**

**FY**

**2002**

**2003**

**2004**

**2005**

**2006**

**2007**

**2008**

**2009**

**2010**

**2011**

**2012**

**2013**

**CTOL/CV**

**IFR**

**OCR**

**CTOL/CV**

**STOVL**

**Autonomic****Logistics****Development**

**Low Rate Initial ****Production (LRIP)**

**Air System****Program Events**

**Propulsion**

**Test and ****Development**

** ****1  2**

**2013**

**CDR**

**FETT ****STOVL**

**F135**

**F136**

**1  2  3  4**

**2012**

**Mission & ****Vehicle Systems**

**IBR**

**CTOL Trng Sys PDR**

**ALIS**
**PDR**

**TSys/ALIS CDR**

**Blk 1     RFO**

**Blk 2 Flt Test**

**Blk 0 & 1 Flt Test**

**Blk 3 Flt Test**

**CTOL 1st Flt**

**CV 1st Flt**

**STOVL 1st Flt**

**OT&E**

**OA**

**OA**

**(4 CTOL, 2 STOVL)**

**(4 CTOL, 4 STOVL, 4 CV)**

**EOA**

**OA**

**OA**

**OA**

**Flt Test Bed**

**MILCON Test Facilities**

**(2 CTOL, 2 STOVL, 2 CV)**

**CDR**

**FETT**

**IFR**

**FETT**

**PDR**

**CDR**

**ISR**

**OCR**

**PDR**

**IBR**

## Development Strategy

**Integrated development**
- Compatible information models for DPD, ASDB, etc.
- Consistent user interface, procedures, training, etc.
- Coordinated CM, update procedures, metadata, etc.
- Common distribution infrastructure
**Due to absence of MLS or two-way guards, establishing separate JAMIS instance for each security classification level**
- Unclassified, SECRET Collateral, TOP SECRET SAR
**Spiral development**
- A series of builds, prioritized per program needs, to support:
- An increasing amount of information
- In increasing numbers of tools
- Interfaced to an increasing number of organizations
- Brawler datasets are first cycle (Mar 03)
- Will be hard pressed to integrate data from all design and analysis tools

## Some Challenges

**Fostering broad understanding of the need and solution concept**
**Integrating into the system engineering process**
_**Finding**_** authoritative data sources**
_**Getting**_** blue data**
- Data rights
- Release concerns
_**Understanding**_** data**
**Setting standard data interchange formats**
**Less classified representations of highly-classified data **
**Accomplishing data engineering**
- Talent, timeliness, cost

## Summary

**Summary**

**Breaking new ground in information management**
- Promises to advance state of the practice, impact SBA concepts
**Holistic approach and good systems engineering are required**
- The information sharing environment is itself a complex system
**Still a work in progress**
- Incremental deliveries, incremental changes for users
- Significant risk; wish had started sooner
**Many challenges common to other development efforts**
- Some recommendations follow

## Recommendations (1 of 3)

**DoD must treat information as a corporate resource**
**Establish a means to capture data needs**
- Similar to Intel Center Production Requests, Mission Needs Statements
**Crisply define data production “swim lanes” & responsible organizations**
- Government data rights for all reusable data (contracting policy)
- Business/funding rules
**Define data user responsibilities and liabilities**
**Establish means to appeal data release denials**
**Report cards on both producers and users**

## Recommendations (2 of 3)

**Commit to tool standards, not standard tools**
- Tool standardization is impractical, costly, negates power of marketplace
**Identify venues for standards development**
- Commercial standards landscape is quite confused, both nationally and internationally
- DoD should use its ‘bully pulpit’, be engaged
- NIST can help
**Define standard data interchange formats (DIFs) for all information types**
- Well-defined semantics & syntax
- Standard metadata schemas too, including context dependencies
- More granular, less overlapping

## Recommendations (3 of 3)

**DoD should define full range of standard operational contexts**
- Reduce context-dependent data alternatives to a manageable level
- Start with reference missions for each mission area, flesh out down to tactics
- Capture using accepted metadata interchange formats
**Internet/SIPRNet directories and education to provide visibility & awareness about:**
- Available data
- Core metadata about the data assets (not the data itself)
- Dublin Core metadata, extended
- Standard information models and data interchange formats (DIFs)