In this new series of articles, I will deal with the topic STD-MIL-1553 (cited for brevity as fifteen-fifty-three) illustrating the cases of typical tests. Before I get to the heart of the subject, I think it’s useful to bring back some protocol theory (I try to simplify as much as possible). In general, a BUS is an electrical medium and a set of rules by which multiple objects can communicate with each other by sharing the means of data transmission. The actors, interconnected between them, are of three types:
- Remote Terminal (RT): any object that interfaces on the bus (and that is not of the other two types)
- Bus Controller (BC): it is the (unique) object that commands the game by deciding who is to transmit, what is to transmit, and to whom (if 1553 were monarchy, BC would be its king)
- Bus Monitor (BM): it is the object that does absolutely nothing and stands there looking good (as if it were the pensioner who observes the work in progress but without a license of criticism).
Electrical interconnections are redundant: there are physically two separate BUSs, called primary and secondary (sometimes referred to as A and B). The 1553 is an avionic BUS, part of its robustness comes from this redundancy: if it had to go down a channel there would always be the other ready to intervene.
The Remote Terminals are addressed by address (31 is reserved). Each RT has a sort of "memory banks" (30 in total; 0 and 31 are reserved); such counters are addressed via a sub-address and can contain up to 32 words.
There are two kinds of possible communications:
- Between BC and RT
- Between two RT
- Mode Code
I summarize in a tree diagram all possible communications.
To understand the dynamics of communications, I focus on BC-RT data transmission. The Bus Controller sends a word (16 bit) encoding the type of transmission required (called command word, in command jargon). The remote terminal receives or transmits the data, according to when requested by the Bus Controller through the command word; in any case, it transmits a word with its status and its "wishes" (status word, in jargo status).
In detail, the command word contains all the information to define address and subaddress of the Remote Terminal; number of words to transmit or receive.
The status word reports as primary information the address of the remote terminal and allows you to make the basic check that the message has been received by the correct recipient. In addition, it contains further information which, if all of it is invalid, indicates that the remote terminal has nothing to claim.
For completeness, I report the exchange of information in case the Bus Controller commands two Remote Terminal to speak to each other. In this case, the CB transmits two command words containing the addresses (and sub-addresses) of the Remote Terminals that must, respectively, transmit and receive.
Before closing, I have two small notes (useful later):
- The address 31 is reserved for broadcast communications (receive all Remote Terminals)
- The subaddress 0 e 31 are reserved to mode codes (we’ll talk about it).
In the next article I will certainly talk about majors and minor frames but I will offer a shortcut to implement every communication that is needed when "you are" Bus Controller with a single function of "1553 channels", my library dedicated to STD-MIL-1553 protocol.
Thank you for your invaluable attention. If you want to make a contribution to this series of articles, you can do it in a simple way: with a like or a sharing. If you have any comments or questions, I will gladly answer them all.