Page 1 of 1

SubSubSystem Data Type

PostPosted: Thu Mar 26, 2009 12:41 pm
by jyoung
Attached is a simple example of my question

I have a model with three inputs that perform an addition and then feed into and atomic subsystem. In the subsystem another addition is performed and then a sqrt.

I created user defined types that constrin the top level inputs from 0 - 100 and 1 - 2.

When I build the project I get an "Arithmetic Exception During Post-condition Computations" error because the inputs to the sqrt are no longer constrined and the the default range for double is used. This of course causes and error with sqrt.

Do I have to manually chnage the type for all inputs in all sub-systems to maintain the correct domain?

This doesn't seem right to me because if I have a model and there are 3 inputs to that model and I set the domain for these inputs than all lower level values shoudl be a function of these inputs. If I set the top level range to be 0 - 1 than I don't see why a value of -1e12 shoudl be tested at a lower level because that value can never be acheived. It seems like there might be a way to make the lower level vectors a function of the top level inputs.


Re: SubSubSystem Data Type

PostPosted: Tue Mar 31, 2009 11:17 am
by jyoung
Any thoughts on this subject?

Re: SubSubSystem Data Type

PostPosted: Wed Apr 01, 2009 10:01 am
by busser
There are 2 sqrt() functions in your lower level subsystem "Math". The arithmetic exception is happening on the second of the 2 sqrt() functions. The input to this sqrt() is the output of an "+" operation. One of the inputs to the "+" was not constrained in the "Math" subsystem. It is defined as a double, so the result of the "+" includes negative numbers which is why the exception was flagged.

ares_sqrt.jpg (927.16 KiB) Viewed 8535 times

You did define domains for both inputs the the "+" operator at the top level of the hierarchy, which is where the second input to the "+" in the "Math" subsystem comes from. However, the signal going into the second input port of the "Math" subsystem has not been defined because the translator does not create auto-types for the outputs of division operations.

The Simulink model translator does a really good job propagating signal definitions from their source location in the model (as identified in the .srf file) to all other locations in the model that are directly connected - or indirectly connected through blocks like unit delays, switches, and others that don't change the semantics of the signal. The translator even creates auto-types/domains for signals originating from bounded blocks like saturation blocks and interpolation tables where extrapolation is not being allow. However, it is not able to perform the domain computations necessary to create auto-types and auto-domains for signals that come out of arithmetic operators like the division operator in your top level system. That is the purpose and expertise of the VGS model analysis and vector generator technology.

One of the topics thoroughly covered in the training class is how and where to define signal domains. The primary point is that signals should be defined at their source location. A source location is the origination point of the value domain for that signal - such as the outputs of arithmetic operations. In your case, if you define the second input to the "Math" subsystem as being of type User1 (which is valid because User1 / User2 = User1 since the domain of User2 is [1..2]) then re-translate and rebuild the T-VEC project, the results will no longer indicate an arithmetic exception in the sqrt() function.

ares_sqrt2.jpg (328.1 KiB) Viewed 8532 times

Re: SubSubSystem Data Type

PostPosted: Wed Apr 01, 2009 10:46 am
by jyoung
Yes this is the same conclusion I came too.

I was hoping that this was not the case. This is a very simple example with only a few inputs and one subsystem, but in my integrated model I have hundreds of inputs and many dozens of sub-systems (in-fact this could easily be a hundred sub-systems). In order for t-vec to correctly analyze my model I have to define the inputs to each sub-system which might end up being thousands of inputs in total. That would be a lot of work, but potentially do able. The bigger issue I have is that many of the sub-system are designed to perform intermediate calculations and the ranges to the system may not be immediately obvious to the model developer. Therefore in order to get the input ranges the developer would have to run a number of test cases on the model and track the inputs to the sub-system. In essence they are running a number of test cases on the model and end up testing the extreme ranges of the inputs. Is this not what t-vec is trying to do as well? What additional benefit does t-vec provide if I’m already testing the extremes of my model while determining the ranges to input into t-vec?

Of course it determines the test vectors required to execute all of the pathways, but one of your extra capabilities that t-vec offers is the ability to test the model by looking at all of the extremes where errors are most likely to occur. I may be doing this already while trying to determine the ranges of each sub-system.

In my example if the math was a little complicated I couldn’t just use User1 as the type for Input2 within the Math model. I would have run my model a number of times changing Input2 and Input3 in my top level system and monitor Input2 in the Math sub-system until I could define the range. Then I would make a new type User3 that was for the Input2 in the math model. In this model that is easy to do, but in my real system this becomes a very large task and I was hoping the tester could do this for me and I would think all of the information needed is there in the model (I could be wrong).

I’m not being critical I just trying to find out what will be needed once we are utilizing this tool with a number of integrated systems instead of my simple examples.


Re: SubSubSystem Data Type

PostPosted: Wed Apr 01, 2009 11:23 am
by busser
We understand your points, but this process is not as difficult as you may fear. Mitigating aspects are

there are facilities in the Signal Range editor for tracking signals back to their source filtering the view to identify the signals that you are interested in

the amount of propagation and auto-type creation being done by the translator is actually quite extensive

the need for defining types is mostly only necessary for floating point signal and is not generally necessary for ints, unsigneds, booleans, etc.

the need for defining types even for floating point variables is also not always necessary, depending on the use of the variable. For example, your only need in this case was to
constrain the inputs going into the sqrt operators so as to inform the vector generator not to bother with input values that would cause such an exception.

low level utilities such as "Math" from your example can be indicated within Simulink that they should be inlined into the parent that references it. In such a case, there would not be any separate T-VEC subsystem to worry about. For example, if you had inlined "Math" into its parents, then the basic type declarations that you did for the top level would have been completely sufficient and you would not have received any arithmetic exception diagnostics because the domains, by the time they are seen at the sqrt() functions would have been constrained by the vector generation process to be non-negative.

This perspective that you are describing is one of the main reasons we prefer to work with new customers directly in the form of early training classes that include hands on work and plenty of examples and opportunities to address these kinds of issues. This is rather difficult via emails and Forum questions ;)