Transformation Rules

The concrete high-level implementation rules applied in the prototype are listed below: − Before the transformation begins, all necessary libraries must be loaded

− The link to the MiLEST library for all blocks added to the test model should be dis- abled in order to manipulate their parameters within this model

− For each SUT a test harness must be built

− The data types of all generated signals should inherit from the types specified for them in the SUT model and consequently in VFs

− The names of all generated Inport blocks at the source and signal lines connecting them with the SUT should match

− The structure of the TestData must be consistent with the MIL_Test/Test Data/Test

Data Architecture/<Test data generator> from the library

− The simulation parameters in the resulting test model inherit the ones in the source model

The technical transformation rules related to the specification levels are listed in Table 5.1 for illustration purpose. Starting at the test harness level, the TDGen unit is generated based on the structure of the TSpec unit. If the TSpec is further defined by the test engineer, the transforma- tion functions refine the TDGen unit by updating the number of requirements and test data sets inside them. This is possible by analyzing the fixed elements of the TSpec, e.g., ‘Test Info’ in- terfaces, and projecting them onto the transformation target, e.g., ’Requirement’ subsystem in

the TDGen. Similar methodology applies for all the levels in the test system hierarchy. Table 5.1: Transformation Rules for Test Data Sets Retrieval.

Level Test Specification Test Data Generation

TSpec subsystem identified Generate ’Test Data’ subsystem applying the pattern from

MIL_Test/Test Data/Test Data Architecture/<Test data generator>

Test Harness

Number of SUT input signals Number of generated signals for ‘Test Data’ subsystem

’Test Info’ interface Generate a ’Requirement’ subsystem

Test Re-

quirement Number of ’Test Info’ interfaces Number of requirements

’Activate ’ interface Generate a ’Test Data’ set pattern and a corresponding

state in ’Generation Sequence’ diagram

Number of ’Activate’ interfaces Number of ’Test Data’ sets

Test Case – Validation

Function Number of ’Activate’ interfaces Number of states in ’Generation Sequence’ diagram

SUT input signal in Bus Selector, ‘MATLAB

Fcn’, signal comparison block

Generate a ‘MATLAB Fcn’ connected to an output port labeled with SUT input’s name

SUT input signal in Bus Selector, ‘Logical

expression’, signal comparison block

Omit ‘Logical expression’ and detect other connected feature extractor

SUT input signal in Bus Selector, ‘Complete step’, signal comparison block

Generate ‘Complete step’ connected to an output port labeled with SUT input’s name

SUT input signal in Bus Selector, ‘Detect

constant’, signal comparison block

Generate a subsystem labeled ‘Constant’ and an output port labeled SUT input signal

SUT input signal in Bus Selector, ‘Detect

increase’, signal comparison block Generate a subsystem labeled ‘Increase’ and an output port labeled SUT input signal

SUT input signal in Bus Selector, ‘Detect

decrease’, signal comparison block

Generate a subsystem labeled ‘Decrease’ and an output port labeled SUT input signal

SUT input signal in Bus Selector, ‘Detect

step’, signal comparison block

Generate a ‘Step’ and an output port labeled SUT input signal

SUT output signal in Bus Selector, signal

comparison block and reference block Generate a Bus Selector (with SUT output selected inside), signal comparison block, reference block, Memory block, and an output port labeled ‘Activate’

SUT input signal in Bus Selector and signal comparison block parameterized by ‘==’

Generate a subsystem labeled ‘Constant’ connected to an output port labeled with SUT input’s name

SUT input signal in Bus Selector and signal comparison parameterized by ‘>’ or ‘>=’

Generate a subsystem labeled ‘Increase’ connected to an output port labeled with SUT input’s name

Feature Generation

– Feature Detection

SUT input signal in Bus Selector and signal comparison parameterized by ‘<’ or ‘<=’

Generate a subsystem labeled ‘Decrease’ connected to an output port labeled with SUT input’s name

The approach is summarized based on a simple, relatively abstract example in Figure 5.18. As- suming that a transformation from functional requirements into their conditional representation is already done, two VFs nested in the TSpec unit are designed (see the right part of Figure 5.18). The preconditions encapsulate information about the test data demanded to activate the appropriate assertions. For each single precondition a corresponding set of signal generators is used resulting in the test data sets. The next step is to constrain the data with time. Either de- fault or parameterized duration time for a single signals set may be applied. A temporal con- straint – after(time1) is used in the example below. Finally, further parameters (e.g., signal value, permitted value range) depending on the feature from which the corresponding signal is generated, are set. This is supported by the values contained in the precondition’s parameter rs.

Hence, the test signals sequences are obtained. In Figure 5.18, the preconditions correspond to their test data sets. If the transformation is complete, the generated signals activate every single assertion one after another following the predefined time intervals.

SUT InOut Bus Preconditions1 Assertions1 Preconditions2 Assertions2

Generate Test Data1

from Preconditions1

Generate Test Data2

from Preconditions2

Test Data Generation

after (time)

after (time) _{transformation}automatic

Formal IF-THEN rules SUT informal requirements

semi-automatic transformation manual transformation

Verdict

Test Specification

Figure 5.18: Test Stimuli Definition – an Abstract View.

In Figure 5.19, a similar situation as in Figure 5.18 is presented, but on the lower level of ab- straction (i.e., using concrete signals). In VF1, all the values above the dotted line over the sig-

nal u1(t) activate the flag assertion. Thus, u1(t) is generated applying a corresponding pattern

and it is available within time ∈ (0, t1). Afterwards, u1(t) remains unchanged and u2(t) in-

creases within time ∈ (t1, t2) so as to enable the flag assertion in VF2. In this example, no de-

pendencies between features exist. Thus, the process of the test stimuli generation is completed.

q2(t)

SUT InOut_Bus

Verdict u1(t) Validation Function 2 0 t1 t2 time generatetd1within (0, t1) u2(t) 0 t1 t2 generatetd2within (t1, t2) time q1(t) time u1(t) time IF THEN ASSERT time u2(t) time IF THEN ASSERT q2(t) Validation Function 1

Test Data Generation

Test Specification