Simulation Model Portability 2

1
Simulation Model Portability 2

• Overview of the SMP2 Standard

2
Introduction

• Simulation Model Portability Standards
• SMP2 Objectives
• SMP2 Concepts
• Summary
• Discussion

3
Simulation Model Portability Standards

• ESA has recognised the need for greater
  portability/exchange and reuse since the early
  90s to
• Promote reuse between different project phases
• To promote reuse between different projects
• Initiated the development of the Simulation Model
  Portability (SMP) Standards in the mid-90s
• Main focus was to support the exchange of models
  between ESAs different simulation platforms
  (e.g. SIMSAT and EUROSIM) as well as third party
  platforms.
• ESA has used the High-Level Architecture (HLA)
  for model interoperability

4
Portability and Reuse vs. Interoperability
Platform A
Platform B
Simulation Kernel A
Simulation Kernel B
SMP
SMP
Porting Reuse
Model A
Model B
Model B
Model A
Model C
Model C
Model D
Model E
Platform A
Platform B
Simulation Kernel A
Simulation Kernel B
Interoperability
SMP
SMP
Model A
Model B
Model D
Model E
Model C
5
SMP1

• First version of the portability standards
  defined
• Standards to ensure portability between platforms
• Standard interface between models and simulation
  environment (SMI)
• Guidelines for model developers
• Used on a number of satellite simulator
  developments
• Limited by the lowest common denominator between
  simulation environments
• Found to have limited benefit
• Lack of support for reuse
• Little support for model integration (major
  problem in complex simulations)
• Little support for object-oriented concepts

6
SMP2 Objectives

• Cost Reduction
• Promote Model and Simulator Reuse
• Portability
• Between simulation environments
• Between platforms (e.g. operating systems and/or
  middleware)
• Support Model Integration (e.g. plug and play)
• Configurable and Flexible Simulations (e.g.
  dynamically defined simulations)
• Machine readable model meta-data
• Establish Basis for Model Repository
• Risk Reduction
• Integration of Engineering Data
• Facilitate greater use of models throughout the
  lifecycle of a system
• Open Standard Built on Standard Technology

7
SMP2 Configuration Control Board

• Current Active Members
• ESA
• ESTEC (Luis Arguello/Juan Miro)
• ESOC (Niklas Lindman)
• VEGA (SMP2 Definition and Prototyping)
• Headway (SMP2 Prototyping User)
• Dutch Space (SMP2 Prototyping Infrastructure)
• SciSys (Review and Comment)
• Other companies/organisations following SMP2
• Airbus
• EADS Astrium
• EADS Space Transportation
• EA International
• UK MOD
• http//groups.yahoo.com/group/smp_list/
• SMP2 progress reported to ECSS E-10 Part 4 1A
  Modelling and Simulation standardisation
  activities

8
SMP2 Based on Standard Technology

• OMG Model Driven Architecture (MDA)
• Platform Independent Model
• Platform Specific Model
• UML
• Based on UML 1.x
• Capable of extensions to support UML 2.0
• XML
• XMI
• XSLT
• XPATH
• XLink

9
SMP2 Basic Concepts
Catalogue (Types Models)
Assembly
Platform Independent Model (PIM)
Instantiation Configuration
Model Configuration (in memory)
Model Library (.lib, .dll)
Platform Specific Model (PSM)
Design-Time
Run-Time
10
SMP2 Elements

• SMP Meta-model
• Defines Common Concepts Components, Interfaces,
  Hierarchies, Relationships and Inheritance
• Defines Common Types
• Abstract Component Model
• Defines basic features a model component must
  support
• Defines class factory pattern for component
  instantiation
• Simulation Services
• The services provided or expected by the
  simulation environment
• Language Binding
• Provides a binding between the meta-model and a
  specific implementation language e.g. C, Java,
  C, CORBA IDL
• Non-object oriented languages (e.g. FORTRAN, C)
  can be wrapped inside an OO component.

11
The SMP2 Meta-Model

• Components
• Properties only accessible from interfaces
  (set/get)
• Fields directly accessible
• Interfaces
• Requires
• Provides
• Hierarchical Decomposition
• Components can contain other components
• Inheritance
• Single Inheritance of Implementation
• Multiple inheritance of interfaces
• Relationships

12
SMP2 Process
Run-Time
Design-Time
System
Real-World
System Engineering
Abstract System Element
System Engineer definition of Radar Receiver and
what it is composed of
Realises
Real World
Concrete System Element
Representation
Representation
Catalogue
Simulation Engineering
Assembly
Type (Abstract Component)
Realises
Platform Independent Model (PIM)
Model (Concrete Component)
Instantiation
Choice
Mapping
Mapping
Choice
Decide
Model Library (.DLL, .LIB)
Software Engineering
Model Configuration(in memory)
Platform Specific Model (PSM)
Configuration
V1
V2
V1
V2
V3
13
SMP2 Example My RADAR
14
SMP2 Process In a Nutshell
15
SMP Process Configuration

• Performed at run-time
• Creates the representation of the models in
  memory
• Links each component to an implementation (in the
  form of a dynamically loaded library)
• Allows dynamic loading of different component
  implementations without recompiling the
  simulator
• Different versions (evolution)
• Different fidelity
• Different algorithms

16
The SMP2 Meta-Language

• Simulation Model Definition Language (SMDL)
  provides the basis for defining a model
• Defined in a set of schema that define the SMP2
  Meta Model e.g.
• Base
• Elements (with Annotations, Documents,
  Attributes, Links)
• Element is common base for almost all other
  language elements
• Units
• Defines Base Units and Conversions (e.g. F to K,
  C to K)
• Dimensions (Mass, Length, Time, Amps, Kelvin,
  Moles, Candela)
• Types
• Reference Type (e.g. interfaces, classes,
  components)
• Value Types (e.g. Integer, Float, Boolean, String
  etc.)
• Instances
• Assembly
• Component Instances
• Child Component Instances
• Links to other components

17
SMDL and UML
Concept Only (N. Lindman)
18
Abstract Component Model

• Base Type (IObject)
• All interfaces and components inherit from this
• Reflection
• Query available interfaces/operations and
  properties
• Dynamic Invocation
• Of interface/operations revealed from reflection
• Containment
• Can contain sub-components
• Persistence
• Save and restore simulation
• Object Creation Lifecycle
• At initialisation or dynamic (class factory,
  garbage collection, reference counting)
• Simulation Service Binding
• Expected services provides by the run-time
  infrastructure

19
Simulation Services

• Load and Initialisation
• Events (Provided by the simulation environment)
• Load
• Initialise
• Run
• Pause
• Terminate
• Service Acquisition (to find out what services
  are available)
• Standard Services
• Logger (Logging events in the component models or
  simulation environment)
• Scheduler (Schedule components execution
  cyclically and discretely)
• Time Keeper (Provide components with simulation
  time)
• Event Manager (Allow components to register new
  events)
• Optional Services
• Component Factory (Dynamic creation of
  components)
• Recorder (Run-time recording of simulation data)

20
SMP2 Platform Mappings

• Requires a mapping to each platform e.g. C,
  J2EE, CORBA, .NET, HLA
• C mapping developed so far
• Draft Java mapping has been proposed but not in
  v1.0 of SMP2
• Aim is to support automated code generation of
  all the Glue code, modellers can focus on the
  modelling
• C mapping defines a number of classes
  representing components and interfaces, including

• IObject
• IComponent
• IContainer
• IPersist
• IReflection
• IDynamicInvocation

• IServiceProvider
• ILogger
• IScheduler
• ITimeKeeper
• IEventManager
• IComponentFactory

21
Interfaces to Engineering Data

• The dream is to allow SMP2 models to be
  generated and/or configured from Engineering Data
• Various Activities to define Engineering Data in
  UML/XML
• SysML The SysML group response to RPP from OMG
  System Engineering Domain SIG expected to be
  architecturally aligned with STEP AP-233
• STEP based on Express Language but now
  aligned with XML
• XASTRO defines a complete system architecture in
  XML (ESA/VEGA)
• Avionics Architecture Design Language
• Based on Honeywells proprietary Meta-H
• Being standardised by the Society of Automotive
  Engineers (SAE)
• Converging on MDA, UML, XML
• Planned core of the ASSERT Framework 6 programme

22
SMP2 Status

• Definition process started in early 2003
• Alpha Version 1.0 of the Standard Issued
  (December 2003)
• Prototyping has already shown SMP2 Standard to be
  workable
• Mainly technical details and scope need to be
  finalised
• Beta 1 Issued April 16th 2004
• Release Candidate 1.0 planned June 2004
• Issue 1.0 planned September 2004
• Tool support is essential and is in the process
  of development
• Possibly develop a UML 2.0 profile for SMP2

23
Summary

• SMP2 v1.0 will provide a mature standard for
  users
• Offers cost and risk reduction in all domains
• It is built on open, non-proprietary, platform
  independent technology
• Supports bindings to different platforms (e.g.
  C initially)
• Automatic code generation of all interfaces and
  assemblies hides complexity from the modellers
• Allows legacy models to be put in a component
  wrapper
• Could provide the basis of model catalogues and
  repositories
• Potential to be generated from System Engineering
  data in the future

24
Thank You!