UNCLASSIFIED/UNLIMITED
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
choong-ho.yi@combitech.se
Dr Qi Huang
Saab AB
Nettovägen 6
SE-17588 Jarfalla
+46 73 437 4431
qi.huang@saabgroup.com
Dr Robert Suzić
Combitech AB
P.O. Box 6011
SE-17263 Sundbyberg
+46 8 580 86078
robert.suzic@combitech.se
Jan Tegnér
Saab AB
St Olofsgatan 9 B
SE-75321 Uppsala
+46 73 437 7105
jan.tegner@saabgroup.com
ABSTRACT
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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
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.
1 INTRODUCTION
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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
EU Core Technical Framework Study: Semantic mapping among M&S and Systems
Engineering Standards
2 OVERVIEW OF THE CORE TECHNICAL FRAMEWORK
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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
EU Core Technical Framework Study: Semantic mapping among M&S and Systems
Engineering Standards
Live Virtual Capability
Domains
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
• Interoperability
• 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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
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
subcomponents:
• 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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
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
automation.
• 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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
EU Core Technical Framework Study: Semantic mapping among M&S and Systems
Engineering Standards
3 ARCHITECTURE AND ARCHITECTURE FRAMEWORK
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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
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 SEMANTIC MAPPINGS AMONG THE M&S AND SE STANDARDS
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
UNCLASSIFIED/UNLIMITED
UNCLASSIFIED/UNLIMITED
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
section.
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
UNCLASSIFIED/UNLIMITED