Difference between revisions of "State Variable Inits"

From T-VEC Wiki
Jump to: navigation, search
(Related Topics)
 
Line 7: Line 7:
 
===Related Topics===
 
===Related Topics===
 
*The purpose of Test Sequence specification is to provide the model developer with a mechanism to assess the dynamic aspects of a model or model subsystem. This is explained in the [[Test Sequence Vector Example|Test Sequence Vector Example]].
 
*The purpose of Test Sequence specification is to provide the model developer with a mechanism to assess the dynamic aspects of a model or model subsystem. This is explained in the [[Test Sequence Vector Example|Test Sequence Vector Example]].
*State Variable Inits do not impact the states in Stateflow. This is explained in [[State Flow Test Vectors||State Flow Test Vectors]].
+
*State Variable Inits do not impact the states in Stateflow. This is explained in [[State Flow Test Vectors|State Flow Test Vectors]].
  
 
==Example Model - Single State Delay==
 
==Example Model - Single State Delay==

Latest revision as of 17:43, 28 February 2007

This section provides a few examples to explain how the State Variable Inits test vector generation property provides a mechanism to support test coverage of Simulink constructs that have state data such as the Unit Delay construct. The purpose of the example is to:

  • Show example vectors that are produced by the different State Variable Init settings
  • Show how the test vectors are mapped through the test drivers to initialize inputs as well as state variables
  • Show how the resulting test results reflect both the inputs as well as the state variable test driver settings
  • Explain why the State Variable Inits mechanism provides the control aspects associated with multi-depth state that can be verified without the user defining Test Sequences in the SL2TVEC GUI.

Contents

Related Topics

  • The purpose of Test Sequence specification is to provide the model developer with a mechanism to assess the dynamic aspects of a model or model subsystem. This is explained in the Test Sequence Vector Example.
  • State Variable Inits do not impact the states in Stateflow. This is explained in State Flow Test Vectors.

Example Model - Single State Delay

The following is a simple model that contains one unit delay. The input is a simple 8 bit integer with a range from -128 to 127. The output is based on the input at time T and the unit delay from time T-1 (expect if the unit delay has an initial value at time T=0, as can be specified in Simulink).

Single Time Delay

Vectors for State Variable Inits

The following image shows the vectors that are produced based on the different State Variable Init settings. Based on the rules, the key variable is the _local.IState_Unit_Delay variable, which is associated with the init setting:

  • T=0 - _local.IState_Unit_Delay = Initial Conditions from Simulink Block (See Image below, the Initial conditions value is 0)
Initial Conditions
  • Ignore - is treated fundamentally the same as T>0. However, it is the default setting when there are no state variables
  • T>0 - _local.IState_Unit_Delay values are solved for (i.e., through vector generation convergence), rather than initialized to their T=0 values
  • T>=0 - generates vectors for each DCP individually, first applying T=0 rule and then applying T>0 rule



State Variable Inits and Vectors

Test Driver Mapping

The RTW auto generated code makes these variables visible. Therefore, the following code illustrates how these variables are mapped to specific test driver inputs. The two key variables include the input test_sequences_U.In1 and state variable associated with the unit delay test_sequences_DWork.UnitDelay_DSTATE_b.

 // **** Test 1 ****
  // set outputs
  test_sequences_B.Sum = 127;
    
  // set inputs
  test_sequences_U.In1 = 127;
  test_sequences_DWork.UnitDelay_DSTATE_b = 0;
    
  // execute the test
  test_se_SingleTimeDelay();
  test_s_SingleTimeDelay_Update();
    
  // print vector number and output values to results
  fprintf(ofstream, "%d,", 1);

  // __Single_Time_DelayData._output
  fprintf(ofstream, "%d,", test_sequences_B.Sum);
  printf("test %d output %d: %d,\n",1, 1, test_sequences_B.Sum);

  // __Single_Time_DelayData.__local.IState_Unit_Delay
  fprintf(ofstream, "%d,", test_sequences_DWork.UnitDelay_DSTATE_b);
  printf("test %d output %d: %d,\n",1, 2, test_sequences_DWork.UnitDelay_DSTATE_b);

  fprintf(ofstream, "\n");

The test driver is adequate for testing the control of a code subsystem, because the state variables can be set to key values that demonstrate the compliance of the auto generated code with the specification, as reflected by the test results comparions.

Single Delay Example Test Results

Example Model - Double State Delay

This rationale for being able to verify code with a single state applies to multiple state depths too, as illustrated by the following example that contains two unit delays that are sequenced.

Double Time Delay


Vectors for State Variable Inits

The following image shows the vectors that are produced based on the T>=0 setting force both state variables _local.IState_Unit_Delay and _local.IState_Unit_Delay1 to be converged by the vector generation, and the example further illustrates the sequenced nature of the variable values. This point is key, because the control aspects associated with multi-depth state can be verified without the user defining Test Sequence Vector control mechanisms in the SL2TVEC GUI.

Doublt Time Delay Vectors for T>=0

Test Driver Mapping

The RTW auto generated code makes these two state variables (test_sequences_DWork.UnitDelay_DSTATE and test_sequences_DWork.UnitDelay1_DSTATE) visible. Therefore, the following code illustrates how these variables are mapped to specific test driver inputs.

// **** Test 1 ****
// set outputs
  test_sequences_B.Sum_e = 127;
    
  // set inputs
  test_sequences_U.In2 = 127;
  test_sequences_DWork.UnitDelay_DSTATE = 0;
  test_sequences_DWork.UnitDelay1_DSTATE = 0;
    
  // execute the test
  test_se_DoubleTimeDelay();
  test_s_DoubleTimeDelay_Update();
    
  // print vector number and output values to results
  fprintf(ofstream, "%d,", 1);

  // __Double_Time_DelayData._output
  fprintf(ofstream, "%d,", test_sequences_B.Sum_e);
  printf("test %d output %d: %d,\n",1, 1, test_sequences_B.Sum_e);

  // __Double_Time_DelayData.__local.IState_Unit_Delay
  fprintf(ofstream, "%d,", test_sequences_DWork.UnitDelay_DSTATE);
  printf("test %d output %d: %d,\n",1, 2, test_sequences_DWork.UnitDelay_DSTATE);

  // __Double_Time_DelayData.__local.IState_Unit_Delay1
  fprintf(ofstream, "%d,", test_sequences_DWork.UnitDelay1_DSTATE);
  printf("test %d output %d: %d,\n",1, 3, test_sequences_DWork.UnitDelay1_DSTATE);

  fprintf(ofstream, "\n");

The test driver code again is adequate for testing the control of a code subsystem, because the state variables can be set to key values that demonstrate the compliance of the auto generated code with the specification.