Other useful resources:

## 1. Introduction

Universal science and engineering framework should be compatible with any third party science and engineering software. Compatibility with IronPython had been considered in "Universal Framework for Science and Engineering - Part 12: Grandiose Projects" article. This article is devoted to compatibility with Simulink. I do not have full compatibility with Simulink yet. Rather I have found answers of following two questions:

- Could be *.mdl Simulink files easy exported by the framework;
- What advantages provides export of these files.

I have tried to develop adapter which is enable to import some Simulink files and I have found that compatibility problem is enough easy. Advantages of compatibility will be considered in this and following my artiles. Now I am continuing writing "Grandiose Projects 2. The incredible machine" article and I have found that the incredible machine without Simulink is not incredible machine. Later I will add Simulink samples to incredible machine. Since "Grandiose Projects 2. The incredible machine" arctile is overloaded I have decided to write new article. Both articles will written simultaneously. This article is devoted to compatibility with Simulink. My previous article will be complemented by Simulink applications.

## 2. Background

Simulink block schemes contain blocks with math transformations. These blocks are connected by lines. The meaning of lines is information flow. The framework has typed arrows. One type is consuming of information flow. Framework has another type of arrows such as mechanical connection, relative geometrical position, interaction with physical field, etc. So main idea of compatibility is translation of information flow lines to information consuming arrows.

## 3. Outlook

Outllok of the idea will be considered by examples. Suppose that we have following Simulink scheme:

This scheme is translated to following framework scheme:

Arrows in second scheme have inverted direction and second scheme does not contain feedbak line. Feedback is implemented by another way. Let us compare elements of both schemes. The input element in first scheme is presented by following fragment of *.mdl file:

Block { |

BlockType Sin |

Name "Input" |

Amplitude "1" |

Frequency "1" |

} |

Corresponding element of framework has following properties:

Here we have explicit formula parameters "Amplitude" and "Frequency" have been replaced by constants *a* and *f* respectively. Next block Simulinlk has been replaced by block with following properties:

Negative term *a* is "constant". The "constant" notion is conventional. Constants can be forced by different factors. We leave trivial description of **Amlifier** and **T 1** blocks. Properties of **T 2** are presented below:

First window represents transformation function. Second window means that output of this block is send to *a* constant of **Sum**. So feedback had been provided.

## 4. User interface

Presented above scheme is indeed invisible. We have special "Simulink" component with following properties:

First tabpage enables us edit *.mdl file text. We also can download *.mdl file. Second tabpage represents Similink scheme. Third page enables us edit layout of public components. In result we have following component on desktop:

## 5. Implementation

Implementation is based on mapping between Simulink and Framework components. The Framework components are being stored in resources. Following picture presents resources which correspond to different Simulink blocks

The Gain, Sin, Sum resources correspond to Simulink blocks with same types. The compilation procedure sets Framework components instead Simulink blocks.

## 6. CodeDom compilation

Compatibility with Simulink can be reached by different ways. Here we will consider CodeDom compilation of Simulink files. CodeDom compilation had been already considered in my CodeProject article and arxiv article. Every Simulink file can be transformed to C# code. Let us provide an example of such transformation. Suppose that we have following Simulink scheme:

This scheme corresponds to following code:

using System;
using System.Collections.Generic;
using System.Text;
using Simulink.CSharp.Library.Interfaces;
using Simulink.CSharp.Library;
namespace Calculation
{
public class Calculate : IStateCalculation
{
public void Update()
{
arrow_3 = +arrow_1 - arrow_2;
arrow_4 = (System_0_const_K) * arrow_3;
double block_3 = arrow_4 - ((1) * state[0]);
derivation[0] = block_3;
arrow_0 = +((5) * state[0]);
double block_4 = arrow_0 - ((2) * state[1]);
derivation[1] = block_4;
arrow_2 = +((1) * state[1]);
oldTime = time;
}
System.Double arrow_0;
System.Double arrow_1;
System.Double arrow_2;
System.Double arrow_3;
System.Double arrow_4;
public double[] State
{
get
{
return state;
}
}
public double[] Derivation
{
get
{
return derivation;
}
}
double[] state = new double[2];
double[] derivation = new double[2];
double time;
double oldTime;
public double Time
{
get
{
return time;
}
set
{
time = value;
}
}
double u = 0;
double System_0_const_K = 0;
public Dictionary<string, SetValue> Input
{
get
{
return input;
}
}
Dictionary<string, SetValue> input;
void SetBlock_0(object o)
{
arrow_1 = (System.Double)o;
}
public Dictionary<string, GetValue> Output
{
get
{
return output;
}
}
Dictionary<string, GetValue> output;
object GetBlock_0()
{
return arrow_2;
}
public Calculate()
{
input = new Dictionary<string, SetValue>();
input["Input"] = SetBlock_0;
output = new Dictionary<string, GetValue>();
output["Scope"] = GetBlock_0;
constants = new Dictionary<string, SetValue>();
constants["System_0_const_K"] = SetConst_0;
}
public void Reset()
{
arrow_0 = 0;
arrow_1 = 0;
arrow_2 = 0;
arrow_3 = 0;
arrow_4 = 0;
}
public Dictionary<string, SetValue> Constants
{
get
{
return constants;
}
}
Dictionary<string, SetValue> constants;
void SetConst_0(object o)
{
System_0_const_K = (double)o;
}
}
}

Let us comment this code. The code contains intrinsic calculation and external access members.

### 6.1 Intrinsic calculation

First of all note that if blocks are connected by line than these blocks have common variables. For example the output variable of **T 1** block is in fact the input variable of **T 2** block. So identifiers of arrows are being used for such variables. Name of common variable of **T 1** and **T 2** blocks is `arrow_0`

. Names of intrinsic block variables contain the "block_" prefix and block number. The Update function performs necessary calculations. Let us comment fragment of its code

arrow_3 = +arrow_1 - arrow_2;
arrow_4 = (System_0_const_K) * arrow_3;

First operator corresponds to first Sum element of the scheme. The + and - signs correspond to List of Signs. This operator calculates `arrow_3`

. The `arrow_3`

is output of *Sum* element and input of *Gain*. Second operator correspond to Gain element. Result of this operator is `arrow_4`

. The `arrow_4`

is output of *Gain* and input of **T 1** transformation function. So we translate all blocks of the scheme.

### 6.2 External access

External access is implemented by following interface.

public interface IStateCalculation
{
void Update();
void Reset();
double[] State
{
get;
}
double[] Derivation
{
get;
}
Dictionary<string, SetValue> Input
{
get;
}
Dictionary<string, GetValue> Output
{
get;
}
Dictionary<string, SetValue> Constants
{
get;
}
double Time
{
get;
set;
}
}
public delegate void SetValue(object o);
public delegate object GetValue();

The `GetValue`

(`SetValue`

) delegates are being used for getting (setting) scheme variables. The Input property enable us input values to block. Following sample provides such input:

IStateCalculation calc = null;
SetValue sv = calc.Input["Input"];
double a = 5;
sv(a);

In this sample we have set double value to input variable (the "Input" is variable name). Following code presents reading the value of the "Scope" output variable.

GetValue gv = calc.Output["Scope"];
object o = gv();

It is worth to node that in general Simulink scheme is a system with internal state. The `State`

(`Derivation`

) property provides access to state vector (derivation of state vector). The above scheme contains two first order transformation functions. So dimension of state vector of this scheme is equal to 2. And we have following code:

public double[] State
{
get
{
return state;
}
}
public double[] Derivation
{
get
{
return derivation;
}
}
double[] state = new double[2];
double[] derivation = new double[2];

The `Time`

property enable us to get/set current time. The `Constants`

enable us to set values of constants. The `Reset`

method sets system into its initial state.

## 7. Applications

Emulation of Simulink is not interesting as standalone. It is interesting as integrated to Framework. Such integration enable us use mechanics, field theory virtual reality and other useful features.

### 7.1 Identification of system parameters

Let us consider once again following Simulink scheme:

This scheme contains one constant. This constant is coefficient of

*Gain*. We would like to define this constant. The Simulink scheme is included in following Framework scheme.

In this scheme the

**Simulink** component is wrapper of Simulink scheme which uses runtime C# compilation. The

icon means usage of Simulink wrapper with C# compilation. The

**Input** component provides input for

**Simulink** component. Properties of

**Input** are presented below:

The

*t* parameter of formula is time, other parameters are constants. So the

**Input** provides harmonic signal. Properties of

**Simulink** component are presented below:

These properties have following meaning. The *Input* parameter of Simulink scheme is equal to *Formula_1* of **Input** component. The value of the *K* constant of the Simulink scheme is equal to 1.9 (*K* is Gain coefficient). Suppose that we have record of other signal with another value of *K* and we would like to define this value. Both signals are presented on following picture:

Red curve corresponds to *K*= 1.9 and green curve corresponds to another value of *K* which we would like to define. We will use following scheme for our purpose:

Let us explain meaning of components of this scheme. Meaning of **Input** and **Simulink** components is already explained. The **Series** component contains imported signal with another value of *K*. The **Accumulator** component accumulates output of **Simulink** component. Properties of **Accumulator** are presented on following picture:

This component accumulates signal. Step of accumulation is equal to 0.01. Number of steps is equal to 501. The **Result** component has following properties:

This component calculates *f(x)*. The *f* is output function of **Accumulator** and the *x* is array of x-coordinates of **Series** component. So *f(x)* contains y - coordinates of output signal of **Simulink** component. The **Processor** properties are presented below:

These properties have following meaning. Right and center pain mean that we would like approximate y - coordinates of **Series** by *Formula_1* of **Result**. Left pain means that identifiable parameter is *K* coefficient of **Simulink** component. Roughly speaking algorithm is looking for such value of *K* that output signal of **Simulink** match to imported signal (**Series**). After this identification procedure we have new value of *K* (See below).

### 7.2 Interdisciplinary sample. Two channel follow system of radar

Two channel follow-up system of radar had been already considered in my article "Universal Framework for Science and Engineering - Part 3: Control systems. Processing of signals". This sample is more advanced and shows interdisciplinary character of the Framework. It includes following branches of science and engineering:

- Spatial geometry;
- Field theory;
- Advanced mechanics;
- Control theory;
- Virtual reality.

#### 7.2.1 Problem outlook

Outlook of problem is schematically presented below:

Radar antenna has two channel follow-up system with azimuth and elevation channels. Spatial geometry of this phenomenon is presented below:

Input data is being obtained from signal reflection. Control system acts to radar. So radar follow up visibility line. Let us consider theoretical issues of the problem.

#### 7.2.2 Theoretical issues

##### 7.2.2.1 Phase method of definintion of direction

Phase method of definition of direction can be explained by following geometrical task. Suppose that we have equilateral spatial triangle *ABC*.

We would like to find equidistance from

*A*,

*B* and

*C* line

*L*. Solution of this task is well known

*L* is normal to triangle plane and intersects center of triangle. Similar method can be implemented if we use phase of signal instead distance. Now suppose that antenna have three inputs with different phases. Now suppose that radar antenna have three signals with different phases. Following-up system tries to equalize phases. It is clear that signal is not received in three geometric points. Physics of real radar is much more complicated. However in some cases three point model can be good approximation of physical phenomenon. We suppose in this sample there are three conventional points near antenna and signal contains three signals received from these points.

##### 7.2.2.2 Advanced mechanics

In general radar antenna could not be considered as mechanical absolutely rigid body. Therefore elastic oscillations of antenna will be considered here. The Framework contains aggregate designer with good support of elastic mechanical simulation. This aggregate designer is described in my previous article. Here I remind it. Why aggregate designer? Indeed mechanical equations are well known long time ago. But software development for simulation of complicated mechanical objects is not quite easy task. Aggregate designer make this task much easier. Let us consider mechanical model of spacecraft from models of its modules as example. Typical spacecraft module is schematically presented below:

This module has own coordinates system OXYZ. Also it has places of connections. We can connect other modules to this module. Behavior of module is defined by following kinematic parameters:

- Radius vector
*r*;
- Velocity
*V*;
- Orientation quaternion
*Q*;
- Angular velocity .

But module is not rigid in general. And these parameters are not parameters of module. These parameters are rather parameters of one point of module. In this article we suppose that these parameters are parameters of origin of OXYX coordinat system. Since module is not rigid it has additional degress of freedom. These degrees of freedom can be interpreted as generalized coordinates *q*_{i} (*i* = 1,...,*n*). Instant state of module is defined by following parameters:

I will call them state variables. Parameters:

will be called accelerations. Mechanical equations define accelerations by state parameters. Accelerations near connection can be defined by following way:

where *i* is number of connection. Other variables are matrixes which depend on state variables. Let us connect two modules:

Both modules have equal acceleration near connection. First module acts to second one by force *F*_{12} and mechanical momentum *M*_{12}. Similarly second module actcs to first one by force *M*_{21} and mechanical momentum *F*_{21}. Following equations:

*F*_{12}=-*F*_{21};

*M*_{12}=-*F*_{21};

are well known. Mechanical equations of module can be represented by the following way:

In these expressions accelerations are independent variables. *F*_{i} (*M*_{i}) is force (mechanical momentum) of *i*- h connected module. Other vector and matrix parameters denend on state variables. Adding following evident expressions:

results to linear by accelerations system of equations. This system enables us to find all accelerations. So we have mechanical equations. It is worth to note that this system is redundant. If *n*_{1}(*n*_{2}) is number of freedom degrees of first (second) module then system has *n*_{1} + *n*_{2} degrees of freedom. However aggregate has *n*_{1} + *n*_{2} - 6 degrees of freedom. The framework can avoid this redundancy. But I will not describe it in this arcticle. There are a lot of module types. Programmatically all of them implement following interface:

/// <summary>
/// Aggregable Mechanical Object
/// </summary>

I will consider samples of modules below. Here I describe this interface. Meaning of this interface members is presented in following table:

**Number** |
**Member** |
**Comment (meaning)** |

1 |
Dimension |
Dimension of differential equation system |

2 |
NumberOfConnections |
Number of connections with other aggregates |

3 |
State |
State vetor (contains independent variables of differential equation) |

4 |
InternalAcceleration |
Accelerations of generalized coordinates |

5 |
this[int numOfConnection] |
State of connection |

6 |
GetAccelerationMatrix |
Acceleration matrix of connection |

7 |
GetForcesMatrix |
Forces matrix of onnection |

8 |
GetConnectionForce |
Connection force and momentum |

9 |
Children |
Children aggregates |

10 |
IsConstant |
The is constan flag |

11 |
Parent |
Parent object |

So this interface reflects parameters of above formulas. These parameters contains necessary information for aggregate construction. It is worth to note that if matrix of linear equations is constant then we can invert it one time and this fact enable us simplify solution Therefore this interface has

`IsConstant`

flag. Following aggregate library contains a set of basic mechanical objects.

First library object represents rigid body mechanics. Equations of rigid body are well known and I will not present them here. Rigid body has variable number of connections. Its editor of properties is presented below:

Number of connections their positions and orientations can be changed. Elastic console body is a mechanical system of infinite degrees of freedom. Usually math model of this object contains finite degrees of freedom with finite set of valuable harmonic oscillations. Every harmonic oscillation can be described by following second order system of ordinary differential equation:

Editor of properties of elastic body is presented below:

This editor enables us change number of harmonics and their numerical properties. Object of this type is used for simulation of antenna mechanics.

##### 7.2.2.3 Declarative geometrical approach

Direct or imperative approach in calculation uses explicit "expression" of phisical phenomenon such us "Evaluate following expression". This approach contains all disadvantages of imperative approach. Here we will use declarative approach which has following advantages:

- Laconism;
- Good interoperability with other phenomena.

Let us provide declarative description. There are moved object, physical field of moved object which is naturally geometrically linked to moved object. There are elastic antenna which interacts with physical field. Interaction depends on relative position of moved object and antenna. However declarative approach enables us implicitly take to account this dependence. Engineer has a lot of problems which are besides explicit description of geometrical dependence on geometrical position. This task is also used in virtual reality. Virtual reality also implicitly takes to account geometrical positions.

##### 7.2.2.4 Control theory

Typical control scheme of following system is PID control. Differentiation provides stability. Integration provides astatism. Simulink is used for simulation of PID controller. There are a lot of control laws implemented in Simulink. Now these control laws can be exported to the Framework.

#### 7.2.3 Implementation

##### 7.2.3.1 Moved object

Moved object implemented by following diagram:

The **Motion equations** contains explicit kinematic formulas:

The **Motion frame** is moved reference frame. It uses formulas of **Motion equations** by the following way

The above picture has following meaning. Time dependencies *X*(*t*), *Y*(*t*), *Z*(*t*) of **Motion frame** coordinates represented respectively by *Formula_1*, *Formula_2*, *Formula_3* of **Motion equations** object. Time dependencies of *Q*_{0}(*t*), *Q*_{1}(*t*), *Q*_{2}(*t*), *Q*_{3}(*t*) components of orientation quaternion are represented by *Formula_4*, *Formula_5*, *Formula_6*, *Formula_7*. Later geomerical position of **Motion frame** will be used implicitly.

##### 7.2.3.2 Physical field of moved object

Simulation of physical field is presented on following picture:

Main object is **Field**. The **GL** arrow means that the field is geometrically linked to **Motion frame**. So arrow **GL** is purely declarative. And position of **Motion frame** is taken to account implicitly. The **Field Math** object contains explicit formulas of phase field:

Here *x*, *y*, *z* relative coordinates of geometrical point and *a* is wave number of radiation field. Object **Field** has following properties:

These properties have following meaning. Relative coordinates *x*, *y*, *z* are respectively linked to variables *x*, *y*, *z* of **Field Math** object. Value of **Field** correspond to *Formula_3* of **Field Math** object. Note that here abstract (declarative) approach is also used. We do not explicitly point *x*, *y*, *z* coordinates.

##### 7.2.3.3 Model of receiver

We will use three point approximation model which is described in 7.2.2.1. This model is presented below:

The model contains three virtual sensors **S 1**, **S 2** and **S 3**. The sensors are installed on reference frames **1**, **2** and **3** respectively. Positions of the frames are considered with respect to reference frame **Base**. Later the **Base** will be installed on reference frame of antenna (as mechanical object). The **1**, **2** and **3** are moved with respect to **Base**. This relative motion is caused by elastic oscillations of antenna (as mechanical object). The **Coordinates** object contains formulas of this motion. Later the **Coordinates** object will be linked to expressions of elastic oscillations. The above picture is not convenient for following usage since it contains many objects which we did not edit in future. It would be useful to encapsulate this picture. We have container designer for this purpose. Following picture presents encapsulation of receiver:

Checked boxes correspond to following objects:

**Coordinates;**
**Base;**
**S 1;**
**S 2;**
**S 3.**

The **Coordinates** properties will be linked to elastic oscillations values. The **Base** frame will be linked to frame of antenna (as mechanical object) The **S 1**, **S 2**, **S 3** will be used for calculation of reflected signal. Encapsulated object is presented below:

##### 7.2.3.4 Interaction with field

Model of interaction with field is presented below:

For interaction we simply connect virtual sensors **S 1**, **S 2**, **S 3** to **Field** by "sensor - field interaction" arrows. Sensors are contained in encapsulated **Antenna** object. So three little black squares near **Antenna** correspond to the sensors. Although we are only connected squares a lot of operations have been performed implicitly. First of all relative position of sensor with respect to field have been taken to account. Secondly we have noted that in **Field** we did not point Relative coordinates *x*, *y*, *z* coordinates. Here we use these (abstract) coordinates for three objects **S 1**, **S 2**, **S 3** (free coordinates for each object). This operation also has been performed implicitly.

##### 7.2.3.5 Mechanical model of antenna

Mechanical model of antenna is elastic body with 6 elastic harmonics. Properties of antenna are presened below:

Atnenna is forced by mechanical momentum of control system. This momentum will be considered below.

##### 7.2.3.6 Interaction of mechanics and receiver properties

We have noted that positions of conventional points depend on elastic oscillations. This dependence can be expressed by following way:

where is shift of any coordinate of any conventional point, *q*_{i} - are generalized coordinates, *k*_{i} - coefficients. Set of cooefficients (as whole) depends on number of conditional point and coordinate name (*x*,*y*,*z*). Implementation of this depenence is presented in following picture:

Let us explain meaning of comopnents. One of output parameter of **Antenna mechanics** is vector *q* of generalized coordinates. The **Elastic shifts** object uses this output vector. Following picture presents properties of **Elastic shifts**:

Right part of picture means that *x* variable is alias of *q* vector of generalized coordinates. The *ax* expression is scalar product. The *a* variable is constant vector with following properties:

The **Elastic shifts** contains 9 scalar products. The 9 number has following reason: we have three points and every point has 3 coordinates. The **Elastic shifts** has feedback to **Shifts** object:

This feedback changes "constants" of **Shifts** object. The **Shifts** object calculates sums of constant shifts and shifts caused by elastic oscillations. The **Shifts** is used by encapsulated object **Coordinates** which is contained in **Antenna** object. We already described (see. 7.2.3.3) that **Coordinates** object contains coordinates of conventional points.

##### 7.2.3.7 Follow-up algorithm

Our system has two channels:

Antenna has three phase signals. We would like make two deviation signals from three phase signals. The geometry of signals is presented in following picture:

Here *A*, *B* and *C* are conventional points and *P* is position of observed objects. Lengths of intervals *AP*, *BP* and *CP* are equal in nominal. However if *P* is moved by such way that *L* line is rotated around *x* axis than |*PA*| shall not be equal |*PB*|. So difference |*PA*| - |*PB*| can be considered as deviation of visibility line around *y* axis (azimuth deviation). It is also clear that deviation caused by rotation around *y* axis is proportional to (|*PA*|+|*PB*|)/2 - |*PC*|. We do not have lengths *PA*|, |*PB*| and |*PC*|. But we have phase differences and deviations can be estimated by them. Full control logics is presented in following picture:

The *Delta* component calculates deviations by following way:

Right pane means that *x*, *y* and *z* variables correspond to outputs of **S 1, ****S 2**, **S 3** sensors respectively. The *Formula_1* and *Formula_2* correspond to azimuth and elevation deviations respectively. Deviations are used by PID controllers **Channel 1** and **Channel 2** objects which are implemented as proxy of Simulink object. The PID_Controller.mdl file had been downloaded and then had been used for this situation. These objects have following properties:

First picture represents logics of *.mdl file. Second picture represents constants and input variable. Here input variable is *Formula 1* of **Delta** objects or azimuth deviation. Properties of **Channel 2** are very similar to properties of **Channel 2**. Outputs of these objects are used as control mechanical momentums of antenna. This fact is reflected by following properties of **Antenna mechanics**:

This picture has following meaning. Mechanical momentums *M*_{x}, *M*_{y} are equal to outputs of **Channel 1** and **Channel 2** respectively. Full simulation picture is presented below:

Typical transition processes are presented below:

First chart contains deviations and second chart components of angular velocity of antenna. This sample requires additional files.

##### 7.2.3.8 Virtual reality

We have considered physical phenomena of two channel follow-up system. Now this physics will be used for virtual reality. We would like to present view of moved object though virtual videocamera which is installed on antenna. First of all we provide proper orientation of camera. The visibility axis of camera should be collinear to visibility axis to antenna. However visibility axis of antenna do not always canonically coincides with any mechanical axis of antenna. Additional frame will be introduced to provide proper orientation of camera. This frame is presented in following picture

The frame is named **Following Rotation**. Later virtual videocamera will be installed on this frame. Since virtual reality do not requires relative positions and orientations we can encapsulate physics. In result we have following object.

This object has three public objects:

- Base reference frame;
- Reference frame of moved object;
- Reference frame of installed camera installed on antenna.

Now we will construct following situation:

This diagram has following objects:

Object name |
Comment |

**Following Motion** |
Encasulated physics of physical phenomenon |

**Plane** |
3D Graphical model of transport plane |

**Following camera** |
Virtual videocamera installed on antenna |

**Forward** |
Reference frame for additional virtual videocamera |

**Side** |
-"- |

**Low** |
-"- |

**Forward camera** |
Additional virtual videocamera |

**Side camera** |
-"- |

**Low camera** |
-"- |

This sample requires additional files and "Aviation + Simulink + OpenGL" version of the framework.

To try this sample you need set parameters (Start time, Start step, Step, Step count and Pause) of virtial reality as it is presented in following picture

Then the Start button should be clicked. More suitable values of these parameters are presented on following table:

Parameter |
Value |

Start time |
0 |

Start step |
0.02 |

Step count |
400 |

Pause |
0 |

####

#### 7.2.4 WPF version of 3D visualization

The framework had been founded in 2002. First virtual reality framework had been based on OpenGL. During writing of this article WPF visualization was developed. So it is reasonably supply this article with WPF visualization source code. You can download it. You can also download above situation.

WPF 3D performance substationally exceeds OpenGL one. So we need set foolowing parameters of animation:

Parameter |
Value |

Start time |
0 |

Start step |
0.0002 |

Step count |
40000 |

Pause |
0 |

####

#### 7.2.5 Conclusion

This sample shows advantages of declarative approach. If we stated (relative) geometrical positions then we have no concern about lot of other details. Action of physical fields automatically takes to account positions and orientations. Control signal depends on relative orientations and positions of objects. Otherwise relative orientations and positions depend on control signal. Later motion simulation is used in virtual reality. Both virtual reality and simulation of physical phenomenon use reference frames. Virtual reality simulation becomes installation of virtual cameras and 3D models on reference frames provided by simulation of physical phenomena.

### 7.3 Stateflows. Automatic transmission control

Simulink supports stateflows. Now importance of stateflows in IT is evident. Moreover Stateflows are suppurted by some programming languages (C# for example). I think that best way of compatibility with Simulink stateflows is usage of Windows Workflow Foundation. Let us consider following example. Automatic transmission control is typical workflow problem. Full Simulink diagram of automatic transmission system is presened below:

This scheme contains a catalogue of subschemes. The Framework wrapper of Simulink represents this catalogue by following way

Left pane represents catalogue structure. Right pane represents subschemes. Logics of automation transmission control is described here. This logics contains state machines which are presented on following scheme:

It is clear that following Windows Workflow Foundation diagrams represent in fact same state machines.

So the natural way of compatibility of Simulink state machines and framework state machines is translation Simulink stateflow to Windows Workflow Foundation.

## WAIT

## Points of interests

Compatibility with Simulink will provide a lot of prospects. Many engineering developments could be imported.

## History

I have decided to provide compatibility at November 2008. But I did not know good way of this idea. At June 2009 I have found a good way of idea implementation. During 10 days I have developed first version. History is not finished. This article is rather announcement. Many *.mdl files cannot be yet imported. This article and code will be extended.

<input type="hidden" id="gwProxy" /><input type="hidden" id="jsProxy" önclick="jsCall();" />