by **busser** » Mon May 26, 2008 12:35 pm

It seems that this is a common question that we often hear from users of Simulink/SCADE type modeling tools. However, this is not the opinion of the Simulink/SCADE tool vendors.

Simulink/SCADE are design modeling tools. They are graphical representations of the final software - that is they are graphical code representations that are fundamentally no different than the 3rd generation languages (C, C++, Ada, etc) that can be generated directly from them. They reflect design choices on how to implement requirements, they do not represent the actual requirements information itself.

Design models reflect specific design choices. For example, the user has the choice of implementing a requirement that remembers a particular sequence of inputs. Such a requirement may be implemented as a Stateflow state machine or as an arrangement of discrete logic gates with feedback paths. The choice is up to the designer. The actual choice, that is - the Simulink model - is not the requirement, it is only one choice of how to implement the requirement.

Also, design models are, by intention, optimizations. They make trade offs for efficiency in speed or memory utilization or reuse of existing model elements or understandability/maintainability or to meet style guidelines, etc. etc. etc. Requirements can't be optimized, they simply must be stated completely. Timing or memory related requirements may need to be expressed, but this does not affect the actual functional requirement expressions themselves.

Also, design models are, by intention, incomplete input-to-output mappings. Design models make assumptions about the input variables they process. For example, if there are 3 signals going into a Simulink/SCADE model and these 3 signals are A, B, and C, and these signals are components of a unit-vector. The requirements about these signals must include the relationship

A**2 + B**2 + C** = 1

This is the definition of unit-vector. Such requirements are common for systems such as flight-guidance-related applications where the system needs to compute geometric locations in space, such as a system computing orbital eccentricity. This relationship is of very critical importance as a requirement for the model. But there will be no part of a Simulink/SCADE model that actually computes this identity relationship if the model can assume that the sender of the A,B,C input signals will guarantee that this relationship always holds true.

To summarize, fundamentally a functional requirement is a mathematical mapping between an output of a system boundary, the inputs to that system boundary, and a constraint relationship governing the mathematical mapping is the one valid description of the output's value. All functional requirements can be expressed in the form

Output Z = f(inputs) WHEN (expression)

A given output, for example Z, may have many functional relationships for different conditions

Output Z = f1(inputs) WHEN (expression1)

Output Z = f2(inputs) WHEN (expression2)

Output Z = fN(inputs) WHEN (expressionN)

As long as expression1, expression2,...expressionN are disjoint conditions (that is, they are non-overlapping conditions. No pair of expression1, expression2,...expressionN constraints can be true at the same time)

T-VEC's TTM tool is designed to enable users to capture functional requirements in their pure and formal representation. Together with T-VEC, such requirements can be analyzed for consistency, disjointness, race conditions, etc. This can be done long before the Simuilink/SCADE models are developed to implement these requirements and help insure that the requirements being implemented in Simulink/SCADE type tools are in fact the desired requirements and there are no errors and ambiguities in the requirements that would lead to incorrect design choices in the Simulink/SCADE design models, which would then produce incorrect C/C++/Ada code via their 3rd generation language code generators.