Conference Presentation at the SESP Workshop (Simulation and EGSE for European Space Applications), September, 2009 Please visit https://sites.google.com/site/simulationarchitecture/ for further information

1. SimArch:
A Layered Architectural Approach to
Reduce the Development Effort of
Distributed Simulation Systems
Daniele Gianni1, Andrea D’Ambrogio2 and Giuseppe Iazeolla2
1European Space Agency
daniele.gianni@esa.int
2Dept.
of Computer Science
Unversity of Rome TorVergata, Italy
{dambro, iazeolla}@info.uniroma2.it
11th International Workshop on Simulation & EGSE Facilities for Space Programmes (SESP 2010), Sept 28– 30, 2010, Noordwijk, NL

2. Outline
• Background:
– Why Distributed Simulation (DS)?
– Why DS for Ground Segment (GS)?
– IEEE 1516 High Level Architecture (HLA) Main Concepts
• Problem Statement
• SimArch
• Example Application
– Scenario, Local Simulation (LS) System, From LS to DS
– Experimental Setting
SESP 2010 2/17

3. Why DS?
• In general, DS brings
– scalability, i.e., it can scale up for the increased
computational requirements
– aggregation and reusability, i.e., it enables the
reuse of simulation systems available in
geographically distributed sites;
– parallelism, i.e., it can exploit intrinsic model
parallelism
SESP 2010 3/17

4. Why DS for GS?
• DS can bring into GS design:
– A more realistic simulation experiment using data
from the space segment
• A GS can consist of several systems that can
inherently be geographically distributed (e.g.
main and back-up facilities)
• To increase simulation realism, data sequences
from the real system (e.g. space segment) can be
injected into the simulation
• In this case, systems composing the GS can be
only simulated in loco
SESP 2010 4/17

5. IEEE HLA Main Concepts
• Federate: a remotely-
accessible simulation
program
• Federation: the overall
distributed simulation,
composed of a set of Federate
Federates Model Logic
• RTI: provides RTI Ambassador
Federate Ambassador
communication and
coordination services to
the Federates that join Runtime Infrastructure (RTI)
into a Federation SESP 2010 5/17

6. Problem Statement
• Developing a DS HLA-based system requires a
considerable extra effort with respect to the
equivalent LS one
• The extra effort can be outlined as:
– Extra effort to acquire HLA knowledge and skills
– Extra coding effort to create HLA federates: about
3.5K extra LOC per federate
– Extra design effort to determine design choices: e.g.
which federates are to develop, which can be reused,
which time advancement modality and simulation
paradigm need to be adopted, etc.
SESP 2010 6/17

7. SimArch Solution
• To introduce a layered architecture that raises DS
developers from all the concerns of the
distributed execution, thus practically eliminating
the extra effort
• This can be shown by a mechanical procedure
that derives a DS simulator from the equivalent
LS one
• Aside-advantage: simulation model portability
over diverse LS and DS infrastructures
implementing SimArch interfaces
SESP 2010 7/17

8. SimArch
Simulation Model Layer Layer 4
Simulation Components
Layer 3
Layer
Discrete Event Simulation
Service Layer Layer 2
Distributed Discrete
Event Simulation Layer Layer 1
Distributed Computing
Infrastructure Layer 0
CORBA-
CORBA WS HLA DIS ALSP HLA
General Purpose Simulation oriented Mixed
SESP 2010 8/17

9. Process Interaction Paradigm
ev2
Key
E2
ev1
Entity
E1 Input Port
ev3 Out Port
E3
Link/Event ev
ev4
SESP 2010 9/17

10. Example Scenario
Space Segment
Input Data
Stream
Antenna 1
Host A Gateway 1 Ground Segment Antenna 2
Data Delivery Input Data
Back-up Facilities Stream
Network
(LAN1)
Gateway 2
Internet
Main Facilities Data Delivery
Network
(LAN2)
Host B
SESP 2010 10/17

11. Local Simulator Overall Architecture
Host A Host B
Gate- Gate-
LAN 1 LAN 2
way 1 way 2
WAN
Key Flow
Control WANACK
Entity
Input port
Out port
Link
SESP 2010 11/17

12. Partitioning
Federate 2
Host A Host B
Gate- Gate-
LAN 1 LAN 2
way 1 way 2
WAN
Federate 1
Key Flow
Control WANACK
Entity
Input port
Out port
Federate 3
Link
Partitioning border
SESP 2010 12/17

13. Federate 1
Federate 2
Host A Host B
Gate- Gate-
LAN 1 LAN 2
way 1 way 2
WAN
Host
A Federate 1
Gate- Key Flow
WANACK
LAN 1
Control
Entity
Input port
Federate 3
way 1 Out port
Link
Partitioning border
Key Flow
Entity Control WANACK
Input port
Out port
Link
Partitioning border
Remote item
SESP 2010 13/17

14. Federate 2
Gate- Gate-
LAN 1 LAN 2
way 1 way 2
WAN
Key
Entity
Input port
Out port
Link Federate 2
Partitioning border Host A Host B
Remote item LAN 1
Gate-
way 1
Gate-
way 2
LAN 2
WAN
Federate 1
Key Flow
Control WANACK
Entity
Input port
Out port
Federate 3
Link
Partitioning border
SESP 2010 14/17

15. Federate 3
Host
Key
B
Entity Gate-
Input port LAN 2
Out port
Link
way 2
Partitioning border
Remote item
Flow
WANACK
Control
Federate 2
Host A Host B
Gate- Gate-
LAN 1 LAN 2
way 1 way 2
WAN
Federate 1
Key Flow
Control WANACK
Entity
Input port
Federate 3
15/17
Out port
Link
Partitioning border
SESP 2010

16. Experimental Setup
• 4 Federates (3 Model
US - Georgia Italy
federates + 1
Federation Manager)
• 3 running in Rome
CoC's
LAN
Georgia Tech WAN
TorVergata
CORBA RTI Server
• 1 running in Atlanta
• HLA implementations:
Federate 2
Client
SimLab
Pitch pRTI and
Key
Federate CORBA-HLA (figure
shows CORBA-HLA)
IIOP protocol
Pitch protocol over TCP and UDP
Server
Federate 0 Executive
FederationManager Federate 1
pRTI 1516
• Validation by
Local
Client Client Client
ORB and CORBA RTI
comparison between
LS and DS output
SESP 2010 16/17

17. Conclusion
• DS can be used in GS design to improve
simulation realism by injecting data from real
systems into the simulated environment
• Developing a DS system requires considerable
extra effort with respect to the local one
• We have shown how a layered approach can
practically eliminate the extra effort
• We have outlined an example and described a
mechanical procedure to derive a DS system
for a LS one
SESP 2010 17/17