dws tips
[email protected]
DWS TIPS
-----------------------------------------------------------------
CATEGORY: Requirements Interpretation
TITLE: How to test "_CAPT(FO)" or _[CAPT/FO]
NUMBER: CDS_0001
-----------------------------------------------------------------
EXAMPLE:
if ALT_PFD_DISPLAYED_CAPT(FO) > 99,900 then
display "99900"
endif
The 777 SCD refers to many variables as VARIABLE_CAPT(FO). The
737 DSS refers to similar variables as _[CAPT/FO]. In these cases,
the requirements are defining software that will operate exactly
the same whether the software is executing on the captain's side or
the first officer's side.
Tests need only verify the operation on one side, typically the
captain's side. It is likely that since the software is required
to operate the same on both sides, there is little chance of
differences in operation between the two sides. Testing both sides
for every variable would almost double the number of test cases
since 95% of all variables are defined to operate the same on both
sides.
A test is required to ensure that the displays are generally
correct on the first officer's side also. This is usually done in
a separate test where all the first officer's displayed symbols are
verified to appear on the display as per figure XXX.
-----------------------------------------------------------------
CATEGORY: TDF Variables
TITLE: Variables which depend on logic from other sections
NUMBER: CDS_0002
-----------------------------------------------------------------
EXAMPLE:
Section 1:
A := B + C
Section 2:
if A < 30 then
display 30
endif
Using the example above, when testing section 2, it is NOT
possible to set A directly. Since A depends on logic in another
requirements section, A must be set using a function which utilizes
the logic defined in section 1. In a TDF, A is set as follows:
DEFINE FUNCTION set_A (in_value : IN REAL) RETURN CHAR IS BEGIN
-- ---------------------------------------------------------------
-- This function sets the A using the requirements defined in
-- section 1.
--
-- in_value : -2048..2047
B := in_value;
C := 0;
RETURN;
END;
$set_A(29); | |X....|.....|.....|.....|
$set_A(30); | |.X...|.....|.....|.....|
Take note, however, that if variable B and C are also tested in
section 2, then a little more creativity is necessary for the
function set_A. The necessary creativity varies for each example.
For SCD examples, to determine if a variable depends on other
logic, look at the parameter set/use table. Find the variable (A
in this case) in the table and determine where the variable is set.
If the variable is "set" in a requirements section, it most likely
must be set using a function which considers the logic from the
other section. If, however, the set use table indicates that the
variable is "set" in a different requirements sheet, the variable
can be set directly. (This holds true if the software under test
contains code for only one SCD sheet. If multiple sheets are
included in the SUT, then you must look at all the sheets to
determine if the variable can be set directly)
-----------------------------------------------------------------
CATEGORY: TDF Variables
TITLE: Max/Min values - ICD or full physical
NUMBER: CDS_0003
------------------------------------------------------------------
EXAMPLE: None
In an attempt to "break" the software we would like to test the
full physical range of the variables. However, we may or may not
have direct access to the variables. Therefore, we will test only
the ICD min and max, not the full physical range (32 bit variables
on 777).
-----------------------------------------------------------------
CATEGORY: TDF Testcases
TITLE: Testing multiple requirements in 1 test case.
NUMBER: CDS_0004
-----------------------------------------------------------------
EXAMPLE: None
Avoid testing too many requirements in a single test case. It
is better to separate into many different test cases to make the
TDF more understandable. Do this even though it might double the
amount of test cases. The tests will be more maintainable if they
are simpler.
-----------------------------------------------------------------
CATEGORY: TDF Init
TITLE: Init_ functions
NUMBER: CDS_0005
-----------------------------------------------------------------
EXAMPLE: None
Every testcase should be initialized to the same state using an
"init_" function such as "init_airspeed". This init file should do
a couple of things:
1) Initialize EVERY variable used in the TDF to a known state.
This includes variables that appear in set_ functions. The known
state should include setting sta.var to valid.
2) Set the initial condition to a state that DOES NOT appear in any
of the test cases. For example, if testing airspeed, set the
airspeed to 123 knots unless one of the testcases also sets to this
value.
-----------------------------------------------------------------
CATEGORY: TDF Init
TITLE: Initialize every TDF to a known state.
NUMBER: CDS_0006
-----------------------------------------------------------------
EXAMPLE: None
Initialize every TDF to a known value. This is much more
complex in that every variable within the entire function should be
set to a known value. Every TDF should be initialized to the same
state to ensure that when running multiple TDFs in series, the
values set in one TDF do not affect the following TDFs.
-----------------------------------------------------------------
CATEGORY: TDF Functions
TITLE: Format for functions
NUMBER: CDS_0007
-----------------------------------------------------------------
EXAMPLE:
DEFINE FUNCTION set_X (param : IN REAL) RETURN CHAR IS BEGIN
-- ------------------------------------------------------------
-- This function sets X using the logic defined in section X.X.X.
--
-- param : -2048..2047.875
[use logic from X.X.X to set X]
RETURN;
END;
The above example suggests a format for functions used with DWS
testing. The format uses the following guidelines:
SSL statements - Use capital letters for SSL statements
DEFINE FUNCTION
RETURN CHAR IS BEGIN
RETURN
END
function name - Use standard function prefixes where possible
set_ , init_ , verify_ , message_ , slew_
The prefix is lower case. If the function
operates on an SCD parameter (like
set_ALT_PFD_DISPLAYED), the SCD parameter is
capitalized.
parameter - Passed parameters are lower case and cannot be
reserved SSL statements. See the SSL manual for
information on the syntax. NOTE: If no
parameters are passed, then empty parenthesis
() are required.
RETURN values - The SSL "DEFINE FUNCTION" command was originally
intended to perform as a function which returns
a value. This was modified so that the function
did not return a value. But the RETURN [TYPE]
syntax remains. DWS functions, normally used
as subroutines, use RETURN CHAR, even though
they are not returning a character.
Comments - Various comment lines are used:
1) -- ----------------------------------------
This comment line is used to separate the
SSL DEFINE FUNCTION command from the rest of
the function.
2) -- Description of the function.
The lines immediately following the separator
are used to describe what the function does.
A typical description appears in the example
above.
3) -- parameter description
The lines after the function description are
used to name the parameters and possible
values. Examples:
-- airspeed : -2048..2047.9375
-- altitude : -131072..131071
-- in_status : valid,test,ncd,npr
-- dme : vor1,vor2,adf1,adf2
Logic - The logic used in the function depends on the
requirements. Some tester creativity is
necessary to create a useful function.
RETURN - The RETURN differentiates a function from a
subroutine. If the DEFINE FUNCTION is used
as a function, then the RETURN([TYPE]) must
return a value as specified in the DEFINE
FUNCTION line. If a subroutine is desired,
use RETURN;
END - The end of the DEFINE FUNCTION statement.
-----------------------------------------------------------------
CATEGORY: Multiple Condition Tables
TITLE: Representing "NOT" operators in the table
NUMBER: CDS_0008
-----------------------------------------------------------------
EXAMPLE:
if METRIC_SPEED_DISP and
not.SPEED-FLAG then
display symbol in magenta
else
do not display symbol
endif
This example uses a NOT operator in the logic.
When creating a multiple condition table, try to use the same
logic as defined in the requirement.
Variable Tested True Condition Abbreviation
----------------------- -------------------- ------------
METRIC_SPEED_DISP TRUE A
SPEED_FLAG TRUE B
Logic Tested Output
-------------- ------------
if A and not.B then
display magenta symbol (1)
else
do not display symbol (2)
endif
A B Var Tested O/p Test # Notes
---- ---- ----------- ----- ------ -------
0 0 All zeros (2) etc. etc.
1 1 All 1s (2)
0 0 A = 0 (2)
1 0 A = 1 (1)
1 0 B = 0 (1)
1 1 B = 1 (2)
-----------------------------------------------------------------
CATEGORY: Multiple Condition Tables
TITLE: Representing encoded variables
NUMBER: CDS_0009
-----------------------------------------------------------------
EXAMPLE:
if sta.MARKER_BEACON.e <> npr and
(sta.DISC_350_VOR.e = npr or
not.MARKER_BEACON_STATUS)
then
if MARKER_BEACON.e = 1 then
display output (1)
else
if MARKER_BEACON.e = (2 or 3) then
display output (2)
else
if MARKER_BEACON.e = (4 or 5 or 6) then
display output (3)
else
if MARKER_BEACON.e = 7 then
display output (4)
else
display output (5)
endif
endif
endif
endif
else
display output (6)
endif
Represent the encoded variables as shown below:
Variable Tested True Condition Abbreviation
----------------------- -------------------- ------------
sta.MARKER_BEACON.e <> npr A
sta.DISC_350_VOR.e = npr B
MARKER_BEACON_STATUS TRUE C
MARKER_BEACON.e ENCODED D
Logic Tested Output
-------------- ------------
if A and (B or not.C) then
if D = 1 then
(1) (1)
else
if D = (2 or 3) then
(2) (2)
else
if D = (4 or 5 or 6) then
(3) (3)
else
if D = 7 then
(4) (4)
else
(5) (5)
endif
endif
endif
endif
else
(6) (6)
endif
A B C D Var Tested O/p Test # Notes
---- ---- ---- ---- ----------- ----- ------ --------
0 0 0 0 All zeros (6) etc. etc.
1 1 1 1 All 1s (1)
0 1 X(0) X(1) A = 0 (6)
1 1 X(0) X(1) A = 1 (1)
1 0 1 X(1) B = 0 (6)
1 1 1 X(1) B = 1 (1)
1 0 0 X(1) C = 0 (1)
1 0 1 X(1) C = 1 (6)
1 1 X(0) 0 D = 0 (5)
1 1 X(0) 1 D = 1 (1)
1 1 X(0) 2 D = 2 (2)
1 1 X(0) 3 D = 3 (2)
1 1 X(0) 4 D = 4 (3)
1 1 X(0) 5 D = 5 (3)
1 1 X(0) 6 D = 6 (3)
1 1 X(0) 7 D = 7 (4)
-----------------------------------------------------------------
CATEGORY: TDF Initializations
TITLE: Example init_ function
NUMBER: CDS_0010
-----------------------------------------------------------------
EXAMPLE:
This example function demonstates the concept of initializing every
test case.
DEFINE FUNCTION init_RDMI (sect : IN STRING) RETURN CHAR IS BEGIN
-- -----------------------------------------------------------------
-- This function initializes all variables used in the testing of
-- the PFD RDMI, including DSS sections 3.10.1,3.10.2,3.10.3, and
-- 3.10.4.
--
-- sect : "rose and ref","pointers","annunciations"
-- This refers to the DSS section under test
[ Set ALL input variables used in the RDMI sections to a known
state. Design this "known state" so that its output is
unique - that is, the output is different than any of the
test cases within the TDFs]
put_line ("Initial Conditions:");
IF parameter = "annunciations" then
put_line (" VOR1 - Green");
put_line (" ADF2 - Cyan");
ELSE
IF parameter = "pointers" then
put_line (" Bearing Pointer 1 points to 90");
put_line (" Bearing Pointer 2 points to 270");
ELSE
IF parameter = "rose_and_ref") then
put_line (" Compass rose displayed");
put_line (" 45 at the top of the rose");
ENDIF
ENDIF
ENDIF
put_line ("");
pass_fail("Do the initial conditions appear on the display?");
RETURN;
END;
-----------------------------------------------------------------
CATEGORY: TDF File
TITLE: Using an ASCII editor to create the TDF file
NUMBER: CDS_0011
-----------------------------------------------------------------
EXAMPLE: None
The TDF file should be created using an ASCII editor. Microsoft
word can be used, but the file should be saved as a text only file.
In addition, it seems that there may be some settings in Word which
cause some problems when saving the ASCII file. Thus, when creating
any ASCII file (especially using Microsoft Word), use the following
guidelines:
1) Do not use TABS. When creating tables, use a manual space to
create the columns.
2) Do not allow the editor to automatically create the margins. Use
a hard return at the end of EVERY line.
3) When using Word, save the file as Text Only.
-----------------------------------------------------------------
CATEGORY: Multiple Condition Tables
TITLE: Splitting large tests into multiple TDFs
NUMBER: CDS_0012
-----------------------------------------------------------------
EXAMPLE: See below
At times, a multiple condition logic section may be too large
to test in 1 TDF. The tests must then be split between 2 or more
TDFs. The following is an example of how to split requirements
which contain a large multiple condition table.
EXAMPLE TABLE:
Variable Tested True Condition Abbreviation
----------------------- -------------------- ------------
[ Example variables] ENCODED A
ENCODED B
ENCODED C
TRUE D
TRUE E
TRUE F
TRUE G
TRUE H
TRUE I
TRUE J
TRUE K
TRUE L
TRUE M
TRUE N
TRUE O
TRUE P
Logic Tested
--------------
if A = a1 then
if B = b1 then
if D and E and F and G then
(1)
else
(2)
endif
else
if B = b2 then
if H and I then
(3)
else
(4)
endif
else -- B = b3
(5)
endif
endif
else
if A = a2 then
if C = c1 then
if J and K and L and M then
(6)
else
(7)
endif
else
if C = c2 then
if N and O and P then
(8)
else
(9)
endif
else -- C = c3
(10)
endif
endif
else -- A = a3
(11)
endif
endif
Test
A B C D E F G H I J K L M N O P Logic O/p Test #
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ----- --- ------
a3 b3 c3 0 0 0 0 0 0 0 0 0 0 0 0 0 0's (11)
a1 b1 c1 1 1 1 1 1 1 1 1 1 1 1 1 1 1's (1)
a1 b1 x 1 1 1 1 x x x x x x x x x A=a1 (1)
a2 x c1 x x x x x x 1 1 1 1 x x x A=a2 (6)
a3 x x x x x x x x x x x x x x x A=a3 (11)
a1 b1 x 1 1 1 1 x x x x x x x x x B=b1 (1)
a1 b2 x x x x x 1 1 x x x x x x x B=b2 (3)
a1 b3 x x x x x x x x x x x x x x B=b3 (5)
a2 x c1 x x x x x x 1 1 1 1 x x x C=c1 (6)
a2 x c2 x x x x x x x x x x 1 1 1 C=c2 (8)
a2 x c3 x x x x x x x x x x x x x C=c3 (10)
a1 b1 x 0 1 1 1 x x x x x x x x x D=0 (2)
a1 b1 x 1 1 1 1 x x x x x x x x x D=1 (1)
a1 b1 x 1 0 1 1 x x x x x x x x x E=0 (2)
a1 b1 x 1 1 1 1 x x x x x x x x x E=1 (1)
a1 b1 x 1 1 0 1 x x x x x x x x x F=0 (2)
a1 b1 x 1 1 1 1 x x x x x x x x x F=1 (1)
a1 b1 x 1 1 1 0 x x x x x x x x x G=0 (2)
a1 b1 x 1 1 1 1 x x x x x x x x x G=1 (1)
a1 b2 x x x x x 0 1 x x x x x x x H=0 (4)
a1 b2 x x x x x 1 1 x x x x x x x H=1 (3)
a1 b2 x x x x x 1 0 x x x x x x x I=0 (4)
a1 b2 x x x x x 1 1 x x x x x x x I=1 (3)
a2 x c1 x x x x x x 0 1 1 1 x x x J=0 (7)
a2 x c1 x x x x x x 1 1 1 1 x x x J=1 (6)
a2 x c1 x x x x x x 1 0 1 1 x x x K=0 (7)
a2 x c1 x x x x x x 1 1 1 1 x x x K=1 (6)
a2 x c1 x x x x x x 1 1 0 1 x x x L=0 (7)
a2 x c1 x x x x x x 1 1 1 1 x x x L=1 (6)
a2 x c1 x x x x x x 1 1 1 0 x x x M=0 (7)
a2 x c1 x x x x x x 1 1 1 1 x x x M=1 (6)
a1 x c2 x x x x x x x x x x 0 1 1 N=0 (9)
a1 x c2 x x x x x x x x x x 1 1 1 N=1 (8)
a1 x c2 x x x x x x x x x x 1 0 1 O=0 (9)
a1 x c2 x x x x x x x x x x 1 1 1 O=1 (8)
a1 x c2 x x x x x x x x x x 1 1 0 P=0 (9)
a1 x c2 x x x x x x x x x x 1 1 1 P=1 (8)
Because of the size of this table, it may be necessary to
split the testing into 2 TDFs. In the following example,
the testing of the multiple condition logic begins at
test case 20 of TDF 1 and extends into a 2nd TDF. The
tester must decide exactly how to split the logic.
TDF 1:
-------
Test
A B C D E F G H I J K L M N O P Logic O/p Test #
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ----- --- ------
a3 b3 c3 0 0 0 0 0 0 0 0 0 0 0 0 0 0's (11) 20
a1 b1 c1 1 1 1 1 1 1 1 1 1 1 1 1 1 1's (1) 21
a1 b1 x 1 1 1 1 x x x x x x x x x A=a1 (1) 22
a2 x c1 x x x x x x 1 1 1 1 x x x A=a2 (6) 23
a3 x x x x x x x x x x x x x x x A=a3 (11) 24
a1 b1 x 1 1 1 1 x x x x x x x x x B=b1 (1) 25
a1 b2 x x x x x 1 1 x x x x x x x B=b2 (3) 26
a1 b3 x x x x x x x x x x x x x x B=b3 (5) 27
a2 x c1 x x x x x x 1 1 1 1 x x x C=c1 (6) 28
a2 x c2 x x x x x x x x x x 1 1 1 C=c2 (8) 29
a2 x c3 x x x x x x x x x x x x x C=c3 (10) 30
a1 b1 x 0 1 1 1 x x x x x x x x x D=0 (2) 31
a1 b1 x 1 1 1 1 x x x x x x x x x D=1 (1) 32
a1 b1 x 1 0 1 1 x x x x x x x x x E=0 (2) 33
a1 b1 x 1 1 1 1 x x x x x x x x x E=1 (1) 34
a1 b1 x 1 1 0 1 x x x x x x x x x F=0 (2) 35
a1 b1 x 1 1 1 1 x x x x x x x x x F=1 (1) 36
a1 b1 x 1 1 1 0 x x x x x x x x x G=0 (2) 37
a1 b1 x 1 1 1 1 x x x x x x x x x G=1 (1) 38
- - - - - - - - - - - - - - - - H=0 See TDF 2
- - - - - - - - - - - - - - - - H=1 See TDF 2
- - - - - - - - - - - - - - - - I=0 See TDF 2
- - - - - - - - - - - - - - - - I=1 See TDF 2
- - - - - - - - - - - - - - - - J=0 See TDF 2
- - - - - - - - - - - - - - - - J=1 See TDF 2
- - - - - - - - - - - - - - - - K=0 See TDF 2
- - - - - - - - - - - - - - - - K=1 See TDF 2
- - - - - - - - - - - - - - - - L=0 See TDF 2
- - - - - - - - - - - - - - - - L=1 See TDF 2
- - - - - - - - - - - - - - - - M=0 See TDF 2
- - - - - - - - - - - - - - - - M=1 See TDF 2
- - - - - - - - - - - - - - - - N=0 See TDF 2
- - - - - - - - - - - - - - - - N=1 See TDF 2
- - - - - - - - - - - - - - - - O=0 See TDF 2
- - - - - - - - - - - - - - - - O=1 See TDF 2
- - - - - - - - - - - - - - - - P=0 See TDF 2
- - - - - - - - - - - - - - - - P=1 See TDF 2
TDF 2:
-------
Test
A B C D E F G H I J K L M N O P Logic O/p Test #
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ----- --- ------
- - - - - - - - - - - - - - - - 0's See TDF 2
- - - - - - - - - - - - - - - - 1's See TDF 2
- - - - - - - - - - - - - - - - A=a1 See TDF 2
- - - - - - - - - - - - - - - - A=a2 See TDF 2
- - - - - - - - - - - - - - - - A=a3 See TDF 2
- - - - - - - - - - - - - - - - B=b1 See TDF 2
- - - - - - - - - - - - - - - - B=b2 See TDF 2
- - - - - - - - - - - - - - - - B=b3 See TDF 2
- - - - - - - - - - - - - - - - C=c1 See TDF 2
- - - - - - - - - - - - - - - - C=c2 See TDF 2
- - - - - - - - - - - - - - - - C=c3 See TDF 2
- - - - - - - - - - - - - - - - D=0 See TDF 2
- - - - - - - - - - - - - - - - D=1 See TDF 2
- - - - - - - - - - - - - - - - E=0 See TDF 2
- - - - - - - - - - - - - - - - E=1 See TDF 2
- - - - - - - - - - - - - - - - F=0 See TDF 2
- - - - - - - - - - - - - - - - F=1 See TDF 2
- - - - - - - - - - - - - - - - G=0 See TDF 2
- - - - - - - - - - - - - - - - G=1 See TDF 2
a1 b2 x x x x x 0 1 x x x x x x x H=0 (4) 1
a1 b2 x x x x x 1 1 x x x x x x x H=1 (3) 2
a1 b2 x x x x x 1 0 x x x x x x x I=0 (4) 3
a1 b2 x x x x x 1 1 x x x x x x x I=1 (3) 4
a2 x c1 x x x x x x 0 1 1 1 x x x J=0 (7) 5
a2 x c1 x x x x x x 1 1 1 1 x x x J=1 (6) 6
a2 x c1 x x x x x x 1 0 1 1 x x x K=0 (7) 7
a2 x c1 x x x x x x 1 1 1 1 x x x K=1 (6) 8
a2 x c1 x x x x x x 1 1 0 1 x x x L=0 (7) 9
a2 x c1 x x x x x x 1 1 1 1 x x x L=1 (6) 10
a2 x c1 x x x x x x 1 1 1 0 x x x M=0 (7) 11
a2 x c1 x x x x x x 1 1 1 1 x x x M=1 (6) 12
a1 x c2 x x x x x x x x x x 0 1 1 N=0 (9) 13
a1 x c2 x x x x x x x x x x 1 1 1 N=1 (8) 14
a1 x c2 x x x x x x x x x x 1 0 1 O=0 (9) 15
a1 x c2 x x x x x x x x x x 1 1 1 O=1 (8) 16
a1 x c2 x x x x x x x x x x 1 1 0 P=0 (9) 17
a1 x c2 x x x x x x x x x x 1 1 1 P=1 (8) 18
By separating the logic in the above listed fashion, if changes are
necessary for tests in TDF 1, the same changes do not need to be made
in TDF 2.
-----------------------------------------------------------------
CATEGORY: Multiple Condition Tables
TITLE: Representing multiple conditions which contain complex logic
NUMBER: CDS_0013
-----------------------------------------------------------------
EXAMPLE:
if MARKER_BEACON.e = TRUE and (0 <= DME_DIST.e < 100)
then
display output (1)
else
display output (2)
This example contains logic which is represented as follows:
Variable Tested True Condition Abbreviation
----------------------- -------------------- ------------
MARKER_BEACON.e TRUE A
DME_DIST.e 0 <= X < 100 B
Logic Tested Output
-------------- ------------
if A and (0 <= DME_DIST.e < 100)
then
display output (1) (1)
else
display output (2) (2)
endif
A B Var Tested O/p Test # Notes
---- ---- ----------- ----- ------ --------
0 0 All zeros (2) etc. etc.
1 1 All 1s (1)
0 1 A = 0 (2)
1 1 A = 1 (1)
1 0 B = 0 (<0) (2)
1 0 B = 0 (=100)(2)
1 1 B = 1 (=0) (1)
1 1 B = 1 (<100)(1)
NOTE1: List each output separately (2 B=0 cases, 2 B=1 cases).
NOTE2: Choose values which test the boundary conditions within
the multiple condition logic.
-----------------------------------------------------------------
CATEGORY: Multiple Condition Tables
TITLE: Avoid using multiple condition tables if possible
NUMBER: CDS_0014
-----------------------------------------------------------------
EXAMPLE:
if (sta.EXAMPLE_VARIABLE = valid or test)
then
display output (1)
else
if (sta.EXAMPLE_VARIABLE = ncd)
then
display output (2)
else
do not display an output
endif
endif
This example shows logic which at first glance seems to contain
multiple condition logic. But on careful inspection, we see that
the logic only contains a single variable (sta.EXAMPLE_VARIABLE).
When representing the test cases for this logic, it is preferable
to use simple test case descriptions rather than expanding this
logic into a multiple condition table. The simple test case
descriptions are easier to read and more concise than the multiple
condition descriptions. The multiple condition comments should be
used only to show that complex logic (containing 2 or more variables)
is properly tested by the TDF.
=====================================================================
Test Case Description:
A. Test sta.EXAMPLE_VARIABLE = valid.
B. Test sta.EXAMPLE_VARIABLE = test.
C. Test sta.EXAMPLE_VARIABLE = ncd.
D. Test sta.EXAMPLE_VARIABLE = invalid.
E. Test sta.EXAMPLE_VARIABLE = npr.
=====================================================================
-----------------------------------------------------------------
CATEGORY: Requirements Interpretation
TITLE: How to test "pre"
NUMBER: CDS_0015
-----------------------------------------------------------------
Example:
if (pre.parameter <> parameter)
then
display ("The button has been pressed") for 2 seconds
else
do nothing
endif
In this example, the software is to perform an action
after a button has been pressed. During normal operation, both
"pre.parameter" and "parameter" contain the same value. But once
the button is pressed, the parameter's value before the button
is pressed is contained in "pre.parameter", and the value after
the button is pressed is contained in "parameter".
This example is readily tested in a TDF. The simplest method
is as follows:
METHOD 1:
---------
$set_pre_parameter (TRUE);
$pause(4);
parameter := FALSE;
NOTE: A function is used to set pre_parameter to enhance the
readability of the TDF. Using set_pre_parameter helps the
TDF read like the requirements read.
The parameter is first set to true. We then must wait a
sufficient amount of time to ensure that the value has been
updated in the software. Variable update rates vary from 20Hz to
1 Hz, and our EDU systems execute 2 to 4 times slower than the
real software! The parameter is then set to false. When the
software updates the parameter, the previous value is "true"
and the current value is "false". The "pre" condition is thus
simulated.
It is sometimes necessary to have stricter control over the
software execution. The "pause" function works when the software
is running, but pauses only a certain amount of seconds in real
time. Because the EDU systems can run much slower than real time, it
is sometimes difficult to know how long to pause. A more precise
method of creating the "pre" condition, but a method which
is more cumbersome to use, is as follows:
METHOD 2:
---------
$sut.break; -- This stops the software from executing
$set_pre_parameter ("true");
$sut.mstep(#); -- # refers to number of SW frames.
-- # must be great enough for the SW to
-- update the variable.
parameter := false;
$sut.mstep (#);
$sut.resume;
In most cases, method 1 is preferable. Method 2 works well,
but takes time to execute all of the "sut." steps. When using
method 1, ensure that the pause time is great enough for use on
the EDU systems.
-----------------------------------------------------------------
CATEGORY: Requirements Interpretation
TITLE: How to test OPCs
NUMBER: CDS_0016
-----------------------------------------------------------------
Example:
if OPC_CHEVRON_AP.g
then
Display the Chevron Airplane Symbol
else
Display the Standard Airplane Symbol
endif
Description:
Requirement variables of the type "OPC_...." require special
consideration. Most variables are tested simply by setting
:= TRUE and FALSE inside the TDF. This is not
possible for the OPC variables. The displays which are
controlled by the OPCs are designed to change only at
powerup. No display change will occur if the OPC variable is
set without going through the powerup routines.
Solution:
The OPC problem is solved using the following:
1) Use "set_" functions to set the OPC inside the TDF
$ set_OPC_CHEVRON_AP_G(true); | |X....|.....|
$ set_OPC_CHEVRON_AP_G(false); | |.X...|.....|
2) Define OPC "set_" functions in the main area setup
include file - npd_setup.inc, ppd_setup.inc,
epd_setup.inc, or bpd_setup.inc.
DEFINE FUNCTION set_OPC_CHEVRON_AP
(value : IN BOOLEAN) RETURN CHAR IS
-- --------------------------------------------------
--
-- Traceability : v05_airplane_symbol
-- DSS Volume - 5, Section - 3.10.2
--
-- This function sets OPC_CHEVRON_AP. Since the OPCs
-- are updated only on powerup initializations, a
-- powerup is simulated after the OPC is set.
--
-- value : true, false
--
BEGIN
OPC_CHEVRON_AP.g := value;
run_powerup_initialize;
RETURN;
END;
3) Define the Powerup Initialize Routine in the main project
include file dws_setup.inc
DEFINE FUNCTION run_powerup_initialize ()
RETURN CHAR IS
-- ----------------------------------------------
--
-- Traceability: none
--
-- This routine sets a driver variable which will force
-- the code to undergo powerup routines. Running this
-- function DOES NOT reinitialize the OPCs. Thus, OPCs
-- are set to desired values, then this function is
-- run.
--
BEGIN
POWERUP_INITIALIZE.i := TRUE;
RETURN;
END;
NOTE: A similar function should be defined
run_powerup_initialize_opc. This function will
use POWERUP_INITIALIZE_OPC.I. The function
will cause the driver to initialize everything,
including the OPCs.
4) Add correlations to the area correlation files
ppd_corr.ct, npd_corr.ct, epd_corr.ct, and bpd_corr.ct
POWERUP_INITIALIZE.i 1
DWS_VAR.DRV_DPKG_INITIALIZE.DATA
POWERUP_INITIALIZE_OPC.i 1
DWS_VAR.DRV_DPKG_INITIALIZE_OPC.DATA
5) Add definitions to the area definition files
ppd_def.ct, npd_def.ct, epd_def.ct, and bpd_def.ct
define packet DRV_DPKG_INITIALIZE bus DWS_VAR freq 20
size 1 is
begin
DATA 0:31..0:31 DISCRETE;
end;
define packet DRV_DPKG_INITIALIZE_OPC bus DWS_VAR freq 20
size 1 is
begin
DATA 0:31..0:31 DISCRETE;
end;
-----------------------------------------------------------------
CATEGORY: Requirements Interpretation
TITLE: How to test Compact Mode
NUMBER: CDS_0017
-----------------------------------------------------------------
Example:
if COMPACTED_MODE.g
then
Display symbol in small characters
else
Display symbol in medium characters
endif
Description:
The EFIS compact mode controlled by the variable
COMPACTED_MODE.g is an EFIS display modes just like the
primary and the secondary EFIS displays. The display of the
different modes is controlled by the driver. A function is
required to change the modes using logic found in the driver.
Solution:
Set different display modes using the following:
1) Use "set_" functions to set the mode inside the TDF
$ set_display_mode("compact"); | |X.....|.....|
$ set_display_mode("efis primary"); | |.X....|.....|
These two TDF lines set the display to compact mode, then
back to the efis primary display mode.
2) Define the set function in the project include file
dws_setup.inc
DEFINE FUNCTION set_display_mode
(mode : IN STRING) RETURN CHAR IS
-- ------------------------------------------------------
--
-- Traceability : none
--
-- This function sets the display mode using logic found
-- in the driver file (b737_np_driver.ada).
--
-- mode : efis primary, efis secondary, engines, compact
IF mode = "efis primary" THEN
DISPLAY_FORMAT.i := EFIS_PRI_CAPT;
ENDIF;
IF mode = "efis secondary" THEN
DISPLAY_FORMAT.i := EFIS_SEC_CAPT;
ENDIF;
IF mode = "engines" THEN
DISPLAY_FORMAT.i := ENGINES;
ENDIF;
IF mode = "compact" THEN
DISPLAY_FORMAT.i := EFIS_COMP_CAPT;
ENDIF;
RETURN;
END;
3) Correlate DISPLAY_FORMAT.i in the area correlation files
ppd_corr.ct, npd_corr.ct, and epd_corr.ct.
DISPLAY_FORMAT.i 1 DWS_VAR.DRV_DPKG_FORMAT_1.DATA
4) Define the bus definition for DISPLAY_FORMAT.i in the
area bus define files ppd_def.bd, npd_def.bd,
and epd_def.bd.
(The following definition is similar to du_fmt_type in
the software package CTL_RDM_FM_FORMAT_ID_TPKG_.ADA)
define packet DRV_DPKG_FORMAT_1 bus DWS_VAR freq 20
size 1 is
begin
DATA 0:24..0:31 (BACKLITE_OFF,
FAIL_BLANK,
DISP1_BLANK,
EFIS_PRI_CAPT,
EFIS_PRI_FO,
EFIS_SEC_CAPT,
EFIS_SEC_FO,
EFIS_COMP_CAPT,
EFIS_COMP_FO,
ENGINES,
PFD_CAPT,
PFD_FO,
EICAS_ENG_PRI,
EICAS_ENG_COMP,
EICAS_ENG_SEC,
BITE_INTERACTIVE_TEST_1,
BITE_INTERACTIVE_TEST_2,
BITE_INTERACTIVE_TEST_3,
MFD_BLANK,
MFD_AIR,
MFD_CONFIG,
MFD_CONSEQ,
MFD_ELEC,
MFD_FUEL,
MFD_HYD,
MFD_MISC,
MFD_STATUS,
ND_CAPT,
ND_FO,
ND_UNAVAIL
);
end;
-----------------------------------------------------------------
CATEGORY: Bus Definitions
TITLE: BNR Bus Definitions
NUMBER: CDS_0018
-----------------------------------------------------------------
Example:
In the Code:
Oil_Press_Lo_Red_Lmt_EEC_R : IO_Common_TPKG.S0_Record_Type;
-- Scale+0 Type
type S0_Record_Type is record
Data : Disp_Common_TPkg.S0_Type;
Stat : Disp_Common_TPkg.Status_Type;
end record;
for S0_Record_Type use record
Data at 0 range 0..27;
Stat at 0 range 28..31;
end record;
GROUND_SPEED_IRU : IO_Common_Tpkg.S3_Record_Type;
Wind_Direction_IRU : IO_Common_Tpkg.SFF_28_Record_Type;
BARO_ALTITIUDE : array (IO_Common_Tpkg.Capt_Fo_Type) of
IO_Common_Tpkg.SN2_Record_Type;
Description:
The examples show data type definitions for variables in
software. In order for tests to be able to "talk" to the
software, the tests must must define the data type of the
variables in SSL the same as the data type in the code. The
data typing in SSL is done using bus definitions.
Summary:
For types Sx_RECORD_TYPE or LSx_RECORD TYPE:
x = S-factor
n = number of bits = 28
MAX = (1/2**x) * (2**(n-1))
= 2**(n-1-x)
LS0,S0: MAX = 2**(28-1-0)
= 2**27 or 16#8000000#
(Hex is easier to visualize!!)
LS1,S1: MAX = 2**(28-1-1)
= 2**26 or 16#4000000#
LS2,S2: MAX = 2**25 or 16#2000000#
LS3,S3: MAX = 2**24 or 16#1000000#
LSN1,SN1: MAX = 2**(28-1-(-1))
= 2**28
(DO NOT REPRESENT AS A HEX NUMBER!!)
LSN2,SN2: MAX = 2**(28-1-(-2))
= 2**29
LSN3,SN3: MAX = 2**30
SFF: MAX = 180
Solution:
Data Representation
-------------------
Observe the S0 example Oil_Press_Lo_Red_Lmt_EEC_R. It is
possible to visualize the software data as follows:
<-----------Data------------------>
| | | 11|1111|1111|2222|2222|2233|
|0123|4567|8901|2345|6789|0123|4567|8901|
Status from bits 28 to 31
Data from bits 0 to 27
In SSL, the data is visualized in an opposite manner:
<-----------Data------------------>
|3322|2222|2221|1111|1111|11 | | |
|1098|7654|3210|9876|5432|1098|7654|3210|
Status from bits 0 to 3
Data from bits 4 to 31
Record Types
------------
S0 refers to the decimal point for the data at the 0th
bit position. Thus, the least significant bit of
the data represents a value of 1.
S1 refers to the the decimal point moving to the 1st bit
position. The LSB now represents 0.5.
SN1 refers to the decimal point moving to the 2nd bit
position. The LSB will now represent 2.
SFF refers to standard fractional format. In this
representation, the data field can hold data representing
1 revolution around a circle. In SSL, we represent this
data as 360 degrees around the circle (+/- 180), more
commonly referred to as Standard Angle Format. For our
purposes, SFF = SAF.
Bus Definitions
---------------
The most important piece of information for the bus
definition for BNR variables is the MAX value. The MAX
value tells SSL the scaling of the variable. For example:
DATA 0..3 BNR MAX 8
This part of the bus definition tells SSL that there
are 8 possible positive numbers and 8 possible negative
numbers.
Since there are only 4 bits in the DATA field
(n=4), and since the most significant bit for BNR data
is the sign bit, the remaining 3 bits can represent
2**3 possible combinations. The value of the LSB
is thus:
For DATA 0..3 BNR MAX 8
LSB = MAX/2**(n-1) MAX = LSB * (2**(n-1))
= 8/2**3 = 1 * 2**3
= 1 = 8
For DATA 0..3 BNR MAX 4:
LSB = MAX/2**(n-1) MAX = LSB * (2**(n-1))
= 4/2**3 = 0.5 * 2**3
= 0.5 = 4
For DATA 0..3 BNR MAX 16
LSB = MAX/2**(n-1) MAX = LSB * (2**(n-1))
= 16/2**3 = 2 * 2**3
= 2 = 16
NOTE: The MAX is equivalent to an UNSIGNED value which
occurs if you set the most significant bit to 1
and the rest of the bits to 0. The physical
maximum for 3 bits is 7 (111), but there are
a total of 8 possible numbers, 0 through 7. To
obtain the correct scaling, the MAX must be
the physical MAX plus the value of 1 LSB!
SSL MAX = Physical MAX + 1 LSB
The same concepts illustrated above are used to define
the buses for the examples - S0,S3,SN2,SFF.
LS0,S0: x = S factor = 0; LSB = 1/2**x
= 1
n = number of data bits = 28; MAX = LSB * (2**(n-1))
= 1 * 2**27
The data is contained in bit 4 through 31, with an
LSB = 1 (the decimal point is at bit 0).
There are 28 bits in the data field. The easiest
way to set the max is to set the MSB = 1, and all
other bits to 0.
<-----------Data------------------>
|3322|2222|2221|1111|1111|11 | | |
|1098|7654|3210|9876|5432|1098|7654|3210|
decimal point ----->.
binary 1000 0000 0000 0000 0000 0000 0000
hex 8 0 0 0 0 0 0
define packet Oil_Press_Lo_Red_Lmt_EEC_R bus DWS_VAR
freq 20 size 1 is
begin
STATUS 0:0..0:3 DISCRETE INIT 4;
DATA 0:4..0:31 BNR MAX 16#8000000#;
end;
LS1,S1: (x = S factor = 1; LSB = 1/2**x = 1/2**1
n = number of data bits = 28; MAX = LSB * (2**(n-1))
= 2**(-1) * 2**27
= 2**26
<-----------Data------------------------->
|332 2|222 2|222 1|111 1|111 1|11 | | |
|109 8|765 4|321 0|987 6|543 2|109 8|765 4|3210|
binary 100|0 000|0 000|0 000|0 000|0 000|0 000.0
hex 4 0 0 0 0 0 0
define packet xxxx bus DWS_VAR
freq 20 size 1 is
begin
STATUS 0:0..0:3 DISCRETE INIT 4;
DATA 0:4..0:31 BNR MAX 16#4000000#;
end;
LS3,S3: (x = S factor = 1; LSB = 1/2**x = 1/2**3
n = number of data bits = 28; MAX = LSB * (2**(n-1))
= 2**(-3) * 2**27
= 2**24
<-----------Data------------------------->
|3 322|2 222|2 221|1 111|1 111|1 1 | | |
|1 098|7 654|3 210|9 876|5 432|1 098|7 654|3210|
decimal point ----->.
binary 1|000 0|000 0|000 0|000 0|000 0|000 0.000
hex 1 0 0 0 0 0 0
define packet GROUND_SPEED_IRU bus DWS_VAR
freq 20 size 1 is
begin
STATUS 0:0..0:3 DISCRETE INIT 4;
DATA 0:4..0:31 BNR MAX 16#1000000#;
end;
LSN2,SN2: (x = S factor = -2; LSB = 1/2**x = 1/2**(-2)
n = number of data bits = 28; MAX = LSB * (2**(n-1))
= 2**2 * 2**27
= 2**29
<-----------Data------------------------->
|33 22|22 22|22 21|11 11|11 11|11 | | |
|10 98|76 54|32 10|98 76|54 32|10 98|76 54|xx.3210|
decimal point ----->.
binary 10|00 00|00 00|00 00|00 00|00 00|00 00|00 00
hex 2 0 0 0 0 0 0 0
define packet BARO_ALTITUDE bus DWS_VAR
freq 20 size 1 is
begin
STATUS 0:0..0:3 DISCRETE INIT 4;
DATA 0:4..0:31 BNR MAX 536870912.0; -- 16#20000000#
end;
NOTE: You must represent this as a real number, not as a
HEX number. SSL will crash if you try to represent
a HEX number which is greater than the 2**(n-1).
The HEX number used as a comment helps make it
easier to visualize the MAX.
SFF,SAF:
The MAX equals 180 by definition. Possible values are
+/- 180.
define packet WIND_DIRECTION bus DWS_VAR
freq 20 size 1 is
begin
STATUS 0:0..0:3 DISCRETE INIT 4;
DATA 0:4..0:31 BNR MAX 180
end;
-----------------------------------------------------------------
CATEGORY: Bus Definitions
TITLE: Encoded Bus Definitions
NUMBER: CDS_0019
-----------------------------------------------------------------
Example 1:
type Color_Type is ( Red, Blue, Green, Yellow, Orange, Black ,
White , Purple , Brown );
Hair_Color : Color_Type;
Example 2:
In the Code:
type Nav_Mode_Type is (INVALID, EXP_MAP, CNTR_MAP, EXP_VOR,
CNTR_VOR, EXP_APPR, CNTR_APPR, PLAN);
type Status_Type is ( NPR, INVALID, NCD, TEST , VALID );
type Nav_Mode_Record_Type is
record
Status : Status_Type;
Data : Nav_Mode_Type;
end record;
for Nav_Mode_Record_Type use
record
Status at 0 range 28 .. 31;
Data at 0 range 0 .. 27;
end record;
type Capt_FO_Array_Nav_Mode_Type is
array ( Capt, FO ) of NAV_Mode_Record_Type;
Nav_Mode : Capt_FO_Array_Nav_Mode_Type;
Description:
A standard method is used to define encoded variables in the
bus defininitions. The standard method will make the bus
definitions and the TDFs more readable.
Summary:
A standard bus definition for an encoded variable would look
something like the following:
define packet bus DWS_VAR freq 20 size 1 is
begin
DATA 0:x..0:y (encoded_value_1, value_2, ... , value_n) ;
end;
Example 1:
define packet HAIR_COLOR bus DWS_VAR freq 20 size 1 is
begin
DATA 0:0..0:31 ( Red, Blue, Green, Yellow, Orange, Black ,
White , Purple , Brown );
end;
Example 2:
define packet NAV_MODE bus DWS_VAR freq 20 size 2 is
begin
CAPT_STAT 0:0..0:3 (NPR,INVALID,NCD,TEST,VALID);
CAPT_DATA 0:4..0:31 (INVALID, EXP_MAP, CNTR_MAP, EXP_VOR,
CNTR_VOR, EXP_APPR, CNTR_APPR, PLAN);
FO_STAT 0:0..0:3 (NPR,INVALID,NCD,TEST,VALID);
FO_DATA 0:4..0:31 (INVALID, EXP_MAP, CNTR_MAP, EXP_VOR,
CNTR_VOR, EXP_APPR, CNTR_APPR, PLAN);
end;
Solution:
Previous bus defines would define the encoded section of the
parameter as DISCRETE:
define packet HAIR_COLOR bus DWS_VAR freq 20 size 1 is
begin
DATA 0:0..0:31 DISCRETE;
end;
A TDF would then use something like:
hair_color.i := 1| |X....|.....|.....|
The following would make the TDF more readable:
hair_color.i := RED| |X....|.....|.....|
In order to utilize "RED", the value for RED must be
defined either using the SSL " : ",
or defined in the bus definition. The better
method, the one used above, defines the encoded values
within the bus definition.
NOTE: The TDF line
hair_color.i := 1| |X....|.....|.....|
will still work, even with the new bus definition format.
The new format will allow the creation of more readable TDFs.
-----------------------------------------------------------------
CATEGORY: TDF Functions
TITLE: Frame level execution control of SUT for testing
NUMBER: CDS_0020
-----------------------------------------------------------------
There may be occasions when we require frame level control.
The following is an example to achieve this.
(The aim is to have a better method of using SUT.BREAK, SUT.STEP)
Let us assume there is a DSS requirement as follows :
if (PRE.sta.Heading <> test) and sta.Heading = test
HEADING_IN_TEST.t = TRUE
else
HEADING_IN_TEST.t = FALSE
endif
if (HEADING_IN_TEST.t = TRUE) then
HEALTH_OUTPUT.I = FALSE
else
HEALTH_OUTPUT.I = TRUE
endif
* Let us assume that we are able to correlate HEALTH_OUTPUT.I and
verify its O/P
* To test HEALTH_OUTPUT.I = FALSE, it is required to set
HEADING_IN_TEST.t=TRUE.
* Looking at the above logic, to set HEADING_IN_TEST.t = TRUE, we
may do some thing as follows
sta.HEADING = VALID;
pause(2); -- So that PRE gets set to VALID
sta.HEADING = TEST;
* This method, though it ensures that HEADING_IN_TEST.t = TRUE as
well as HEALTH_OUTPUT.I = FALSE, THIS HAPPENS DURING THE FIRST
PASS THROUGH this section of the code ( The first pass after the
values have been set). In the very next frame the settings will
change to HEADING_IN_TEST.t = FALSE and HEALTH_OUTPUT.I = TRUE.
* Since trying to check the output(HEALTH_OUTPUT.I= FALSE) in the
TCM matrix is not likely to give us the desired results, it is
imperative to find a method to do a frame level control.
* Given this situation the most obvious thing is to use SUT.BREAK,
SUT.STEP and SUT.RESUME
* Let us look at the disadvantage of SUT.STEP in the following
statements
sta.HEADING = VALID;
pause(2); -- So that PRE gets set to VALID
sut.break;
sta.HEADING = TEST;
sut.step;
* By the above set of statements our belief would be that sta.HEADING
would have got set to TEST and the execution through the code would
have resulted in HEALTH_OUTPUT.I = FALSE.
* More often than not, the above mechanism WILL NOT PRODUCE the desired
result.
* (It may be pertinent to note that the updation of values by SSLI with
SUT.STEP depends on the FREQUENCY given in bus definitions for which
we generally have a default of 20)
* Also trying to use SUT.MSTEP may be like trying to grope in the dark
as the number of MSTEPS to be given is a guesswork and cannot be
ensured
to give correct results always on the same DWS_SYSTEM let alone the
other DWS_SYSTEMS.
HENCE we need to find an alternative method and the following is the
suggestion
* First look at the processing rate mentioned for the Logic
* Choose a variable (other than the ones in the purview) such that
* It is updated at the SAME PROCESSING RATE
* It can be correlated to check its value thru SSLI
* It does not get affected by the current logic
* For the current problem let me assume, I have a variable
CAPTAINS_DISPLAYS.I
* The following are the sequence of steps that will be required to
be done for a single FRAME execution control.
Set_Current_Format(EFIS_PRI_CAPT); -- IMPORTANT: Sets
CAPTAINS_DISPLAYS.I = FALSE
sta.HEADING = VALID;
pause(2); -- So that PRE gets set to VALID
sut.break;
Set_Current_Format(EFIS_SEC_CAPT);-- IMPORTANT: WOULD Set
CAPTAINS_DISPLAYS.I= TRUE
sta.HEADING = TEST;
----------- Put these lines in a function --------------
LOOP
sut.step;
EXIT WHEN ( CAPTAINS_DISPLAYS.I = TRUE );
END LOOP;
--------------------------------------------------------
Verify_HEALTH_OUTPUT_I ( TRUE );
Sut.resume;
NOTE : The following points may be borne in mind.
1. If it is possible to observe the variable like HEADING_IN_TEST.t,
choose that as a first preference.
2. There may be situations where HEADING_IN_TEST.t may be combined with
other variables with an AND condition. These other variables may have
a time-delay associated with. Such of those variables having the
longest
time-delay must be chosen as the second preference.
3. If there just no other variables, then the LOOP can be designed to
observe
the transition in output values and put suitable statements to the
report
file. LOOK-OUT : The code may have problems and may not set the
output
variable. To exit out of such situations have a counter that will
anyway
exit after some 50 SUT.STEPS or so.
-----------------------------------------------------------------
CATEGORY: TDF Functions
TITLE: Handling float variables
NUMBER: CDS_0021
-----------------------------------------------------------------
If you encounter variables that are declared as float in the code,
then it is not possible to assign or observe the values directly,
instead you need to make use of a Hex value in the matrix.
NOTE : When observing the values as outputs, the determined Hex
value may not exactly match the value as the mantissa is
chopped for the number of digits. So comparison may be done
using some tolerance as x ~ 1.
Steps :
RV = Required Value, HV = Hex Value
1. If the RV = 0, then HV = 0
2. If the RV < 0, then follow these steps
a) Keep multiplying the RV by 2^n (where n is a number)
b) Stop the multiplication at the moment when number becomes
1.xxxx
c) Keep a note of the value of n
d) Determine the binary equivalent for xxxx ( ignoring 1 and
the decimal )
c) This value spans the bits 0 to 22
d) Determine exp = 127 - n. Represent exp in Binary for bits
23 to 30
e) Determine the Hex equivalent for the entire word
The result of step 'e' gives HV that will be used in the Matrix
Ex : -> RV = 0.02
-> 1.28 = 0.02 x 2 ^ 6, where xxxx = 28 and n = 6
-> exp = 121
-> Bits 0 to 22 = 11100 , Bits 23 to 30 = 01111001
-> HV = 16#3C80001C#
3. If the RV > 0, then follow these steps
a) Keep dividing the RV by 2^n (where n is a number)
b) Stop the division at the moment when number becomes 1.xxxx
c) Keep a note of the value of n
d) Determine the binary equivalent for xxxx (ignoring 1 and
the decimal)
c) This value spans the bits 0 to 22
d) Determine exp = 127 + n. Represent exp in Binary for bits
23 to 30
e) Determine the Hex equivalent for the entire word
The result of step 'e' gives HV that will be used in the Matrix
Ex : -> RV = 99.84
-> 1.56 = 99.84 / 2 ^ 6, where xxxx = 56 and n = 6
-> exp = 133
-> Bits 0 to 22 = 111000 , Bits 23 to 30 = 010000101
-> HV = 16#42800038#
-----------------------------------------------------------------
CATEGORY: Init_ Functions
TITLE: Having two init conditions for a test
NUMBER: CDS_0022
-----------------------------------------------------------------
The Test Development Guidelines, p. 7-13, indicate that every test
case must be initialized to a known condition. In addition to this,
the initialization of each test case should produce a display or
value which is different than the test case's display or value.
It is not the intent of the requirement to have all test cases
initialized to the same value, but rather that all test cases are
initialized to a known value which is different than the tested
value. In general, it is sufficient to initialize all test cases to
the same value (for example, setting the airspeed display to 136 knots
because none of the test cases test for 137 knots). However, in
cases, where there may only be 2 possibilities for an output, the
initialization should be different for different test cases. If a
boolean is TESTED to be false as the output, it should be set true
on initialization. If it is supposed to be true on the output, it
should be set false on initialization. We have examples of this on
777, where the initialize function looked something like:
init_display (true)
init_display (false)
DWS TIPS
The software test in question is run on the displays workstation
(DWS) and is not necessarily a "system test". This may just be a
matter of symantics, but let me briefly explain the difference. On
the DWS, we organize our tests by individual requirements sections.
Our software tests are pseudo "module" level tests, where we focus on
single requirement in an attempt to verify that the software is acting
properly. On the DWS, we are able to isolate on individual PFD
functions because our DWS software builds do not contain all of the
737-800 functionality. Our software tests are not meant to be
"end-to-end" tests, since at the DWS level, we do not have all the
737-800 software running in our builds. We rely on system tests (a
different group of tests) to accomplish the end-to-end systems tests.
DWS TIPS
This note concerns the question about creating more meaningful
comments in the report file for multiple condition tests. As you are
well aware, we have put a large amount of time and effort into creating
the multiple condition comments section of the TDF. These multiple
condition comments are our best attempt at describing our test design.
The comments give us a straightforward and REPEATABLE method of
designing tests for multiple condition requirements. Our multiple
condition testing process can be used to test simple logic containing
only 2 or 3 variables as well as very complex logic containing 20 or
more variables.
One of the main reasons we created the multiple condition comments
was to avoid test case descriptions which look like the following:
A. Test Display logic
sta.ADIRS_CAS = valid
ADIRS_CAS > 100
sta.ALT_BARO_CORR = valid
ALT_BARO_CORR > 10,000
This type of comment works well for 2 or 3 variables, but becomes very
cumbersome when we have very complex combinational logic containing many
variables. Even just listing the toggled variable can be confusing,
especially if the variable is used in the logic many times. Consider
the following combinational logic (letters have replaced the actual
variable names):
if A > 100 then
if (B = b1 and a > 500) then
if D and E and F and G then
(1)
else
(2)
endif
else
if (B = b2 and c = c1) and
(a > 200) then
if H and I then
(3)
else
(4)
endif
else
(5)
endif
endif
else
if A < 50 then
if (C = c1 and B = b1) then
if J and K and L and M then
(6)
else
(7)
endif
else
if (C = c2 and a < 25) or *******
[ (B = b2 and c = c3)
(d + e) > 100 ] then
if N and O and P then
(8)
else
(9)
endif
else
(10)
endif
endif
else
(11)
endif
endif
Let's say for example we are toggling the a < 25 variable in the line
which contains ******. How would we go about creating a set of comments
for a test case description for this test? Perhaps we could try
something like this:
A. c = c2, a < 25, b = b2, c <> c3, d+e > 100, n = true,
o = true, p = true
Realizing that we would be using variables names instead of the letters
given above, we have just created a very cumbersome test case
description, a description which we attempt to avoid by using the
multiple condition comments. The multiple condition comments offer a
short hand notation which readily shows which variable is being tested.
We want to avoid creating large test case descriptions for each test
case.
Remember, we are trying to create a process which is applicable to
ALL of our multiple condition testing. Therefore, we DO NOT want to
start filling in individual comments for each test case in the multiple
condition tests. In my experience, these comments soon become very
confusing, especially for complex logic. We have created the multiple
condition test comments to avoid this confusion.
So, what are we to do concerning commenting each of our test cases?
We are currently producing report files which say something like the
following:
A. Test display logic (See comments section of the TDF)
We then have 20 or so test cases which contain this same comment. Is
this confusing? What options do we have.
1) Add comments to each test case.
I strongly suggest that we DO NOT do this. Our short hand multiple
condition comments are meant to avoid this.
2) Add the multiple condition comments section to the report file.
We started doing this in the beginning of the 777 program. It soon
became apparant that we were filling the report file up with a lot of
additional lines of explanation. The report file was becoming difficult
to quickly scan. Adding the comments for a 2 or 3 variable multiple
condition worked O.K., but when we had 20 or 30 variables, .......
The report files were more difficult to read with all the extra
stuff in them.
3) Continue doing things the way we are now doing them
I would unfortunately consider this our best option. Remember, the
TDF is a configured test artifact. Our multiple condition comments are
configured. If there is an error in a test which tests the multiple
condition logic, we can look at the test description and see that it
says "see comments section of TDF". Since the TDF is configured, we
can look at the TDF for more information.
Test Display logic
Variable Tested True Condition Abbreviation
----------------------- -------------------- ------------
sta.MARKER_BEACON.e <> npr A
sta.DISC_350_VOR.e = npr B
MARKER_BEACON_STATUS TRUE C
MARKER_BEACON.e ENCODED D
Logic Tested Output
-------------- ------------
if A and (B or not.C) then
if D = 1 then
(1) (1)
else
if D = (2 or 3) then
(2) (2)
else
if D = (4 or 5 or 6) then
(3) (3)
else
if D = 7 then
(4) (4)
else
(5) (5)
endif
endif
endif
endif
else
(6) (6)
endif
A B C D Var Tested O/p Test # Notes
---- ---- ---- ---- ----------- ----- ------ --------
0 0 0 0 All zeros (6) etc. etc.
1 1 1 1 All 1s (1)
0 1 X(0) X(1) A = 0 (6)
1 1 X(0) X(1) A = 1 (1)
1 0 1 X(1) B = 0 (6)
1 1 1 X(1) B = 1 (1)
1 0 0 X(1) C = 0 (1)
1 0 1 X(1) C = 1 (6)
1 1 X(0) 0 D = 0 (5)
1 1 X(0) 1 D = 1 (1)
1 1 X(0) 2 D = 2 (2)
1 1 X(0) 3 D = 3 (2)
1 1 X(0) 4 D = 4 (3)
1 1 X(0) 5 D = 5 (3)
1 1 X(0) 6 D = 6 (3)
1 1 X(0) 7 D = 7 (4)
We could either use this description for all tests in the multiple
condition or, better, use this description only for the first test and
use the following for the rest of the tests:
back
