Testing Requirement with Operator ‘>’:

Req :

Software shall set TO1 = TRUE when [(TIN1 > 30.0)]

Test Approach :

• Assume that the data range of TIN1 is [-10.0 to 200.0]
• Note the toggling status of TO1 in terms of arranging the input

**Note that 1 LSB should be equal to 1 for integer data type and float precision in case of float data type

Testing Requirement with Operator ‘>=’

Req :

Software shall set TO1 = TRUE when [(TIN1 >= 30.0)]

Test Approach :

•  Assume that the data range of TIN1 is [-10.0 to 200.0]

Testing Requirement with Operator ‘<’

Req :

Software shall set TO1 = TRUE when [(TIN1 < 30.0)]

Test Approach :

•   Assume that the data range of TIN1 is [-10.0 to 200.0]
• Note the toggling status of TO1 in terms of arranging the input

Testing Requirement with Operator ‘<=’

Req :

Software shall set TO1 = TRUE when [(TIN1 <= 30.0)]

Test Approach :

Assume that the data range of TIN1 is [-10.0 to 200.0]

Testing MC/DC Requirement:

Note that this requirement is irrespective of Level of software and subjected to agreement in software
plan.

Req :

Software shall set TM1 = TRUE when [(TX1 = TRUE) AND (TY1 > 30.0)]

Test Approach :

• Ensure that TM1 = FALSE as initial condition
• When checking the output, TM1, ensure that o/p values are toggled in different test case
• Since TY1 is a float i/p, values should be checked for greater by 1 LSB (or possible constraint due to HW).

Testing Timer Requirement

Req :

Software shall set TY1 = TRUE when [TX1 = TRUE] for 300 ms.

Test Approach :

• Check for output with the shortest timer/counter pulse for inactive state
• Check for output with the timer/counters:
  • Make TX1 = TRUE for ‘half-time duration’ i.e, 150 ms, then make TX1 = FALSE for 150 duration
  • Timer is active for about half the timer/counter value,
  • Inactive for the duration of the timer/counter value and then
  • Active for the duration of the timer/counter value
  • Active for the duration + some tolerance (eg. 10 ms), of the timer/counter value

This is ensure that timer reset is properly taken care in the software before testing for full duration

Testing Latching Requirement :

Req :

Software shall set ‘TX Failed’ = TRUE when ‘RX Invalid’ = TRUE for 100 ms.
  Software shall latch ‘TX Failed’ in RAM.

Test Approach :

•  First part of requirement should be verified as per ‘Testing Timer Requirement’
• For the latching of data in RAM, it should be verified as:
  • Test that latched data is set when the input condition is set for setting the latch
  • Test that latched data is set even when the input condition is not-set, for duration of
    timer/counter
  • Power Cycle the target board (or reset on other simulated environment)
  • Check that latch data is reset

Testing Interpolation Requirement:

Req :

Software shall calculate the velocity schedule from the Airspeed using the linear interpolation as shown
below:

Test Approach :

• Check that output in terms of float can be checked as part of any message could be checked, else can
• check this as part of interpolation module tests
• For every point on Airspeed, check for +/-1 LSB of input (Airspeed)
• Assumed LSB = 1 for Airspeed, needs to seen as per requirement
• Assumed that Airspeed range as per the data dictionary (or ICD) range = 0 to 600 knots

Testing Analog Requirement :

Req:

Software shall interface 28V DC power input via 12 bit ADC sampled at 1 ms.

Test Approach :

• Assume that DC power range = 0 to 28V, hence:
  • 0V = 0
  • 28V = 0xFFF on 12 bit ADC
  • 1 LSB = 28/0xFFF V
• Assume that SW scheduler runs @ 1ms

Testing NVRAM Requirement:

Req :

• When commanded, software shall set store the LVDT-1 offset in NVRAM if it is within the range 0-10 mm.
• Software shall send a message on ARINC Label 110 with:
• Bit 10 => Status offset validity (data range between 0-10 mm) and,
• Software shall send a message on ARINC Label 120 with the value of LVDT-1 offset, if data is written
  properly in NVRAM
• Unless commanded, software shall set use the LVDT-1 offset from NVRAM after power-up

Test Approach :

Note: Focus of the section is to make the test case related to NVRAM being written – [A], verified from an output
regarding the data write status – [B], and retrieved properly next time after power-up – [C].
Typical issues of an NVRAM implementation:

• If for any reason, SW does not able to write, it times-out without indicating properly
• Usually NVRAM implementation are done on walk-through, i.e, every time the new data is getting written
  in NVRAM, previous location is erased, and then data gets written to next available location.
• Robustness -> On 100-200 power-up, data missed to be retrieved. This typically reveals the protocol issue
  on NVRAM read at power up.
• Robustness ->The number of times the data should be forced to written should be based on forcing the
  data to be written ‘at least once’ throughout the NVRAM to prove wrap-around design for choosing new
  location is properly implemented