My question is why do I need 4 vectors ? Can I not show complete coverage with 2 vectors? One to go down the If path and the other to go down the else path. I think this a fundamental question about what t-vec is doing when it generates a set of vectors.

Coverage is not really the only desirable result. Analysis and detection of errors is also one of the goals of the test vector produced by T-VEC.

By default, T-VEC generates 2 test vectors for each DCP (Domain Convergence Path - i.e. logical constraint path). One vector is produced using LOW BOUND favoring rules and the other is produced using HIGH BOUND favoring rules. Beyond simple MCDC coverage is the examination of constraint solution sets near the boundaries of the solution space. It is a well known fact (and part of the foundation of Domain Testing Theory) that coders/specifiers/modelers, etc. make most mistakes near the domain boundaries of their problem space. For example, use of > where >= was really the required relationship. T-VEC's LOW/HIGH bound mode vector generation process attempts to provide default test vectors that hit more of the domain boundary points than just MCDC alone.

T-VEC's general algorithm first solves the constraint equations that govern the outputs being produced (the constraints of the DCP path) simultaneously in terms of variable domains. Once a stable input space is identified, it begins collapsing this space to a final single point, by collapsing the variables that make up the input space to a single point, one at a time, then allowing the convergence process to collapse the input space further around that variables chosen single point value. It continues to follow this approach until all variables are fixed to a single value, which identifies the point in the input space that defines the whole set of input values for that test vector. It then plugs these values into the output equation to come up with expected output values. The LOW/HIGH bound vector generation concept is what is used to decided how to collapse each individual un-fixed input variable to a single value. In LOW bound mode, the minimum possible value for that variable, at the current stage of the convergence process, is chosen as the fix-point value. In HIGH bound mode, it is the maximum value of the current domain.

Note, the domain of values is not necessarily the default input domain for the variable, it is the domain that results from solving the constraint equations of the DCP. In your example, even though both u1 and u2 had initial 0..100 domains, after applying the u1<u2 relations, these domains were converged so that any point in u1 will have a corresponding point in u2 that satisfies the u1<u2 relation.

There are other reasons for having a default minimum set of test vectors that include both LOW and HIGH bound vector generation passes, but those reasons are beyond the scope of your question.

On a side note if I run thsi through DV I get a set of two vectors. WIthout any constraints they are [0,0], [0,-1]. I'm noty saying either is better I'm just trying to figure out the difference.

Your point about "without any constraints" is precisely the issue - what good are points like [0,0], [0,-1]. Any one, any tool, can blindly pick points in the open unconstrained domain, then plug them in and see what happens and make a decision as to what to do with it. T-VEC is designed to eliminate this manual and tedious trial and error steps in testing by eliminating the "execute it (or simulate it) and see what happens" processes. The translation of Simulink models into T-VEC form identifies all of the logical paths in the model to be the focus of the test vector generation process and then identifies a set of input values that specifically cover that logical path. This is the reason it can then compute the expected results, because it knows exactly what output relationships are governed by that logic path - so it can plug in the inputs and compute the results - and do so independently from Simulink ! It is never a good idea to allow the tool used to do simulation and code generation to also be its own oracle to the expected results. Such a testing process is no better than software testers looking at the code being tested in order to come up with the tests. A successful test in such situations proves nothing more than the compiler did what it said that it would do. In the case of Simulink/Stateflow, using it as the oracle presumes that the RTW code generator is perfect and can't make mistakes. This is not the case. We have found many situations where the RTW code produced different results than was produced by the simulation engine and/or different results than T-VEC or a human would produced if calculating by hand.

I hope this answered your basic questions. Please feel free to continue with more questions on this topic, or any other.