EU Core Technical Framework Study Semantic mapping among MS and

By Roy Rogers,2014-04-15 07:12
7 views 0
EU Core Technical Framework Study Semantic mapping among MS and


    EU Core Technical Framework Study:

    Semantic mapping among M&S and Systems Engineering Standards

    Dr Choong-ho Yi

    Combitech AB

    P.O. Box 6011

    SE-17263 Sundbyberg

    +46 8 580 86062

    Dr Qi Huang

    Saab AB

    Nettovägen 6

    SE-17588 Jarfalla

    +46 73 437 4431

    Dr Robert Suzić

    Combitech AB

    P.O. Box 6011

    SE-17263 Sundbyberg

    +46 8 580 86078

    Jan Tegnér

    Saab AB

    St Olofsgatan 9 B

    SE-75321 Uppsala

    +46 73 437 7105


    In cooperation with EDA (European Defence Agency), EU Core Technical Framework Study was

    conducted during 2008-2009. The goal of the study is to enable a framework that promotes secure,

    multinational distributed simulations. The main domains targeted are Training, Simulation Based

    Acquisition (SBA) and Concept Development and Experimentation (CD&E). On developing such a

    framework, efforts have been made to reuse the existing state-of-the-art methods and techniques without

    reinventing the wheel, which would increase usability and acceptance of the framework.

    This paper gives an overview of the Core Technical Framework developed during the study and then

    presents a part of the results in more detail, i.e. semantic mapping among the M&S and Systems

    RTO-MP-IST-087 5 - 1



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

    Engineering standards. The mapping has been made between the specification documents produced from

    the standards. Such a mapping contributes to increased communication between different types of

    stakeholders, reuse of M&S artefacts and interoperability.


    Typically system development including simulation model development and its intended deployment

    needs to be performed by considering a number of different aspects from different stakeholders with

    different responsibility and interests. In the past these different stakeholders usually had their own

    methods, representation languages and terms to describe their parts of the system from their perspectives

    which fit for their own purpose. Three major problems with this way of working are:

     It is difficult for the different stakeholders involved to communicate with each other in efficient

    manner due to lack of common base.

     It is difficult to establish a holistic view of the whole system.

     Consequently, verification and validation (V&V) can not be conducted effectively or efficiently.

    1An architecture framework provides a collection of views each of which is intended to describe different

    parts and aspects of a system from the viewpoints of different stakeholders. Using an architecture

    framework each of the stakeholders can express his/her concerns in terms of views in a manner consistent

    and communicative with other views that are also provided by the same framework, and that describe

    other stakeholders’ concerns. Further, system descriptions captured in such views can be reused within

    current or future projects. Thereby an holistic and consistent description of a complex problem from

    different perspectives can be achieved, ensuring traceability between the developed distributed simulation,

    various tactics, techniques, procedures, strategy or doctrinal guidance, system and organizational

    processes and functions etc. Further, it ensures all participating stakeholders develop a common

    understanding of the problem in focus, e.g. organizational and system capability.

    One may say that architecture framework approaches, e.g. MODAF (Ministry of Defence Architecture

    Framework), DoDAF (Department of Defence Architecture Framework) and NAF (NATO Architecture

    Framework), originate from the Systems and Software Engineering (S/SE) community. Nevertheless we

    claim that architecture frameworks are equally applicable to M&S as well for at least two reasons:

    2 M&S can be considered as a subset of S/SE.

     Architecture framework can be preferably used as a hub to create an alignment among the M&S

    and S/SE approaches (standards, methods, techniques).

    Section 2 provides an overview of the proposed Core Technical Framework which contains among others

    the mapping between Systems Engineering and M&S as a subcomponent. Section 3 contains a general

    discussion about architecture and architecture framework. Then the mapping is presented in detail in

    Section 4, and final remarks are made in Section 5.

     1 “Architecture framework” and “architecture” will be defined in Section 3.

    2 We are aware that this may be a very strong statement. There are M&S-specific issues indeed that are not covered sufficiently

    in S/SE. For example, VV&A in M&S and S/SE are different from each other. What we mean is, from the system viewpoint,

    a simulation model is a system as well.

    5 - 2 RTO-MP-IST-087



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards


    2.1 Purpose

    The purpose of the EU Core Technical Framework Study has been to define an EU-wide Distributed

    Simulation Architecture enabling secure, cost-efficient, multinational, distributed simulation

    experimentation and training across the participating member states (pMS).

    The main benefit of a Core Technical Framework is to promote reuse of earlier simulation efforts, to

    support collaborative efforts, to ensure interoperability and to provide methods, capabilities and technical

    solutions to enable cost effective use of distributed simulations in the whole lifetime cycle.

    2.2 Scope and Effect

    Constructing an EU Core Technical Framework is not a simple task due to the increasing complexity of

    the operative environment and the diversity of distributed simulations that now need to be integrated.

    The operations of today are characterized by the collaboration of a growing number of players, in a multi-

    national environment with different organizations, methods, technologies and policies & regulations. Such

    Multi-Dimensional Mission Operations (MDMO) is ranging from non-military tasks as humanitarian

    relief operations or crisis management activities to pure military operations.

    Peace-keeping/enforcement operations are examples of such operations, which are conducted by joint

    military forces from different allied countries acting together for the accomplishment of a common

    strategy through partnership, cooperation and interaction beyond national borders. Combined operations,

    e.g. humanitarian relief operations, which may include cooperation with civilian organizations, such as

    local government, police and non-governmental organizations like the Red Cross are also needed.

    These operations benefit from a wide distributed simulation capability, which enables joint acquisition,

    training, execution, examination and evaluation in order to handle complex situations and achieve

    operational effects. Design, planning, performance and evaluation of distributed simulations are, however

    a complex task where multiple dimensions of complexity need to be covered.

    This study encompasses distributed simulations in the domains:

     Concept Development & Experimentation (CD&E) utilizes the joint network of connected real-

    world and simulated systems to investigate and develop requirements on technical systems,

    doctrines and operational processes;

     Simulation Based Acquisition (SBA) for material procurement or capability development can be

    performed in an cost-effective way through the availability of real-world systems and simulators

    in a net-centric environment;

     Joint and Combined Distributed Training at different operational levels, to achieve a functional

    and effective organization using live systems connected to simulator systems and training centres.

RTO-MP-IST-087 5 - 3



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

    Live Virtual Capability


     SBA Training Combined CD&E Constructive Joint

    Figure 1: Distributed simulations and domains [1]

    By using distributed simulations EU participating member states are saving money (e.g., by using

    simulation assets like simulators, intelligent agents in combination with physical resources), time (e.g.,

    units get ready faster for a certain culture/environment/operation), diminishing environmental impact (e.g.,

    use of flight simulators instead of aircrafts to train tactical behaviour), increased safety (e.g., increased

    survivability of both own units and population in crisis area), security (e.g., in a acquisition process

    country A does not want to give insight into a certain simulation model of an aircraft to country B but it

    allows its remote use in a distributed simulation).

    Finally, the modern armed forces, especially peacekeeping units, usually face long lasting, low intensity

    campaigns. In such settings, there are two concurrent forces: the need to keep relatively high alert levels,

    and in the same time having a good troop proficiency training schedule. This dictates the possibility to

    safely conduct simulated training, tactics development and experimentation, while part of the system

    remains operational. The need is to switch between combat readiness by training with the operational

    equipment and combat alert, thus safety and speed of recovery should be considered.

    From a Modelling & Simulation perspective distributed simulations for combined operations are complex,

    since multiple simulations standards usually are used, different operational levels require different

    aggregation levels, i.e. whether the forces are handled as single units or battalions, use of both live, virtual

    and constructive (L-V-C) simulations, handling communication simulation and design, planning,

    execution and evaluation of the distributed simulations.

    2.3 Needs and requirements

    The EU Core Technical Framework (CTF) addresses the participating member states need for:

     Collaborative work


     Reuse of simulation assets

     Use-worthiness focusing on efficiency, effectiveness and satisfaction in aspects of cost, time,

    shared resources and impacts

     Security that takes account of security policies, information zones and levels etc

    5 - 4 RTO-MP-IST-087



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

     Flexibility, openness, scalability and modularity

The CTF is a descriptive text document, not prescriptive. It describes a set of methodologies, processes,

    state of the art paradigms, applicable practices and recommendations in order to support distributed

    simulation for CD&E, SBA and Training.

    2.4 Approach

    The Core Technical Framework (CTF) takes legacy, mandatory and upcoming standards, into account

    when developing and using distributed simulations. These standards span a number of modelling and

    simulation standards like High Level Architecture (HLA), Distributed Interactive Simulation (DIS) and

    Test & Training Enabling Architecture (TENA), software engineering standards like Model Driven

    Architecture (MDA), architecture frameworks (e.g., MODAF), and information security standards.

    Additionally, the CTF is oriented towards a net-centric way of thinking involving service paradigm and

    consistent documentation according to architecture frameworks.

    Figure 2: Net-centric approach to distributed simulations [1]

    Moreover the CTF supports M&S life cycle from scenario generation and experiment planning to

    execution and After Action Review (AAR) using a common development process handling heterogeneous

    simulation architectures in an integrated manner.

    The CTF can serve a wide range of stakeholders with different needs and interests, dependency of work

    processes, methods and technical platforms for distributed simulation.

    2.5 Core Technical Framework structure and contents

    The Core Technical Framework (CTF) introduced is composed of four main components and several


     Smorgasbord which is a collection of applicable standards, methods and services from which the

    user may select the ones appropriate for his needs. It is a union of following:

    RTO-MP-IST-087 5 - 5



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

     Architecture framework views for consistent documentation of distributed simulation

    scenarios, assets and results.

     A description of a number distributed modelling and simulation standards, software

    engineering standards and information security standards

     A service framework for distributed simulations that facilitate use of services from a net-

    centric perspective.

     Reference Model which consists of two subcomponents:

     A collection of most relevant terms used throughout the framework and explanations of them,

    i.e. a taxonomy.

     Mapping between some simulation standards and systems engineering standard.

     Simulation architecture which describes technical approaches and high level design to support

    distributed simulations from planning to evaluation promoting reuse, resource management and


     Methods & recommendations which describe how processes, architecture frameworks like

    MODAF views and design recommendations could facilitate development and reuse.

    Figure 3: The structure of the Core Technical Framework [1] The CTF is described pictorially in Figure 3.

    5 - 6 RTO-MP-IST-087



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards


    3.1 Architecture

    Architecture is how a system is built or will be built, whether it is a house, a software system or a business. If you want to analyse that system to see how to improve it then you would look at the model for that system, as the model gives you a simplified view of the system. In the case of a house this model could for example be building plans and ventilation charts, for a business it could be process flows and organisation charts.

    If you look at a whole enterprise it consists of many different kinds of activities, organisations and systems. A distributed simulation for SBA/training/experiment across different pMS is an example of such an enterprise where different organisations collaborate in achieving a mutual goal. It is often quite complex and therefore it is difficult to get a good understanding of all the details of the enterprise. In other words it is not easy to describe the architecture of the enterprise. The problem is that not only is there a need to understand the enterprise and its architecture, there is also a need to communicate this understanding to other parts of the enterprise. Today this is often tackled by creating documents which describe and regulate the business. The problem with this approach is the difficulty to maintain consistency between the

    different documents and to find the areas which have been left uncovered. In any enterprise but the smallest, this is in the end unavoidable with a document based approach. The way to solve this problem is to use an architecture description in form of models where you can link different areas with each other to maintain consistency.

    The need to describe your architecture is becoming ever more important as the complexity increases due to international cooperation and increasing demands on the enterprise. International cooperation also requires common standards and processes and it changes the focus of standardisation from individual systems to interoperability between systems and organisations. Another reason is the need for handling large amounts of information which requires better structure and management of the information in the enterprise and its systems. The need for flexibility is high to be able to more quickly adapt to changing demands, for example due to increasing environmental awareness. This means that the systems need to be more loosely coupled, as is the case in distributed simulations.

    There is a need for a framework which describes how to use the different models and how they tie together.

    This framework also needs to be based on well known standard so as to be able to use experience from other enterprises and ensure the existence of supporting tools and methods.

    3.2 Architecture framework

    An architecture framework is a standard way to describe architecture. A good framework will support the linkage between different parts of the architecture description so as to keep the description consistent and clearly show which parts are not covered. This means you can identify conflicts so they can be resolved and also enable reuse. It also supports tracing requirements from their identification to how they were or will be implemented in systems. This enables validation that the requirements have been correctly implemented.

    The framework is an enabler, and as such it creates the basis for good architecture descriptions, but it does not automatically mean that all descriptions produced according to the framework are good descriptions. A framework with its service views enables utilization of different conceptual approaches like Service Oriented Architecture (SOA) for distributed simulations.

    A good architecture framework is expected to support the following:

    RTO-MP-IST-087 5 - 7



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

     Consistency is supported by creating one object which is then reused in different parts of the

    architecture, as well as by linkages between different objects so that you can identify what effect

    changes to an object will have to other objects.

     Traceability is supported by allowing you to follow the effect of decisions and requirements

    through the architecture. For example how a requirement for exchange of certain type of

    information leads to the use of a particular data format, e.g. requirement on other HLA Base

    Object Model (BOM).

     Context is supported by giving the surrounding of the sought after object placing it in its context.

    For example by showing the supporting activities to exercise/SBA/experiment management so as

    to identify outer limits on those.

     Flexibility is supported by creating a well described surrounding and thus it is easy to see what is

    affected by change and what still needs to be supported by the new objects. For example when

    implementing new services which will replace old point to point connections it is possible to

    identify which systems need to be able to access the new service that can be shared between the

    different stakeholders.

     Reuse is supported by having a well defined architecture description where it is easier to find

    already described objects and reuse them directly as they are described in the correct way. An

    example of such an object could be a federate description.

     Understanding of other architecture descriptions is supported by having a well defined

    architecture description, which makes it easier to compare other architecture descriptions to it and

    therefore relate to them.

    Currently several architecture framework approaches are available, e.g. MODAF, DODAF, and NAF.

    While some differences exist between these approaches, the differences are of minor importance from the

    viewpoint of this study. Here follows description of views from NAF. The architecture framework consists

    of views. Each of the views presented consist of sub-views.

     All View covers the overarching aspects of an architecture that relates to all views. Most

    importantly it covers the scope of the architecture description and the definition of the concepts

    used in the architecture.

     Capability View supports the process of analysing and optimising the enterprises capabilities. A

    capability is a high level description of the enterprise’s ability to perform actions.

     Operational View is a description of the tasks and activities, operational elements, and

    information exchanges required to accomplish business goals.

     Service-Oriented View focuses on identifying and describing services it also captures mapping

    of services to operational activities. The views support the concept of a Service-Oriented

    Architecture (SOA). An example of a service could be a discovery service that finds available and

    suitable federates.

     Systems View describes systems and system interconnections providing for, or supporting,

    operational activities. It is here you would capture a common technical infrastructure to support

    the operational activities, like which technical artefacts like federates and technical nodes support

    operational activities of training /SBA/experimentation.

     Technical View is a set of rules or standards to ensure that a system satisfies a specified set of

    operational requirements. For example mandatory standards are covered by this view.

     Programme View describes how the capabilities and services relate to the various programmes

    and projects being implemented. This information can be further leveraged to show the impact of

    acquisition decisions on the architecture.

    5 - 8 RTO-MP-IST-087



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

    The views are not standalone but are tied together by a common model (called the Meta model) which is intended to ensure consistency between the different views.


    4.1 Delimitation

    The relations will be established by mapping the products of the standards to each other through MODAF (to be precise, MODAF 1.2) views. The standards participating in the mapping are:

     FEDEP (Federation Development and Execution Process)

     MDA (Model Driven Architecture)

     ISO 15288 System Life Cycle Processes Standard By “products” we mean the specification documents from the standards. In this sense it is “product oriented”. One may think of “process oriented” mapping as well, i.e. relating the phases of the standard

    processes to each other. We consider, however, the product oriented mapping provides more tangible output. On the other hand, the process oriented mapping is to be recommended when, e.g. coordinating activities of different stakeholders involved in a project.

    Further, relations are defined over some of the major standards only by extending previous results made somewhere else. A complete mapping is beyond the scope of the study, because the mapping is

    demonstrated as a proof of concept. Also, a major guideline for this study was to reuse the state-of-the-art findings without reinventing the wheels from the scratch.

    4.2 Related work

    Connecting architecture framework with M&S has been proposed for different purposes by several researchers previously. Roughly these approaches can be classified in two groups:

     Using M&S for architecture framework

     Using architecture framework for M&S. In [2] within the first group, DoDAF has been extended with two new Operational Views to make the DoDAF views compliant with DEVS (Discrete Event System Specification) which is a computer

    executable formal language. Thereby the DoDAF views become executable, i.e. they can be simulated, e.g. to verify the consistency of the view themselves, to assess and examine the feasibility of operational concepts and operational plans described in the views. Similar approach has been presented in [3]. The

    goal of this study was to test the hypothesis that Executable Architecture (architecture framework combined with M&S) provides an effective methodology or framework to address and analyze counter-terrorism and homeland security Capability gaps. Another effort to make the DoDAF executable was presented by [4].

    The work of [5] is an approach within the second group. This work was inspiring to us and at the same time confirmed our initial ideas concerning the need of semantic mappings between and among M&S and S/SE standards. Figure 4 below shows a mapping from DoDAF and FEDEP products to the process of MDA.

    RTO-MP-IST-087 5 - 9



    EU Core Technical Framework Study: Semantic mapping among M&S and Systems

    Engineering Standards

    Figure 4: FEDEP, DoDAF and MDA connection [5] The authors observe that:

    Currently, system creation is habitually setback due to a lack of

    understanding of the problem space. This is exacerbated by the

    introduction of capabilities based development, which demands

    interoperability, modularity, platform independence, distributed

    processing, and composable capabilities. These requirements can be

    realized through an alignment of operational requirements documentation

    (DoDAF) with a simulation testing environment (FEDEP) in a platform

    independent development process (MDA). … Use of an aligned SE

    process will enhance communication between architectural developers and

    software experts.” The mapping identified in their work, see Figure 4, is included in our mapping to be presented later in this


    4.3 The mapping

    The products of the M&S and Systems Engineering standards that are mapped to the MODAF Views are

    listed below. For space reason, these standards and their products are not described in detail in this paper.

    For detail the readers are referred to, e.g. [1].

     Federation Development and Execution Process (FEDEP)

     Federation Objective (FO)

     Federation Conceptual Model (FCM)

     Federation Object Model (FOM)

    5 - 10 RTO-MP-IST-087


Report this document

For any questions or suggestions please email