The Euclid RTP 11'13

1

• The Euclid RTP 11.13
• SEDE Data Model
• Keith Ford
• Thales Training Simulation

2
Presentation Overview

• SEDE Overview
• Rationale for SEDE Data Model
• SEDE Data Model
• Conclusions

3
SE Development Environment
Repository
Knowledge Base
4
SEDE Implementation (1)
5
SEDE Implementation (2)
6
SEDE INTERFACES
SE Management Tool
Repository
7
SEDE Tool Suite
Federation User Requirement Tool
Goal Editor
Analyse Users Needs
Evaluation Definition Tool
SE Analysis Tool
Evaluation Definition Selection Tool


Define Fed. User Requirements
Conceptual Model Tool
Federation Composition Tool
Federation Requirements Tool
Scenario Allocation Tool
Define Fed. System Requirements

Network Configuration Tool
Design Federation
Federation Infrastructure Tool
Network Test Tool
Federate Test Suite
Test Navigational Tool
Implement Federation
FCI Tool
Instructors Reallocation Tool
Federation Monitoring Control
Integrate Test Federation
Tool
Evaluation Execution Tool
Remote Audio Configuration
Tool
Operate Federation
On-line Federate Configuration
Tool
SE Management Tool
C3I Simulation Communication
Perform Evaluation
Asset Characterisation Tool
System Tool
Data Distribution Tool
8
Presentation Overview

• SEDE Overview
• Rationale for SEDE Data Model
• SEDE Data Model
• Conclusions

9
Rationale for Data Model (1)
Goal Editor
Design Federation
Implement Federation
Analyse User Needs
Define Fed. User Reqments
Define Fed. System Reqments
Integrate Test Federation
Perform Evaluation
Operate Federation
Repository
10
Rationale for Data Model (2)
User Scenario Req. Tool
Analyse User Needs
Design Federation
Implement Federation
Define Fed. User Reqments
Define Fed. System Reqments
Integrate Test Federation
Perform Evaluation
Operate Federation
Repository
User Goals
11
Rationale for Data Model (3)
User Constraint Req. Tool
Analyse User Needs
Design Federation
Implement Federation
Define Fed. User Reqments
Define Fed. System Reqments
Integrate Test Federation
Perform Evaluation
Operate Federation
Repository
User Goals
Federation Scenario
12
Rationale for Data Model (4)
Conceptual Model Tool
Analyse User Needs
Design Federation
Implement Federation
Define Fed. User Reqments
Define Fed. System Reqments
Integrate Test Federation
Perform Evaluation
Operate Federation
Repository
User Goals
Federation Scenario
User Constraint Requirements
13
Rationale for Data Model (5)
SE Management Tool
Analyse User Needs
Design Federation
Implement Federation
Define Fed. User Reqments
Define Fed. System Reqments
Integrate Test Federation
Perform Evaluation
Operate Federation
Repository
User Goals
Conceptual Model
Federation Scenario
User Constraint Requirements
14
Use of Data Model
Repository
ProjectInfoEntry
15
Repository Entry Structure
Data format defined using XML
Need to define standard format for storing/
interchanging data
16
Presentation Overview

• SEDE Overview
• Rationale for SEDE Data Model
• SEDE Data Model
• Conclusions

17
SEDE Data Model

• Provides an interface description for SEDEP and
  the tools that support it c.f. DIF
• Provides a design description of data for
  producers of the data
• Map of where to find data for consumers of data
• Defined using UML
• Distinction between classes that are
  project-specific and those that are reusable
  assets
• Re-useable assets stored in Asset Libraries

18
Asset Re-use
Logical View
Project A
Project B
Project A-specific Entry
Project B-specific Entry
Asset X
19
Project Re-use
Logical View
Project A
Project B
Project A
Project B
Project A Entry X
Project B Entry X
Copy
Project A
Project B
X
X
20
Example SEDE Data Models

• Federation requirements
• Scenario
• Federation Conceptual Model
• Federation Composition
• Network and computer design
• Federation infrastructure runtime data
• Evaluation (definition, design, results, etc.)
• IOS runtime data
• Asset characterisation
• Project data model

21
Example Data Model Element
22
SEDE Data Model Rules (1)

• Classes should be identified according to their
  data content not their data format e.g. there
  would be a Test Plan class, not a Word document
  class
• Classes should be (relatively) small.
• Good data modelling practices should lead to this
  result
• Helps to promote re-use of the data i.e. it is
  more likely that a small data entry will satisfy
  a new requirement rather than a large complex
  entry.
• Each class should have a unique set of primary
  key attributes
• Project specific classes should have the Project
  Name as one of their primary keys
• Foreign keys should be included in classes to
  provide referential integrity

23
SEDE Data Model Rules (2)

• Classes should depict the logical structure of
  the data, as identified by data modelling
  principles
• If this breakdown is more detailed than that
  required in the Repository, this should be
  indicated using Groups

24
Data Model Groups (1)

• A sub-hierarchy of data model classes can be
  grouped together to indicate that they will
  actually be implemented in a single Repository
  Entry
• Classes in the Data Model that are not in a Group
  map 1-to-1 with the repository Entry Types

25
Data Model Groups (2)
Logical View
26
XML Translation of Native Format Files

• Useful to save data in native format as well as
  translated to XML
• Improves performance
• Must synchronise both repository entries
• Requires tool specific translators
• Convert to XML
• Organise data according to SEDE data model
• Enables tools providing similar functionality to
  access data

27
Aggregation/Dis-aggregation of Repository Entry
Ref to B
Ref to A
XML Document
28
Presentation Overview

• SEDE Overview
• Rationale for SEDE Data Model
• SEDE Data Model
• Conclusions

29
Conclusions

• SEDE Data model provides a standard method for
  representing data structures to facilitate it
  being exchanged between tools
• Need an internationally recognised standard to
  support FEDEP/SEDEP
• Euclid RTP 11.13 provides a good starting point
  for further work in this area.

30
?
QUESTIONS keith.ford_at_thales-tts.com