DOCUMENT INSTRUCTION

1 (25)

EIN/T/R M. Blix EINMABX

1013-CAA 139 1138

EIN/T/DC (Torsten Nordholm)

EINBOSI

2000-04-03

G

Uppgjord — Prepared

Faktaansvarig — Subject responsible

Nr — No.

Dokansv/Godk — Doc respons/Approved

Kontr — Checked

Datum — Date

Rev

File

E

BASIC TEST INSTRUCTION - BTI Driver

Enclosures

1. PLEX BTI example - 1/1013-CAA 139 1138
2. HLPLEX BTI example - 2/1013-CAA 139 1138

Contents

Page

1

REVISION INFORMATION

2

2

APPLICATION

2

3

PURPOSE OF THIS DOCUMENT INSTRUCTION (DI)

2

4

BASIC TEST INSTRUCTION (BTI)

2

4.1

Purpose of a BTI

3

4.2

Users of a BTI

3

4.3

Identification of a BTI

3

4.4

Contents of a BTI

5

4.5

Writing a BTI

6

4.5.1

1 Introduction

6

5

ABBREVIATIONS

24

6

TERMINOLOGY

25

7

REFERENCES

25

DOCUMENT INSTRUCTION

2 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

1

REVISION INFORMATION

This document replaces the following documents:

•

BASIC TEST INSTRUCTION-BTIDRIVER (BTI) -
TX/DK- 92:267 Uen.

•

BASIC TEST INSTRUCTION-BTIDRIVER (BTI for HLPLEX) -
TX/DK- 94:501 Uen.

Table 1

Revision History

Rev

Date

IR

A

95-05-17

TX/DK- 95:177 Uen

B

95-06-01

TX/DK- 95:221 Uen

C

96-03-28

DTD converted to
EDML/GT 2/FAD 102
8609 R3//EN

D

96-08-21

Added wildcards
description to Expected
IO. UAB/K/T - 96:171

E

97-04-04

Removed Abranch info

F

99-01-13

Support for SEND
command. Changes
in S command (WITH
added). Changes made
in Expected IO: [ I/O
dev.].

G

2000-04-03

Support for CHECK
BUF command in PLEX
BTI.

2

APPLICATION

This Document Instruction applies to new Basic Test Instructions written for the
BTI Driver for all AXE 10 design and test departments.

3

PURPOSE OF THIS DOCUMENT INSTRUCTION (DI)

This DI defines the structure and contents of a Basic Test Instruction (BTI) for
the APZ Emulator. This DI also defines the syntax for the BTI keywords.

4

BASIC TEST INSTRUCTION (BTI)

The Basic Test Instruction (BTI) shall be written in EDML.

DOCUMENT INSTRUCTION

3 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

4.1

Purpose of a BTI

The purpose of a BTI is to:

•

Support a Basic Test method that tests the function and logic of
a single program automatically and that can be reused to speed
up and secure a complete regression test.

•

Lift Basic Test to a higher abstraction level.

•

Support the performance of Basic Test according to the method
described in the process description CP SW Unit Design and
Basic Test.

4.2

Users of a BTI

Those who need information and guidelines from the BTI DI are:

•

The person responsible for the block.

•

Basic testers.

•

Basic Test leaders.

•

Function/SMT Testers.

4.3

Identification of a BTI

The document head should contain the following information:

Document type:

The corresponding tag is called ’docname’. Enter the document
type BASIC TEST INSTRUCTION in capital letters.

Prepared:

The corresponding tag is called ’prep’. Enter your company code
and office code, separated by a ’/’, and your registered initials.

Example: ETX/TX/DZ ADS

Subject responsible:

The corresponding tag is called ’subresp’.
This field is not always used.
If used, enter the company code and office code, separated
by a ’/’.

Example: ETX/TX/DZ

Note: The field is entered only when:

DOCUMENT INSTRUCTION

4 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

•

A person other than the document’s author is to
be consulted on the contents of the document

•

The office providing the data is not subordinate to
the approving office

No:

The corresponding tag is called ’docno’.
Enter the document number, which must have the format:
<n>/1521-<ABC> <p> <language notation>
where
<n> is the prefix
<ABC> is the ABC class, CAA
<p> is the type and sequence number (107 XXXX for PLEX,
152 XXXX for HLPLEX).
<language notation> is the language in which the document
is written.

Example: 1/1521-CAA 107 1111 Uen

1/1521-CAA 152 2222 Uen

Doc respons/Approved:

The corresponding tag is called ’appr’.
Enter a dash ’-’ until the document has been approved. The
company code and office code of the final documentation office
is entered here. The manager of this office signs (name) with a
color pen, on the hard copy of the document, to prove it is a
valid document. On a computer-stored document, the name
is specified within brackets to indicate that the document has
been signed.

Example: ETX/TX/DZ (L. Jansson)

Checked:

Enter a ’-’ until the document has been technically approved.
The document is technically approved by the line organization
group supervisor, who signs his/her initials in hand-writing
on the hard copy of the document. On a computer-stored
document, the registered initials are specified to indicate that
the document has been signed.

Example: ETXJMN

Date:

Enter the date in the order yyyy-mm-dd. The date on the
document is the date when the document was last modified.

Example: 1994-06-21

DOCUMENT INSTRUCTION

5 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Rev:

The corresponding tag is called ’rev’.
The letter defines the revision state of the document. Begin
with A for a new document. Use capital letters A ... Z, AA ...
ZZ, except I, O, P, Q, R, U and W. A document change that
affects the factual contents must be indicated by a stepped
revision letter. For other changes, the revision letter should
not be altered.

Example: C is stepped to D, AB is stepped to AC.

A preliminary document is denoted by a ’P’ before the revision
letter, and a numeral, indicating the sequence number, after the
revision letter. If a preliminary document must be revised, the
sequence number is stepped.

Example: PA1 is stepped to PA2.

When approved, the document gets a full-letter revision.

Example: PB4 becomes B.

Title:

Enter the title of the BTI. Use capital letters. Do not use more
than 60 characters in the title if you can avoid it.

Example: BLOCK BASSC, DYNAMIC OUTGOING/INCOMING
B-CHANNEL ASSIGNMENT

Write required supplementary information on the next line,
in lower-case letters.

4.4

Contents of a BTI

All Basic Test Instructions for the APZ Emulator are to have a uniform structure
and layout.

A BTI has the following contents:

1

INTRODUCTION

1.1

Prerequisites

1.2

Scope

1.3

References

1.4

Definition of Macros

2

TEST DESIGN

2.1

<Headline for Test Case 1>

DOCUMENT INSTRUCTION

6 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

2.1.1

<Heading for Subtest 1>

2.1.n

<Heading for Subtest n>

2.2

<Headline for Test Case 2>

2.2.1

<Heading for Subtest 1>

2.2.n

<Heading for Subtest n>

2.n

<Headline for the Test Case n>

4.5

Writing a BTI

This section explains how to write a Basic Test Instruction. It defines the
headings and numberings to be used. Under each heading, there is an
explanation of what the specific heading is to comprise.

4.5.1

1 Introduction

Specify name, revision and amendment level of the tested block.

4.5.1.1

1.1 Prerequisites

Describe the following prerequisites for your BTI:

•

Tools used to generate the Basic Test Instruction.

•

The version of the APZ Emulator.

•

All blocks involved; include block names, block references,
prefixes, product id, suffixes and revision status of these
blocks, for example:

ET3 ( 825) 2360/CAA 107 5060/A45E R3A03
DUMMY (1023) 2000/CAA 107 9998/A10E A

•

Identity and revision of the System and Application files
(HLPLEX).

4.5.1.2

1.2 Scope

This should contain:

•

A short summary of the scope of the test.

•

A short description of what was omitted in the test if the
coverage is not complete.

4.5.1.3

1.3 References

Include documents used as input from Function and Block Design, such as:

•

Function Framework

DOCUMENT INSTRUCTION

7 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

•

Function Specification

•

Function Description

•

Function Description Flow Chart

•

Block Description

•

Block Description Flow Chart

•

Operational documents (CODs, PODs, OPIs)

4.5.1.4

1.4 Definition of Macros

Under this heading macros that can be used throughout the rest of the BTI
should be defined.

Table 2

Terminology

<..>

nonterminal

[..]

optional

|

or

{..}+

one or many

{..}*

zero or many

NL

Special terminal that stands for new line

Syntax used in macro definition

The syntax of the macro definition is:

{

:xmp.

{

Macro:$<macro name>$ = { <numeral> | <string> } { , [NL]

$<macro name>$ = { <numeral> |

<string>} }* NL

}*

:exmp.

}*

The macro definition will always start with the keyword "Macro:", followed by
the definitions. To define more than one macro, separate them by a comma
(,). After a comma, a new line may be started, as indicated by [NL]. The "NL"
shall not be written, it stands for "new line". You may also use the keyword
"Macro:" more than once to structure your macro definitions, even in different
blocks. Example:

DOCUMENT INSTRUCTION

8 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

:xmp.

Macro: $rr$= 12

Macro: $k1$= 12, $k2$=13

Macro: $p1$= "READY", $k3$= 12,

$p2$= "12,13"

:exmp.

All macro definitions must precede the first test case and be placed within

:xmp.

-

:exmp.

.

The use of macros may improve the BTI because:

•

Maintenance will be easier, for example, if the value of a macro
that has been used throughout the BTI is to be changed.

•

Readability will be increased. For example, special data of
interest will be easily separated from other data.

All macros are defined as strings or numerals and are only used for substitution
of text. The name of a macro is any combination of ( a-z, A-Z, 0-9, _ )
characters surrounded by dollar signs ($macro_name$). Upper and lower case
is not significant. The underscore character is significant.

The macro can be assigned either a string or a numeral. The numeral can
be either a decimal or hexadecimal number. Hexadecimal numbers can
be specified as "#xxxx" or "h’xxxx", where "xxxx" is up to 32 hexadecimal
digits, i.e. 128 bits.

A string is any combination of characters that is allowed in PLEX and MML
commands surrounded by quotation marks ( " ). A quotation mark in a string
must be represented by double quotation marks ( "" ). A string cannot start
on one line and continue on the next, i.e. a string cannot contain newline
characters. There is actually no difference between declaring a macro as a
numeral or string. In this example

Macro: $X1$= 17, $S1$= "17"

the effect is the same, i.e. X1 is equal to S1. Errors can be found earlier when
using a numeral value rather than a string.

Note that the macros are not recursive and the use of macros in a macro
definition section is not allowed.

Macros are expanded after keyword recognition has been made. This makes it
impossible to use macros to have constructs like:

Macro: $Funny_stuff$= "action: S CMD"
...
Purpose:
$Funny_stuff$
...

DOCUMENT INSTRUCTION

9 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

In the APZ Emulator catch functions it is required to write a ’$’ which does
not mean a macro name. This must be written as two ’$’ signs (e.g, "return
0 with $$D1").

4.5.1.5

2 Test Design

2.1

<Headline for Test Case 1>

2.1.1

<Heading for Subtest 1>

2.1.n

<Heading for Subtest n>

2.2

<Headline for Test Case 2>

2.2.1

<Heading for Subtest 1>

2.2.n

<Heading for Subtest n>

2.n

<Headline for Test Case n>

Under these headings the test cases are defined. Each test consists of one or
more subtests.

Sub headings (for example: 2.1, 2.2, .., 3.1, 3.2, .. etc.) are to be used to
structure the BTI. The BTI format does not impose the use of headings.
Although not recommended, it is possible to put all test cases in one :xmp.
block.

It is recommended to place all test cases on the same chapter level, for
example,

:h3.

DOCUMENT INSTRUCTION

10 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Syntax used in test cases (PLEX BTI)

The layout of each test case is as follows below. See Enclosures 1 for an
example.

DOCUMENT INSTRUCTION

11 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

:xmp.

{

Purpose:

{ <one-line-of-text> NL }*

[ Restore:

<file-name> NL]

[ Initiate: { <emulator-cmd-except-mml-cmd> NL }+ ]

{

{

Action:

{

S <signal-name> [ WITH ] { <signal-data> }* NL

| SEND <signal-name> [BLOCK <block-name> | REFERENCE <block-reference>]

WITH { <signal-data> }* NL

| RETURN

{<signal-name> | <numeral>} [ WITH <signal-data>+ ] NL

| RESPONSE { <one-line-of-text> | <string> } NL

| <mml-command> NL

}+

}+

{

Expected sig: { <signal-name> { <numeral> | + }* NL }+

| Expected io:

{ {[ ’[’<i/o-device name>’]’ ] <one-line-of-text> |

[ ’[’<i/o-device name>’]’ ] <string> } NL }+

| Expected fileio:

{ { <one-line-of-text> | <string> } NL }+

}*

{

Check var:

<var>= { <string> | <numeral> }

{ , [NL]

<var>= { <string> | <numeral> } }* NL

| Check buf:

buf(

{ <index> [ - <index> ] }

[, <bufptr>, <width> ] )

= { <string> | {<numeral>}+ } NL

| Check size:

<id>= <numeral>

{ , [NL]

<id>= <numeral> }* NL

| Change block: <block-name> NL

}*

}*

[ Terminate: { <emulator-cmd-except-mml-cmd> NL }+ ]

[ Save: <file-name> NL ]

}*

:exmp.

DOCUMENT INSTRUCTION

12 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Syntax used in test cases (HLPLEX BTI)

The HLPLEX syntax is a superset of the PLEX syntax. The layout of each test
case is as follows below. See Enclosures 2 for an example.

:xmp.

{

Purpose:

{ <one-line-of-text> NL }*

[ Restore:

<file-name> NL]

[ Initiate: { <emulator-cmd-except-mml-cmd> NL }+ ]

{

{

Action:

{

S <signal-name> [ WITH ] { <signal-data> }*

NL

| SEND <signal-name> [BLOCK <block-name> | REFERENCE <block-reference>]

WITH { <signal-data> }* NL

| RETURN

{<signal-name> | <numeral>} [ WITH <signal-data>+ ] NL

| RESPONSE { <one-line-of-text> | <string> } NL

| <mml-command> NL

| E {<eventset-name>.}* <event-name> ( [<param-name> => <param-value>

{,<param-name> => <param-value>}*] )

ON <eventpath-name> NL

| Z <seizurecase-name> ( [<param-name> => <param-value>

{, <param-name> => <param-value>}*] )

[

RELATION (<rel> => <rel-value>)

| REFERENCE <ref-eventpath-name>

| INSTANCE ’{’ <self> , <lowfid> , <highfid> ’}’ ]

ON <eventpath-name> NL

| ZRET [ <seizurecase-name> ] ON <eventpath-name>

[ AND <eventpath-name> ] NL

| ZRETE [ <seizurecase-name> ] REASON { <id> | <numeral> } NL

| P <procedure-name> ( [<param-name> {<==|<==>|=>} <param-value>

{, <param-name> {<==|<==>|=>} <param-value>}*] ) NL

| PRET [ <procedure-name> ] ( [<param-name> {==>|<==>|=>} <param-value>

{, <param-name> {==>|<==>|=>} <param-value>}*] )

[ RETURN <param-value> ] NL

| PRETE [ <procedure-name> ] [ ( [<param-name> {==>|<==>|=>} <param-value>

{, <param-name> {==>|<==>|=>} <param-value>}*] )]

REASON { <id> | <numeral> } NL

| CLOSEEP <eventpath-name> NL

}+

}+

DOCUMENT INSTRUCTION

13 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

{

Expected sig: { <signal-name> { <numeral> | + }* NL }+

| Expected io:

{ {[ ’[’<i/o-device name>’]’ ] <one-line-of-text> |

[ ’[’<i/o-device name>’]’ ] <string> } NL }+

| Expected fileio:

{ { <one-line-of-text> | <string> } NL }+

| Expected event: { {<eventset-name>.}* <event-name>

( [<param-name> => <param-value>

{, <param-name> => <param-value>}* ] )

ON <eventpath-name> NL }+

| Expected szc: { <seizurecase-name> ( [<param-name> => <param-value>

{, <param-name> => <param-value>}*] ) NL }+

| Expected szcret:

{ <seizurecase-name> ON <eventpath-name> NL }+

| Expected szcrete: { <seizurecase-name> REASON { <id> | <numeral> }

ON <eventpath-name> NL }+

| Expected proc: { <procedure-name> ( [<param-name> {<==|<==>|=>} <param-value>

{, <param-name> {<==|<==>|=>}

<param-value>}*] ) NL }+

| Expected procret: { <procedure-name> ( [<param-name> {==>|<==>|=>} <param-value>

{, <param-name> {==>|<==>|=>} <param-value>}*]

[ RETURN <param-value> ] NL }+

| Expected procrete: { <procedure-name> REASON { <id> | <numeral> } NL }+}*

{Check var:

= {

|

}

{ , [NL]

= {

|

} }* NL

| Check size:

<id>= <numeral>

{ , [NL]

<id>= <numeral> }* NL

| Check hlpvar: <hlpvar>= { <string> | <character> | <numeral> |

<enum-id> | ’{’ <struct-member-list> ’}’ }

{ , [NL]

<hlpvar>= { <string> | <character> | <numeral> |

<enum-id> | ’{’ <struct-member-list> ’}’ } }* NL

| Check state:

[<module-name>.]<process-name> ( <instance-num> ) = <state>

{ , [NL]

[<module-name>.]<process-name> ( <instance-num> ) = <state> }* NL

| Check terminate: [<module-name>.]<process-name> ( <instance-num> ) =

{ TRUE | FALSE }

{ , [NL]

[<module-name>.]<process-name> ( <instance-num> ) =

{ TRUE | FALSE }

}* NL

| Check eventpath: <eventpath-name> = { OPEN | CLOSED }

{ , [NL] <eventpath-name> = { OPEN | CLOSED }

}* NL

| Change block: <block-name> NL

| Change AM: <application-module-name> NL

}*

}*

[ Terminate: { <emulator-cmd-except-mml-cmd> NL }+ ]

[ Save: <file-name> NL ]

}*

:exmp.

DOCUMENT INSTRUCTION

14 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Syntax explanation

The following is a brief explanation of the syntax. HLPLEX in parentheses
after the keyword indicates a HLPLEX specific keyword. For more details,
consult Reference 1.

Keywords are characterized by the fact that they end with a colon (:). They can
be written with both small and capital letters. They are recognized only if they
begin a new line, spaces are ignored. Between the keyword and the colon
there may be spaces. Also, one or more spaces between words in keywords is
possible, i.e. this is all the same keyword:

check var:

Check Var:
Check Var :

Note that keyword recognition is made before macro expansion, that is, a
macro cannot contain keywords.

The terminal NL represents a new line break and is used to explicitly state
where a line break is necessary. Besides, a line break is always necessary
before keywords.

Purpose:

This keyword is used to give a description of the test case. A
test case always starts with "Purpose:". Example blocks (:xmp.
blocks) not starting with "Purpose:" (or "Macro:") are ignored.
Note that a new "Purpose:" must be given after each "Save:"
or "Terminate:".

Restore:

This keyword is used to restore a previously saved state, see
"Save:". This may avoid long execution sequences to initialize
variables over and over again in each test case.

Initiate:

This keyword is used to initiate and prepare for a test case.

Use "Initiate:" to set up a new environment, for example the
monitor block. All APZ Emulator commands except MML
commands are possible to use here. However, the following
commands are more useful than others: B (set monitor block),
LEV (set the signal level) and dynamic buffer commands for
PLEX.

In catchsig definitions, $D1 must be written as $$D1.

One recommendation is to make sure that the monitor block is
set so that signal sending is done towards the correct block.

DOCUMENT INSTRUCTION

15 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Under "Initiate:" several commands can be specified, one
per line. Their results will not appear in "Expected sig:" or
"Expected IO:", respectively.

Do not use any APZ Emulator commands that starts the
execution.
DO NOT USE: S (start execution on a signal), START (start
execution on an address). To start the execution on a signal or
MML command, see the ’Action:’ keyword. To start execution
on an address is not allowed, because it is bad practice and it
makes the BTIs impossible to maintain.

Action:

This keyword is used to start the test case. The different
actions are:

S (send signal), keyword ’WITH’ optional,

SEND, must have keyword ’WITH’ . Keywords ’BLOCK’ and
’REFERENCE’ are optional.

The ’SEND’ command can specify a receiving block, which
removes the need for changing the block monitor before the
signal is sent.

Example of specifying a block with a block name:
SEND POPIND BLOCK LAD WITH 5

Example of specifying a block with a block reference:
SEND POPIND REFERENCE H’2304 WITH 5

RETURN (answer a combined forward signal),

RESPONSE (supply extra data to a command),

MML commands.

The following actions are HLPLEX specific actions:

E (send an event into the dump down an already open
eventpath),

Z (create a process using a seizurecase that is loaded on
the dump),

ZRET (acknowledge successful creation of a process not
loaded on the dump),

ZRETE (reject the creation of a process not loaded on the
dump),

DOCUMENT INSTRUCTION

16 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

P (initiate a call to a procedure owned by a module on the dump),

PRET (acknowledge successful call of a routine not loaded
on the dump),

PRETE (return an exception to the caller of a routine not loaded
on the dump),

CLOSEEP (close an open eventpath)

Additional description

The RETURN action is used to send the answer signal to a
combined forward signal that has no receiver in the dump.
Before this, there must be an "Expected sig:" for the forward
signal.

The RESPONSE action is used to answer questions from
the APZ Emulator, for example. The data is sent to the APZ
Emulator exactly as it is specified. There is no known example
today there this is useful.

The parameter list in PRETE is only used in case the user
must provide a parameter like ’SELF’ to tell the APZ Emulator
which process instance the exception is to be sent to. It is not
used for user parameters.

The verification of MML commands with check printout (;) will be
taken care of automatically.

Note that there is no need to give all signal data. Signal
data not given is thought of as not necessary. An undefined
value is used.

Some signals send strings as signal data, these strings will have
to be converted into signal data. Example:
A string "PASSIVE" shall be sent in as string. Remember how
strings are stored in string variables: length of string first and
then the characters in high and low order bits of the following
words. A good advice is to make a macro of the string.
The string must be padded with zero data words up to the
length specified in the signal description. This is only needed
when there are other data words after the string data. In this
example, the string is declared as 1K in the signal description,
so it occupies 6 signaldata.

Macro: $PASSIVE$ = "H’5007, H’5341, H’4953, H’4556,0,0" !
"P7 SA IS EV"

DOCUMENT INSTRUCTION

17 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

The nonterminal signal data can be any expression valid in the
APZ Emulator for the signal command. It is also possible to
separate the parameters with a comma. Example:

Action: S CMD 1 2, ^, 1:STATE(3) CINDNUM

The result from the action that can be verified are printouts
and signals without receiver in the dump. For HLPLEX, it
is also possible to verify events, seizurecases, seizurecase
returns, seizurecase exceptions, procedure/function calls,
procedure/function returns and procedure/function exceptions
without receiver.

Expected sig:

This keyword is used to specify an expected signal from an
action. Only signals that do not have a reception can be seen
as expected signals. That is, if there are several blocks in a
test object, only signals that have no receiving block can be
specified as expected.

Irrelevant data in the signal must be marked, because the order
of signal data is significant in signal transmission and signal
reception statements. This is done by inserting + on the place of
the omitted signal datum.

The only exception to this rule is data at the end of the signal
data list which can be omitted without marking them, because
such an omission does not alter the signal data order.

It is also possible to separate the parameters with a comma.

Expected IO:

This keyword is used to specify an expected printout from an
action on any desired I/O device.
If a large printout is given it is possible to specify the first part
of the printout as "Expected IO:" and skip the trailing part that
might not be interesting to verify. Only the part given will then be
verified. It is not possible to do the opposite, to leave the first
part out and then specify the trailing part as "Expected IO:".

Each line under "Expected IO:" must match the printout exactly
with spaces, tabulators and data.

Quotation mark ( " ) is used for specifying leading blanks, for
example, in tabulation. Example:

Expected io:
" IND STATE "
" 1 IDLE "

DOCUMENT INSTRUCTION

18 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Empty lines in the output are indicated with two quotation
marks ("").

It is also possible to use wildcard to skip characters that might
not be interesting to verify.
’ * ’ - matches any number of characters per line.
’ ? ’ - matches any single character.

Example:

Expected io:
TEST OF * SYSTEM
ALCODE I?SIZE ALCASE ID? ID?

instead of:

Expected io:
TEST OF ALARM SYSTEM
ALCODE I1SIZE ALCASE ID1 ID2

The escape character ’\’ makes it possible to match the
characters ’*’ and ’?’ by using the character sequences "\*" and
"\?". It is also possible to match against binary data with the
"\XX" sequence, where XX is a hexadecimal representation of
the wanted character. This is more useful in Expected FileIO
than in Expected IO. The escape character itself may be
matched with two escape characters in sequence.

The BTI Driver will accept IO printouts from any window
in the APZ Emulator, not only from CmdWin (AT-0). The
IO-device name is optional and has the following structure:
[AAAAAA-DDD], where A is any character (A..Z, a..z or 0..9)
and D is any digit (0..9). The correct number of characters
are 2 to 6 characters before ’-’ and 1 to 3 digits after ’-’ in
the IO-device name.
NOTE: The IO-device name must start with ’[’ and end with ’]’.

Example:

Expected io: [AT-1] SYSTEM RESTARTED

This will result in a check that the printout is made on AT-1. If
the IO-device is not specified the BTI Driver will accept that
the printout is made on any IO-device.

The purpose with specifying IO-device is to verify that the
printout is made on that IO-device and not elsewhere.

It can be used to test a command, where an IO parameter tells
which IO-device that a printout shall be given on.

DOCUMENT INSTRUCTION

19 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

It can also be used to verify that a spontaneous printout is
given on AT-1 which is the default receiver of these (controlled
with the devprca command).

Note that two simultaneous printouts on different IO-devices
may be mixed in the BTI Driver. To avoid that, alarm printouts,
for example, can be redirected to AT-0 with the devprca
command. The queue system in the IO handling will then
ensure that the printouts are given after each other.

Expected FileIO:

This keyword is used to specify an expected output to a FMS
file. Only write operations may be checked for, read operations
are not logged to the APZ Emulator API.
As an example, consider the task of matching some binary file
output. This will check the first four bytes:

Expected fileio: \e8\c7\d2\ab

Expected event (HLPLEX):

This keyword is used to specify an expected event from an
action. Only events that do not have a reception can be seen
as expected events; i.e. events within a test object are not to
be specified as expected.

It is not necessary to specify all parameters of the event in
the list of parameters. If a parameter is to be omitted from
comparison with an expected value, simply omit that parameter
from the list of parameters of the expected event.

Expected szc (HLPLEX):

This keyword is used to specify an expected HLPLEX
seizurecase from an action. Only seizurecases that do not
have a reception can be seen as expected seizurecases;
i.e. seizurecases within a test object are not to be specified
as expected.

It is not necessary to specify all parameters of the seizurecase
in the list of parameters. If a parameter is to be omitted from
comparison with an expected value, simply omit that parameter
from the list of parameters of the expected seizurecase.

Expected szcret (HLPLEX):

This keyword is used to specify an expected HLPLEX
seizurecase return from an action initiated by the Z command.
Only seizurecase returns that do not have a reception can be
seen as expected seizurecase returns; i.e. seizurecase returns
within a test object are not to be specified as expected.

DOCUMENT INSTRUCTION

20 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Expected szcrete (HLPLEX):

This keyword is used to specify an expected HLPLEX
seizurecase exception from an action initiated by the Z
command. Only seizurecase exceptions that do not have a
reception can be seen as expected seizurecase exceptions;
i.e. seizurecase exceptions within a test object are not to
be specified as expected.

Expected proc (HLPLEX):

This keyword is used to specify an expected HLPLEX
procedure/function call. Only procedure/function calls
that do not have a reception can be seen as expected
procedure/function calls; i.e. procedure/function calls within a
test object are not to be specified as expected.

It is not necessary to specify all parameters of the
procedure/function calls in the parameter list. If a parameter
is to be omitted from comparison with an expected value,
simply omit that parameter from the list of parameters of the
expected procedure/function call.

Expected procret (HLPLEX):

This keyword is used to specify an expected HLPLEX
procedure/function call return from an action initiated by the
P command. Only procedure/function call returns that do not
have a reception can be seen as expected procedure/function
calls returns; i.e. procedure/function call returns within a test
object are not to be specified as expected.

It is not necessary to specify all parameters of the
procedure/function call return in the parameter list. If a
parameter is to be omitted from comparison with an expected
value, simply omit that parameter from the list of parameters of
the expected procedure/function call return.

Expected procrete (HLPLEX):

This keyword is used to specify an expected HLPLEX
procedure/function exception from an action initiated by the
P command. Only procedure/function exceptions that do not
have a reception can be seen as expected procedure/function
exceptions; i.e. procedure/function exceptions within a test
object are not to be specified as expected.

Check var:

This keyword is used to check if a variable has the expected
value. Can only be specified at the end of a test case. The
nonterminal <var> can be any PLEX variable, with pointer

DOCUMENT INSTRUCTION

21 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

and index. The syntax follows the V command in the APZ
Emulator. Example:

Check var: CINDNUM= 17, 0 : STATE(3) = 42,
2-65 : STATE(4) = 1742

"Check var:" will always be verified after "Expected IO:",
"Expected sig:" etc. as the APZ Emulator must stop execution
before it is possible to read the value of a variable.

Check buf:

”Check buf:” is used to verify the value of one or more buffers.
The value of a buffer can be denoted as either a string, or
value(s). The value(s) can be either decimal or hexadecimal
(for example h’4e, or #4e).

Syntax 1:
Check buf: buf(StartIndex-EndIndex,BufPtr,Width) = values |
string
Check buf: buf(Index,BufPtr,Width) = value | string

Syntax 2 (“current” buffer is used):
Check buf: buf(StartIndex-EndIndex) = values
Check buf: buf(Index) = value

StartIndex = start index in buffer. Must be less than EndIndex.

EndIndex = end index in buffer. Must be greater than StartIndex.

Index = index in buffer.

BufPtr = buffer pointer (number), is a pointer to a buffer in the
system. The pointer is stored in a buffer variable in a user block.
The buffer that is allocated first will get a BufPtr value of 1 -
but that must be confirmed by making a test execution of the
BTI Script. The value of BufPtr is deterministic as long as
the BTI Script is executed from start, and the APZ Emulator
is restarted in between. If the buffer is allocated with the
“ALLBUF”-command in the “Initiate:”-sector of the BTI Script,
the value of BufPtr is displayed in the APZ Emulator. If the
buffer is allocated from within a Plex block, it is more difficult
to obtain the value of BufPtr. If the value of BufPtr is sent in
a signal to the BTI Script, the value can be obtained in the
“Expected sig:”-sector, when making a test execution of the BTI
Script. The “ALLBUF”-command can also be used in the APZ
Emulator to list all existing allocated buffers.

Width = logical width of buffer. Must be set to 1, 2, 4, 8 or 16.
When using strings, syntax 1 must be used - all three arguments
are necessary - and Width must be set to 8.

DOCUMENT INSTRUCTION

22 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Examples:
Check buf: buf(10) = 65
Check buf:

buf(4,9,16) = H’F6 (or #f6)
buf(5,9,16) = H’F7 (or #f7)

Check buf: buf(10,21,8) = “A”
Check buf: buf(0-2) = 65 66 67
Check buf: buf(0-2,21,8) = “ABC”

[Note: ASCII: “A” = 65, “B” = 66, “C” = 67]

"Check buf:" will always be verified after "Expected IO:",
"Expected sig:" etc. (if they are present), as the APZ Emulator
must stop executing before it is possible to read the value of a
buffer. Many more “buf()” can be used after “Check buf: buf()”,
as long as the next “buf()” starts on a new line.

The usage of ”buf()” in “Check buf: buf()” is not identical to the
usage of the “BUF”-command in the APZ Emulator, the following
restrictions are applicable for “Check buf: buf()”:
- wild cards (“*” and “?”) are not allowed.
- for example: “Check buf: buf(0-2) = 65” is not allowed, instead
“Check buf: buf(0-2) = 65 65 65” must be used.

Check size:

This keyword is used to check the size of a file. The nonterminal
<id> can be any variable name included in the file. Pointer and
index shall not be specified.

Check hlpvar (HLPLEX):

This keyword is used to verify the value of a HLPLEX variable.
The <hlpvar> is specified in the same way as in the APZ
Emulator command "HV".

See reference 1.

Exemples:
Check hlpvar: MYCARDINAL = 23
Check hlpvar: MYPROCESS(1):MYSTRUCT = { 2, IDLE,
FALSE, ’Q’ }
Check hlpvar: MYARRAY[2,3] = 1
Check hlpvar: MYFILE(4):MYVAR = 8

"Check hlpvar:" will always be verified after "Expected IO:",
"Expected sig:" etc. as the APZ Emulator must stop execution
before it is possible to read the value of a variable.

Check state (HLPLEX):

This keyword is used to check the state of a HLPLEX process.

Check terminate (HLPLEX):

DOCUMENT INSTRUCTION

23 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

This keyword is used to check that a HLPLEX process
terminates.

Check eventpath (HLPLEX):

This keyword is used to check the status of a HLPLEX
eventpath.

Change block:

This keyword is used to change monitor block. Note that the
change of current monitor block, if necessary, must be done
before the "Action:" keyword. The monitor block can also be
changed with the APZ Emulator command "B" in the initate
section.

Change AM (HLPLEX):

This keyword is used to set the active HLPLEX application
module to <application-module-name>. Note that it does not
change the current monitor block.

Terminate:

This keyword is used to conclude a test case.

Use "Terminate:" to reset the APZ Emulator after a test case.
All APZ Emulator commands, except MML commands, are
possible to use here.

The "Terminate:" commands can be used in an optional number.

Save:

This keyword is used to save a special state of the APZ
Emulator on a file. The save file(s) shall be used to avoid test
sequences, by means of returning to a specific state of the APZ
Emulator and starting a new test case from there. If the APZ
Emulator is in HLPLEX mode, additional HLPLEX related
state information are saved.

Please note that a new test case must start after a "Save", you
can not save in the middle of a test case. If you want to save a
state, then a new "Purpose:" must be inserted after the "Save:".

Comments and spacing

Comments must be enclosed by exclamation marks ( ! ) and should be
used as in PLEX. You may also end a comment with a new line character.
Do not use comments before the first "Macro:" or "Purpose:" keyword when
starting a new :xmp. block.

DOCUMENT INSTRUCTION

24 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

Note especially that the ‘\‘ character is used as a line extender. It can be used
anywhere, but is intended to be used for long APZ Emulator commands and in
the "Expected IO:" field. In order to be recognized, this character must be the
last character on the line including trailing spaces.

Example:

:xmp.

Purpose:

Testing of ...

Action:

S CMD 1 2 3 !

a comment

! \

4 5 6

Expected IO:

This! a comment

!very long line of output can be \

continued on the next line and even several\

lines can be extended. ! a comment.

:exmp.

This example contains one action "S CMD 1 2 3 4 5 6" and one expected IO
"This very long line of output can be continued on the next line and even
several lines can be extended". Note the comment between "This" and "very".
It is removed and substituted with one space. Comments are not removed
within strings.

5

ABBREVIATIONS

Table 3

Abbreviations

cmd

command

io

input - output

param

parameter

proc

procedure

sig

signal

var

variable

BTI

Basic Test Instruction

CP

Central Processor

DI

Document Instruction

DS

Data Store

EMU

APZ EMUlator

HLPLEX

High Level PLEX

MML

Man - Machine Language

SW

Software

DOCUMENT INSTRUCTION

25 (25)

1013-CAA 139 1138

2000-04-03

G

Nr — No.

Datum — Date

Rev

File

E

6

TERMINOLOGY

—

7

REFERENCES

Table 4

References

Name

Number

1 APZ Emulator User’s Guide

198 17-CAA 139 1058 Uen