FMU tool-wrapper and FMU source-code generate different simulations in INTO-CPS

[tfabbri]

I'm testing the simulation in INTO-CPS of a system composed of two systems connected.

The output generated by the simulation of the system using the FMUs exported with tool-wrapper and source-code are different as depicted below in these images.

The fist image refers FMUs with tool-wrapper (with the overture interpreter operating with it) and the second image refers to the FMUs with generated source code. In the first 2 seconds of simulation the behavior is different.

[tfabbri]

Just an update about this issue:

Looking at csv file generated by the simulation, it seems that (maybe) the issue is from the COE:

The first value of each row represents the current time-step for a simulation with step-size equal to 0.01.
There is a strange behavior between the 0.09, 0.09999... and 0.10999

[bandurvp]

Hi @tfabbri , thank you for all the information, I'll take a look at it soon.

[tfabbri]

Hi @bandurvp , I've done some tests and one of the issue is generated during the computation of -

threadRunCount = (currentCommunicationPoint + communicationStepSize - threads[i].lastExecuted)
                               / threads[i].period;

into vdmDoStep . This operation may generates some issues (like a threadRunCount = (int) 0.99999... resulting in threadRunCount = 0) , requiring some round/cast operations.

[bandurvp]

Hi @tfabbri , nice detective work, thank you for looking into it. Floating point always underflows like this, and the problem is especially bad on embedded MCUs, especially 8-bit ones... How about some sort of rounding function that can be called instead of the (int) cast? I'll do some tests as well and get back to you.

[bandurvp]

Hi @tfabbri , I was actually going to implement a threshold-based addition and difference mechanism, so if you want to look into this maybe this is a good avenue to try. I decided not to do it in the initial implementation because the formulas were getting very awkward to write in single lines. The idea is something like a = b iff | a - b | < d, where d is the threshold value.

[bandurvp]

Just documenting ideas, a good threshold value might be a fraction of the step size, something like communicationStepSize / 10e-5. This value itself will be subject to under- and overflow, but I don't think variations of that kind in this value should matter. Then all value comparisons should be done relative to a threshold such as this.

[bandurvp]

Hi @tfabbri , I have just pushed a fix that takes care of the kink in the graph generated by the source code FMU, but the problem now is that the slope of the line is too high, please see below. I'll work on this further.

[bandurvp]

Hi @tfabbri , I noticed another thing that i wanted to confirm with you whether it is a difference between the two FMU types. Does the tool-wrapper look like the following between 0 and 1?

[bandurvp]

Hi @tfabbri , I'm going to re-design vdmDoStep because it is very hard to figure out, in the current design, where the fault lies, plus I was never happy with how I did it in the first place. If you're working on it currently, maybe leave it for a while.

[tfabbri]

Hi @bandurvp, I did not have the opportunity to look at the code of your solution, but from the output generated it seems that it is not behaving as discrete time system. The output of each FMU is a function of the input at the previous tstep (roughly speaking, there must be a delay of a tstep). Written in a mathematical form (where x is the internal state of the fmu, u is the input and y is the output) :

x(k+1) = Ax(k) + Bu(k)
y(k)  = Cx(k)

I do not know where to put those steps, but I think you have to do something like:

• Compute the output based on the stored input;
• Save the current input;

Does it make sense?

[bandurvp]

Hi @tfabbri , that seems about right. From your description and from the tool-wrapper graph you provided, it seems that the correct value for C should be 5, but for me it's 10.