EN 16603-40-07:2020

SLOVENSKI STANDARD
01-september-2020
Vesoljska tehnika - Ploščadi za simulacijsko modeliranje
Space engineering - Simulation modelling platform
Raumfahrttechnik - Software-Modellierungs-Platform
Ingénierie Spatiale - Plateforme informatique de modèles de simulation
Ta slovenski standard je istoveten z: EN 16603-40-07:2020
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 16603-40-07
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2020
ICS 49.140
English version
Space engineering - Simulation modelling platform
Ingénierie spatiale - Plateforme de modélisation pour Raumfahrttechnik - Teil 40-07: Modelliersoftware-
simulation Platform
This European Standard was approved by CEN on 17 May 2020.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2020 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16603-40-07:2020 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European foreword . 7
Introduction . 8
1 Scope . 9
2 Normative references . 10
3 Terms, definitions and abbreviated terms . 11
3.1 Terms from other standards . 11
3.2 Terms specific to the present standard . 11
3.3 Abbreviated terms. 16
3.4 Nomenclature . 16
4 Principles . 17
4.1 Objectives . 17
4.2 Common Concepts and common types . 17
4.3 Architecture . 18
4.4 Time handling principle . 19
4.5 Simulation lifecycle . 20
4.6 Simulation method . 21
4.6.1 Discrete-event simulation (DES) . 21
4.6.2 Parallelization and distribution . 22
4.6.3 Inter component communication . 22
4.7 Models, Services and Components . 23
4.7.1 Objects . 23
4.7.2 Components. 25
4.7.3 Factories . 27
4.7.4 Models and Services . 27
4.8 Publication and Persistence . 28
4.9 Dynamic invocation . 29
4.10 Components meta data . 31
4.10.1 Catalogue . 31
4.10.2 Package . 31
4.10.3 Configuration . 32
4.11 Model exchanges considerations . 32
4.11.1 Overview . 32
4.11.2 SMP Bundle . 32
5 Interface requirements . 33
5.1 Common . 33
5.1.1 Primitive Types specification . 33
5.1.2 Time Kinds . 35
5.1.3 Path string . 36
5.1.4 Universally Unique Identifiers (UUID) . 37
5.1.5 Exception specification . 37
5.2 Components and Objects interfaces . 37
5.2.1 Object Specification (IObject) . 37
5.2.2 Collection Specification (ICollection) . 38
5.2.3 Component Specification . 39
5.2.4 Aggregation. 42
5.2.5 Composition . 45
5.2.6 Events . 47
5.2.7 Entry points . 50
5.2.8 Dynamic Invocation . 50
5.2.9 Persistence (IPersist) . 54
5.2.10 Failures . 55
5.2.11 Field interfaces . 56
5.2.12 Requirements on utilization of Simulation Environments interfaces by
components . 62
5.3 Simulation Environment interfaces . 63
5.3.1 Logger (ILogger interface) . 63
5.3.2 Time Keeper (ITimeKeeper) . 65
5.3.3 Scheduler (IScheduler) . 67
5.3.4 Event Manager (IEventManager) . 75
5.3.5 Resolver (IResolver) . 79
5.3.6 Link Registry (ILinkRegistry) . 80
5.3.7 Simulator (ISimulator) . 82
5.3.8 Persistence . 94
5.3.9 Publication . 95
5.3.10 Type Registry . 102
5.3.11 Component Factory (IFactory) . 107
5.4 Meta data . 108
5.4.1 Catalogue . 108
5.4.2 Package . 112
5.4.3 Configuration data . 112
6 Implementation mapping . 113
6.1 Catalogue to C++ . 113
6.1.1 Mapping templates . 113
6.1.2 Namespaces and files . 116
6.1.3 Element and Type Visibility Kind . 116
6.1.4 Mapping of elements . 117
6.1.5 Basic Value Types . 126
6.1.6 Compound Value Types . 128
6.1.7 Reference Types . 130
6.2 Package to library . 133
6.2.1 Mapping templates . 133
6.2.2 Common to Unix and Windows . 133
6.2.3 Unix (Shared object) . 134
6.2.4 Addendum for Windows Dynamic Link Library (DLL) . 135
6.2.5 SMP Bundle . 136
Annex A (normative) Catalogue file - DRD . 137
A.1 Catalogue DRD . 137
A.1.1 Requirement identification and source document . 137
A.1.2 Purpose and objective . 137
A.2 Expected response . 137
A.2.1 Scope and content . 137
A.2.2 Special remarks . 137
Annex B (normative) Package file - DRD . 138
B.1 Package DRD . 138
B.1.1 Requirement identification and source document . 138
B.1.2 Purpose and objective . 138
B.2 Expected response . 138
B.2.1 Scope and content . 138
B.2.2 Special remarks . 138
Annex C (normative) Configuration file - DRD . 139
C.1 Configuration DRD . 139
C.1.1 Requirement identification and source document . 139
C.1.2 Purpose and objective . 139
C.2 Expected response . 139
C.2.1 Scope and content . 139
C.2.2 Special remarks . 139
Annex D (normative) Manifest file - DRD . 140
D.1 Configuration DRD . 140
D.1.1 Requirement identification and source document . 140
D.1.2 Purpose and objective . 140
D.2 Expected response . 140
D.2.1 Scope and content . 140
D.2.2 Special remarks . 142
Bibliography . 143

Figures
Figure 4-1: Common Concepts and Type System . 18
Figure 4-2: SMP Architecture . 18
Figure 4-3: SMP State machine . 20
Figure 4-4: Object mechanisms . 24
Figure 4-5: Overview of components hierarchy . 25
Figure 4-6: Component Mechanisms . 26
Figure 4-7: Component State machine . 26
Figure 4-8: Sequence of calls for dynamic invocation . 30

Tables
Table 4-1: Overview of simulation states . 21
Table 4-2: ViewKind values . 28
Table 5-1: Primitive Types . 33
Table 5-2: Component states . 39
Table 5-3: Semantically equivalent types for connections . 61
Table 5-4: Default Log Message Kinds . 64
Table 5-5: Condition for emitting predefined global events . 78
Table 6-1: C++ declaration templates . 114
Table 6-2: C++ definition templates . 116
Table 6-3: C++ mapping for the Visibility kind attribute . 116
Table 6-4: C++ mapping of Association depending on ByPointer attribute. 119
Table 6-5: C++ mapping for the Direction kind attribute . 120
Table 6-6: C++ mapping for Property depending on ByPointer attribute . 121
Table 6-7: C++ mapping for the Operator attribute kinds . 124
Table 6-8: C++ declaration templates for packages . 133
Table D-1 : SMP Manifest Key . 141

European foreword
This document (EN 16603-40-07:2020) has been prepared by Technical
Committee CEN-CENELEC/TC 5 “Space”, the secretariat of which is held by
DIN.
This standard (EN 16603-40-07:2020) originates from ECSS-E-ST-40-07C.
This European Standard shall be given the status of a national standard, either
by publication of an identical text or by endorsement, at the latest by December
2020, and conflicting national standards shall be withdrawn at the latest by
December 2020.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. CEN [and/or CENELEC] shall not be held
responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request given to
CEN by the European Commission and the European Free Trade Association.
This document has been developed to cover specifically space systems and has
therefore precedence over any EN covering the same scope but with a wider
domain of applicability (e.g. : aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards
organizations of the following countries are bound to implement this European
Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
Space programmes have developed simulation software for a number of years,
which are used for a variety of applications including analysis, engineering
operations preparation and training. Typically, different departments perform
developments of these simulators, running on several different platforms and
using different computer languages. A variety of subcontractors are involved in
these projects and as a result a wide range of simulation software are often
developed. This standard addresses the issues related to portability and reuse
of simulation models. It is based on the work performed by ESA in the
development of the Simulator Model Portability Standards SMP1 and SMP2
starting from the mid-end of the nineties.
This standard integrates the ECSS-E-ST-40 with additional requirements which
are specific to the development of simulation software. The formulation of this
standard takes into account:
• The existing ISO 9000 family of documents, and
• The Simulation Model Portability specification version 1.2.
The intended readership of this standard is the simulator software customer
and supplier.
Scope
ECSS-E-ST-40-07 is a standard based on ECSS-E-ST-40 for the engineering of
simulation software.
ECSS-E-ST-40-07 complements ECSS-E-ST-40 in being more specific to
simulation software. Simulation software include both Simulation
environments and simulation models. The standard enables the effective reuse
of simulation models within and between space projects and their stakeholders.
In particular, the standard supports model reuse across different simulation
environments and exchange between different organizations and missions.
This standard can be used as an additional standard to ECSS-E-ST-40 providing
the additional requirements which are specific to simulation software.
This standard may be tailored for the specific characteristic and constrains of a
space project in conformance with ECSS-S-ST-00.

Applicability
This standard lays down requirements for simulation software including both
Simulation environments and simulation models. The requirements cover
simulation models’ interfaces and simulation environment interfaces for the
purpose of model re-use and exchange to allow simulation models to be run in
any conformant simulation environment.
A consequence of being compliant to this standard for a model is the possibility
of being reused in several simulation facilities or even in several projects.
However, adherence to this standard does not imply or guarantees model
reusability, it is only a precondition. Other characteristics of the model, to be
defined outside this standard, such as its functional interfaces and behaviour,
its configuration data as well as quality, suitability and performance, etc. are
also heavily affecting the potential for a model to be reused. In addition,
agreements need to be reached on simulation environments compatibility,
model validation status as well as legal issues and export control restrictions.
Therefore, this standard enables but does not mandate, impose nor guarantee
successful model re-use and exchange.
Model reuse in this standard is meant both at source-code and binary level,
with the latter restricted to a fixed platform.
Normative references
The following normative documents contain provisions which, through
reference in this text, constitute provisions of this ECSS Standard. For dated
references, subsequent amendments to, or revision of any of these publications
do not apply. However, parties to agreements based on this ECSS Standard are
encouraged to investigate the possibility of applying the more recent editions of
the normative documents indicated below. For undated references, the latest
edition of the publication referred to applies.

EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS system - Glossary of terms
EN 16603-40 ECSS-E-ST-40 Space engineering - Software general requirements
[SMP_FILES] ECSS_SMP_Issue1(2March2020).zip – SMP C++
Header files, SMP XML schemas and SMP Catalogue.
(Available from ECSS website)
https://www.w3.org/T XML schema specification
R/xmlschema11-2/
http://www.opengrou The UUID specification from Open Group.
p.org
https://www.osgi.org/ OSGi Specifications
developer/specificatio
ns/
Terms, definitions and abbreviated terms
3.1 Terms from other standards
a. For the purpose of this Standard, the terms and definitions from ECSS-S-
ST-00-01 and ECSS-E-ST-40 apply.
b. For the purpose of this Standard, the terms and definitions from
ECSS-E-ST-70 apply, in particular the following term:
1. mission
3.2 Terms specific to the present standard
In the following list of terms, underlined words are further defined in the same
list.
3.2.1 aggregate
relationship between two components implemented by storing their references
NOTE Each component in such a relationship keeps its
own lifecycle and it does not dependent on that
of other components.
3.2.2 association
relationship between two instances of any data-type, where each instance has
its own lifecycle and there is no owner
3.2.3 breakpoint
unambiguous state of a simulation
3.2.4 component
building block of a simulation that can be instantiated and that has a well-
defined contract to its environment
3.2.5 composite
component implementing composition
3.2.6 composition
hierarchical relationship where child component is destroyed if the parent
component is destroyed
3.2.7 configuration
specification of values for fields of components
3.2.8 constructor
specific operation of a component, bearing the same name of the component,
whose purpose is to allocate and build an instance of said component
3.2.9 consumer
component that can receive data in one of its input fields from an output field
of another component
3.2.10 container
typed collection of child components
3.2.11 contract
set of interfaces, operations, fields, entry points, event sinks, event sources and
all the associated constraints, used to interact with a component
3.2.12 data transfer
copy of value from an output field to an input field
3.2.13 entry point
operation without parameters that does not return a value, which can be added
to the scheduler or event manager service
3.2.14 epoch time
absolute time of the simulation
3.2.15 event
see “simulation event”
3.2.16 event manager
component that implements the IEventManager interface
NOTE The IEventManager interface is specified in
clause 5.3.4.
3.2.17 event sink
receiver of specific notifications, owned by a component and subscribed via a
subscription mechanism
3.2.18 event source
emitter of specific notifications, owned by a component and offering a
subscription mechanism
3.2.19 exception
non-recoverable error that can occur when calling into an operation or property
3.2.20 field
feature characterised by a value type and holding a value
3.2.21 input field
field explicitly marked for receiving values as a result of a data transfer
3.2.22 interface
named set of properties and operations
3.2.23 logger
component that implements the ILogger interface
NOTE The ILogger interface is specified in clause
5.3.1.
3.2.24 mission time
relative time measuring elapsed time from a mission specific point in time
3.2.25 model
component that implements the IModel interface
NOTE The IModel interface is specified in clause
5.2.3.2.
3.2.26 model implementation
executable code implementing a model
3.2.27 model instance
occurrence of a model implementation
3.2.28 output field
field explicitly marked for being the source of a value in a data transfer
3.2.29 operation
declaration of a behavioural feature of a component or an interface with the
option to define parameters, return value and raised exceptions
3.2.30 package
collection of types, where each one is either a value type or a component
3.2.31 platform
set of subsystems/technologies that provide a coherent set of functionality
through APIs and specified usage patterns
3.2.32 primitive type
type that can no longer be de-composed and that is pre-defined by the standard
NOTE The available primitive types are listed in Table
5-1: Primitive Types.
3.2.33 property
typed feature of a class, an interface or a component that can be accessed by two
operations, the setter and the getter, not necessarily both present
3.2.34 provider
component that can send data of one of its output fields to an input field of
another component
3.2.35 reference
pointer to a component
NOTE When dealing with the C++ mapping, the term
reference has a meaning specific to that
language, whereas in the rest of this standard it
means point to a component (but it cannot for
instance be a pointer to a class).
3.2.36 resolver
component that implements the IResolver interface
NOTE The IResolver interface is specified in clause
5.3.5.
3.2.37 schedule
planned time ordered execution of entry points
3.2.38 scheduler
component that implements the IScheduler interface
NOTE The IScheduler interface is specified in clause
5.3.3.
3.2.39 service
component that implements the IService interface
NOTE The IService interface is specified in clause
5.2.3.3.
3.2.40 simple field
field of a type that maps directly to a primitive type
3.2.41 simulation environment
platform implementing the standard E-40-07 services (event manager, link
registry, logger, resolver, scheduler and time keeper) and the ISimulator
interface
3.2.42 simulation event
call to an entry point by either scheduler or event manager
NOTE The term “event” is synonymous.
3.2.43 simulation time
relative time since start of simulation
3.2.44 simulator
collection of services and hierarchy of model instances together with a
simulation environment
3.2.45 simulation
single execution of a simulator
3.2.46 simulation service
service instance resolvable by name in the global scope of the simulation
environment
3.2.47 source
component that owns one or more references, one or more event links, or one or
more output fields
NOTE The term “source component” is synonymous.
3.2.48 source component
See source
3.2.49 target
component that implements one or more interfaces, provides one or more event
sinks, or one or more input fields
NOTE The term “target component” is synonymous.
3.2.50 target component
see “target”
3.2.51 time keeper
component that implements the ITimeKeeper interface
NOTE The ITimeKeeper interface is specified in clause
5.3.2.
3.2.52 value
state of a value type
3.2.53 value type
set of values which a variable can possess
3.2.54 Zulu time
the computer clock time, also called wall clock time
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms and symbols from
ECSS-S-ST-00-01 and the following apply:

Abbreviation Meaning
Discrete-Event Simulation
DES
Simulation Model Definition Language
SMDL
Simulation Modelling Platform
SMP
Uniform Resource Identifier
URI
Uniform Resource Locator
URL
Universally Unique IDentifier
UUID
3.4 Nomenclature
The following nomenclature applies throughout this document:
a. The word “shall” is used in this Standard to express requirements. All
the requirements are expressed with the word “shall”.
b. The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring,
recommendations in this document are either
converted into requirements or tailored out.
c. The words “may” and “need not” are used in this Standard to express
positive and negative permissions, respectively. All the positive
permissions are expressed with the word “may”. All the negative
permissions are expressed with the words “need not”.
d. The word “can” is used in this Standard to express capabilities or
possibilities, and therefore, if not accompanied by one of the previous
words, it implies descriptive text.
NOTE In ECSS “may” and “can” have completely
different meanings: “may” is normative
(permission), and “can” is descriptive.
e. The present and past tenses are used in this Standard to express
statements of fact, and therefore they imply descriptive text.
Principles
4.1 Objectives
The main objective of this standard is to enable the effective reuse of simulation
models and applications within and between space projects and their
stakeholders. In particular, the standard supports model reuse across different
simulation environments and exchange between different organizations and
missions.
The portability of models between different simulation environments is
supported by defining a standard interface between the simulation
environment and the models. Models can therefore be plugged into a different
simulation environment without requiring any modification to the model
source code.
The portability of models between different operating systems and hardware
takes into consideration dependencies such as avoiding calls to operating
specific APIs or use of hardware specific features. The guidelines to the model
developer, on how to avoid developing models with such dependencies, is
outside the scope of this standard.
4.2 Common Concepts and common types
The main purpose of SMP is to promote platform independence,
interoperability and reuse of simulation models. This is done by defining;
• Common Concepts: All SMP models fulfil common high-level concepts
addressing fundamental modelling issues. This enables the development
of models on an abstract level, which is essential for independence from
simulation environments and reuse of models;
• Common Type System: All SMP models are built upon a common type
system. This enables different models to have a common understanding
of the syntax and semantics of basic types, which is essential for
interoperability between different models.
In other words, models are using common concepts and a common type system
to become interoperable. Thus, models ‘live’ in between these two common
layers as shown in Figure 4-1.
SMP: Common Concepts
Model A
Model B
SMP: Common Type System
Figure 4-1: Common Concepts and Type System
4.3 Architecture
The SMP architecture covers two types of components;
• Simulation Models provide application specific behaviour;
• Simulation Environments provide Simulation Services.
This architecture is depicted in Figure 4-2.
Simulation
…
Model 1 Model 2 Model N
Simulation Environment
Simulation Services
Logger Scheduler Time Keeper
Event Manager Link Registry Resolver

Figure 4-2: SMP Architecture
An SMP compliant simulation environment provides the following six
simulation services:
• Logger: Allows logging messages (see clause 5.3.1);
• Time Keeper: Provides the four different SMP time kinds (see clause 4.4
and 5.3.2);
• Scheduler: Allows calls of entry points based on timed or cyclic events
(see clause 5.3.3);
• Event Manager: Provides mechanisms for global asynchronous events
(see clause 5.3.4);
• Resolver: Provides the ability to get a reference to any model within a
simulation (see clause 5.3.5);
• Link Registry: Maintains a list of the links between model instances (see
clause 5.3.6).
In addition, it supports other concepts laid out in this standard via some
dedicated interfaces:
• Simulation state machine controlling interface (see clause 4.5 and 5.3.7);
• Interfaces allowing Self-persistence as described in clause 4.8 (see also
IStorageReader in clause 5.3.8.1 and IStorageWriter in clause 5.3.8.2);
• Publication: A set of interfaces allowing models to publish their state to
the simulation environment (see clause 5.3.9);
• Type registry: A registry allowing components to register types that later
can be used for publication (see clause 5.3.10);
• Component Factory: Ability to create components via a factory (see
clause 5.3.11).
The arrows in Figure 4-2 indicate interaction between components. In SMP,
communication is performed via interfaces. Two different types of interfaces
can be identified in this architecture:
• Interfaces between components and the Simulation Environment, and
• Inter-component communication interfaces.
4.4 Time handling principle
SMP defines four different time scales, referred to as time kinds (see clause 5.1.2
for exact specification):
• Simulation Time: Relative time since start of simulation, starting at 0
when the simulation is setup.
• Zulu Time: Zulu Time is the computer clock time, also called wall clock
time.
• Epoch Time: The absolute time of the simulation.
• Mission Time: Mission time is a relative time, i.e. it measures elapsed
time from a mission specific point in time.
SMP defines both Epoch and Mission Time as a fixed offset from Simulation
Time. The Offset is set via calls to the SMP time keeper service and the two time
kinds progress linearly with Simulation time. SMP does not define how
Simulation time progress with respect to Zulu time. Typical examples of such a
correlation is:
• Real-Time: The simulation time progresses with real-time, where
real-time is typically defined by the computer clock.
• Accelerated: The simulation time progresses relative to real-time using a
constant acceleration factor. This factor can be larger than 1.0, which
relates to ʺfaster than real-timeʺ, smaller than 1.0, which means ʺslower
than real-timeʺ, or 1.0, which coincides with real-time.
• Free Running: The simulation time progresses as fast as possible, and is
not related to real-time. Typically, the speed is coordinated with the
timed events of the scheduler, which underlines the close relationship
between these two services (Time Keeper and Scheduler).
SMP does not mandate which of these modes a simulation environment
supports.
4.5 Simulation lifecycle
Any SMP simulation goes via a lifecycle as defined in Figure 4-3. The
simulation environment is responsible to ensure that this state diagram is
followed. It is controlled via the ISimulator interface (see clause 5.3.7).

Figure 4-3: SMP State machine
Each state in Figure 4-3 has its own purpose and behaviour as explained in
Table 4-1. Notice that some state transitions are automatically performed by the
Simulation Environment as indicated in Figure 4-3, while others need explicit
calls to the ISimulator interface.
Table 4-1: Overview of simulation states
Name Description
Building In Building state, the model hierarchy is created. In this state, Publish() and
Configure() can be called any time to call the corresponding Publish() and Configure()
operations of each component.
Connecting In Connecting state, the simulation environment traverses the model hierarchy and
calls the Connect() method of each component.
Initialising In Initialising state, the simulation environment executes all initialization entry points
in the order they have been added to the simulator using the ISimulator
AddInitEntryPoint() method (see 5.3.7).
Standby The simulation environment does not progress simulation time. Only entry points
registered relative to Zulu time are executed.
Executing The simulation environment does progress simulation time. Entry points registered
with any of the available time kinds are executed.
Storing In Storing state, the simulation environment first stores the values of all fields
published with the State attribute to storage (typically a file). Afterwards, the Store()
method of all components (Models and Services) implementing the optional IPersist
interface is called, to allow custom storing of additional information.
Restoring In Restoring state, the simulation environment first restores the values of all fields
published with the State attribute from storage. Afterwards, the Restore() method of
all components implementing the optional IPersist interface is called, to allow custom
restoring of additional information.
Reconnecting In Reconnecting state, the simulation environment makes sure that models that have
been added to the simulator after leaving the Building state are properly published,
configured and connected.
Exiting In Exiting state, the simulation environment is properly terminating a running
simulation.
Aborting In this state, the simulation environment attempts a simulation shut-down, whereby
the simulation can stop executing as the users expect, without guaranties for actual
release of resources.
4.6 Simulation method
4.6.1 Discrete-event simulation (DES)
SMP is built on discrete-event simulation (DES) theory where the behaviour of
a system is modelled as a discrete sequence of events in time. Each event that
marks a change in the state of the systems occurs at a particular instant in time.
The simulation can jump in time from one event to the next since no change in
the system occurs between consecutive events.
The main elements in SMP that support this approach are:
• The simulation components schedule EntryPoints (see clause 5.2.7.1) on
the SMP scheduler (see clause 5.3.3) for execution of events.
• The Simulation state is captured in the persisted data.
4.6.2 Parallelization and distribution
SMP assumes a single scheduler executing its events in sequence. All
components are loaded inside the same address space allowing direct
communication between them. The standard however does not prevent
parallelization or distribution to be built into layers on top of the standard.
4.6.3 Inter component communication
4.6.3.1 Overview
SMP supports the following main method of communication between
components:
• Direct interface based communication
• Data flow based communication
• Event based communication
4.6.3.2 Interface based communication
An interface-based design adds interfaces as the standard mechanisms for inter-
model communication. This isolates the definition of an interface (the
“contract”) from its implementation. In an interface-based design, a model
provides any number of interfaces. An Interface defines a contract between
models. Every model implementing the interface provides all the functionality
of the interface, so that every model, which consumes this interface can rely on
the interface implementation. As interfaces are a mechanism to de-couple
models, they do not give access to fields, but only to operations. With special
operations (i.e. use of Properties. See definition 3.2.33 ʺpropertyʺ) that read
...