23351 Madero,

Mission Viejo, CA 92691. USA.

Tel:
+ 1 949 859 8800
Fax: + 1 949 859 9643
Email: sales@holtic.com
Web: www.holtic.com

Using an Application Programming

Interface (API) to Simplify
MIL-STD-1553 Designs

September 2014
Anthony Murray

HOLT INTEGRATED CIRCUITS

1

Introduction to MIL-STD-1553 Data Bus

MIL-STD-1553 is a military data bus standard which evolved over a number of years and was formalized
by the US Air Force in 1973. It is a Time Division Multiplexed bus, meaning communication occurs
between multiple sources over a single transmission medium (bus) at different moments in time. The
bus is dual-redundant, where normal operation involves a primary bus with a secondary bus available as
a back-up should the primary bus fail or be damaged. Communication is by command/response, where
all activity is initiated by a single entity and responded to by all others. Three types of device, or
terminals, are allowed connect to the bus, namely, a Bus Controller (BC), Remote Terminal (RT) and
Monitor Terminal (MT). Figure 1 shows a simplified block diagram of a MIL-STD-1553 bus.
Subsystem2

Subsystem3

RT2

RT3

Bus A

Bus B

BC

RT1

MT

Subsystem1

Figure 1. Simplified block diagram of MIL-STD-1553 bus.

Bus Controller (BC)
The bus controller (BC) manages the flow of data on the bus. Its main purpose is to issue commands
which are responded to by other terminals. For example, all data transfers and status requests are
initiated by the bus controller. The bus has just one active BC, but may, under certain circumstances,
transfer BC responsibility to a selected RT capable of performing BC duties.
Remote Terminal (RT)
The remote terminal (RT) is a device which acts as an interface between a subsystem and the MIL-STD1553 bus. Its primary function is to decode commands from the BC and maintain data flow between the
subsystem and the bus. Each remote terminal is allowed up to 30 subaddresses, which are usually
assigned specific tasks or functions within the subsystem, e.g. subaddress 15 may be used to transmit
data from the subsystem to the bus, subaddress 14 may be used by the subsystem to receive data from
the bus. Each bus may have up to 31 remote terminals, with unique RT addresses 0 30 (note there is
no specific ranking or priority in the RT addresses). As the subsystem interface, the remote terminal is
also responsible for data protocol error detection and subsystem status updates. In most aircraft
applications, the remote terminal is often embedded in the subsystem itself.

HOLT INTEGRATED CIRCUITS

2

Monitor Terminal (MT)

The monitor terminal (MT) is a passive listening device that records message data and characteristics
occurring on the bus. Usually, the MTs main function is to store bus traffic for maintenance, diagnostic
and testing purposes.
Data Encoding and Bus Physical Layer
Data flow along the bus is dictated by the MIL-STD-1553 protocol, which is outlined in a standard that
defines aspects such as bit rate, data encoding, message length and gap time. In addition the
specification also defines the bus waveform electrical characteristics and physical connection attributes.
As stated above, the remote terminal (RT) is capable of checking commands and data for validity; in
addition, the RT is capable of detecting electrical errors such as waveform distortion from the bus.
MIL-STD-1553 Application
A typical MIL-STD-1553 application is conceptualized in Figure 2. Data is typically collated by a central
processing unit such as a host microcontroller (MCU), which typically performs higher level system
functions such as interrupt servicing, RAM data access and time stamping, and communicates with the
bus controller (BC), remote terminal (RT) and monitor terminal (MT) via a host interface. The lower level
BC, RT, MT functions are usually implemented in a COTS MIL-STD-1553 protocol IC(s) or Field
Programmable Gate Array (FPGA). Data typically needs to flow from a high-level system application, for
example a sensor array, all the way to the physical bus where it is transferred to other users. This
involves multiple layers of complexity, from the application to the MCU to the bus protocol details.
Application Programming Interfaces (APIs) provide a high-level link which enables system software
engineers to tie these layers together in software, without being intimately familiar with all the details
of each layer.
Termination

System
application
e.g. sensor array

Host
Interface
Host MCU

MIL-STD-1553
Protocol
and
Bus Interface
BC
RT

Memory
MT
Application
Hardware (LRU)

End
User 1
MIL-STD-1553
Bus
End
User 2

.
.
.
End
User n

Termination

Figure 2. MIL-STD-1553 Application Example.

HOLT INTEGRATED CIRCUITS

3

Using APIs in MIL-STD-1553 Data Bus Applications

The MIL-STD-1553 protocol and BC, MT, RT bus functions are typically implemented in a MIL-STD-1553
protocol IC or FPGA. This protocol device requires complex programming at the register level to define
functions such as data buffering, subaddress functional definitions, error and interrupt management.
This low-level programming is device-specific and system software engineers typically do not have the
knowledge or time to familiarize themselves with this level of detail. An API will typically bridge this gap,
providing the software engineer with a set of high-level function calls to perform these basic tasks. The
function calls incorporate device-specific low-level drivers, which provide direct access to the hardware
at the register level. The concept is illustrated in Figure 3.
Application
Operating
System (OS)

Bare Metal
(No OS)

API
Low Level Drivers
Hardware

Figure 3. Software Model Layers showing API.

The last section of this paper gives a simple example of how an API may be used to configure a COTS
MIL-STD-1553 protocol IC in a typical application. Before this, it is necessary to understand how MILSTD-1553 messages are structured on the bus.
MIL-STD-1553 Message Structure
MIL-STD-1553 messages consist of a series of words, whose structure at the bit level is defined in the
standard. Each word consists of 20 bits; three bits are used for bit synchronisation and one for parity
check, therefore there are 16 active bits in a MIL-STD-1553 word. Three types of word are defined. The
command word is used by the bus controller to issue commands to other terminals on the bus; the data
word is used to transfer actual data; the status word is used by terminals to communicate status back to
the BC. MIL-STD-1553 messages may contain up to 32 data words. Figure 4 gives an example of a
message requesting an RT to transmit 32 data words. The RT can also receive 1 to 32 data words from
the BC or another RT.

HOLT INTEGRATED CIRCUITS

4

Message 2

Message 1
BC
Command

RT Status
Response

Transmit
Command

Status
Word

RT Transmitted
Data

Data
Word 2

Data
Word 1

tr

Data
Word 32

Next
Command

tg

tr = Response Time
tg = Intermessage Gap

Figure 4. Typical MIL-STD-1553 Message.

A typical MIL-STD-1553 BC organises groups of messages into frames, for periodic
transmission/reception. As MIL-STD-1553 message flow is on a command/response basis, frames are
usually scheduled to repeat at fixed (known) periods, resulting in highly deterministic bus traffic. Groups
of messages with like timing are typically organised into minor frames of fixed time period, say 10ms.
Arrangements of minor frames are further organised into major frames. The concept is shown in figure
5.
Minor Frame Period, e.g. 10ms
Message 1 of Next
Minor Frame
BC
Command

BC
Command

Response

tr

Response

BC
Command

Message 2

.....

Message n

Next
Major Frame

Minor
Frame Period
Minor
Frame 1

Response

tr = Response Time
tg = Inter-message Gap

tg

Message 1

BC
Command

Response

Minor
Frame 2

Minor
Frame 3

Minor
Frame 4

Minor
Frame n

Minor
Frame 1

.....

Major Frame Period, e.g. 1s

Figure 5. MIL-STD-1553 Message Hierarchy.

Typical MIL-STD-1553 systems require messages be transmitted or received periodically, with different
message functions often requiring different periods. The above scheme allows the system designer to
send messages with different frequencies within a known (periodic) time. For example, in the above
hierarchy with 10ms minor frames and 1s major frames, a 1Hz message would appear in the same minor

HOLT INTEGRATED CIRCUITS

5

frame once every major frame (1s period). In the same major/minor frame hierarchy, a 10Hz message
would appear every tenth minor frame (100ms period).
The set up of BC message schedules similar to above is often programmed using high-level API functions
which access the MIL-STD-1553 protocol and bus interface at the register level (see Figure 2).

Using an API to Configure Holts MIL-STD-1553 BC/MT/RT Terminal

This section elaborates on the previous sections and describes how an API may be used to configure Holt
Integrated Circuits BC/MT/RT MIL-STD-1553 protocol and bus interface solution, HI-6130. The HI-6130 is
a protocol IC which incorporates BC, MT and up to 2 independent RT functions. Analog transceivers are
integrated on-chip to allow direct connection to the MIL-STD-1553 transformer bus interface. In most
cases, just one or two of the terminal modes are activated, but any combination may be used.
The example below concentrates on bus controller set up and operation, which involves a set of
complex operations that occur at the register level in the protocol IC. The API executes these through a
series of logical function calls such that the user need not be familiar with the protocol hardware. The
example focuses on major and minor frame construction and scheduling.
Bus Controller Message Scheduling
The HI-6130 bus controller may be configured to operate semi-autonomously with very little host MCU
interaction (see Figure 2). The API function calls provided by Holt may be used to allocate memory
locally in the protocol IC, construct messages, control scheduling and react to application conditions by
execution of conditional op codes. There are four main objects that need to be defined to successfully
transact frames on the bus, namely, Data Blocks, Message Blocks, Op Codes and the Frames themselves.
A flow diagram of the function calls and input parameters is shown in Figure 6.
Data Blocks
The BC Data Block is used to store MIL-STD-1553 data words (1 to 32) associated with individual
messages. Data Blocks are created using the BCDataBlkCreate() function. The user simply needs to
specify the size of the block and a unique block identifier (ID) as parameters and the API function will
automatically allocate a physical block of RAM in the HI-6130. See Figure 7.
Message Blocks
BC Message Blocks are used to store control and status information about a particular MIL-STD-1553
message, for example RT subaddress, RT status word, time-tag and time to next message (inter-message
gap) (see Figure 7). Each type of message (BC to RT, RT to RT, RT to BC, etc.) has a different function call
and associated input parameters. For example, the function BCMsgCreateBCtoRT() creates a Message
Block for BC to RT messages. The user specifies associated parameters such as Block ID, target RT
address, target RT subaddress, message word count and time to next message. Figure 7 shows how
Message Blocks and Data Blocks interact with each other.

HOLT INTEGRATED CIRCUITS

6

Op Codes
The HI-6130 supports a set of instruction op codes, which are used for message execution and control.
The API function BCOpcodeCreate() enables the user to create individual op codes by specifying the op
code type as an input parameter. The most common op code type is OpcodeXEQ (message execution);
other examples are OpcodeIRQ (generate host interrupt) and OpcodeLTT (load time-tag counter).
Op code definition is extremely important as this is the basis for minor and major frame creation. Many
op codes may be executed conditionally by specifying an associated condition parameter. Figure 7
shows how op codes interact with Message Blocks.
Minor and Major Frame Set-Up and Execution
As seen in Figure 5, a minor frame is essentially a collection of messages within a fixed time slot. Since
the HI-6130 requires all message and frame control be encapsulated in an op code, the device defines a
minor frame as a collection of op codes operating on messages. The majority of these op codes will be
OpcodeXEQ (message execution). Minor frames are generated using the API function
BCFrameCreate(). The user must specify an array of op code IDs (from previously defined op codes) as
an input parameter. Other parameters are the frame type (minor or major) and the total frame time.
The same function BCFrameCreate() is used to create major frames. A major frame is essentially defined
as a collection of op codes, OpcodeCMF, calling previously defined minor frames. The minor frame ID
is specified as an input parameter.
Figure 7 shows a typical BC messages sequence structure.

HOLT INTEGRATED CIRCUITS

7

// Create Data Block DBLK1.

BCDataBlkCreate()

Channel ID (0 to 31)
Data Block ID (DBLK1)
Data Block Size
Initial Data Pointer
Block Word Count

// Create Message Block MSG1.

BCMsgCreateBCtoRT()

Channel ID (0 to 31)
Message ID (MSG1)
Associated Data Block ID (DBLK1)
Receiving RT Address (0 to 31)
Receiving RT Subaddress (1 to 31)
Message Word Count
Time to next message
BC Control Word Options

// Create XEQ op code that executes MSG1.

BCOpcodeCreate()

Channel ID (0 to 31)
Opcode ID (OP1)
Opcode Type (OpcodeXEQ)
Condition
Parameter 1 (MSG1)

// Create CMF op code that calls minor frame MNR1 from major frame.

BCOpcodeCreate()

Channel ID (0 to 31)
Opcode ID (OP2)
Opcode Type (OpcodeCMF)
Condition
Parameter 1 (MNR1)

// Create minor frame MNR1 10ms in length which executes op codes specified by Opcode IDs.
Opcode IDs will be a list of OpcodeXEQ op codes for each message in the minor frame.

BCFrameCreate()

Channel ID (0 to 31)
Frame ID (MNR1)
Frame Type (Minor)
Opcode IDs (XEQ1, XEQ2, ....)
Opcode Count
Frame Time (10ms)

// Create major frame MJR1 1s in length which executes op codes specified by Opcode IDs.
Opcode IDs will be a list of OpcodeCMF op codes for each minor frame in the major frame.

BCFrameCreate()

Channel ID (0 to 31)
Frame ID (MJR1)
Frame Type (Major)
Opcode IDs (CMF1, CMF2, ....)
Opcode Count
Frame Time (1s)

Figure 6. Flow Diagram of MIL-STD-1553 Frame Generation using Holt API.

HOLT INTEGRATED CIRCUITS

8

Message 1 (MSG1)

Data Block 1 (DBLK1)

BC Control Word

Data Word n

Minor Frame 1 (MNR1)

Rx Command Word
(RT-RT only)

Data Word(s)

CMF

XEQ

Data Block Pointer

Data Word 1

CMF

XEQ

Time to next message

.
.
.
.
.

.
.
.
.
.

Time-Tag Word

Major Frame 1 (MJR1)

Block Status Word

Loopback Word
RT Status Word
Tx Command Word
(RT-RT only)
2nd RT Status Word
(RT-RT only)
Data

Message 2 (MSG2)

Data Block 2 (DBLK2)

BC Control Word

Data Word n

Rx Command Word
(RT-RT only)

Data Word(s)

Data Block Pointer

Data Word 1

.
.
.
.
.

Other Messages
in MNR1

Message 3 (MSG3)

Data Block 3 (DBLK3)

BC Control Word

Data Word n

Minor Frame 2 (MNR2)

Rx Command Word
(RT-RT only)

Data Word(s)

XEQ

Data Block Pointer

Data Word 1

XEQ

.
.
.
.
.

.
.

Message 4 (MSG4)

Data Block 4 (DBLK4)

BC Control Word

Data Word n

Rx Command Word
(RT-RT only)

Data Word(s)

Data Block Pointer

Data Word 1

.
.
.
.

Other Messages
in MNR2

Figure 7. Bus Controller Messages Sequence Structure.

HOLT INTEGRATED CIRCUITS

9

Conclusion
This paper demonstrates how an Application Programming Interface (API) may be used to control a
complex system such as a MIL-STD-1553 data bus. The lowest level of control typically occurs at the
protocol IC register level, which requires an in depth knowledge of vender-specific hardware. An API
provides a level of abstraction through a series of high-level function calls, communicating with the
protocol IC at the register level via vender-supplied low-level drivers. This enables the software engineer
to control the flow of data from the application layer to the physical bus, without being intimately
familiar with the hardware.

HOLT INTEGRATED CIRCUITS

10

References
1. HI-6130 Datasheet: MIL-STD-1553 / MIL-STD-1760, 3.3V BC/MT/RT Multi-Terminal Device
2. HI-6130 API Library Software Manual

Contact Information
Holt Integrated Circuits,
23351 Madero,
Mission Viejo. CA 92691.
Email: amurray@holtic.com
Tel: +1 949 859 8800.

HOLT INTEGRATED CIRCUITS

11