420 likes | 628 Views
3.3 Other OneSAF Activities: SISO, SIMCI and SWB. Dr. Robert Wittman Mr. Stephen Lopez-Couto. Discussion Topics. Introduction SISO Activities SIMCI Activities Software Blocking Activities Questions. Scenario Composition. Military Scenario Development Environment.
E N D
3.3 Other OneSAF Activities: SISO, SIMCI and SWB Dr. Robert Wittman Mr. Stephen Lopez-Couto
Discussion Topics • Introduction • SISO Activities • SIMCI Activities • Software Blocking Activities • Questions
Scenario Composition Military Scenario Development Environment Ease of Use in the MS Power Point environment
Simulation Interoperability Standards Organization (SISO)Activities
Product Development Group Kickoff 5 April 2006 MSDL: The Study Group 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 CSC Confidential.
MSDL: The Product Development Group • PDG Teleconference 2nd Thursday of every month from 11:00-12:30 EST • DG Teleconferences 1st and 3rd Thursday of every month from 11:00-12:30 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) • Chuck Turnitsa (ODU) • Jeff Covelli (General Dynamics/CTIA) • Per Gustavsson (Erickson/Sweden) • Erik Borgers (Netherlands) CSC Confidential.
MSDL Road to Balloting (Evolving) PDG Spec Review 28 June 07 PDG Review Period ~ 2 weeks • Fall-SIW: 16-21 Sept. 2007 • PDG Meeting • Thursday, 20 Sept. • 1:00 PM – 4:00 PM • Room TBD • Balloting Status 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 CSC Confidential.
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 CSC Confidential.
Technical Specification XML Representation Documents • 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 MSDL Technical Specification Version 1.0 MSDL Business Rules Version 1.0 MSDL Coding Standards Version 1.0 CSC Confidential.
Business Rules Documents XML Representation MSDL Technical Specification Version 1.0 • 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 evolvingenvironmental conditions MSDL Business Rules Version 1.0 MSDL Coding Standards Version 1.0 CSC Confidential.
Coding Standards Documents XML Representation • 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) MSDL Technical Specification Version 1.0 MSDL Business Rules Version 1.0 MSDL Coding Standards Version 1.0 CSC Confidential.
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/(qsfyem55oy4eup45vvvgeu55)/PolicyMatrix/download.aspx?id=e90e8a0b-3b39-4706-ab69-5b41378df6f7 CSC Confidential.
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 xsd:Attributes are not used • Xsd:all 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 CSC Confidential.
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 • Xsd:choice or union mechanisms CSC Confidential.
Unit objectHandle forceSymbolID … Position … Unit objectHandle forceSymbolID … UML to XML Relationship • All Classes are declared as xsd:complexType • All attributes are declared as a local xsd:element within an xsd:complexType • Composition associations are locally declared as an xsd:element within and xsd:complexType • Associations that are not defined as compositions are globally declared as an xsd:element. (These should be typed and then locally declared as xsd:element ref=) • Falls under UN/CEFACT XML NDR V2.0 Section 5.4 Reusability Scheme (described a hybrid element & type approach) ForceRelationship objectHandle CSC Confidential.
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 CSC Confidential.
Drafting Group Product MSDL Drafting Group JC3IEDM Alignment Report2006-11-16François Gagnon (tiger team lead) – EnvironmentRob Wittman Jr. – Forces, Sides and AssociationsKevin Gupton – Tasking Org. and InstallationsMike Fraka – Tactical Graphics and OverlayCurtis Blais – Military Operation Other Than War Report and Presentation available at www.sisostds.org/index.php?tg=fileman&idx=get&id=29&gr=Y&path=Tiger+Teams&file=JC3IEDM_Tiger_Team.zip CSC Confidential.
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 CSC Confidential.
Aligning MSDL with the JC3IEDM Software Evolution Due to the Alignment
Communications Networks Task Organization Units Equipment … … … Aligning MSDL with the JC3IEDM Areas of Interest 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
Aligning MSDL with the JC3IEDM: Software Evolution Software Evolution Due to the Alignment
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
JC3IEDM as an Internal Data Model for the C4I Adapter Data Model Analysis and Implementation • 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
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. CSC Confidential.
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. CSC Confidential.
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 CSC Confidential.
FY06 FY07 FY08 FY09 FY10 FY11 FY12 FY13 FY14 FY15 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q Execution Phase CTC Training IAIC Dev TFT SWB 08-10 (SWB 2) Major Blocks support major capabilities and new TV-1 and require full SWB Preparation & Execution Phases, an OE and a full IAIC. “Plus” Blocks inserts approved new operational capabilities identified from prior testing or critical field requests into a current Baseline. Requires impact/risk analysis. IAIC focus on new capability. An OE should not be required. OIF/OEF 08 ζ Risk Reduction Regression (as required) Analysis TFT IAIC CTC Training Dev SWB 09-11 (SWB 2+) OIF/OEF 09 Regression Risk Reduction OE Window Prep Phase Execution Phase Development CTC Training IAIC TFT SWB 10-12 (SWB 3) OIF/OEF 10 ζ Risk Reduction (OVs, SVs) Regression OE Window SWB 11-13 (SWB 3+) Analysis IAIC CTC Training Development TFT OIF/OEF 11 Risk Reduction Regression (as required) Potential OE Window Prep Phase Execution Phase SWB 12-14 (SWB 4) (OVs, SVs, BEMP) TFT CTC Training IAIC Development OIF/OEF 12 Risk Reduction Regression OE Window SWB 13-15 (SWB 4+) Analysis IAIC CTC Training Development TFT OIF/OEF 13 Risk Reduction Regression (as required) Potential OE Window Prep Phase Execution Phase SWB 14-16 (SWB 5) (OVs, SVs, BEMP) TFT CTC Training IAIC Development OIF/OEF 14 Risk Reduction Regression OE Window Software Blocking Schedule~6 months old, no longer accurate
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 CSC Confidential.
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 CSC Confidential.
Primary Exchange Secondary Exchange 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 MCS WS MCS GW EMT ASAS 4 AIS 8g 7g 10g 4d 4c 4e Fires BN ASAS AFATDS FDC 13 4b 10b 8b 7b 3 9c 6a 6c 11 10f 9a MVR BN Main 8d ASAS EMT MCS WS MCS GW AFATDS FECC 10f 8f 7f 3b 3a 3d 7d 5 3c 1a AFATDS FDC Fires BTRY 2a 9d CO 7a 6d *Breakout 9 8a 10e 1b FIST FOS 10a Stryker 8e 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 FOS PFED M2A3 M1A2 SEP Stryker FBCB2 CCN: SWBB2 FS-1a.1ON v2_0 Dv4 27 Jun 05 (P-Fv1)
Thread Narrative CSC Confidential.
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 CSC Confidential.