1 / 28

Federation Agreements - Observations, Considerations and Proposals out of NATO MSG-052

Knowledge Network. Federation Architecture & Design. MSG-052. Federation Agreements - Observations, Considerations and Proposals out of NATO MSG-052. Wim Huiskamp (TNO), Dannie Cutts (Aegis Technologies), Stephane Chaigneau (DGA) & MSG-052 Task Group Members.

jarrett
Download Presentation

Federation Agreements - Observations, Considerations and Proposals out of NATO MSG-052

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Knowledge Network Federation Architecture & Design MSG-052 Federation Agreements - Observations, Considerations and Proposals out of NATO MSG-052 Wim Huiskamp (TNO), Dannie Cutts (Aegis Technologies), Stephane Chaigneau (DGA) & MSG-052 Task Group Members Knowledge Network for Federation Architecture and Design

  2. Outline MSG-052 Background Structured Approach Formalized Approach Recommendations

  3. Underlying Tenet of MSG-052 Knowledge Network for Federation Architecture and Design: Problem: Knowledge of “good design” is gained through hands-on experience, trial-and-error and experimentation. This type of knowledge is, however, seldom re-used and rarely shared in an effective manner. Approach: A ”Community of Practice”, consisting of federation development experts from NATO and partner nations, to foster development of state-of-the-art federation architecture and design solutions, and provide a Knowledge Base for the M&S community as a whole. Ref: 07F-SIW-024

  4. MSG-052 Federation Agreements subgroup Subgroup tasked on ‘Agreements’ 3 Workshops from Feb2007 to March 2008 Workshops prepared through CWE Presentations by Germany, Netherlands, USA and France describing Federation Agreements viewpoints Discussions and consensus building Results of the Agreements subgroup’s work are the subject of this presentation

  5. MSG-052 View regarding Agreements • Agreements are an integral component of overall Simulation Design and crucial to simulation success (whether agreements are documented, formalized, implicit or ad-hoc) • Agreements serve to clarify expectations, constraints and responsibilities between members of a simulation • Agreements exist throughout the simulation lifecycle (particularly important for long-lived or re-used federations) • Agreements should be structured into • four categories of information: Operational, System, Technical and Physical (discussed later – Part I) • a set of formalized information products (discussed later – Part II)

  6. Outline MSG-052 Background Structured Approach Rationale Information centric approach Information products Stakeholders Structure for Agreements Formalized Approach Recommendations

  7. FEDEP/DSEEP Top-Level View Establish Agreements Consider Federation Agreements across the entire FEDEP … not just Step 4 !

  8. Requirements Problem statements Objectives Operational Scenarios Conceptual model Federate list Object model and interaction concept Federation management agreement Scenarios to federate mapping Time management Coordinate system Technology (HLA, DIS, TENA,..) Middleware Services PDUs Firewall TCP/IP FOM (xml) Hardware resources

  9. Formal Definition of Agreements • If …Then .. Else … • Interaction Diagrams

  10. Rationale for a structured approach Agreements are captured as Information Products Clarify and Define required Information Products Define Stakeholders for Information Products Agreements are made during the whole process Agreements influence all steps. Adopt an information centric approach

  11. Information Product Categories Operational Perspective Includes Requirements, Problem Statement Objectives, CONOPS, Operational Scenario, Conceptual model, Measures of merit.Maps to FEDEP/DSEEP steps 1, 2 and 7 System Perspective Maps the logical activities in the scenario to the members, System composition, identify Information exchange data mode (architecture).Maps to FEDEP/DSEEP steps 2 and 3 Technical Perspective Maps scenario elements to federates; specifies the interface of each member, and indicates the technical components (e.g. RTI, tools) Maps to FEDEP/DSEEP steps 3, 4, 6 & 7 Physical Perspective Description / Design of the physical aspects of a distributed simulation (e.g. Networks, Computers, tool versions, etc.) Maps to FEDEP/DSEEP steps 4 and 5

  12. Define Simulation EnvironmentObjectives Develop Simulation Environment Design Simulation Environment Execute Simulation Environment and Prepare Outputs Perform Conceptual Analysis Plan, Integrate, and Test Simulation Environment Analyze Data and Report Results 1 5 4 3 6 2 7 Operational Problem statements Requirements Objectives Operational Scenarios Conceptual model System Object model and interaction concept Federate list Federation management agreement Scenarios to federate mapping Time management Technical Technology (HLA, DIS, TENA,..) Coordinate system Middleware Services PDUs FOM (xml) Physical TCP/IP Hardware resources Firewall

  13. Define Simulation EnvironmentObjectives Develop Simulation Environment Design Simulation Environment Execute Simulation Environment and Prepare Outputs Perform Conceptual Analysis Plan, Integrate, and Test Simulation Environment Analyze Data and Report Results 1 5 4 3 6 2 7 Operational Program manager <fed. customer, problem setter> Federation user Operational Customer Military operators Federation manager <problem solver> Analyst / Evaluator <AAR> System Federation designer Technical Simulation designer Federate designer SME Federate Application Designer Federation support operators Physical S/W engineers Network engineer Network architect

  14. Structured Agreements: The “5 W’s design pattern” What is agreed to (content) When is it applicable (moment in time) Who is affected by it (involved parties, federates) Where it applies (circumstances, conditions) Why this agreement was made (rationale) EXAMPLE: Synced Local Time What: Member will sync local clocks thru NTP When: member joins federation Who: All members Where: Always Why: local Logs should have synced timestamps Are 5Ws sufficient ?

  15. MSG-052 Background Structured Approach Formalized Approach Recommendations Outline

  16. Objectives Logic Architecture Mapper Operational scenario Integration Report Config Analyze report Requirement FOM Config Conceptual Model Test Report Initialization scenario Raw results VV&A Objectives Mapping Define Simulation EnvironmentObjectives Develop Simulation Environment Design Simulation Environment Execute Simulation Environment and Prepare Outputs Perform Conceptual Analysis Plan, Integrate, and Test Simulation Environment Analyze Data and Report Results 1 5 Generic Process DSEEP 4 3 6 2 7 HLA FEDEP Generic Information Products Information Products Meta Model Simulation Interoperability Infrastructure HLA Simulation Implementation Mapping

  17. Rationale for a formalized approach Improved reuse of information across and between federations Improved sharing of information between distributed team members with the support of tools Reduced complexity in information use through information categories and user roles Improved support for traceability and check of completeness Potential to automatically generate documentation and computer code to reduce the technical effort and improve coherence

  18. Metamodel proposals for DSEEP Define Simulation EnvironmentObjectives Develop Simulation Environment Design Simulation Environment Execute Simulation Environment and Prepare Outputs Plan, Integrate, and Test Simulation Environment Perform Conceptual Analysis Analyze Data and Report Results 1 5 4 3 6 2 7 Requirements Operational Conceptual model Federate list

  19. MSG-052 Background Structured Approach Formalized Approach Recommendations Outline

  20. Recommendations MSG-052: Gain consensus on Agreements Categories, Content and Stakeholders Gain consensus on the metamodel for DSEEP Information products NMSG: Develop and Adopt a formal NATO metamodel for DSEEP SISO DSEEP PDG: Improve and introduce the proposals in the DSEEP standard Industry: Include and support proposals in future Simulation design tools

  21. Questions / Discussion? Knowledge Network Federation Architecture & Design MSG-052 Knowledge Network for Federation Architecture and Design

  22. MSG-052 Participants Name Nationality Company Ancker Göran Swedish Saab Avionics AB Bizub Warren USA USJFCOM/JWFC Boulet James USA PLEXSYS / JFCOM Chaigneau Stephane French DGA – French MOD Cutts Dannie USA AEgis Technologies Group / JFCOM De Salvador Luis Spanish MINISTERIO DE DEFENSA Ekvall Håkan Swedish BAE Systems C-ITS AB Ericsson Michael Swedish Carmenta Ford Keith British Thales González Godoy Sabas Spanish Spanish Army Hassaine Fawzi Canada Defence R&D Canada Kervella Audren France DASSAULT AVIATION

  23. MSG-052 Participants Name Nationality Company Huiskamp Wim Dutch TNO Defence, Safety and Security Hultén Torbjörn Swedish BAE Systems C-ITS AB Jansen Roger Dutch TNO Defence, Safety and Security Jimenez Patricio Spanish Spanish Mod Johansson Ulf Swedish SaabTech Systems AB Johansson Maj Swedish Kervella Audren France DASSAULT AVIATION Lundmark Stefan Swedish Saab Training Systems AB Löfstrand Björn Sweden Pitch Technologies AB Malherbe Thierry France SOGITEC Meyer Christophe France THALES – Security Solutions and Services

  24. MSG-052 Participants Name Nationality Company Siebeneicher Jochen German BWB – Federal Office of Defense Technology and Procurement Smith Neil British UK Defence Science and Technology Laboratory (Dstl) Steinkamp Dieter German IABG mbH Tegner Jan Swedish SaabTech Systems AB Wall Ola Swedish Kockums Waller Björn Swedish FOI Wemmergård Joakim Swedish FMV Öhlund Gunnar Swedish FMV

  25. Consider Federation Agreements across the entire FEDEP … not just Step 4 ! Establish Federation Agreements

  26. Architectures and frameworks The following slides describe the information products, roles and metadata involved during the FEDEP/DSEEP and which are linked with the Agreements. These items are classified in four categories, which are based on an extension to the NATO Architecture Framework (NAF). The NAF describes 3 views: Operational, System and Technical. We propose a fourth ‘Physical’ category to take into consideration the implementation level.

  27. Four categories of Agreements: Operational: Includes Requirements, Objectives, CONOPS, Operational Scenario, Maps to steps 1, 2 and 7 System :System composition (architecture), FOM, Maps to steps 2 and 3 Technical: maps scenario elements to federates ; chooses the technical components (RTI, … ) Maps to steps 3, 4, 6 & 7 Physical: Description / Design of the physical aspects of a federation (e.g. Networks, Computers, tools, etc.) Maps to steps 4 and 5 Define Simulation EnvironmentObjectives Develop Simulation Environment Design Simulation Environment Execute Simulation Environment and Prepare Outputs Perform Conceptual Analysis Plan, Integrate, and Test Simulation Environment Analyze Data and Report Results 1 5 4 3 6 2 7 Corrective Actions / Iterative Development

More Related