Requirement VS. Model requirement

A place for discussing topics that do not fit into the other TTM categories

Requirement VS. Model requirement

Postby jack » Sun May 25, 2008 9:14 pm

Someone use simulink or scade,think that the simulink model or scade model can be looked as the requirement,
i am not sure whether this eys is correct,and what is the different between the TTM requirement model and the Simulink or SCADE
"requirement model"?
Posts: 16
Joined: Sat Mar 15, 2008 9:59 am

Re: Requirement VS. Model requirement

Postby 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.
Site Admin
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Re: Requirement VS. Model requirement

Postby jack » Tue May 27, 2008 8:16 am

By the way,how can the TTM requirement be analyzed for consistency by T-VEC?
Posts: 16
Joined: Sat Mar 15, 2008 9:59 am

Re: Requirement VS. Model requirement

Postby busser » Tue May 27, 2008 9:09 am

There are multiple aspects of "consistency". Checking for consistency is done in a number of ways, but they all mostly involve the attempt to generate test vectors. The process of generating test vectors is actually a form of consistency check. For example, if you have a Condition Table where the condition is

ttm_cond_table.png (19.31 KiB) Viewed 7115 times

and the input variables have the following types and domain definitions.

ttm_consistent_input.png (2.34 KiB) Viewed 7120 times

ttm_not_consistent_input.png (2.37 KiB) Viewed 7120 times

For this TTM condition table, the attempt to generate test vectors will result in an error

tvec_error.png (37.79 KiB) Viewed 7124 times

for table row 2 - which can be seen by navigating to TTM through the DCP 2 link information.

ttm_error_row_highlight.png (5.04 KiB) Viewed 7121 times

It this case, the requirement expressed in the Row 2 requirement expression is not consistent with the domain of the variables being referenced in the condition expression.

There are other forms of consistency. For example, if one table references another table, but the output domain for the referenced table does not support the expression that references it, the vector generation process will not produce a test vector. This would indicate that the 2 tables are not consistent with each other, at least not in the way the requirement is using the lower level table.

Also, each row of a condition table should have a unique condition - that is, the condition domains should not overlap. The mechanism called "disjointness checking" can be used to determine whether or not each condition expression in the table is unique. There is good information in the latest TTM user's guide describing this mechanism.

To summarize, consistency checking is the process of insuring that a requirement's description is valid with respect to all of the variables and tables referenced by the requirement. The way to determine such validity is to attempt to produce a test vector. If a test vector can be produced for the requirement, its expression is consistent. If a test vector can not be produced, the requirement's expression is not consistent.
Site Admin
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Return to General Topics

Who is online

Users browsing this forum: No registered users and 1 guest