Goal is to simulate as early as possible system of interest through stimuli injected from operational context: physical environment and other connected systems.

In order to get representative representations of  operational context it is necessary to use executable models for the different elements of the context. So idea is to use FMI standard instead of looking at semantic gateway between different modeling languages or tools. FMI allows exporting each model representing an element of system context as and FMU (Functional Mockup Unit). Those FMUs can then be imported in a systems engineering tool and can be connected to the system of interest.

Figure 1: co-simulation graph in a SysML Internal Block Diagram

The resulting model, also called “coupled model”, defines a graph for co-simulation. That graph is useful to know the sequence of calls for the different FMUs (execute a step through fmi2doStep function ) and the sequence of data to exchange between FMUs and the System Of Interest (thnaks to  fmi2getXXX and fmi2setXXX functions).

Figure 2: Basic master algorithm.

Progress in execution and data exchange are implemented through a master algorithm (see figure 2). That algorithm allows for co-simulation of system of interest in its operational context even that system is not yet realized.

Figure 3: Operational context and use of FMI

In operational context, we use FMUs that embed both compiled model (.dll, .so, etc) and a solver dedicated to model execution (see Figure 3). Master algorithm is in charge of orchestrating execution of the different FMUs. We can then observe system behavior in response to the injected stimuli and then validate that the model behaves as expected (meets the requirements).

And what has just been said for a global system (satellite, car, aircraft, etc) can also apply for a subsystem (see Figure 4).

Figure 4: Operational context of a subsystem and FMI.

Idea is to formalize constraint relationships between system key properties through acausal equations and then bind equation parameters to those properties: weight, payload capacity, power, speed…

If we take some assumptions on values or ranges for some system properties we can then use solvers able to solve equations. It is then possible to determine values of other properties and evaluate system performance in its current representation and with given assumptions.

This approach can be used during mission analysis stage to analyse feasibility of a solution class and do pre-sizing. It can then be used all along the system lifecycle up to physical realisation of product where it becomes possible to deduce all ranges of values for system properties.

• • We investigate ability to refine and then simulate a functional architecture initiated through a high level system model like SysML or Capella and completed with functional blocks expressed by other languages like Simulink or Xcos.

There are two main axes:
1. Methodology: we study mapping of concepts between languages (blocks, ports, activities, connectors, flow…) and the way to complete those concepts at a finer-grain of detail in order to support realistic simulation.
2. Technical: we study feasibility of combining several simulation tools, especially through FMI standard