In this article we will see how to implement the 1553 functional tests with the UUT acting as Remote Terminal.
We will implement four cases of functional tests, assuming that our unit under test acts as Remote Terminal and responds to the address 5 and subaddress 10 and 11 respectively to receive and transmit. The cases we will deal with are:

• Verify that the UUT is able to send one or more words
• Verify that the UUT is able to receive one or more words
• Verify that the UUT is able to respond to “modecode”
• Verify that the UUT is able to intercept the transmission errors

Regardless of the case, we will use the "1553_BC" function of my library "1553 channel".

FIRST CASE: ask UUT to send us one or more words and evaluate its Word Status.

Let’s say that the words to be received are 3. We value the input parameters of function 1553_BC as follows:

• RT address: address equal to 5 and subaddress equal to 11
• Resource: CH1 and Primary Bus (to transmit from the relevant BUS)
• Count: the number of words we want to receive, in this case 3
• All other parameters set with default values

We run the function and on completion we get the following values:

• RXdata: the requested words as received (in example: A, B and C in hexadecimal)
• StatusWord: the status word sent to us by Remote Terminal interrogated, decoded field by field. The same is reproposed also in the numerical formatting, string and booleana
• Counters: if all goes well, returns the value 1 in the msg field and err the value 0 in the msg field

SECOND CASE: send to UUT one or more words and evaluate its Word Status.

Suppose you want to send four words (1, 2, 3 and 4). We value as follows:

• RT address and resource: as in previous case
• Count: zero; this time we don’t ask for datas to RT
• TXData: filled with the words we want to transmit, in this case the four words from the value 1, 2, 3 and 4
• All other parameters remain with their default values

We run the function and on completion we get the following values:

• RXdata: empty; RT doesn’t transmit anything
• StatusWord and counters: as in previous case

THIRD CASE: transmit to the UUT a “modecode”.

Modecodes are particular messages (command word) that the Bus Controller can send to invoke commands defined by the same standart 1553. For example, one of these is "repeat last command" through which we ask the Remote Terminal to send us the last command received.

We always use 1553_BC and value the parameters as follows:

• RT address: the subfield address shows the address of the Remote Terminal while subaddress must be worth zero (remember from the first article that the subaddress is reserved? It is for this reason)
• Count: with subaddress zero, it no longer indicates the number of words we want to receive; it reports the coding of the modecode to send (in this case, 18 for the command repeat last command)
• All other parameters remain with their default values

We run the function and on completion we get the following values:

• RXdata: report the last command word received from the Remote Terminal
• StatusWord AND counters: as in previous case

FOURTH CASE: send UUT a wrong message.

Often verification of behavior is required following a badly formatted message, for example with a parity bit error. This case too can be handled by function 1553_BC as follows:

• RT address: 5 for address, 10 for subaddress (is the BC to transmit the word)
• Count: zero: don’t ask for word to Remote Terminal
• Err type and spec: respectively 3, to select the parity error and 1 to enter the error in the first word
• All other parameters remain with their default values

We run the function and on completion we get the following values:

• StatusWord: as in previous cases but with message error reporting

To sum up, only one function is needed to implement the four use cases. 1553_BC can be used in automatic sequence (for example via National Instruments Test Stand), as a function in your applications and individually. Previous cases can also be verified manually using the interactive panel provided with the "1553 channel" module.

In the next article I’ll explain what we did in the "low floors" of the 1553 board driver installed on the PC of the test bench (we’ll talk about minor and major frames…).
Thank you for your reading. Every intervention is always welcome, I will answer to all.

Antonio Costantino