The Joint Strike Fighter JSF Distributed Product Description DPD

1
The Joint Strike Fighter (JSF)Distributed
Product Description (DPD)
Jim Hollenbach, SSI, DPD Project Coordinator Lt
Col Bob Hartnett, USAF, JSF Director of Modeling,
Simulation and Analysis
2
JSF SBA Strategy for EMD

• 2001 Down-select to one Weapon System
  Contractor (WSC), enter Engineering
  Manufacturing Development
• During EMD, JSF will further SBA realization by
  having WSC build a JSF Distributed Product
  Description (DPD)
• a distributed collection of the most
  current, authoritative JSF information available,
  provided to users via web technology such that it
  appears as a single, logically unified product
  representation
• DPD-based JSF representations will operate in
• Government-managed Strike Warfare Collaborative
  Environment (SWCE)
• WSC-managed Engineering and Manufacturing
  Collaborative Environment (EMCE)

3
JSF DPD - The Hub of IPPD Process
Concept Development
Functional Design
System Requirements
Joint Strike Fighter
J O I N T S T R I K E
F I G H T E R
Section 1
System Threat Assessment Report
Scope
Section 2
Applicable
Operational ConceptDocument
Documents
Section 3
C4I Support Plan
Performance
Requirements
Section 4


Section 5
Performance
Packaging
Verification
Section 6
JMS
Notes
JORD
Models Simulations
Physical Info System Design
JSF DPD other shared info (e.g., threats)
Cost, Schedule Program Mgmt
DRIVERS
Manufacturing
WING/TAIL
LIFT/ FAN
FILLETS
ENGINE
AIRFIELD
TAILHOOK
ENGINE
Distributed Networks
AVIONICS
Mission Planning, Wargaming
AUTONOMIC BATTLEFIELD
JSF PARADIGM
Logistics
Marines
Navy
Air Force
Training
TE
4
Components of the JSF MS Toolset
Strike WarfareCollaborative Environment (SWCE)
Toolset
Engineering Manufacturing Collaborative
Environment (EMCE) Toolset
5
DPD Goals

• Provide timely inputs to JSFPO personnel and MSA
  tools, resulting in shorter decision cycle times
• Improve the traceability (validation) of JSF
  representations
• Increase information coherency, reducing the
  number and extent of potential misunderstandings
  across the JSF government/industry team
• Reduce manual data translations to yield lower
  translation costs and increased productivity
• Make information more readily retrievable
  throughout the JSF life cycle, saving resources
  and facilitating better informed decisions/actions

6
DPD Scope

• Initial DPD, so cant try to satisfy all program
  info needs
• Will satisfy JSF information needs of SWCE and
  EMCE
• SWCE 30 tools in mission effectiveness, cost,
  supportability, engineering and manufacturing
  domains
• EMCE will not be defined until down-select
• Only provides JSF info (not threats, friends,
  factory, etc.)
• Information types
• Product data (e.g. structure, performance
  parameters)
• Algorithms (including look-up tables)
• Software source code (e.g., for flight control or
  mission avionics functions) where its the most
  primitive source
• Complete life cycle requirements, functional
  allocation, as designed, as built, as tested, as
  employed

7
Development Requirements

• Must be coherent in
• Semantics
• Syntax
• Levels of resolution (granularity)
• Integrity among interdependent attributes
• Information duplication kept to an absolute
  minimum
• Appropriate uses for all information made clear
• e.g., with metadata per DMSO VVA RPG templates
• Information model and associated glossary to be
  developed by WSC
• Govt will provide access to SMEs for each SWCE
  tool

8
Data Interchange with DPD
DPD-Tool Data Exchange via DIFs

• WSC to define machine-readable data interchange
  formats (DIFs) for info exchange with DPD
• DIF is a common, intermediate format
• DIFs to followcurrent emergent standards to
  max practical extent (e.g., STEP, XML DTDs
  Schema)

Cost Models
Design Tools
DIFs
Structure
Cost
Mission Effectiveness Simulations
DPD
Behavior
Logistics
Properties
Supportability Models
Vulnerability Analysis Tools
9
DPD Access via theResource Access System (RAS)
10
DPD Delivery

• WSCs to propose schedule, but expected early in
  EMD
• Delivery defined as
• Making the DPD electronically accessible to
  authorized government personnel
• Demonstrating that the DPD satisfies requirements
  (e.g., scope, data model, coherency, glossary,
  metadata)
• Providing appropriate documentation, including
  the data model and instructions for using the
  DPD
• Training JSFPO-designated personnel in use of the
  DPD and the Resource Access System and
• Demonstrating end-to-end use of DPD to
  communicate an evolution in the JSF design and
  consequent assessments using a portion of the
  SWCE MS suite

11
Providing JSF Representations
Examples Thunder
Purpose, federation scenario specifics
Generic data- driven model or simulation initiali
zed with JSF scenario parameters
Input data sets
Load
Software changes to core model or simulation
DIFs
Brawler
Model or simulation configured to reflect JSF
design a scenario
Results from a model, simulation or
federation execution
Most authoritative JSF information DPD
Compile
Execute
Software creation /changes to instantiate JSF
Information Mappings / Translations
Load
Input data sets
Federation integration
Execution -specific
Develop/modify software for an entire
simulation (JSF only)
JSF simulation configured to reflect JSF design
a scenario
Application neutral info appears once
Compile
Input data sets
Load
Application information element -specific
Application scenario -specific components
JSF Virtual Simulator
Executable applications
12
Digital System Models(a.k.a. Product Models)

• A DSM is system-specific software to represent
  that system within a particular application
• One of several reusable artifacts that are
  created in the JSF representation development
  process (previous slide)
• JSF wants to enable reuse of all these artifacts,
  with users to only reach as far left as necessary
  to meet their needs
• WSC will build and share DSMs for all SWCE tools
  he uses
• WSC will establish and share translation rules
  and software
• Govt will build several DSMs with DPD info
• Govt will configure SWCE tools with parameters
  from DPD
• All JSF model, simulation, DSM and translation
  software will undergo VV, with complete
  visibility between govt WSC

13
DSMs Not Considered Part of DPD

• Based on experience thus far, JSF has chosen to
  not include DSMs other application-specific
  artifacts within its definition of the JSF DPD
  because
• Application-specific mappings, translations,
  input data sets and DSMs normally cant be used
  by multiple applications
• Since they are application-specific, they dont
  need an application-neutral DIF to interchange
  them
• If DSMs were included, logic would compel
  including all other application-specific
  artifacts in the DPD
• They have different purposes, interchange
  mechanisms, configuration management methods and
  business cases
• This narrower definition disagrees with earlier
  concepts

14
Key Points andRecommendations for SISO

• JSF DPD project is breaking new ground, will
  yield many valuable lessons
• Its too early to be dogmatic about DPD
  definitions and architectures
• 99F-SIW-134 noted The definition and CONOPS of
  DPDs will evolve asusers experiment with the
  concept
• Reuse opportunities should be considered as a
  continuum and pursued wherever theyre
  cost-effective
• We often think of reuse too narrowly
• Enabling standards may be appropriate at each
  point
• SISO should continue to consider SBA lessons and
  where it can help with standards development

15
Discussion