1 / 16

IDEAS Group Model for Interoperability

IDEAS Group Model for Interoperability. Ian Bailey, UK Fariba Hozhabrafkan, UK. The IDEAS Group. I nternational D efense E nterprise A rchitecture S pecification for exchange Australia, Canada, UK, USA, NATO, Sweden (observers).

gchan
Download Presentation

IDEAS Group Model for Interoperability

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. IDEAS GroupModel for Interoperability Ian Bailey, UK Fariba Hozhabrafkan, UK

  2. The IDEAS Group • International Defense Enterprise Architecture Specification for exchange • Australia, Canada, UK, USA, NATO, Sweden (observers) Objective — To deliver a unified specification for the exchange of architectural documentation and artefacts between coalition partners.

  3. Coalition • Australia, Canada, UK and USA have a history of military coalition • Each nation is pursuing its own version of net-centric warfare • Need for some degree of international net-centricity • Shared situational picture • Collaborative Engagement Capability • etc. • Each nation is developing its own architectural framework • Requirement to share architectural information between nations to enable interoperability at the operational and system levels

  4. The Team UK Jon Keefe (MOD), Fariba Hozhabrafkan, Ian Bailey (MOD Contractors) US Mike Wayson (OSD), Francisco Loaiza (IDA), Bill Tracey (LMIT), Dave McDaniel (Silver Bullet) CA Matthew Wong (DND) AU Kim Lambert, Doug Wilson (ADO) Observers: NATO Svein Olaussen (NAF Syndicate Lead) Sweden Mikael Hagenbo (Swedish Armed Forces)

  5. Approach • Individually evaluate existing architecture data models to determine the degree of compatibility between the data models, and provide recommendations for the way ahead in developing the architectural exchange specification. • Identify gaps and deficiencies with respect to the IDEAS requirements, and recommend solutions – i.e. rationalise raw requirements into a formal model. • Define the technical approach for IDEAS implementation and usage—the candidates include XMI and XML. The possible use of web services and semantic web technology for interoperability • Pilot implementation and interoperability test cases. • Establish an international IDEAS change management process.

  6. Structure • Layered approach • Starting from first principles to ensure common understanding at the most fundamental level • Reaching down to country-specific definitions whose meaning may need to be understood by other nations fundamental concepts: classes, instances, properties foundation high-level patterns (upper ontology) commonly used relationships: whole-part, sequence, partipation, etc. common objects (agreed taxonomy) internationally accepted terms: person, organization, materiel, etc. national extension national extension national extension national extension terminology specific to nations that which may be useful to other nations - e.g. Bowman, Bradley FV, etc.

  7. Foundation • The nations involved were using different modelling paradigms: • Entity-Relationship • Object-Oriented (inc. UML Meta-Models) • Ontology • All of these modelling approaches are based on formal logic and set theory, but each is subtly different – especially as users tend to adopt a given “style” • These differences were making it hard to establish a common approach between the nations – there was too much scope for misunderstanding between parties • To mitigate these problems, the IDEAS Model defines a foundational layer (based on IEEE Candidate Upper Ontologies such as SUMO & ISO15926)

  8. Foundation Elements • Terminology used is very formal • Not for end-user use • Purpose is solely to establish a formal mathematic foundation to the model • Key objects are: • Element – an individual thing – e.g. USS Theodore Roosevelt • Type – a class of thing – e.g. Nimitz Class carrier • Tuple/Couple – relationships between objects – e.g. USS Theodore Roosevelt is a instance of a Nimitz class vessel Object +tuplePlace * +firstTuplePlace +secondTuplePlace 1 1 «instanceOf» {subsets {subsets tuplePlace} tuplePlace} tuple Type Element couple

  9. Foundation Patterns • The foundation level also establishes fundamental relationships:

  10. High-Level Patterns • To assist in the development of the IDEAS model, the nations have adopted the BORO (Business Object Re-Engineering Ontology) methodology - http://www.boroprogram.org • This methodology is particularly useful for IDEAS because it starts with “legacy” models and gradually develops a common model. • As existing models and data are subjected to the methodology, high-level patterns start to emerge. • So far (this is at an early stage) only one pattern has been formally documented (whole-part) • …though several others have been recognised (e.g. sequence, ownership, communication, connection, etc.)

  11. High-Level Patterns – Whole-Part • Probably the most common of all patterns • e.g. system-subsystem, process-subprocess, organization-suborganization

  12. Common Objects • Some concepts are common to all architectures • The IDEAS Group is identifying the common concepts and placing them in the appropriate part of the model (i.e. under the appropriate part of the foundation) • This work is also exposing the high-level patterns • The big surprise has been how many concepts are not commonly understood between the nations (esp. operational node, system & capability)

  13. Common Objects – Person & Organization • These elements are key to the operational views. • The IDEAS Model adds the concept of states to allow for changes over time (e.g. OV-6b) • All descend from Element • Agent: • Something capable of action • (could be op node ?) Element AgentState PersonState OrganizationState Agent Person Organization

  14. National Extensions • To enable international interoperability, it is necessary for each nation to have some understanding of the others’ terminology • Hierarchical nature of IDEAS means that these nation-specific terms descend from common objects, hence nations can always refer back to a common level of understanding – e.g. a Bradley FV is a light battle tank, Bowman is a tactical radio system, etc. • This work is also likely to generate requirements for new common objects to bridge the semantic gap between nations • …and will also drive the discovery of common high-level patterns

  15. National Extensions Example (work in progress) USA:: GovernmentOrganization USA:: PrivateSectorOrganization Agent OrganizationState Model::Organization USA:: SovereignBody Association AgentRelationship Canada:: LineOrganization Canada:: MatrixProjectOrganization Canada:: ClientOrganization Canada:: USA:: USA:: USA:: NonCanadianGovtOrganization USA:: USA:: DirectCommand IsInDirectSupportOf CombatCommand IsInReserveTo HasTacticalControlOver USA:: USA:: HasOperationalCommandOver HasTacticalCommandOf USA:: USA:: IsUnderCommandForAdministration IsAttachedTo USA:: USA:: USA:: HasOperationalControlOver ProvidesLogisticServicesTo IsInGeneralSupportOrReinforcingOf USA:: USA:: IsAnAlternativeFor HasFullCommandOver USA:: USA:: IsInGeneralSupportOf IsReinforcing USA:: SituationDependentOrganizationRelationship USA:: IndirectOrganizationRelationship

  16. www.ideasgroup.org

More Related