3'3 Other OneSAF Activities: SISO, SIMCI and SWB

1
3.3 Other OneSAF Activities SISO, SIMCI and SWB

• Dr. Robert Wittman
• Mr. Stephen Lopez-Couto

2
Discussion Topics

• Introduction
• SISO Activities
• SIMCI Activities
• Software Blocking Activities
• Questions

3
(No Transcript)
4
(No Transcript)
5
(No Transcript)
6
(No Transcript)
7
Simulation Interoperability Standards
Organization (SISO)Activities
8
MSDL The Study Group
Product Development Group Kickoff 5 April 2006
Mtg 6 I/ITSEC Orlando 29 Nov. 2005

• MSDL SG approved by SISO in Spring, 2005
• Participants represent a wide body of interest,
  including
• Representatives from over 5 different nations
• Over 100 participants at SG meetings
• Industry, Academia, Government
• 98 participants on MSDL SG reflector
• Active coordination with C-BML SG has brought
  about harmonization of plans for Product
  Development Group (PDG)
• Product Nomination approved by SAC 27 Feb. 2006
  and EXCOM March 8, 2006

Mtg 4 George Mason Univ, VA 3 Aug. 2005 17
Participants
Mtg 2 Orlando, FL 8-10 June 2005 35 Participants
Mtg 5 Fall SIW Orlando, FL 22 Sept. 2005
Mtg 3 Euro-SIW Toulouse, France 29 June 2005 27
Participants
Mtg 1 Spring SIW San Diego, CA 6 April 2005 56
Participants
9
MSDL The Product Development Group

• PDG Teleconference 2nd Thursday of every month
  from 1100-1230 EST
• DG Teleconferences 1st and 3rd Thursday of every
  month from 1100-1230 EST
• MSDL Standard Products
• Schema Files
• Specification
• Coding Standards
• JC3IEDM Comparative Analysis Report
• Products Data Analysis and Resolution (DAR)
  Reports
• 01-Sides and Forces
• 02-Organization
• 03-Overlays
• 04-Tactical Graphics
• 05-Environment
• 06-Installations
• 07-MOOTW

• MSDL Product Development Group Officers
• Chairman COL Buck Surdu
• Co-Chair Per Gustavsson
• Vice-Chair Rob Wittman
• Secretary Ken Peplow
• Drafting Group Participation
• Jeff Abbott (Editor - Acusoft)
• Rob Wittman (Editor - MITRE)
• Francois Gagnon (CAE/Canada)
• Jeff Covelli (General Dynamics/CTIA)
• Mike Fraka (USA TRADOC)
• Tram Chase (Simventions)
• Kevin Gupton (ARL-UT)
• Curtis Blais (NPS)
• Beth Loftus (MITRE/MATREX)
• Ghislain Giguere (CAE/Canada)
• Dave Prochnow (MITRE/MATREX)
• Charley Budde (MITRE/MATREX)

10
MSDL Road to Balloting (Evolving)
PDG Spec Review 28 June 07

• Fall-SIW 16-21 Sept. 2007
• PDG Meeting
• Thursday, 20 Sept.
• 100 PM 400 PM
• Room TBD
• Balloting Status

PDG Review Period 2 weeks
Update Specification
Update Period 2 weeks
Balloting Invitation 9 Aug 07
SAC Review 9 Aug 07
SAC Review Period 4 weeks
Balloting Announcement 4 weeks
Balloting Begins 10 Sept 07
Comment Assessment Begins 10 Sept 07
Balloting Period 4 Weeks
Revise Publish
11
The MSDL Standard Whats Included
12
Primary Elements
XML Representation

• 9 Primary Elements including reuse schema
  components from
• Base Object Model SISO Standard and
• JC3IEDM MIP Standard
• OneSAF-Based Elements not being consider for
  balloting
• Plan
• Course of Action
• Threats
• Units and equipment Enumerations
• XML Representation allows for
• Structure and type Validation
• Business rule validation (under investigation)
  using assertion-based tools such as Schematron

13
Technical Specification
XML Representation

• Defines/Specifies
• MSDL data structure
• Cardinality of data elements
• Mandatory and optional data elements
• Valid data types (simple and complex)
• Valid data boundaries
• Valid domain values (enumerations)
• Relationship among data elements
• XML Representation allows for
• Structure and type Validation
• Business rule validation (under investigation)
  using assertion-based tools such as Schematron

Documents
MSDL Technical Specification Version 1.0
MSDL Business Rules Version 1.0
MSDL Coding Standards Version 1.0
14
Business Rules
Documents

• Defines
• Dependencies between elements within the data
  model i.e.
• Units are associated with a single force or
  directly to a single side
• Forces are associated with other forces or
  directly to a single side
• Other use-based constraints associated with the
  data elements i.e.
• A time period can be associated with
  environmental conditions (wind, rate of
  precipitation, etc.)
  to provide scenario-based
  evolving environmental conditions

XML Representation
MSDL Technical Specification Version 1.0
MSDL Business Rules Version 1.0
MSDL Coding Standards Version 1.0
15
Coding Standards

• Defines/Specifies
• XML specific data modeling rules
• XML element and type naming rules
• XML element and Attribute usage rules
• XML global and local definition rules
• Data model extension rules
• Under consideration - Data model translation
  instantiation rules (i.e. going from UML to XML)
• Parser specific rules (SAX/DOM)

Documents
XML Representation
MSDL Technical Specification Version 1.0
MSDL Business Rules Version 1.0
MSDL Coding Standards Version 1.0
16
References

• United Nations Centre for Trade Facilitation and
  Electronic Business (UN/CEFACT) XML Naming and
  Design Rules Version 2.0
• Available at http//www.disa.org/cefact-groups/atg
  /downloads/index.cfm
• Department of the Navy XML Naming and Design
  Rules, final Version 2.0 January 2005
• Available at http//www.doncio.navy.mil/(qsfyem55o
  y4eup45vvvgeu55)/PolicyMatrix/download.aspx?ide90
  e8a0b-3b39-4706-ab69-5b41378df6f7

17
Other Interesting Rules (1/2)

• Lower-Camel-Case (Capitalizes first letter of
  each word, except the first and compounds the
  name) for attribute names objectHandle
• Upper-Camel-Case (Capitalizes first letter of
  each word and compounds the name) for Elements
  and Types (Unit, ForceRelationship)
• Types declared for all elements
• Allows extensions to be managed using Type-based
  restrictions and extensions
• Elements are used to declare class attributes
  xsdAttributes are not used
• Xsdall compositor precluded from use
• Allows elements to occur in any order
• Elements are always optional
• Compositor not allowed to occur more than once
  thus cannot be repeated

18
Other Interesting Rules 2/2

• Major Version Definitions
• Removing or changing values in enumerations
• Changing element or type names
• Changing structure so as to break polymorphic
  processing capability
• Delete or add mandatory elements or attributes
• Changing cardinality from mandatory to optional
• Minor Version Definitions
• Adding enumeration values
• Optional-based extensions
• Adding optional elements
• Root schema versus subschemas must import root
  schemas to access their internal structures
• Import (external root)
• Include (internal to root)
• Section 9 using code lists within XML schemas
• Type definitions add a lot of flexibility in how
  to handle domain values
• Xsdchoice or union mechanisms

19
UML to XML Relationship

• All Classes are declared as xsdcomplexType
• All attributes are declared as a local
  xsdelement within an xsdcomplexType
• Composition associations are locally declared as
  an xsdelement within and xsdcomplexType
• Associations that are not defined as compositions
  are globally declared as an xsdelement. (These
  should be typed and then locally declared as
  xsdelement ref)
• Falls under UN/CEFACT XML NDR V2.0 Section 5.4
  Reusability Scheme (described a hybrid element
  type approach)

ForceRelationship objectHandle
20
JC3IEDMs Impact
21
Joint Consultation, Command and Control
Information Exchange Data Model (JC3IEDM)

• Comprehensive Information Exchange Data Model
• Coordinated with 26 countries
• Defines entities, organizations, actions,
  reporting data, etc.
• Provides XML Schema and Relational Data Model
  representations

http//www.mip-site.org/040_Public_Documents.htm
22
MSDL Drafting Group JC3IEDM Alignment
Report2006-11-16 François Gagnon (tiger team
lead) Environment Rob Wittman Jr. Forces,
Sides and AssociationsKevin Gupton Tasking
Org. and InstallationsMike Fraka Tactical
Graphics and OverlayCurtis Blais Military
Operation Other Than War
Drafting Group Product
Report and Presentation available at
www.sisostds.org/index.php?tgfilemanidxgetid2
9grYpathTigerTeamsfileJC3IEDM_Tiger_Team.zi
p
23
Sides Forces, and Associations

• JC3IEDM Objects and Affiliations Overview
• MSDL SideForces and Associations Elements
• JC3IEDM (Objects and Affiliations) and MSDL
  (Sides, Forces, and Associations) Alignment

24
Simulation to C2 Interoperability(SIMCI)
25
(No Transcript)
26
(No Transcript)
27
Software Evolution Due to the Alignment
Aligning MSDL with the JC3IEDM
28
Areas of Interest
Aligning MSDL with the JC3IEDM

• Ownership Who (what organization) does the
  network belong to?
• Addressing How do I reach a user on the
  network?
• Network Structure Are there subnets, multicast
  groups, or broadcast groups
• Services What services are provided and
  accessible on the networks.
• Role Access Are access privileges role based?
  What are the roles?

MSDL Structure
JC3IEDM Structure
29
Software Evolution Due to the Alignment
Aligning MSDL with the JC3IEDM Software Evolution
30
JC3IEDM As An Internal Data Model For The C4I
Adapter

• Adapter is currently Pass Through Only
• No internal data representation/store
• Two recent requirements have led to the need for
  a change to this design decision
• Common internal data model
• Internal model may lead to a major reduction in
  duplicative mappings
• New interoperability approaches
• Implemented utilizing a Publish and
  Subscribe (PASS) web service architecture
• C2IEDM is the current data model
• JC3IEDM is the objective data model
• Currently used for internal and coalition data
  interoperability

31
Data Model Analysis and Implementation
JC3IEDM as an Internal Data Model for the C4I
Adapter

• Selection of a Data Model
• The options
• Create our own
• Reuse one of the many current simulation or C2
  data models
• Decision was to create a tailored implementation
  based off of the JC3IEDM
• Implementation
• JC3IEDM exists in both XML and relational
  database forms
• Since data persistence is required for the web
  service capability a database was used
• The JC3IEDM DB version was used as a guide for
  the runtime database development
• The Common internal data model references the
  database, but remains strictly pass through

Message Recipient
Simulation Data
Publish
Input Handler
Push to Subscribers
JC3IEDM DB
C4I Adapter
32
Software Blocking (SWB)
33
Software Blocking
What is it?

• An Army organization that is charged with
  attaining schedule and fielding harmonization
  while ensuring interoperability among systems
  participating in the Block.
• SWB is intended to harmonize system requirements,
  software acquisition schedules and contracts,
  capitalize on grouped testing efficiencies and
  manage blocked fielding to overcome the
  shortcomings found in the legacy stovepiped
  acquisition process.

34
Software Blocking
Who Participates?

• Almost all digital vehicles, weapon platforms and
  battle command systems
• Many simulations still under active development
• OneSAF (Block 2)
• CCTT (Block 1)
• WARSIM (Block 3)
• Not many legacy systems
• Other supporting systems
• Test and evaluation systems, etc.

35
Software Blocking
What Does it Require?

• Participation in IPTs
• Answering Data Calls
• Voting
• Technical issues
• Membership
• Documents
• Thread Development (The Biggie)
• IAIC (The Really Biggie)
• Operational Evaluation
• Not required for simulations

36
Software Blocking Schedule6 months old, no
longer accurate
37
Intra Army Interoperability Certification (IAIC)

• The Capstone of each Block
• All systems must pass ALL threads in order to get
  a full stamp of approval
• CTSF has been mandated the sole source of this
  testing
• Cost 120K
• final costs have still not been stated
• We will be testing at the DIL
• It was approved as a satellite site
• Has a DREN connection to the BC systems running
  at CTSF

38
IAIC Test Threads

• Created and Managed by TPIO-Battle Command
• Process All TSMs, TPOs, PMs, etc. representing
  the programs get together and create threads that
  each system must fall in line with
• Essentially creating requirements
• These threads are called Parent Threads
• Sim/Stim programs then go through these threads
  and highlight those items that we implement
• Must be approved by the PM and TPO
• Final threads are handed over to CTSF where they
  are turned into test steps

39
Thread Diagram
FS-1a.1ON Call for Fire Previous Target from an
Observer to FIST (MOD)(OneSAF)
9b
10c
6b
8c
12
4a
7c
BCT CP1
AFATDS FECC
EMT
MCS WS
MCS GW
4
ASAS
AIS
7g
8g
10g
4c
4e
4d
Fires BN
ASAS
AFATDS FDC
13
4b
8b
10b
7b
3
9c
6a
6c
11
10f
9a
MVR BN Main
8d
ASAS
MCS WS
EMT
MCS GW
AFATDS FECC
3b
7f
8f
10f
3a
3d
7d
5
3c
1a
Fires BTRY
AFATDS FDC
2a
9d
CO
7a
6d
Breakout
9
8a
10e
1b
FIST
FOS
10a
8e
Stryker
A3 BFIST
7e

6
Howitzers
1
Observer
2

9e
7
6e
8
1c
10
Breakout

LW 155 DFCS
Paladin PDFCS
Paladin AFCS
GDU
GDU-R
Breakout
M2A3
PFED
FOS
M1A2 SEP
Stryker
FBCB2
CCN SWBB2 FS-1a.1ON v2_0 Dv4 27 Jun 05 (P-Fv1)
40
Thread Narrative
41
How OneSAF Fits Into SWB

• Our involvement in SWB began with Block 2
• And will be in every subsequent block until we no
  longer do new development or cease to stimulate
  new C4I systems
• We have 23 test threads
• Initial agreements (PM and TPO) signed
• Final agreements pending
• TPIO-BC is still analyzing changes that were sent
  to them
• All simulations do their IAIC at the tail end of
  the IAIC period
• We were scheduled to test in June 07
• Slip of Block 2 schedule has pushed this into
  early 2008

42
Questions?