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"?
jack
 
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.
busser
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?
jack
 
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
ttm_cond_table.png (19.31 KiB) Viewed 7180 times


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

ttm_consistent_input.png
ttm_consistent_input.png (2.34 KiB) Viewed 7185 times

ttm_not_consistent_input.png
ttm_not_consistent_input.png (2.37 KiB) Viewed 7185 times


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

tvec_error.png
tvec_error.png (37.79 KiB) Viewed 7189 times


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

ttm_error_row_highlight.png
ttm_error_row_highlight.png (5.04 KiB) Viewed 7186 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.
busser
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 0 guests

cron