American Institute of Aeronautics and Astronautics

1

Model Integration with the Common Simulation Framework SIRIUS

Ulrich Sennes1 and Roland Schabenberger2 Cassidian – an EADS Company, Rechliner Str. 85077 Manching, Germany

This paper presents a new approach for model integration with the common simulation framework SIRIUS. SIRIUS is a software environment enabling multiple simulation models to execute and to interact using a variety of services. It combines a driving and managing software architecture and a collection of tools to integrate and run simulation models coming from different technical domains together in a full or partly virtual computing environment. Simulation models, as well as the framework, may be distributed across different host computers.

I. Introduction IMULATION has changed significantly over the last decade. Nowadays, simulation accompanies a system during its whole life cycle:

• Design phase: Simulation supports design studies. • Development phase: Software in the loop simulation (SILS) is used to develop and verify the

functionality of a system. • Integration & Test phase: Hardware in the loop simulation (HILS) is used to test the real system. • Training simulation is used by pilots before and after entry into service of the A/C.

Another cause for the change of simulation is founded in the increasing complexity of aerial systems.

Representing the system, simulation becomes also more complex in terms of • number of simulation models • involved stakeholders • model complexity itself.

This leads indispensable to establishing a standardized simulation. Therefore, the simulation department of

Cassidian Air Systems developed a common simulation framework called SIRIUS (SImulation Realtime Infrastructure System).

The purpose of this paper is to present this simulation framework with its main functionalities and characteristics and to show how a simulation model integrator benefits from using SIRIUS.

II. Simulation Framework SIRIUS

A. Use-cases SIRIUS is a simulation environment allowing the user to perform several tasks. Fig. 1 shows the defined use-

cases for SIRIUS. SIRIUS • emulates ARINC653/APEX1 operating system with a development environment for Prototyping

real A/C software. • supports Modeling according to the Airbus Procedure AP26332, a standard for development,

integration and validation of simulation models.

1 Dr. Ulrich Sennes, Systems Engineer, MEC52, Cassidian. AIAA Member. 2 Roland Schabenberger, Head of MEC53, Cassidian.

S

AIAA Modeling and Simulation Technologies Conference08 - 11 August 2011, Portland, Oregon

AIAA 2011-6587

Copyright ' 2011 by Cassidian, Germany. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.

American Institute of Aeronautics and Astronautics

2

• supports Development of simulation models by various tools like an automated build system, debugging capabilities, etc.

• allows Re-hosting of A/C software on Linux and Windows based hosts. • simplifies the Integration of simulation models by providing ICD tools and Graphical User

Interfaces. • supports Testing by providing a scripting/automation interface (e.g. for stimulation or simulation

control) and a lossless data recording/replaying system.

B. Architecture The architecture of the SIRIUS framework can be described by four layers, Fig. 2. The loweset layer is the Operating System Abstraction Layer (OSAL). It is optimized to the operating system of

the hardware and handles file I/O, theading, memory, etc. With this layer SIRIUS gives the best performance the platform provides. All other framework components are based on the OSAL and thus platform independent and can be easily ported to new platforms. Currently, SIRIUS is available for the following platforms, mostly targetting POSIX or Windows system capabilities:

• Intel Linux 32Bit, gcc version 4.2.1 (or newer) • Intel Linux 64Bit, gcc version 4.2.1 (or newer) • PowerPC Linux 64Bit, gcc version 4.2.1 (or newer) • iHawk RedHawk 64Bit, gcc version 4.2.1(or newer) • Microsoft Windows XP/Vista/7 32bit, Visual C++ 2005 Professional • Microsoft Windows XP/Vista/7 32bit, Visual C++ 2008 Professional • Microsoft Windows XP/Vista/7 32bit, MinGW/gcc version 4.5 (or newer)

PrototypingLightweigt Development Environment

ARINC653/APEX OS

ModelingAIRBUS AP2633Modeling Standard

Re-HostingARINC653/APEX OS

Linux and Windows, Intel and PPC

TestingScripting Interface

Data Recording Service

IntegrationICD based Integration Tools

Graphical Workbench

DevelopmentC/C++ Programming LibrariesPluggable Service Extensions

SIRIUSFramework

PrototypingLightweigt Development Environment

ARINC653/APEX OS

ModelingAIRBUS AP2633Modeling Standard

Re-HostingARINC653/APEX OS

Linux and Windows, Intel and PPC

TestingScripting Interface

Data Recording Service

IntegrationICD based Integration Tools

Graphical Workbench

DevelopmentC/C++ Programming LibrariesPluggable Service Extensions

SIRIUSFramework

Figure 1. SIRIUS – Overview use cases

American Institute of Aeronautics and Astronautics

3

SIRIUS is a very modular system built dynamically from pluggable software components that implement

services simulation models, interface modules, gateways, integrations to other systems, etc. All parts of the framework are homogeneously managed by a central framework kernel. The framework kernel

simply takes care about the list of active software components, their lifecycle, the public interfaces they provide and the general state of the simulation process. During runtime, the kernel allows each element of the framework to interact with all other active elements – and architecture and object model behind kernel takes care about references, dependencies, memory, etc.

In order to maintain a consistent system state, the framework kernel provides a scheme of predefined states, the

global process run level (very similar to Unix-style runlevels). All framework elements are bound to certain run levels, which in the end describe a set of available framework features – and the framework kernel manages the resulting execution sequence and the element lifecycle (see Fig. 3).

Both the OSAL and framework kernel architecture are offered through a public framework API. That way

SIRIUS not only provides the simulation operating system but also introduces a component model and a programming model to support simulation software development.

Operating System Abstraction Layer

File I/OFile I/O EnvironmentEnvironment MemoryMemory CommonsCommons TestbenchTestbench

High-Res TimingHigh-Res Timing ThreadingThreading SynchronizationSynchronization Dynamic LoadingDynamic Loading Object ModelObject Model

Framework Kernel

Plugin RepositoryPlugin Repository Class RepositoryClass Repository Object RepositoryObject Repository Run LevelsRun LevelsManifestManifest

Framework Services

ExecutiveExecutive CommunicationCommunication AutomationAutomation Harddisk RecordingHarddisk Recording Embedded WebEmbedded Web

Model ControlModel Control ConfigurationConfiguration Console & LoggingConsole & Logging ConfigurationConfigurationScripting & RPCScripting & RPC

Application Interfaces Tools and Applications Gateways

Runtime InterfaceRuntime Interface Class LibraryClass Library BootloaderStartup and Deployment

BootloaderStartup and Deployment

Code GenerationAdapter and Decoding

Code GenerationAdapter and Decoding

ICDConversion and Validation

ICDConversion and Validation

WorkbenchTesting and Monitoring

WorkbenchTesting and Monitoring

AP2633Model InterfaceAP2633

Model InterfaceARINC653/APEX

Model InterfaceARINC653/APEX

Model Interface

Java SDKLanguage Bindings

Java SDKLanguage Bindings

Simulation ControlSimulation Control

AP2633Model InterfaceAP2633

Model InterfaceHLA

External InterfaceHLA

External Interface

Figure 2. Architecture of SIRIUS

SYSTEMSYSTEM

USERUSER

RUNNINGRUNNING

KERNELKERNEL

SHUTDOWNSHUTDOWN

Figure 3. SIRIUS run level

American Institute of Aeronautics and Astronautics

4

The framework services comprise the third layer. Services are the actual workers within the framework and by

providing simulation related features, they make SIRIUS a simulation framework out of a generic and very abstract software architecture. SIRIUS out of the box provides services that for example handle data exchange between models, communication between different SIRIUS instances and different hosts, Process scheduling, model control, as well as auxiliary services such as logging and data recording

The fourth layer contains application interfaces e.g. to simulation models. Tools like a graphical frontend to the

user or for ICD handling and gateways to other (non-SIRIUS) applications are located in this top layer. In general, the application layer provides simplified and domain-specific interfaces for high-level software integration. Although providing public interfaces even to the core elements of the framework, the application layer allows to keep simple tasks simple.

Summarized, the overall architecture and implementation of the SIRIUS framework offers

• high-performance real-time execution of simulation models/components • scalable service oriented software infrastructure to access and reuse existing software components • capability for integrating custom communication interfaces and I/O devices

C. General System Overview The simulation framework SIRIUS enables multiple simulation models to execute and to interact using a variety

of services. It combines a driving and managing software architecture and a collection of tools to integrate and run simulation models coming from different technical domains together in a full or partly virtual computing environment. Simulation models, as well as the framework, may be distributed across different host computers. Fig. 4 shows the a general system overview.

Figure 4. General System Overview

American Institute of Aeronautics and Astronautics

5

D. User Interfaces The simulation user can interact with the simulation model by several means:

• Workbench • Web interface • Console

1. Workbench

SIRIUS provides a worbench as a graphical frontend (Fig. 5) for the simulation user. It allows monitoring the model signals online as well as the data recording and replaying for further analysis. The workbench consists of different views.

Signals are listed in a tree hierarchy, sorted by hosts, models, and ports in the navigation view Properties of a selected signal as defined in the ICD are depicted in the property view. Actual values of selected signals can be seen in the signal data view. The plotter view plots time histories of signals. It is possible to invoke multiple scopes with multiple signlas in

each scope. The actual setting of the plotter and signal data view is displayed in the configuration view. The recording and replaying functionality of SIRIUS can be triggered by the workbench. It is possible to set

marker during recording and to jump to these markers during replay mode. This is handled in the recorder/player view.

All views can be detached for displaying them on separate screens. Additionally it is possible to run further workbench applicationson different hosts, and all instances can access the simulation data concurrently and interactively.

Figure 5. Workbench application

American Institute of Aeronautics and Astronautics

6

2. Web Interface The SIRIUS Web Interface provides generic access to each running SIRIUS process.. Six different modes are

realized as depicted in Fig. 6: • Control view allows general framework control and simulation mode control, Fig. 7. • Signal view displays communication signal values, and offers access to network communication

based on ports and signals. Fig. 8. • Debug view displays communication signal and mode control for each model and allows direct

access to the physical memory of a model based on symbolic names (variable names). • Profiler view displays performance data of a simulation model, Fig. 9. • Attribute view displays internal framework settings and state information. • Recording view controls the data recorder.

Figure 6. Web Interface

American Institute of Aeronautics and Astronautics

7

Figure 8. Signal view

Figure 7. Control view

American Institute of Aeronautics and Astronautics

8

3. Console The console service offers the same functionality as the web interface – but access is done by console

commands. So it is possible to monitor and control the simulation and all core services via scripting.

III. Integration with examples With the raising role of simulation within the overall system development life-cycle, the software integration

becomes an essential part. The common concept of integration is based on interface control documents (ICD) which describe, in a standardized way, how models communicate to each other. SIRIUS simplifies the whole process around ICDs by automating the critical steps of manual integration. It provides a tool chain for ICD handling and adapter code generation. SIRIUS handles signal data exchange and supports the model life-cycle defined in the Airbus Procedure AP2633.

A. Simulation model To integrate a simulation model

• the source code of the model has to be available and • the inputs and outputs have to be defined.

The source code is compiled to a library which will be executed in SIRIUS. Thereby it is indifferent, if the

model is programmed by hand or if it is automatically generated by tools like Scade or Realtime Workshop (Matlab/Simulink). The simulation concept provides a modular segmentation of the simulation by splitting the simulation system in many entities. This leads to a re-use of simulation models in other projects. Furthermore, existing modules do not need to be modified to be integrated.

Figure 9. Profiler view

American Institute of Aeronautics and Astronautics

9

B. ICD process The ICD process may vary from project to project. In this paper, an Excel based interface description is used,

Fig. 3 gives an example. Input data and output data are described in separate sheets of the Excel file. Attributes like name, type, unit, reference, etc. have to be defined here. Signal types may be boolean, integer, float, byte arrays.

Another already realized possibility is to define the ICD in a XML file which could be extracted from an A/C ICD database for example.

SIRIUS reads the ICD files of each model and generates an adapter code which is compiled and linked to the model sorce code.

Deployment

A/C Database

Import

SourceCode

Model ICD

Model Adapter

Model

Processing

SIRIUS

Generation

Deployment

A/C Database

Import

SourceCode

Model ICD

Model Adapter

ModelModel

Adapter

Model

Processing

SIRIUSSIRIUS

Generation

Figure 10. Integration process

Name Type Unit Description Dim1 From Refresh Rate[Hz]

Init Value Last Modifcation

ControlsSIGNAL_CockpitControls_stickLong double rad Elevator Surface

Position1 AIDGWY/SIGNAL_CockpitControls_stickLong 50 0 1

SIGNAL_CockpitControls_stickLat double rad Right Aileron Surface Position

1 AIDGWY/SIGNAL_CockpitControls_stickLat 50 0 1

SIGNAL_CockpitControls_rudder double rad Rudder Surface Position

1 AIDGWY/SIGNAL_CockpitControls_rudder 50 0 1

SIGNAL_CockpitControls_flapsPos double rad Flaps Surface Position

1 AIDGWY/SIGNAL_CockpitControls_flapsPos 50 0 1

SIGNAL_CockpitControls_gearDown int Gear Level State [ 0 = gear up,1 = gear down]

1 AIDGWY/SIGNAL_CockpitControls_gearDown 50 0 1

SIGNAL_CockpitControls_brakeLeft double % Left Brake Position 1 AIDGWY/SIGNAL_CockpitControls_brakeLeft 50 0 1

SIGNAL_CockpitControls_brakeRight double % Right Brake Position 1 AIDGWY/SIGNAL_CockpitControls_brakeRight 50 0 1

SIGNAL_CockpitControls_throttle1 double % Left Throttle Position 1 AIDGWY/SIGNAL_CockpitControls_throttle1 50 0 1

SIGNAL_CockpitControls_throttle2 double % Right Throttle Position

1 AIDGWY/SIGNAL_CockpitControls_throttle2 50 0 1

Figure 11. Example of an Excel ICD

American Institute of Aeronautics and Astronautics

10

C. Makefile SIRIUS provides a very flexible and powerful build environment for C/C++ source code compilation and target

generation. It is based on GNU Make, supports all platforms and compilers and simplifies writing Makefiles dramatically. Model developers or model integrators using the SIRIUS build environment do not have to take care about differences of operating systems or compiler environments any more. The following is a list of tasks the SIRIUS framework’s makefiles, model.mak and model_group.mak, automatically perform when they are included in a simulation model’s makefile:

• Call the SIRIUS Adapter Code Generator. • Include all SIRIUS and generated headers/libraries needed by the simulation model. • Detect, compile and link all source (*.c/cpp) and header (*.h) modules including any shared

libraries (*.so or *.dll). • Based on the Compilier/Operating System environment detected, generate platform dependent

Windows or POSIX target machine code. Fig. 12 gives an example of a Makefile.

D. Configuration While starting SIRIUS, a manifest file in standard xml format (Fig. 13) has to be loaded. This manifest defines

the configuration of the simulation. It contains • plugins, service and model libraries to load • general kernel settings • attributes for each item

############################################################################### include $(PROJECT_ROOT)/Definitions.mak PROJECT = RAD_ALT ICD = RAD_ALT.xml OBJ_DIR = ./ SRC = RadAlt_main.c RadAlt_param.c SRCDIRS += . SRCDIRS += $(PROJECT_ROOT)/Sim/Common/Utils INCDIRS += . INCDIRS += $(PROJECT_ROOT)/Sim/Common/Utils INCDIRS += $(PROJECT_ROOT)/Sim/includes DEF += PROJECT_TYPE = dynamic PROJECT_OUTPUT = $(PROJECT_ROOT)/Sim/libs ############################################################################### include $(SIRIUSSDK_INCLUDES)/envICD = model.mak

Figure 12. Makefile example

include model.mak

American Institute of Aeronautics and Astronautics

11

E. Model execution Simulation models normally execute as independent sub-tasks inside the framework process. That means that the

scheduling of simulation models is necessarily done by SIRIUS. Therefore, the framework performs, monitors and synchronizes each simulation step, Fig. 14:

1. Set input data 2. Call the model's main entry function (assuring data and time consistency) 3. Get output data

With the preparation described above, SIRIUS can be started and the defined models will be loaded. The user is

capable to examine the behaviour of his model by the various tools, SIRIUS is providing. An existing airvehicle simulation embedded in Simulink as one big model was the basis for a new simulation.

Common modules like environmental model or kinematics model (with the equations of motion) have been extracted for integrating them in SIRIUS. Other airvehicle specific models (for instance the propulsion model) have been added.

Because of the modularity of the simulation it is possible to stimulate each model separately. So check-cases can be run for the model itself, or in the context of the whole simulation by muting outputs or overwriting inputs. Test scripts in SIRIUS support this application.

Model

SignalsSignals

model_main()model_main()

SIRIUS Simulation Runtime

1. set input data

2. call model function

3. get output data

Figure 14. Simulation model execution

<?xml version="1.0" encoding="utf-8"?><manifest>

<preferences><property name="path" value="$(installdir)/examples/models" /><property name="priority" value="" /><property name="startlevel" value="running" /><property name="appstate" value="running" />

</preferences>

<services><service name="executive" /><service name="communication" /><service name="messaging" /><service name="automation" />

</services>

<models><model name="SNC" url="./numbers/SNC" cycle="100000" priority="" /><model name="SNP" url="./numbers/SNP" cycle="100000" priority="" />

</models></manifest>

Global Settings

Plugins &Services

Models

<?xml version="1.0" encoding="utf-8"?><manifest>

<preferences><property name="path" value="$(installdir)/examples/models" /><property name="priority" value="" /><property name="startlevel" value="running" /><property name="appstate" value="running" />

</preferences>

<services><service name="executive" /><service name="communication" /><service name="messaging" /><service name="automation" />

</services>

<models><model name="SNC" url="./numbers/SNC" cycle="100000" priority="" /><model name="SNP" url="./numbers/SNP" cycle="100000" priority="" />

</models></manifest>

Global SettingsGlobal Settings

Plugins &ServicesPlugins &Services

Models

Figure 13. Manifest file

American Institute of Aeronautics and Astronautics

12

Conclusions and Outlook SIRIUS is a very powerful tool which enables the simulation user to perform his various tasks like development

and integration/test of simulation models. SIRIUS is easy to use, no dedicated software skills are necessary. The architecture and the main functionalities of the simulation framework as well as different tools which are provided with SIRIUS have been explained. Integration steps have been illustrated by examples.

SIRIUS is ready to use and currently in service in different programms. Extensions to the framework for new use-cases or requirements are possible. SIRIUS is commercially available on demand.

Future work concerns the integration of SIRIUS in Matlab/Simulink. Thus, it shall be possible to combine the

different advantages of both systems for e.g. rapid prototyping of system software and simulation models.

References 1 N.N, "Arinc Specification 653, Avionics Application Software Standard Interface," 1 Jan 1997. 2 Val Serra, S., "AP2633 - Develop, Integrate and Validate Shared Simulation Models," Issue C, Airbus, France, 3 June 2008.