Вы находитесь на странице: 1из 1

MIL-HDBK-1553A

1 November 1988
or a missile) includes or interfaces with an RT. Note that nothing precludes a particular LRU from being both
a data source and a data sink. There mayor may not be a bus monitor connected to the bus for instrumentation
purposes (e.g., for gathering data for flight test or mission analysis) or as part of a backup BC. In each case,
the required function (BC, RT, or bus monitor) is usually clear.
In some cases, a terminal must perform the functions of more than one of the three types. Some RTs must
also have the capability to be BCs. If the (current) BC issued a dynamic bus control mode command to an
RT with the capability to accept it, the RT would become the BC, and the (former) BC would become an RT.
Note that Notice 1 and Notice 2 prohibit the use of this function for Air Force avionics applications, although
neither BCs nor RTs are prohibited from implementing the capability. Some bus monitors may also act as RTs
with a defined terminal address. This capability is often used to check the status of the bus monitor, particularly
in systems in which a bus monitor is permanently installed.
50.2.1 Types of terminals. Terminals can be designed with different degrees of intelligence and autonomy.
They can be divided into three categories by the type of control or protocol logic used in their implementation.
From the simplest to the most complex, these are single-word, single-message, and multiple-message
terminals. BCs can be designed to fit any of these categories, but normally RTs or bus monitors would be
designed only as single-word or single-message terminals.
50.2.1.1 Single-word terminals.
In a system with a single-word terminal, the subsystem must process each
word in each message individually. That is, a single-word terminal requires subsystem intervention or action
for every word. After all the words have been received, the subsystem processor must determine the validity
of the message and construct the proper response. The response must then be transferred to the terminal
one word at a time and transmitted.
A single-word RT would send all received data words to the subsystem, one at a time. The subsystem would
have to validate the message, construct and send the status word on the 1553 bus, and then send any data
words required. For a single-word BC, the subsystem would have to construct the desired command, instruct
the BC to send it, define which of the 1553 buses to send it on (in a redundant bus system), provide any data
words required, read the response from the BC, evaluate the response, and initiate any further action.
In a microprocessor-based subsystem, this type of terminal would probably be an I/O channel to the processor.
Depending on the level of bus traffic, the subsystem processor could experience a reduction of 20% or more
in throughput due to the processing demands of the 1553 I/O channel. Terminals of this sort were common
in the early days of 1553 but are seldom seen today. The amount of support that they demand from the
subsystem is usually unacceptable, and parts are available to implement terminals that are more intelligent
with little difficulty.
50.2.1.2 Single-message terminals.
A single-message terminal has enough capability to construct or
process a complete message without any action by the subsystem. Subsystem action is required only at the
beginning (for a BC) or end (for an RT) of the message or in the event of an error.
A single-message RT is always ready to respond autonomously to a valid command on the 1553 bus. It
decodes the command to determine the proper data and then transfers it to or from the subsystem. The
subsystem may need to be informed that a message has been received so that the data may be used or
updated, but commonly, the subsystem does not require such notification. Since the RT is controlled by the
commands received on the bus, there is no need for any control by the subsystem.
A single-message BC transmits the required command and data words on the 1553 bus. The status word
received in response is then provided to the subsystem, along with any error indication. The subsystem is
responsible for processing any errors and interpreting the status word contents, deciding what the next
message should be, and then issuing it. This type of terminal is typically used with a microprocessor-based
subsystem; the messages to be sent are all constructed by the subsystem processor and placed in defined
Section 50 50-4
Downloaded from http://www.everyspec.com

Вам также может понравиться