MIL-STD-1553 Designer's Guide - [PDF Document] (2023)

MIL-STD-1553DESIGNERS GUIDE

105 Wilbur PlaceBohemia, New York 11716-2482

TEL: (631) 567-5600 FAX: (63) 567-7358

World Wide Web:

http://www.ddc-web.com

SIXTH EDITION

CUSTOMER SERVICE:

U.S.A. and Canada: 1-800-DDC-5757International Direct:1-631-567-5700

12/8/2003

MIL-STD-1553 DESIGNERS GUIDE

First Edition . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .(13,500)1982Second Printing . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .(10,000) 1983ThirdPrinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .(10,000) 1984Fourth Printing . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .(10,000) 1986

Second Edition . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .(10,000) 1987SecondPrinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .(10,000) 1988

Third Edition . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .(10,000)1990Fourth Edition . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . .(10,000) 1993FifthEdition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .(6,000) 1995

Second Printing . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . .(3,500) 1997SixthEdition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .(8,000) 1998

1982, ILC Data Device Corporation. 1998, ILC Data DeviceCorporation. All rights reserved.

The publisher thanks the U.S. Air Force Systems Command for useof "MIL-STD-1553 MultiplexApplications Handbook" in producing thisDesigner's Guide.

ii

MIL-STD-1553 DESIGNERS GUIDE

PREFACESince its inception in 1973 and in subsequent revisionsduring the ensuing years, MIL-STD-1553 hasevolved into thepredominant, internationally accepted networking standard for theintegration of militaryplatforms. Supporting documents such as theMIL-STD-1553 Multiplex Applications Handbook, the RTValidation andProduction Test Plans, and DDCs MIL-STD-1553 Designers Guide, havepositivelyinfluenced the standards worldwide familiarity andacceptance. Today, 1553 has expanded beyond its tra-ditional domainof US Air Force and Navy aircraft to encompass applications forcombat tanks, ships, satel-lites, missiles and the InternationalSpace Station Program. Despite the recent advent of newerandhigher-speed technologies, it is clearly evident that 1553 willcontinue to be used extensively in evolvingupgrade programs as wellas for new applications and integration platforms for years tocome.

Focused on meeting the needs of hardware and software designengineers confronted with1553/1760/1773 interface and/or testrequirements, DDC is pleased to publish and provide you withthissixth edition of the Designers Guide for the MIL-STD-1553community.

As in its five previous editions, the Designers Guide is dividedinto sections to facilitate your ease of ref-erence and review.Section I provides you with an overview of the philosophy andimplementation of MIL-STD-1553B and several related standards.Using DDC 1553 products to illustrate key points of interestwithinthe framework of these technical discussions, Section I alsopresents a comparison of MIL-STDs-1553A and B as well as anoverview of MIL-STD-1760B. Taken directly from the MIL-STD-1553MultiplexApplications Handbook, Section II provides you with acomplete copy of MIL-STD-1553 for your refer-ence, and, asection-by-section interpretation of the rationale behind thevarious paragraphs in the stan-dard. Plus, for your ongoingreference requirements, copies of Notices 1 and 2 to MIL-STD-1553B,as wellas the Production Test Plan and Validation Test Plan arepresented in Sections III through VI.

As the leading full-range developer and manufacturer of 1553data bus components, boards and software,DDC offers a comprehensivecollection of technical data sheets delineating our wide array of1553 dataconversion and communications products in Section VII.These include fully integrated BC/RT/MT compo-nents, transceivers,RT components, transformers, software and a host PCMCIA, VME/VXIand PC-com-patible communications and tester/simulator boardproducts.

The most recent information regarding DDCs 1553 product uses,including space-level applications andour series of AdvanceCommunication Engine (ACE) terminals, is presented in Section VIII.A series ofapplication notes, highlighting practical uses anddesign concerns when implementing 1553 technology, isprovided inSection IX. A listing of corresponding DDC and DESC part numbers isprovided in Section X.For your reference, Subject and ProductNumber Indices are provided in Section XI.

DDC would like to thank Chris deLong and Crossgrove &Associates, for their contributions to theDesigners Guidesdevelopment, and the U.S. Air Force for allowing us to presentportions of their MIL-STD-1553 Multiplex Applications Handbook. Wewould also like to extend our gratitude to our cus-tomers andfriends who have attended our seminars and shared their 1553experiences with us.

We sincerely hope this sixth edition of DDCs MIL-STD-1553Designers Guide will prove useful as aworking document andreference source, enabling you to resolve your requirements in apractical, efficient,cost-effective, reliable manner. While we havemade every effort to ensure the accuracy and correctness oftheinformation presented within these pages, we ask that you do nothesitate to call our attention to anyomissions, oversights, errors,miscalculations or any suggestions you might have for enhancingandimproving this publication.

Thank you for your attention, ongoing consideration andpatronage.

ILC Data Device Corporation

iii

MIL-STD-1553 DESIGNERS GUIDE

iv

TABLE OF CONTENTS

SECTION 1. - DESIGNERS NOTES

INTRODUCTION

1.0 MIL-STD-1553 OVERVIEW . . . . . . . . . . . . . . . . . . .. . . .I-1

1.1 Key Element I-2

1.2 Message Types . . . . . . . . . . . . . . . . . . . . . . .. . . . .I-3

1.3 Word Types I-5

1.4 Options Within the Standard . . . . . . . . . . . . . . . .. . .I-6

1.4.1 Status Bits . . . . . . . . . . . . . . . . . . . . . . .. . .I-6

1.4.2 Mode Codes . . . . . . . . . . . . . . . . . . . . . . ..I-8

1.5 Data Bus Network Considerations . . . . . . . . . . ..I-11

1.5.1 MIL-STD-1553 Bus Network

Requirements . . . . . . . . . . . . . . . . . . . . . .I-13

1.5.2 Data Bus Network Analysis . . . . . . . . . . . .I-15

1.6 The Most Frequently Asked Question

Concerning MIL-STD-1553 . . . . . . . . . . . . . . . . ..I-16

1.6.1 When to Transmit a Status Word

(1553B para. 4.4.3.3 and 4.4.3.4) . . . . . . . . .I-16

1.6.2 Superseding Valid Commands

(1553B para. 4.4.3.2) and

Reset Data Bus Transmitter

1553B para. 4.6.3.2) . . . . . . . . . . . . . . . . .I-17

1.6.3 Illegal Command (1553B para. 4.4.3.4) . . . . . .I-18

1.6.4 Invalid Command (1553B para. 4.4.3.3) . . . . . .I-19

1.6.5 Impact of Notice 2 to MIL-STD-1553B . . . . . .I-19

1.6.6 Responses to Non-implemented Mode

Code Commands and Undefined

Mode Codes . . . . . . . . . . . . . . . . . . . . . .I-20

1.6.7 Two Single Channel Remote Terminal

Operating in a Dual Standby

Redundant System. . . . . . . . . . . . . . . . . .I-23

1.6.8 Testing of 1553 Terminals . . . . . . . . . . . . ..I-24

2.0 A Comparison of Data Bus Specifications . . . . . . . . . ..I-24

2.1 Summary of Data Bus Requirements . . . . . . . . . ..I-25

2.2 Summary of Status Word Protocols

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . .. .I-25

2.3 Summary of Status Word Bit Assignments . . . . . . .I-26

2.4 Summary of Mode Code Usage . . . . . . . . . . . . . ..I-27

2.5 Comparison of Data Bus Characteristics . . . . . . . ..I-28

2.6 Comparison of Terminal Characteristics . . . . . . . ..I-31

2.7 Remote Terminal Characteristics . . . . . . . . . . . . ..I-34

2.8 Transmitter/Receiver Response

Voltage Range . . . . . . . . . . . . . . . . . . . . . . . . .. .I-34

3.0 System Design . . . . . . . . . . . . . . . . . . . . . . .. . . . . .I-35

3.1 Data Bus Topology . . . . . . . . . . . . . . . . . . . . .. . . .I-35

3.2 Data Bus Control . . . . . . . . . . . . . . . . . . . . . .. . . .I-35

3.2.1 Bus Control Mechanization . . . . . . . . . . . ..I-35

3.2.2 Error Management . . . . . . . . . . . . . . . . . ..I-39

3.3 Functional Partitioning and Data Bus

Element Redundancy . . . . . . . . . . . . . . . . . . . . ..I-43

3.4 Data and Control Passing in Hierarchical

Networks I-45

3.5 Network Startup and Shutdown . . . . . . . . . . . . . ..I-49

3.6 System Synchronization and Protocol . . . . . . . . . ..I-51

3.7 Data Control I-54

3.7.1 Subaddress Selection/Operation and

Data Storage . . . . . . . . . . . . . . . . . . . . . .I-54

3.7.1.1 Extended Subaddressing . . . . . . . .I-55

3.7.2 Data Buffering and Validity . . . . . . . . . . . ..I-56

3.7.3 Block Transfers . . . . . . . . . . . . . . . . . . . . ..I-58

3.7.4 Data Protection . . . . . . . . . . . . . . . . . . . ..I-58

3.8 Data Bus Loading Analysis . . . . . . . . . . . . . . . . .. .I-59

3.9 Interface Control Documents . . . . . . . . . . . . . . . ..I-60

4.0 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .. . .I-60

4.1 Types of Terminals . . . . . . . . . . . . . . . . . . . . .. . . .I-60

4.2 Functional Elements . . . . . . . . . . . . . . . . . . . .. . . .I-62

4.2.1 Analog Transmitter/Receiver . . . . . . . . . . ..I-63

4.2.2 Encoder/Decoder . . . . . . . . . . . . . . . . . . ..I-65

4.2.3 Protocol Sequencer and Subsystem

Interface . . . . . . . . . . . . . . . . . . . . . . . . ..I-65

4.2.3.1 Protocol Sequencer with

Remote Terminal Capability . . . . . .I-70

4.2.3.2 Protocol Sequencer with Bus

Controller Capability . . . . . . . . . . .I-70

4.2.4 Bus Coupler Design . . . . . . . . . . . . . . . . ..I-70

5.0 Bus Controller Implementation . . . . . . . . . . . . . . .. . . . .I-70

5.1 Single Message BlUs . . . . . . . . . . . . . . . . . . . .. . .I-71

5.2 Multiple Message BlUs . . . . . . . . . . . . . . . . . . .. .I-71

5.3 Message Headers . . . . . . . . . . . . . . . . . . . . . .. . .I-71

5.4 Stacks vs. Linked Lists . . . . . . . . . . . . . . . . . .. . . . .I-71

5.5 Status Word Analysis . . . . . . . . . . . . . . . . . . . .. . .I-74

5.6 Error Handling . . . . . . . . . . . . . . . . . . . . . . .. . . . .I-75

5.7 Tag Words I-76

MIL-STD-1553 DESIGNERS GUIDE

v

TABLE OF CONTENTS (Continued)

5.8 General Software Considerations . . . . . . . . . . . . ..I-77

5.8.1 BIU Initialization . . . . . . . . . . . . . . . . . . . ..I-77

5.8.2 Controller Synchronization . . . . . . . . . . . ..I-78

5.8.3 Scheduling Via Bus Event . . . . . . . . . . . . ..I-78

5.8.4 Message Error Handling and

Recovery . . . . . . . . . . . . . . . . . . . . . . . ..I-78

5.9 Message Reception and Use . . . . . . . . . . . . . . . ..I-79

6.0 Testing, Integration, and Instrumentation . . . . . . . . .. . .I-80

6.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . .. . .I-80

6.1.1 Levels of Testing . . . . . . . . . . . . . . . . . . ..I-80

6.1.2 Test Requirements . . . . . . . . . . . . . . . . ..I-82

6.1.2.1 Electrical Interface Tests . . . . . . . .I-82

6.1.2.2 Protocol Tests . . . . . . . . . . . . . . . .I-82

6.2 Systems Integration . . . . . . . . . . . . . . . . . . . .. . . .I-84

6.2.1 Simulation . . . . . . . . . . . . . . . . . . . . . . . .. . . . .I-84

6.3 Instrumentation . . . . . . . . . . . . . . . . . . . . . .. . . . .I-85

7.0 Other IssuesI-86

7.1 Network System Security . . . . . . . . . . . . . . . . . .. .I-86

7.1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . .. .I-86

7.1.2 System Security Policy . . . . . . . . . . . . . . ..I-87

7.1.3 System Security Architecture . . . . . . . . . . .I-87

7.1.4 TEMPEST Design . . . . . . . . . . . . . . . . . ..I-87

7.1.5 Encryption Designs . . . . . . . . . . . . . . . . ..I-877.1.6 Trusted Message Routing and

Control Design . . . . . . . . . . . . . . . . . . . .I-88

7.2 MIL-STD-1760A Interconnect Standard for

Aircraft Stores . . . . . . . . . . . . . . . . . . . . . . . .. . . .I-88

7.2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . .. .I-88

7.2.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . ..I-90

7.2.3 MIL-STD-1760A Signals Related to

1553B . . . . . . . . . . . . . . . . . . . . . . . . . . ..I-90

7.2.4 Data Bus Networks and Components . . . . .I-90

7.3 System 2 . . . . . . . . . . . . . . . . . . . . . . . . . .. . .I-92

7.3.1 Significant Elements of System 2 . . . . . . . . .I-92

SECTION II- REVIEW AND RATIONALE OF

MIL-STD-1553A AND MIL-STD-1553B

1.0 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . .. .II-2

1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . .. .II-2

1.2 Application . . . . . . . . . . . . . . . . . . . . . . . .. . . . .II-2

2.0 Referenced Documents . . . . . . . . . . . . . . . . . . . .. . . . .II-2

2.1 Issue Of Document . . . . . . . . . . . . . . . . . . . . .. . .II-2

3.0 Definitions . . . . . . . . . . . . . . . . . . . . . . . .. . . . .II-2

3.1 Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . ..II-2

3.2 Bit Rate . . . . . . . . . . . . . . . . . . . . . . . . . .. . .II-2

3.3 Pulse Code Modulation (PCM) . . . . . . . . . . . . . . ..II-3

3.4 Time Division Multiplexing (TDM) . . . . . . . . . . . . . ..II-3

3.5 Half Duplex . . . . . . . . . . . . . . . . . . . . . . . .. . . . .II-3

3.6 Word . . . . . . . . . . . . . . . . . . . . . . . . . . . ..II-3

3.7 Message . . . . . . . . . . . . . . . . . . . . . . . . . .. . .II-3

3.8 Subsystem . . . . . . . . . . . . . . . . . . . . . . . . .. . . .II-3

3.9 Data Bus . . . . . . . . . . . . . . . . . . . . . . . . . .. . .II-3

3.10 Terminal . . . . . . . . . . . . . . . . . . . . . . . . .. . . .II-3

3.11 Bus Controller . . . . . . . . . . . . . . . . . . . . . .. . . . . .II-4

3.12 Bus Monitor II-4

3.13 Remote Terminal (RT) . . . . . . . . . . . . . . . . . . .. . .II-4

3.14 Asynchronous Operation . . . . . . . . . . . . . . . . . .. .II-4

3.15 Dynamic Bus Control . . . . . . . . . . . . . . . . . . . .. . .II-4

3.16 Command/Response . . . . . . . . . . . . . . . . . . . . .. .II-4

3.17 Redundant Data Bus . . . . . . . . . . . . . . . . . . . .. . .II-4

3.18 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . .. . . .II-4

3.19 Mode Code . . . . . . . . . . . . . . . . . . . . . . . . .. . . .II-5

4.0 General Requirements . . . . . . . . . . . . . . . . . . . .. . . . . .II-5

4.1 Test And Operating Requirements . . . . . . . . . . . ..II-5

4.2 Data Bus Operation . . . . . . . . . . . . . . . . . . . . .. . .II-5

4.3 Characteristics . . . . . . . . . . . . . . . . . . . . . .. . . . . .II-5

4.3.1 Data Form . . . . . . . . . . . . . . . . . . . . . . . ..II-5

4.3.2 Bit Priority . . . . . . . . . . . . . . . . . . . . . . .. .II-5

4.3.3 Transmission Method . . . . . . . . . . . . . . . ..II-6

4.3.3.1 Modulation . . . . . . . . . . . . . . . . . . . . . . .. .II-6

4.3.3.2 Data Code . . . . . . . . . . . . . . . . . . . . . . .. . .II-6

4.3.3.3 Transmission Bit Rate . . . . . . . . . . . . . . . ..II-6

4.3.3.4 Word Size . . . . . . . . . . . . . . . . . . . . . . .. . .II-6

4.3.3.5 Word Formats . . . . . . . . . . . . . . . . . . . . . ..II-6

4.3.3.5.1 Command Word . . . . . . . . . . . . .II-6

4.3.3.5.1.1Sync . . . . . . . . . . . . . . . . .II-6

4.3.3.5.1.2 Remote Terminal Address . . . II-7

4.3.3.5.1.3 Transmit/Receive . . . . . . .II-8

4.3.3.5.1.4 Subaddress/Mode . . . . . .II-8

4.3.3.5.1.5 Data Word Count

Mode Code . . . . . . . . . . . . . . . . . . . .II-8

4.3.3.5.1.6 Parity . . . . . . . . . . . . . . . .II-8

4.3.3.5.1.7 Optional Mode Control . . .II-8

MIL-STD-1553 DESIGNERS GUIDE

vi

TABLE OF CONTENTS (Continued)

4.3.3.5.1.7.Dynamic Bus

Control . . . . . . . . . . . . . . . . . . . . . .II-10

4.3.3.5.1.7.2 Synchronize (Without

Data Word) . . . . . . . . . . . . . . . . . . . . . ..II-10

4.3.3.5.1.7.3 Transmit Status

Word . . . . . . . . . . . . . . . . . . . . . . . .II-11

4.3.3.5.1.7.4 Initiate Self-Test . . . . . .II-11

4.3.3.5.1.7.5 Transmitter

Shutdown . . . . . . . . . . . . . . . . . . . . .II-11

4.3.3.5.1.7.6 Override Transmitter

Shutdown . . . . . . . . . . . . . . . . . . . .II-11

4.3.3.5.1.7.7 Inhibit Terminal

Flag (T/F) Bit . . . . . . . . . . . . . . . . . .II-11

4.3.3.5.1.7.8 Override Inhibit T/F

Bit . . . . . . . . . . . . . . . . . . . . . . . . .II-11Z

4.3.3.5.1.7.9 Reset Remote

Terminal . . . . . . . . . . . . . . . . . . . . .II-12

4.3.3.5.1.7.10 Reserved Mode Codes

(01001 to 01111) . . . . . . . . . . . . . . .II-12

4.3.3.5.1.7.11 Transmit Vector

Word . . . . . . . . . . . . . . . . . . . . . . . .II-12

4.3.3.5.1.7.12 Synchronize (With

Data Word) . . . . . . . . . . . . . . . . . . .II-12

4.3.3.5.1.7.13 Transmit Last

Command Word1 . . . . . . . . . . . . . . .II-12

4.3.3.5.1.7.14 Transmit Built-ln-Test

(Bit) Word . . . . . . . . . . . . . . . . . . . .II-12

4.3.3.5.1.7.15 Selected Transmitter

Shutdown . . . . . . . . . . . . . . . . . . . .II-13

4.3.3.5.1.7.16 Override Selected . . . . . .Transmitter Shutdown. . . . . . . . . . .II-13

4.3.3.5.1.7.17 Reserved Mode

Codes (10110 to 11111) . . . . . . . . . .II-13

4.3.3.5.2 Data Word . . . . . . . . . . . . . . . . .II-13

4.3.3.5.2.1 Sync . . . . . . . . . . . . . . .II-13

4.3.3.5.2.2 Data . . . . . . . . . . . . . . . .II-13

4.3.3.5.2.3 Parity . . . . . . . . . . . . . . .II-13

4.3.3.5.3 Status Word . . . . . . . . . . .II-15

4.3.3.5.3.1 Sync . . . . . . . . . . . . . . .II-15

4.3.3.5.3.2 RT Address . . . . . . . . . .II-15

4.3.3.5.3.3 Message Error Bit . . . . . . . . .II-15

4.3.3.5.3.4 Instrumentation Bit . . . . . . . . . . .II-15

4.3.3.5.3.5 Service Request Bit . . . . . . . . . . . .II-16

4.3.3.5.3.6 Reserved Status Bits . . . . . . . . . .II-16

4.3.3.5.3.7 Broadcast Command

Received Bit . . . . . . . . . . . . . . . . . . .II-16

4.3.3.5.3.8 Busy Bit . . . . . . . . . . . . . . . . .II-16

4.3.3.5.3.9 Subsystem Flag Bit . . . . . .II-17

4.3.3.5.3.10 Dynamic Bus Control . . . . .Acceptance Bit . . . .. . . . . . . . . . . .II-17

4.3.3.5.3.11 Terminal Flag Bit . . . . . . .II-18

4.3.3.5.3.12 Parity Bit . . . . . . . . . . .II-18

4.3.3.5.4 Status Word Reset . . . . . . . . . . .II-18

4.3.3.6 Message Formats . . . . . . . . . . . . . . . . ..II-184.3.3.6.1 Bus Controller To Remote

Terminal Transfers . . . . . . . . . . . . . .II-19

4.3.3.6.2 Remote Terminal Bus

Controller Transfers . . . . . . . . . . . . .II-19

4.3.3.6.3 Remote Terminal To Remote

Terminal Transfers . . . . . . . . . . . . . .II-19

4.3.3.6.4 Mode Command Without

Data Word . . . . . . . . . . . . . . . . . . . .II-20

4.3.3.6.5 Mode Command With

Data Word (Transmit) . . . . . . . . . . . .II-20

4.3.3.6.6 Mode Command With

Data Word (Receive) . . . . . . . . . . . .II-20

4.3.3.6.7 Optional Broadcast

Command . . . . . . . . . . . . . . . . . . .II-20

4.3.3.6.7.1 Bus Controller To

Remote Terminal

Transfers (Broadcast) . . . . . . . . . . . . .II-20

4.3.3.6.7.2 Bus Controller To

Remote Terminal

Transfers (Broadcast) . . . . . . . . . . . . . . .II-20

4.3.3.6.7.3 Mode Command Without

Data Word (Broadcast) . . . . . . . . . . . . . .II-20

4.3.3.6.7.4 Mode Command With

Data Word (Broadcast) . . . . . . . . . . . . .II-20

4.3.3.7 Intermessage Gap . . . . . . . . . . . . . . . . . ..II-22

4.3.3.8 Response Time . . . . . . . . . . . . . . . . . . ..II-22

4.3.3.9 Minimum No-Response

Time-Out . . . . . . . . . . . . . . . . . . . .II-23

4.4 Terminal Operation . . . . . . . . . . . . . . . . . . . . .. . .II-23

4.4.1 Common Operation . . . . . . . . . . . . . . . . ..II-23

4.4.1.1 Word Validation . . . . . . . . . . . . . . . . . . ..II-23

4.4.1.2 Transmission Continuity . . . . . . . . . . . . . ..II-23

4.4.1.3 Terminal Fail-Safe . . . . . . . . . . . . . . . . . ..II-23

4.4.2 Bus Controller Operation . . . . . . . . . . . . ..II-26

MIL-STD-1553 DESIGNERS GUIDE

TABLE OF CONTENTS (Continued)

4.4.3 Remote Terminal . . . . . . . . . . . . . . . . . ..II-26

4.4.3.1 Operation . . . . . . . . . . . . . . . . . . . . . . .. .II-26

4.4.3.2 Superseding Valid Commands . . . . . . . . . . ..II-26

4.4.3.3 Invalid Commands . . . . . . . . . . . . . . . . . ..II-26

4.4.3.4 Illegal Command . . . . . . . . . . . . . . . . . . ..II-26

4.4.3.5 Valid Data Reception . . . . . . . . . . . . . . ..II-27

4.4.3.6 Invalid Date Reception . . . . . . . . . . . . . . ..II-27

4.4.4 Bus Monitor Operation . . . . . . . . . . . . . ..II-28

4.5 Hardware Characteristics . . . . . . . . . . . . .II-28

4.5.1 Data Bus Characteristics . . . . . . . . . . . . ..II-28

4.5.1.1 Cable . . . . . . . . . . . . . . . . . . . . . . . . .. .II-28

4.5.1.2 Characteristic Impedance . . . . . . . . . . . ..II-28

4.5.1.3 Cable Attenuation . . . . . . . . . . . . . . . . . ..II-28

4.5.1.4 Cable Termination . . . . . . . . . . . . . . . . . ..II-28

4.5.1.5 Cable Stub Requirements . . . . . . . . . . . ..II-28

4.5.1.5.1 Transformer Coupled Stubs . . . . .II-36

4.5.1.5.1.1 Coupling Transformer . . . . . . .II-36

4.5.1.5.1.1.1 Transformer Input

Impedance . . . . . . . . . . . . . . . . . . . . . . ..II-36

4.5.1.5.1.1.2 Transformer Waveform

Integrity . . . . . . . . . . . . . . . . . . . . . .II-36

4.5.1.5.1.1.3 Transformer Common

Mode Rejection . . . . . . . . . . . . . . . .II-37

4.5.1.5.1.2 Fault Isolation . . . . . . . . . . . . . .II-37

4.5.1.5.1.3 Cable Coupling . . . . . . . . . . . . .ii-37

4.5.1.5.1.4 Stub Voltage

Requirements . . . . . . . . . . . . . . . . . .II-37

4.5.1.5.2 Direct Coupled Stubs . . . . . . . . .II-37

4.5.1 .5.2.1 Fault Isolation . . . . . . . . . . . . .II-38

4.5.1.5.2.2 Cable Coupling . . . . . . . . . . . .II-38

4.5.1.5.2.3 Stub Voltage

Requirements . . . . . . . . . . . . . . . .II-38

4.5.1.5.3 Wiring and Cabling For EMC . . . . . . .II-38

4.5.2 Terminal Characteristics . . . . . . . . . . . . . . . ..II-38

4.5.2.1 Terminals With Transformer Coupled Stubs II-44

4.5.2.1.1 Terminal Output Characteristics . .II-44

4.5.2.1.1.1 Output Levels . . . . . . . . . . . . . .II-44

4.5.2.1.1.2 Output Waveform II-44

4.5.2.1.1.3 Output Noise . . . . . . . . . . . . . .II-44

4.5.2.1.1.4 Output Symmetry . . . . . . . . . . .II-45

4.5.2.1.2 Terminal Input Characteristics . . .II-45

4.5.2.1.2.1 Input Waveform Compatibility . .II-45

4.5.2.1.2.2 Common Mode Rejections . . . . . .II-45

4.5.2.1.2.3 Input Impedance . . . . . . . . . . . . .II-45

4.5.2.1.2.4 Noise Rejection . . . . . . . . . . . . . .II-46

4.5.2.2 Terminals With Direct Coupled Stubs . . . .II-47

4.5.2.2.1Terminal Output Characteristics . . . . . . ..II-47

4.5.2.2.1.1 Output Levels . . . . . . . . . . . . . .II-47

4.5.2.2.1.2 Output Waveform . . . . . . . . . .II-47

4.5.2.2.1.3 Output Noise . . . . . . . . . . . . . .II-47

4.5.2.2.1.4 Output Symmetry . . . . . . . . . . .II-47

4.5.2.2.2 Terminal Input Characteristics . . .II-48

4.5.2.2.2.1 Input Waveform Compatibility . .II-48

4.5.2.2.2.2 Common Mode Rejections . . . .II-48

4.5.2.2.2.3 Input Impedance . . . . . . . . . . .II-48

4.5.2.2.2.4 Noise Rejection . . . . . . . . . . . .II-48

4.6 Redundant Data Bus Requirements . . . . . . . . . ..II-49

4.6.1 Electrical Isolation . . . . . . . . . . . . . . . . . ..II-49

4.6.2 Single Event Failures . . . . . . . . . . . . . . ..II-49

4.6.3 Dual Standby Redundant Data Bus . . . . . .II-49

4.6.3.1 Data Bus Activity . . . . . . . . . . . . . . . . . . ..II-49

4.6.3.2 Reset Data Bus Transmitter . . . . . . . . . . ..II-49

APPENDIX

10.0 General . . . . . . . . . . . . . . . . . . . . . . . . ..II-50

10.1 Redundancy . . . . . . . . . . . . . . . . . . . . . ..II-50

10.2 Bus Controller . . . . . . . . . . . . . . . . . . . ..II-50

10.3 Multiplex Selection Criteria . . . . . . . . . . ..II-50

10.4 High Reliability Requirements . . . . . . . . . .II-51

10.5 Stubbing . . . . . . . . . . . . . . . . . . . . . . . . ..II-51

10.6 Use of Broadcast Option . . . . . .................II-51

SECTION III

Notice I . . . . . . . . . . . . . . . . . . . . . . . . . . ..III- 1

SECTION IV

Notice 11 . . . . . . . . . . . . . . . . . . . . . . . . . . ..IV- 1

SECTION V

Production Test Plan for Remote Terminals . . . . . . . . . . .. .V- 1

SECTION VI

RT Validation Test Plan . . . . . . . . . . . . . . . . . . . .. . . . . . . .VI-1

vii

MIL-STD-1553 DESIGNERS GUIDE

viii

TABLE OF CONTENTS (Continued)

SECTION VII

DATA BUS PRODUCT INFORMATION

Product Summary Table . . . . . . . . . . . . . . . . . . . . .. . . .VII- 2

BU-61582 . . . . . . . . . . . . . . . . . . . . . . . . . .VII-8

BU-61590 . . . . . . . . . . . . . . . . . . . . . . . . . .VII-12

BU-65170/61580 and BU-61585 . . . . . . . . . . . . . . . . . ..VII- 17

BU-65178/65179/61588/61689 . . . . . . . . . . . . . . . . . . ..VII- 59

BU-65528 and BU-65527 . . . . . . . . . . . . . . . . . . . . .. . .VII- 66

BU-65529 . . . . . . . . . . . . . . . . . . . . . . . . . .VII-94

BU-65539 . . . . . . . . . . . . . . . . . . . . . . . . . .VII-96

BU-65550 and BU-65551 . . . . . . . . . . . . . . . . . . . . .. . .VII-120

BUS-61553 . . . . . . . . . . . . . . . . . . . . . . . . ..VII-145

BUS-61559 . . . . . . . . . . . . . . . . . . . . . . . . ..VII-147

BUS-63100 SERIES . . . . . . . . . . . . . . . . . . . . . . . .. .VII-149

BUS-65112 and BUS-65117 . . . . . . . . . . . . . . . . . . . ..VII-162

BUS-65142/65142 SERIES . . . . . . . . . . . . . . . . . . . . .. .VII-166

BUS-65153 . . . . . . . . . . . . . . . . . . . . . . . . ..VII-173

BUS-65517II . . . . . . . . . . . . . . . . . . . . . . . . ..VII-181

BUS-65518 . . . . . . . . . . . . . . . . . . . . . . . . ..VII-183

BUS-65536 and BUS-65535 . . . . . . . . . . . . . . . . . . . .. .VII-195

BUS-69000 SERIES . . . . . . . . . . . . . . . . . . . . . . . .. .VII-202

BUS-69080/69082/69083 . . . . . . . . . . . . . . . . . . . . .. . .VII-227

Pulse Transformers . . . . . . . . . . . . . . . . . . . . . . .. . .VII-243

Standard Product Processing . . . . . . . . . . . . . . . . . .. . .VII-249

SECTION VIII

DATA BUS PRODUCT BRIEFS

1553 Terminals for Space Applications . . . . . . . . . . . . .. .VII- 2

MIL-STD-1553 Transformers . . . . . . . . . . . . . . . . . . .. . .VIII- 4

SECTION IX

DATA BUS APPLICATION INFORMATION

System Advantages of the Integrated 1553 Terminal . . . . . IX-3

Processor-to-ACE Interfaces . . . . . . . . . . . . . . . . . .. . . . .IX-11

ACE RT Memory Management Options . . . . . . . . . . . . . ..IX-28

Simple Interfaces to Simple Systems . . . . . . . . . . . . . .. .IX-43

Avoiding Piffalls Using Your Mil-Std-1553 Card . . . . . . . ..IX-52

Electrical and Layout Considerations for 1553

Terminal Design . . . . . . . . . . . . . . . . . . . . . . . .. . . .IX-56

Understanding the ACEs Self Test Capabilities . . . . . . . ..IX-68

Factors to Consider When Using a PC in a

MIL-STD-1553 Environment . . . . . . . . . . . . . . . . . . . .. .IX-72

Additional Application Notes Available from DDC . . . . . . ..IX-75

SECTION X - DESC PRODUCTS

DDC to DESC Part Numbers . . . . . . . . . . . . . . . . . . . .. . .X- 2

SECTION XI- INDEX

Subject Index . . . . . . . . . . . . . . . . . . . . . . . . .. . .XI- 2

Product Part Number Index . . . . . . . . . . . . . . . . . . .. . . . .XI- 4

DESIGNERS NOTES

I-1

I.DESIGNER'S NOTES

DESIGNERS NOTES

I-2

INTRODUCTIONMIL-STD-1553, Digital Internal TimeDivisionCommand/Response Multiplex Data Bus, is a mili-tarystandard (presently in revision B), which hasbecome one of thebasic tools being used today bythe DoD for integration of weaponsystems.The stan-dard describes the method of communication andtheelectrical interface requirements for subsystemsconnected to thedata bus. The 1 Mbps serial com-munication bus is used to achieveaircraft avionic(MIL-STD-1553B) and stores management(MIL-STD-1760B) integration. In the future it will be usedto extendthe systems integration to flight controls,propulsion controls, andvehicle management sys-tem (electrical, hydraulic, environmentalcontrol,etc.).

Several other documents exist, which are related toMIL-STD-1553.MIL-HDBK-1553 describes theimplementation practices for thisstandard includ-ing: design considerations, examples ofapplica-tions, and guidelines for implementations. PortionsofMIL-STD-1553 are also the foundation of the MIL-STD-1773(Fiber-optics), and MIL STD-1760B(Stores Management). In addition,MIL-STD-1553 isembodied in or referenced by the followinginterna-tional documents: NATO STANAG 3838, ASCC AirStandard 50/2,and UK DEF STAN 00-18 (Part2)/Issue 1.

This Designers Guide will provide; 1) a synopsis ofthe standardand some frequently asked questionsand their answers, 2) aspecification comparison ofthe detailed uses of the standard, 3) areview ofsystem design considerations, and 4) a discussionof remoteterminal and bus controller designs.

1.0 MIL-STD-1553 OVERVIEWThe 1553 standard is organized similarto most mil-itary standards with a foreword, scope,referenceddocument section, definitions, general require-ments, theappendix, and a tri-service Notice 2.Notice 2, which supersedesNotice 1, was devel-oped to define which options of the standardarerequired to enhance tri-service interoperability andto furtherdefine some of the open-ended timingvariables implied within thestandard.

1.1 Key ElementsSome of the key MIL-STD-1553B elements arethebus controller, the embedded remote terminal (asensor orsubsystem that provides its own internal1553 interface), thestand-alone remote terminal,bus monitor, and two other devices thatare part of

the 1553 integration; the twisted shielded pair wiredata bus andthe isolation couplers that areoptional.

The bus controllers main function is to providedata flow controlfor all transmissions on thebus. In this role, the bus controlleris the sole sourceof communication. The system uses acommand/response method.

The embedded remote terminal consists of inter-face circuitrylocated inside a sensor or subsystemdirectly connected to the databus. Its primary job isto perform the transfer of data in and outof the sub-system as controlled by the bus controller. This typeofterminal usually does not have bus controllercapability. However,if the sensor itself is fairly intel-ligent, it can become acandidate for the backup buscontroller function. Generally, anintelligent sub-system (i.e., computer based) can become abackupbus controller if a second computer,equal in function to theprimary, is unavailable.

The stand-alone remote terminal is the only devicesolelydedicated to the multiplex system. It is used tointerface varioussubsystem(s), which are not 1553compatible with the 1553 data bussystem. Its primaryfunction is to interface and monitortransmission inand out of these non-1553 subsystem(s).

The bus monitor listens to all messages, and subse-quentlycollects data, from the data bus. Primaryapplications of this modeof operation include: col-lection of data for on board bulk storageor remotetelemetry; or use within a hot or off-lineback-upcontroller to observe the state and operational modeof thesystem and subsystems.

The fourth item is the data bus itself. The standarddefinesspecific characteristics for the twisted pairshielded cable. Notice2 tightens these requirementsand adds a definition for connectorpolarity.

The last item to be discussed is the data bus cou-pler unit thatisolates the main bus from the termi-nals. MIL-STD-1553B allows twotypes of data businterface techniques; direct coupling andtransformercoupling. Subsystems and 1553 bus elements areinterfacedto the main data bus by interconnectionbuses (called stubs). Thesestubs are either con-nected directly to the main bus or interfacedviadata bus couplers. The data bus couplers containtwo isolationresistors (one per wire) and an isola-tion transformer (with aratio of 1 to the square rootof 2). The purpose of the data buscouplers is to

DESIGNERS NOTES

I-1

I.DESIGNER'S NOTES

DESIGNERS NOTES

I-2

INTRODUCTIONMIL-STD-1553, Digital Internal TimeDivisionCommand/Response Multiplex Data Bus, is a mili-tarystandard (presently in revision B), which hasbecome one of thebasic tools being used today bythe DoD for integration of weaponsystems.The stan-dard describes the method of communication andtheelectrical interface requirements for subsystemsconnected to thedata bus. The 1 Mbps serial com-munication bus is used to achieveaircraft avionic(MIL-STD-1553B) and stores management(MIL-STD-1760B) integration. In the future it will be usedto extendthe systems integration to flight controls,propulsion controls, andvehicle management sys-tem (electrical, hydraulic, environmentalcontrol,etc.).

Several other documents exist, which are related toMIL-STD-1553.MIL-HDBK-1553 describes theimplementation practices for thisstandard includ-ing: design considerations, examples ofapplica-tions, and guidelines for implementations. PortionsofMIL-STD-1553 are also the foundation of the MIL-STD-1773(Fiber-optics), and MIL STD-1760B(Stores Management). In addition,MIL-STD-1553 isembodied in or referenced by the followinginterna-tional documents: NATO STANAG 3838, ASCC AirStandard 50/2,and UK DEF STAN 00-18 (Part2)/Issue 1.

This Designers Guide will provide; 1) a synopsis ofthe standardand some frequently asked questionsand their answers, 2) aspecification comparison ofthe detailed uses of the standard, 3) areview ofsystem design considerations, and 4) a discussionof remoteterminal and bus controller designs.

1.0 MIL-STD-1553 OVERVIEWThe 1553 standard is organized similarto most mil-itary standards with a foreword, scope,referenceddocument section, definitions, general require-ments, theappendix, and a tri-service Notice 2.Notice 2, which supersedesNotice 1, was devel-oped to define which options of the standardarerequired to enhance tri-service interoperability andto furtherdefine some of the open-ended timingvariables implied within thestandard.

1.1 Key ElementsSome of the key MIL-STD-1553B elements arethebus controller, the embedded remote terminal (asensor orsubsystem that provides its own internal1553 interface), thestand-alone remote terminal,bus monitor, and two other devices thatare part of

the 1553 integration; the twisted shielded pair wiredata bus andthe isolation couplers that areoptional.

The bus controllers main function is to providedata flow controlfor all transmissions on thebus. In this role, the bus controlleris the sole sourceof communication. The system uses acommand/response method.

The embedded remote terminal consists of inter-face circuitrylocated inside a sensor or subsystemdirectly connected to the databus. Its primary job isto perform the transfer of data in and outof the sub-system as controlled by the bus controller. This typeofterminal usually does not have bus controllercapability. However,if the sensor itself is fairly intel-ligent, it can become acandidate for the backup buscontroller function. Generally, anintelligent sub-system (i.e., computer based) can become abackupbus controller if a second computer,equal in function to theprimary, is unavailable.

The stand-alone remote terminal is the only devicesolelydedicated to the multiplex system. It is used tointerface varioussubsystem(s), which are not 1553compatible with the 1553 data bussystem. Its primaryfunction is to interface and monitortransmission inand out of these non-1553 subsystem(s).

The bus monitor listens to all messages, and subse-quentlycollects data, from the data bus. Primaryapplications of this modeof operation include: col-lection of data for on board bulk storageor remotetelemetry; or use within a hot or off-lineback-upcontroller to observe the state and operational modeof thesystem and subsystems.

The fourth item is the data bus itself. The standarddefinesspecific characteristics for the twisted pairshielded cable. Notice2 tightens these requirementsand adds a definition for connectorpolarity.

The last item to be discussed is the data bus cou-pler unit thatisolates the main bus from the termi-nals. MIL-STD-1553B allows twotypes of data businterface techniques; direct coupling andtransformercoupling. Subsystems and 1553 bus elements areinterfacedto the main data bus by interconnectionbuses (called stubs). Thesestubs are either con-nected directly to the main bus or interfacedviadata bus couplers. The data bus couplers containtwo isolationresistors (one per wire) and an isola-tion transformer (with aratio of 1 to the square rootof 2). The purpose of the data buscouplers is to

DESIGNERS NOTES

I-3

prevent a short on a single stub from shorting themain data bus.The selection of the value of theresistors, the transformers turnratio, and thereceiver impedance are such that the stub appearstothe main bus as a clean interface (i.e., highimpedance). Thistechnique reduces the distortioncaused on the main data bus by thetermination.The characteristics of the data bus couplers aredis-cussed in paragraph 4.2.4. Main buses utilizingdirect coupledstubs must be designed to withstandthe impedance mismatch of thestubs. This can bereduced by minimizing stub length (less thanonefoot) and tuning the bus by terminal spacing.Designs not usingdata bus couplers should becarefully analyzed and tested todetermine ifwaveform distortion is significant enough tocausereceiver problems. The other risk associ-ated with direct coupledstubs is a short on a stubwill cause the main bus to fail. Theobvious advan-tage to direct coupled stubs is the elimination ofthelogistical problems associated with another deviceand theinstallation problem of locating these smalldevices (approximately1 inch cube) in the aircraft.Today, data bus couplers and lineterminating resis-tors are available in molded packages, whichcanbecome part of the wiring harness, thus eliminatingsome of theinstallation problems. Also, multiple databus couplers and data busline terminating resistorsare available in single packages, whichreduces thenumber of unique units installed per aircraft.

1.2 Message TypesMIL-STD-1553 is a serial data bus based onmes-sage transmission. Therefore, considerable em-phasis is placedon the term information transferformats, which describe each of the10 messagetypes. Within these 10 message types are the for-matsused to achieve communication, the primaryfunction of the data bussystem. Each messageformat is made up of control words calledcom-mand and status. Data words are used toencode communicationbetween system ele-ments. Both control words and data words areusedin system communication as well as data bus sys-tem control.These message formats have beensubdivided into two groups by 1553Band are shownin figure I-1.1; the information transfer formatsandthe broadcast information transfer formats. Thesetwo groups canbe easily segregated because thebroadcast group does not conformdirectly to thecommand/response philosophy of the other(non-broadcast) message formats. Thiscommand/response philosophyrequires that allerror free messages received by a remote termi-nalbe followed by the transmission of a remoteterminal status word.This handshaking processvalidates error free message completion.Sincebroadcast message formats are transmitted to mul-tiplereceivers, a more detailed scheme is required tovalidate error freemessage reception (this method isdescribed in paragraph 1.4.2).Also, since address 31is used by all terminals receiving abroadcast mes-

Figure I-1.1 Information Transfer Formats

DESIGNERS NOTES

I-4

sage, subaddressing needs to be managed on adata bus systembasis rather than on a remote ter-minal basis. The ability todefine and use more than30 subaddresses is discussed in paragraph3.7.1.

The information transfer formats allow communica-tions betweentwo elements in the data bus systemthe bus controller and theremote terminal (RT). In1553, the bus controller is in control ofall commu-nication and it is the sole device allowed totransmitcommand words. Notice that all messages areinitiated by thebus controller using commandword(s).

Messages to a device (remote terminal) from thebus controllerare issued using a command word(see figure II1.2) containing theremote terminal'saddress, direction of message transmission(trans-mit/receive bit), subaddress (destination within thespecificremote terminal or subsystem), and theword count. The command wordis immediately fol-lowed by the appropriate number of datawordsspecified in the command word. The receiving ter-minalvalidates error free message reception bytransmitting a status word(see figure I-1.3),which contains information about its health.Usingthis technique, the bus controller can transmit datato anyterminal attached to the data bus. In a similarmanner, the buscontroller can initiate a command toa remote terminal, whichrequires the remote termi-nal to transmit a specific message to thebus con-troller. This is accomplished using the RT to buscon-troller message format. Similarly communication

can be established between two unique remoteterminals, when thebus controller commandsone terminal to receive data and the otherter-minal to transmit data. Neither the receiving northetransmitting terminal knows where the messageoriginated ordestined. Both will transmit statuswords in the proper formats.Each status word isevaluated by the bus controller to verify errorfreemessage completion. In addition to these threemessage formats,three control message formatsare provided to support data bussystem manage-ment. These formats are mode code formats allow-ingthe transmission of a command word and up toone data word from thebus controller to a uniqueremote terminal. The remote terminal'sresponseinvolves the transmission of a status word and up toonedata word upon receipt of the mode command.The use of each modecode will be discussed inparagraph 1.4.2.

Figure I-1.1 (con't) Information Transfer Formats

Figure I-1.2 Word Formats

DESIGNERS NOTES

I-5

Broadcast formats are identical to the nonbroad-cast formatsdiscussed above, except the buscontroller transmits commands usinga remoteterminal address of "31" (11111), which has beenreservedfor this function. All remote terminals withthe broadcast receptioncapability will receive thiscommand, validate error free messagereception,and establish a status word response, but thetrans-mission of the status word will be suppressed.Obviously, ifmultiple terminals simultaneouslytransmitted their status responsesa bus "crash"(undetectable message transmissions) wouldoccur. Ascan be seen by the RT to RT(s) transferformats (see figure I-1.1),the bus controller can setup a broadcast data reception for allterminals andthen command a single terminal (unique address)totransmit. Since the data bus system is required to fol-low thelast valid command, the unique terminal willtransmit its statusword (which will be ignored by theother terminals) followed by thespecified number ofdata words. This format allow a a subsystemtobroadcast its data directly to multiple users.Broadcast messagescan be validated using a trans-mit status or transmit last commandmode code (seeparagraph 1.4). Therefore, even broadcast mes-sageformats have a command/response approachto message validation, ifrequired by the systemdesign. Notice 2 of the standard allows forthe trans-mission by the bus controller of broadcast modecodes only(whereas Notice 1 forbid all broadcastmessages).This will ease thebus controller's over-head in performing such tasks asminor/majorframe synchronization.

1.3 Word Types The standard allows for only three types of wordsasdiscussed in the previous message format section;command word,status word, and data word. 1553requires each word to consist of 16bit of data plus, async pattern (3 bit times long), and a one bitparityproviding a 20 bit word format. The contents of each

word type is shown in figure II1.2.The command word provides thedefinition ofthe message format to be transmitted and canonly betransmitted by the bus controller. Asseen in the message formatsection, the commandword may be followed by data, anothercommandword, or a response time gap prior to statuswordtransmission by the remote terminal. The commandword syncpattern is a unique invalid Manchesterwaveform, which cannot beduplicated by data (seefigure I-1.3). The command word sync and thestatusword sync are identical and the inverse of the dataword syncpattern. Therefore, command and statuswords, which initiate asequence, can always bedistinguished from data word sync patterns.Thecommand word address is always the addressof the remote terminalbeing com- mended; abus controller does not have an address whileinthe active bus controller mode (backup bus con-trollers canfunction as an RT with a unique addressor as a bus monitor with noaddress until theybecome an active bus controller).Thetransmit/receive (T/R) bit indicates the direction offlow ofdata words (i.e., receive means data to bereceived by the remoteterminal). The subad-dress/mode code field has two purposes. Whenaunique terminal is to receive or transmit data, the sub-addressacts as an internal address to point to thetype of data desired,the location of a data pointerin memory, subsystem interface, etc.(see para-graphs 3.7.1 and 5.3 for further discussion onsub-addressing).

When the subaddress field is 00000 or 11111, itindicates thatthe next field contains the number ofthe mode code. The next field(word count/modenumber) contains the number of data word(s) inthemessage or the number of the mode code. Odd par-ity isestablished for all words based on the 16 bitsof data plus paritybit.

The data word contains a unique sync (three bittimes long), 16data bits, and a one bit parity. Norestrictions are placed on theencoding of the datafield, except that the "most significant bitshall betransmitted first." Once again, parity is oddandestablished on the 16 bits of data plus the parity bit.

Recently, there have been several efforts tostandardize on dataword formats for the morecommonly used functions. The Army andNavyhave recently developed data bases for some avion-icsequipment. The designer should check the statusof these effortsbefore establishing a unique set ofdata formats for the system.Section 80 (formerly

Figure I-1.3 Command and Status Word Sync

+ VOLTS

COMMAND & STATUSWORD SYNC

VOLTS

11/2 bits

11/2 bits

DESIGNERS NOTES

I-6

Chapter 11) of the "MiL-HDBK-1553 MultiplexApplicationsHandbook" has established guidelines for the development of dataword andmessage formats for data bus applications. (Seeparagraph3.9 for further discussion on system doc-umentation and InterfaceControl Documents.) Thestatus word utilizes the same sync format asthecommand word. The remote terminal address isplaced in thetransmitted status word for two rea-sons; so that the status wordcan be validated bythe bus controller (a remote terminal may alsovali-date the status word address field against that ofthe commandword's during an RT-RT messagetransfer), and so that the statusword will not bemisinterpreted by the other terminals as a com-mandword. Any status word transmitted, must con-tain valid informationat all times (i.e., following RTpower-up, during initialization,and during normaloperation). The message error bit is theonlyrequired status bit and it is used to identify mes-sages whichdo not pass the word or message val-idation tests of 1553 (1553Bparagraph 4.4.1.1 and4.4.1.2). MIL-STD-1553 requires this bit to beset ifa message fails to pass the tests and the statusword to besuppressed (NOT to be transmitted).This means that all messagesthat are NOT errortree will NOT have a responding status word.Thisallows the bus controller to timeout on the nostatus response, thusalerting the bus controller ofa failure condition. To obtain thestatus word withthe error bit set requires a transmit statusmodecode or transmit last command word mode codeto the terminal toretrieve the untransmitted sta-tus word (see paragraph 1.4.2). Theonly excep-tion is the illegal command option (see paragraph1.6.3).The instrumentation, service request, broad-cast command received,busy, subsystem flag,dynamic bus controller acceptance, andterminalflag bits are all optional and are discussed in para-graph1.4.1. Notice 2 tightens the requirements forremote terminalsemploying broadcast recognition,capability of dynamic bus control,RT built-in-test, orsubsystem built-in-test, by requiring the useof the bitsin the status word associated with these functions.Bitpositions 12 through 14 are reserved for future useand must betransmitted as zeros. To obtain usageof these bits requires DoDapproval (no approval hasbeen given as of 7/87). The last bit ofthe status wordis the odd parity bit, which is calculated in asimilarmanner to all other parity bits.

1.4 Options Within the StandardSince the standard covers a widevariety of designs,flexibility has been achieved without loss ofinter-face compatibility, by allowing options to be selected

by the user. If an option is selected, it MUST oper-ate per thestandard. If an option is not used in the design, it must followthe standard'sselected method (e.g., set a bit to zero ifunused).No alternative or options other than those spec-ified bythe standard are allowed. Notice 2 wasdeveloped to define whichoptions of the standardare required to enhance tri-serviceinteroperabilityand to further define some of the open-endedtim-ing variables implied within the standard. As statedpreviously,options are available in the followingareas; status word bits, modecodes, data busredundancy, and coupling techniques.

1.4.1 Status bitsThe optional status bits are; instrumentation,ser-vice request, broadcast command received, busy,subsystem flag,dynamic bus control acceptanceand terminal flag.

The instrumentation bit in the status field Is setto distinguishthe status word from the com-mand word. Since the sync field isused to distin-guish the command and status words from a dataword,a mechanism to distinguish command andstatus word is provided bythe instrumentation bit.By setting this bit to logic zero in thestatus word forall conditions and setting the same bit positioninthe command word to a logic one, the commandand status words areidentifiable. If used, thisapproach reduces the possiblesubaddresses in thecommand word to 15 and requires subaddress31(11111) to be used to identify mode commands(both 11111 and 00000are allowed). If the instru-mentation bit is not used, the bit willremain set tologic zero in the status word for all conditions.

The service request bit is provided to indicate tothe active buscontroller that the remote termi-nal is requesting service. Whenthis bit in the sta-tus word is set to logic one, the active buscontrollermay take a predetermined action (if only one actioncanoccur) or use the transmit vector word modecommand to identify thespecified request. Themessage format for acquiring this isdiscussedunder transmit vector word mode command(below).

For terminals implementing the broadcastoption, the broadcastcommand received bit isset to logic one when the proceeding validcom-mand word was a broadcast command (remoteterminals address 31).Since the broadcast messageformats require the receiving remoteterminals to sup-press their status responses, the broadcastcom-

DESIGNERS NOTES

I-7

mand receive bit is set to identify that the messagewas receivederror free. To allow the bus controller toexamine the status wordrequires the use of the transmit status word mode code orthetransmit last command word mode code. Thebroadcast command receivedbit will be reset, whenthe next valid command occurs if it is NOTone oftwo mode codes; transmit status word or transmitlast commandword. Therefore, to analyze the sta-tus word after a broadcastmessage hasoccurred requires a mode code message to auniqueterminal. The mode code message mustbe transmitted before any othermessage transmis-sion to that unique terminal in order to retrievetoproper status word.

The busy bit in the status word is set to logicone to Indicateto the active bus controller thatthe remote terminal is unable tomove data to orfrom the subsystem in compliance with thebuscontroller's command. A busy condition can existwithin a remoteterminal at any time causing it to benon-responsive to a command tosend data or toreceive data. This condition can exist for allmes-sage formats. In each case, except the broadcastmessageformats, the active bus controller will deter-mine the busycondition immediately upon statusresponse. In the case of thebroadcast message for-mats, this information will not be knownunless thereceiving terminals are analyzed using transmit sta-tusmode code after the broadcast message. If the sta-tus word has thebroadcast received bit set, the mes-sage was received and theterminal was not busy.Notice 2 to the standard discourages the useand exis-tence of busy conditions, as they affect the overallcom-munications flow on the bus, add overhead to the buscontroller,and may have adverse effects upon datalatency requirements withintime critical systems (i.e.,flight controls). A busy condition mustonly occur as theresults of a particular command or messagereceivedby the terminal and NOT due to an internalperiodicfunction. Thus for a non-failed terminal, the buscon-troller, with prior knowledge of the RT's characteristics,candetermine what actions (commands/messages)will cause an RT tobecome busy, thus preventing anyunnecessary busy conditions.

The subsystem flag bit is provided to Indicate tothe active buscontroller that a subsystem faultcondition exists and that databeing requestedfrom the subsystem may be invalid. The subsys-temflag may be set in any transmitted status word.If more than onesubsystem is interfaced to theremote terminal the subsystem flag isthe ORedresults of all subsystems.The only method available

in 1553B to determine subsystem(s) health is via anormalmessage. The use of the subsystem flag bitrequires considerablesystem control philosophy. Ifupon receiving the bit set, the buscontroller is to doanything other than stop all communication withtheterminal, a detailed protocol is required.

The system protocol must define the message (NOTa mode code)that the bus controller uses to poll thesubsystem to determine thereason the bit was set.This polling will provide system applicationsoftwarethe knowledge to determine the availability and sta-tus ofthe unit(s). If the unit(s) are usable, the sub-system flag bitmust be cleared so that troubleshoot-ing analysis does not occur,until another failureoccurs. This can be accomplished usingadditionalmessages or upon transmission of the first message.Thisprocess usually requires several transmissionsduring which time theremote terminal is NOT a partof the normal periodic data bustraffic. Obviously usersubsystems must deal with this temporarysituation;permanent loss of this data. Mode commands cannot be usedto acquire subsystem built-in-test results.

The next bit in the status word is provided toIndicate theacceptance of the bus controller'soffer to become the next buscontroller. The offerof bus control occurs when the presentlyactive buscontroller has completed its established message listandissues a dynamic bus control mode command tothe remote terminalthat is to be the next potentialcontroller. To accept the offer thepotential bus con-troller sets its dynamic bus control acceptancebit inthe status word and transmits the status word.Theestablishment of which controller should be the nextpotentialcontroller will be discussed in the systemdesign section (seeparagraph 3.2). For Air Forceapplications, Notice 2 prohibits thebus controller fromissuing a dynamic bus mode code, therefore thisbitwould always be set to zero.

The terminal flag bit is set to a logic one toIndicate a faultwithin the remote terminal. This bitis used in conjunction with thethree mode code com-mands, inhibit T/F flag, override inhibit T/Fflag, andtransmit BIT word. The first two mode code com-mandsdeactivate and activate the functional opera-tion of the bit.Thetransmit BIT word mode code com-mand is used to acquire moredetailed informationabout the terminal's failure. MostMIL-STD-1553B RTchip sets provide BIT word responses indicatingthehealth of the chip. Notice 2 requires implementation ofthis bitwithin the status word if the remote terminal iscapable of any formof self test (including what maybe performed internal to thevarious chip sets such as

DESIGNERS NOTES

I-8

Transmit- Broadcastreceive Mode code Function Associatedcommandbit data word allowed

1 00000 Dynamic bus control No No

1 00001 Synchronize No Yes

1 00010 Transmit status word No No

1 00011 Initiate self-test No Yes

1 00100 Transmitter shutdown No Yes

1 00101 Override transmitter shutdown No Yes

1 00110 Inhibit terminal flag bit No Yes

1 00111 Override inhibit terminal flag bit No Yes

1 01000 Reset remote terminal No Yes

1 01001 Reserved No TBD

1 01111 Reserved No TBD

1 10000 Transmit vector word Yes No

0 10001 Synchronize Yes Yes

1 10010 Transmit last command Yes No

1 10011 Transmit bit word Yes No

0 10100 Selected transmitter shutdown Yes Yes

0 10101 Override selected transmitter shutdown Yes Yes

1 or 0 10110 Reserved Yes TBD

1 or 0 11111 Reserved Yes TBD

data wraparound and data comparisons).1.4.2 Mode Codes The basicphilosophy of the information transfersystem is that it operates asa transparent commu-nication link. "Transparent" means that anapplica-tion's function does not need to be involved withthemanagement of communication. Obviously, theinformation transfersystem requires managementthat introduces overhead in the data bussystem.The command words, status words, status wordresponse gaps,and intermessage gaps are theoverhead. Within the command word themodecodes provide data bus management capability.The mode codes(see table I-1.1) have been dividedinto two groups; mode codeswithout a data word(00000-01111) and mode codes with a dataword(10000-11111). The use of bit 15 in the commandword to identifythe two types was provided to aid inthe decoding process. Also, theuse of a single dataword instead of multiple data words was adoptedto

simplify the mode circuitry.Generally, with these two types ofmode com-mands, all data bus system managementrequirements can bemet. Additional overhead isrequired by the system to maintain RThealth, sys-tem time control (synchronization), subaddressmessagemapping, aperiodic message control, ini-tialization/shutdownmessages, etc. The determina-tion of whether the command wordcontains a modecode is accomplished by decoding thesubad-dress/mode field (bit times 10-14). This field beingeitherall zero's [00000] or all one's [11111] indi-cates that the commandis a mode code and thatthe word count/mode code field (bit times1519)contain the mode code type. Notice 2 requires thatterminalsmust decode both indicators and that theymust not convey differentinformation. (Some earlierdesigns had used the [00000] indicatorfor the ter-minal hardware and the [11111] indicator for sub-systemhardware.

Table I-1.1 Assigned Mode Codes

Note: TBD to be determined.

DESIGNERS NOTES

Notice 2 also permits the broadcasting of modecodes. While thiscan reduce bus controller overheadin the areas of framesynchronization, it can haveadverse effects upon the system ifinadvertentlyissued (e.g., broadcast of a reset mode code).Thesystem's designer is cautioned to research the impli-cations ofthe use of the broadcast mode code com-mands beforeimplementation.

There is no particular reason for the numericalassignment of themode codes, except for dynamicbus control [00000], which waspreviously definedin 1553A. The separation of mode commands intotwocategories (with and without data words) isimportant to allow forcontrolled expansion of thestandard. By controlling the mode codecommandnumber and its definition, commonalty between var-iousterminals can be maintained. All undefined1unused] mode codes areconsidered Illegalcommands (see paragraph 1.6.3 for discussionofillegal command protocol). Notice 2 requires that allremoteterminals must implement the followingmode codes as a minimum: a)transmit status word,b) transmitter shutdown, c) overridetransmitter shut-down, and d) reset remote terminal. The buscon-troller must have the capability of implementing allmode codecommands. The message formats asso-ciated with mode commands areshown in figure I-1.1.

The dynamic bus control mode code [00000] isprovided to allowthe active bus controller a mecha-nism (using the informationtransfer system mes-sage formats) to offer a potential buscontroller(operating as a remote terminal) control of the databus.Only the single receiver command (uniqueaddress) is allowed to beissued by the active buscontroller. The response to this offeringof the buscontroller is provided by the receiving remote termi-nal,using the dynamic bus control acceptance bit inthe status word.Rejection of this request by theremote terminal requires that thepresently activebus controller must continue offering control tootherpotential controllers, the same controller, or remainincontrol. When a remote terminal accepts control ofthe data bussystem by setting the dynamic buscontrol acceptance bit in thestatus word, control isrelinquished by the presently active buscontrollerand the potential bus controller can then beginbuscontrol. Note that Notice 2 prohibits the bus controllerfromever issuing this mode command for Air Forceapplications.

Two mode codes are used to synchronize the databus system;synchronize without a data word and syn-

chronize with a data word. Synchronization informstheterminal(s) of an event time, to allow coordinationbetween theactive bus controller and terminals.Synchronization information maybe implicit in thecommand word [mode code 00001] or in the dataword[mode code 10001] following the commandword. If a data word isused, the definition of the bitsare the responsibility of thesystem designer andmay contain system information such as timingdata,data mapping pointers, etc. Paragraph 3.6 providesa systemdiscussion of the use of the synchronizewith data word mode codefor remote terminal syn-chronization and subaddress mapping withinaremote terminal for both periodic, aperiodic, andtime criticalmessages.

The status word associated with the transmit sta-tus word modecode [00010] is identical in format tothe status word transmittedwith every error freemessage. However, this is one of two modecodes,which do not change the state of the status word.Therefore,the status word returned with this modecode represents the statusword of the previousmessage NOT the status of the mode codemes-sage. Paragraph 5.2 provides a discussion on theaffects of backto back transmission of this modecode. This mode code gives the buscontroller theability to analyze problems associated with thepre-vious message. Using this approach, a bus con-troller canorganize the communication with a ter-minal to obtain erroranalysis data.

The initiate self-test mode command [00011] isprovided toinitiate built-in-test (BIT) circuitry withina remote terminal. Themode code is usually fol-lowed, after sufficient time for testcompletion, by atransmit BIT word mode command [10011] yield-ingthe results of the test. Notice 2 specifies that theRT receivingthis mode code must complete its testand have the results readywithin 100 milliseconds.The purpose of establishing an upper limitto theamount of time required to perform a reset is thatthe buscontroller, with this prior knowledge, isaware of the maximumamount of time that the con-troller will be off-line" or busy, andmay cease fur-ther communications with this terminal until suchtimehas elapsed. This prevents the bus controller'ssoftware fromcontinuously being vectored to errorhandling routines. The messageformats providedfor the initiate self-test mode command allowforboth individual requests and multiple requests(broadcast).Notice that the initiate self-test modecommand is associated withthe 1553 multiplexhardware only and NOT with the interfacingsub-system. Paragraph 5.2 discusses the problem of

I-9

DESIGNERS NOTES

separating subsystem self test and health statusmessages from RTtests in terminals with embed-ded RTs.

The transmit BIT word mode command [10011]provides the BITresults available from a termi-nal, as well as the status word.Typical BIT wordinformation for both embedded and stand-aloneremoteterminals include encoder-decoder failures,analogtransmitter/receiver failures, terminal controlcircuitry failures,power failures, subsystem interfacefailures, and protocol errors(e.g., parity,Manchester, word count, status word errors, andstatusword exceptions). The internal contents of theBIT data word areprovided to supplement theappropriate bits already available viathe statusword. Notice that the transmit BIT word within theremoteterminal ". . . shall not be altered by thereception of a transmitlast command or trans-mit status word mode code" received by theter-minal. This allows error handling and recovery pro-cedures tobe used without changing the error datarecorded in this word.However, the RT will onlysave the last command and the status codefield[of the status word] if the mode code transmit lastcommand ortransmit status word are transmit-ted. Broadcasting of this commandby the bus con-troller is not allowed. Another point, which needstobe mentioned again, is that the function of trans-mitting RT BITdata ". . . shall not be used to con-vey BIT data from theassociated subsystem[s]."See discussion on subsystem flag bit inparagraph1.4.1.

Four mode code commands are provided to controlthe transmittersassociated with terminals in a sys-tem. These commands can be sentto a singlereceiver or broadcasted to multiple users. Thetrans-mitter shutdown mode code [00100] is used in adual-redundantbus structure, where the commandcauses the transmitter associatedwith the other busto terminate transmissions. No data word isrequiredfor this mode command. The overrlde transmittershutdownmode code [00101] is used in a dual-redundant bus structure where apreviously disabledtransmitter is enabled. No data word is providedforthis mode code.

The selected transmitter shutdown mode code[10100] is used in amultiple (greater than two) redun-dant bus structure where thecommand causes theselected transmitter to terminate transmissionson itsbus. A data word is used to identify the selected databus.The override selected transmitter shutdownmode code [10101] is usedin a multiple (greater

than two) redundant bus structure where the com-mand allows theselected transmitter to transmit on its bus when commanded.Theformat of the data word associated with thesetwo mode commands isNOT controlled by the stan-dard and must be defined by the systemsdesigner.Another method of overriding the transmitter shut-downmode codes [00100 and 10100] is to issue areset mode code to theterminal.

Note that the standard or Notice 2 does notimply that issuanceof either the transmittershutdown or the selected transmittershutdownmode codes will cause the associated receiverto also beshutdown. If the receiver does not"shutdown," then the system'sdesigner shouldbe aware that the terminal may still be receivingandprocessing data (on the shutdown bus).Therefore, the bus controllershould remove the ter-minal from the active periodic communicationslist.

The inhibit terminal flag mode code [00110] is usedto set theterminal flag bit to zero in the statusword. When issued, thestatus word indicates anUNFAILED condition regardless of the actualfail-ure state of the terminal. This mode code is primar-ily usedto prevent continued Interrupts and errorhandling analysis when thefailure has been notedand the system reconfigured asrequired.Commanding this mode code prevents fur-ther failures frombeing reported, which normallywould be reported using the terminalflag in eachsubsequent status word response. The messageformatassociated with this mode code allows forboth single and multiplereceivers to be com-manded. No data word is required with thismodecode. Note that the terminal flag, which is used toindicate anRT fault condition is limited to the remoteterminal NOT anysubsystem faults. (See the previ-ous discussion on initiate selftest and transmit BlTword mode codes.)

The override inhibit terminal flag mode command[00110] negatesthe inhibit function thus allow-ing the T/F flag bit In the statusresponse toreport the present condition of the terminal.This modecode can be transmitted by the activebus controller to both singleand multiplereceivers.There Is no data word associated withthismode code. This mode code could be used toanalyze all the faultsthat exist in a remote terminal,since the inhibit terminal flagmode code will maskfaults that have occurred since itsimplementation.

The reset remote terminal mode code [01000]

I-10

DESIGNERS NOTES

causes the addressed terminal(s) to reset themselves toapower-on initialized state. This mode code may betransmitted to anindividual remote terminal or tomultiple remote terminals(broadcast). Notice 2requires that all terminals receiving thiscommandshall complete their reset function within 5 millisec-ondsfollowing the transmission of their status word(non-broadcastmessage). This mode code providesa means to "start over" at a knownpoint. It may bethe last thing the error handling software triesbeforegiving up on a terminal.

The transmit vector word mode code [10000] isassociated with theservice request bit in the statusword and is used to determinespecific servicebeing required by the terminal. The servicerequestbit and the transmit vector word mode commandprovide theonly means available for the terminal torequest the scheduling ofan asynchronous mes-sage, if more than one service request existsperterminal. If a remote terminal contains only a singleservicerequest, the bus controller may be "smartenough" to perform therequest without the trans-mit vector mode code data word to pointto thelocation of the commands within the bus controllerto performthe service. The message format for thissingle receiver operationcontains a data wordassociated with the terminal's response. FigureI-1.4 illustrates the message formats associated withthis modecommand. Since a service request Ishandled at the convenience ofthe bus con-troller and NOT the remote terminal's, a remoteterminaldesign feature Is required to queuemultiple service requests untilthey can be ser-viced by the bus controller. The transmission ofthetransmit vector word mode code by the buscontroller does notnecessarily release the remoteterminal to set the service requestbit for a newrequest. There are several methods that can beused toresolve this handshake problem. Whateverthe solution chosen by thesystems designer, itshould be applied to all terminals in thesystem.Thus, it's a system design issue, which should beaddressedin the multiplex system specification.Solutions that are acceptableto most designersare; after transmission of the transmit vectorwordcode allow new service request codes, and use ofthe synchronizewithout data word mode codecommand to release the RT to set a newservicerequest. However, the first method has the poten-tial oflosing a critical request if the transmit vectorword is notreceived properly by the bus controller.To counter this problem,previous designs haveused the second method to release theservice

request queue. The transmission of the synchro-nize without dataword mode code after properreceipt of the transmit vector mode codefrees theterminal's service request bit at the expense of anextratransmission.

The transmit last command [1001 0] is used inthe error handlingand recovery process to determinethe last valid command received bythe terminal,except for this mode code. The message formatcon-tains the previous status word and a data word. Thedata wordcontains the previous 16 bits of thelast valid command wordreceived. Notice that thismode command will not alter the state ofthe receiv-ing terminal's status word. This fact allows thismodecommand to be used in error handling and recoveryoperationswithout affecting the status word, whichcould contain added errorinformation. Some hard-ware is designed such that both the lastcommandword and the status word are made available to theerrorhandling software when the transmit last com-mand mode code isreceived by the bus controller.

Each of the mode code types (with and without datawords) haveseveral unused mode codes that arereserved for future use andcannot be used with-out the permission of the Office ofPrimeResponsibility (OPR), which Is the USAF. Seeparagraph 1.6.3fore discussion of illegal commandprotocol, that could be used if aremote terminalreceived a reserved mode code.

1.5 Data Bus Network ConsiderationsOne of the most significantconsiderations facing thedata bus system designer and integrator isthe defin-ition of the data bus network. The bus network mustbedesigned for signal integrity to achieve the biterror and worderror rate performance required bythe standard. In addition, faultisolation and redun-dancy must be considered to allow the designtomeet the required system reliability. It is important tonote thatone of the reasons for the requirements ofdual redundant standbysystems is system survival incase of battle damage to thecommunications media.The physical layout of the media, includingthe sepa-ration of cabling, location of couplers' length ofstubs,and the connection of the media to the terminals areofimportance not only from a maintainability point ofview, but alsoregarding system operation, survivabil-ity, fault isolation, andsystems security. The followingdiscussion provides a summary ofMIL-STD-1553Brequirements that have significant effects onthedesign.

I-11

DESIGNERS NOTES

I-12

Figure I-1.4 Transmit Vector Word Transfer Formats

SYNC REMOTETERMINALACCESS

STATUS WORD3

5

8

1 1 1

11 14 20

3 1 1 1 1 1 1

PA

RIT

Y

TE

RM

INA

L F

LAG

DY

NA

MIC

BU

S C

ON

TR

OL

AC

CE

PTA

NC

E

SU

BS

YS

TE

M F

LAG

BU

SY

BR

OA

DC

AS

T C

OM

MA

ND

RE

CE

IVE

D

RESERVED

SE

RV

ICE

RE

QU

ES

T

INS

TR

UM

EN

TAT

ION

ME

SS

AG

E E

RR

OR

Single Receiver Only Bus Controller to Remote Terminal*

COMMANDWORD

DATAWORD

DATAWORD

STATUSRESPONSE

CONTINUEDBELOW

Source: bus controllerAddress: unique 31Subaddress: unique 31and 32Data word count: 1-32T/R receiver

Source: single receiverService request bit set to 1

MODE CODECOMMAND

STATUSRESPONSE

DATAWORD

CONTINUEDBELOW

SYNC REMOTETERMINALACCESS

STATUS WORD3

5

8

1 1 1

11 14 20

3 1 1 1 1 1 1

PA

RIT

Y

TE

RM

INA

L F

LAG

DY

NA

MIC

BU

S C

ON

TR

OL

AC

CE

PTA

NC

E

SU

BS

YS

TE

M F

LAG

BU

SY

BR

OA

DC

AS

T C

OM

MA

ND

RE

CE

IVE

D

RESERVED

SE

RV

ICE

RE

QU

ES

T

INS

TR

UM

EN

TAT

ION

ME

SS

AG

E E

RR

OR

Source: bus controllerAddress: unique address of S/R statusresponseSubaddress: 31 or 32Mode code: 1000

Source: single receiver Service vector information

Service request bit set to 0(if no new service requests arepresent)

COMMANDWORD

STATUSRESPONSE

DATAWORD

DATAWORD

MASTERCONTROLLERRETURN TOSYNCHRONOUSBUS LIST

Source: bus controllerAddress: unique address of S/R statusresponseSubaddress: unique address of service vectorinformationT/R: transmit

Source: single receiver Asynchronousinformation

* Service request bit can be set for transmittal in any statusresponse (all control and data message formats)

Response time delay gapEnd of message delay or gap

DESIGNERS NOTES

I-13

1.5.1 MIL-STD-1553B Bus Network Requirements Table I-1.2 is asummary listing of the data bus cou-pling requirements contained in1553B. The charac-teristics of the twisted-shielded pair cable havebeenrelaxed from 1553A to allow selection of cable typesfrom avariety of manufactures. It has been shown that

minor variations from the specified fed cable charac-teristicsdo not significantly affect the system perfor-mance. Today it ispossible to obtain high qualitycabling from various manufacturerswhich meet all therequirements of the standard. Notice 2 tightenstheshielding requirements to 90.0 percent coverage for

Parameter MIL-STD-1553B

Transmission line

Cable type Twisted-shielded pair

Capacitance (wire to wire) 30 pF/ft, maximum

Twist Four per foot (0.33/in), minimum

Characteristic impedance, 70 to 85 ohms at 1.0MHz(Zo)Attenuation 1.5 dB/100 ft at 1.0 MHz, maximum

Length of main bus Not specified

Termination Two ends terminated in resistors equal toZo 2%

Shielding 75% coverage minimum

Cable couplingShort stub < 1 ft

Stub definition Long stub > 1 to 20 feet (may beexceeded)

Coupler requirement Direct coupledshort stub;transformercoupledlong stub (ref. fig. I-1.7)

Coupler transformerTurns ratio 1:1.41Input impedance 3,000 ohms,minimum (75 kHz to 1.0 MHz)Droop 20% maximum (250 kHz)Overshoot andringing 1.0V peak (250-kHz square wave with

100-ns maximum rise and fall time)Common mode rejection 45.0 dBat 1.0 MHzFault protection Resistor in series with eachconnection

equal to (0.75 Zo) + 2.0% ohms

Stub voltage 1.0V to 14.0V p-p, I-1, minimum signal voltage(transformer coupled); 1.4V to20.0V, p-p, I-1, minimum signalvoltage (direct coupled)

DESIGNERS NOTES

I-14

the cable and 360 degree shielding with 75.0 percentcoverage forconnector junctions, cable terminations,and bus-stub junctions.

A great deal of concern is attributed to the cable net-workrequirements including; bus length, couplingand stubbing.MIL-STD-1553B does not specify amaximum main bus length, becausethe cablelength, number of terminals and length of stubs areallsubject to trade-offs and must be considered inthe design forreliable system operation. To helpunderstand these problems ageneralized multiplexbus network configuration is shown in figureI-1.5.The main bus is terminated at each end of the cablewith thecharacteristic impedance to minimize reflec-tions caused bytransmission line mismatch. With nostubs attached, the main buslooks like an infinitelength transmission line with no disturbingreflections.When the stubs are added to connect terminals thebus isloaded locally and a mismatch occurs, whichcan result inreflections. The degree of mismatch andresulting signal distortionis a function of theabsolute impedance Z presented by the stubandterminal impedance. To minimize signal distortionit is desirableto maintain a high stub reflectedimpedance into to the main bus. Atthe same timethe impedance needs to be low so that adequate sig-nalpower will be delivered to the receiver. A trade-offand compromisebetween these conflicting require-ments is necessary to achieve thespecified signal-to-noise ratio and system error rate performance.Inaddition to these trade-offs, careful considerationmust be madein the determination of the type ofconnector used to connect theterminal to the bus.This consideration should include therequiredintegrity, isolation, and shielding (Notice 2 requires360degrees of shielding with a minimum of 75%

coverage from the cable to the connector). Otherissues, whichneed to be addressed, include thelocation and type of connector(concentric, twinax,etc.), and if the data bus connectors will bestand-alone or included with other signals in amulti-contactconnector. As a minimum, the two buses (A and B)shouldbe brought into the terminal via separate con-nectors for isolationpurposes.Two methods for coupling' a terminal to the mainbus aredefined in 1553B, transformer couplingand direct coupling (seefigure I-1.6). Transformercoupling is usually used with long stubs(1 to 20 ft.) andrequires a coupler box or in-line moldedcoupler,separate from the terminal, located at the junction ofthemain bus and stub. Direct coupling is usually lim-ited to stubs ofless than 1 ft. In transformer isolatedstubs, fault isolationresistors are included to provideprotection for the main bus incase of a short circuit inthe stub or terminal. The transformercharacteristicsdefined in 1553B and listed in table I-1.2 providesacompromise for the signal level and distortion charac-teristicsdelivered to the terminals. The transformerturns ratio (1 :1.41)provides beneficial impedancetransformations for both terminalreception and trans-mission.

The advantages of transformer coupling are as fol-lows:

(1) The 1:1.4 turns ratio increases the impedance ofthe stub andterminal by a factor of two, as seenby the main bus. This reducesthe loading effectsof the distributed capacitance of the stubcable.This is advantageous by reducing reflections onthe bus andincreasing the overall bus imped-ance.

Figure I-1.5 Data Bus Network

T1 T2 T (N-1) TN

MAIN BUS

STUB

ZoZo

DESIGNERS NOTES

I-15

(2) For a direct coupled terminal, the impedance ofthe stub, asviewed from the secondary side ofthe terminal isolationtransformer, is 2Zo. For atransformer coupled terminal, thisimpedance isZo. Allowing the terminal to drive into amatchedimpedance improves the terminal's transmitterwaveform byminimizing reflections back to theterminal.

(3) Improved DC isolation.

(4) Improved common mode rejection:

Notice 2 states that for Navy applications, termi-nals shallhave both transformers and directcoupled stubs available, whereasfor Army andAir Force applications, only transformer cou-pled stubsare required.

1.5.2 Data Bus Network AnalysisA plot of the calculatedfirst-order-magnitude stubabsolute impedance Z versus stub lengthis pre-sented in figure I-1.7. As indicated, the improvementof stubload impedance is a result of impedancetransformation that isproportional to the square ofthe turns ratio, assuming an idealtransformer. Theband of curves for the transformer-coupledcaseindicated by the darkened area between the curvesresults fromassuming various values of transformershunt impedance. The lowerbound is the curveusing a transformer with the minimumimpedancespecified in 1553B. The upper bound is for anidealtransformer with very high impedance. All values ofstubimpedance are magnitude values for a 70-ohm

cable with 30 pF/ft capacitance and are calculatedfor 1,000 ohmsterminal input impedance, with theexception of the upperdirect-coupled curve. Thiscurve is based on the 1553B specifiedterminal inputimpedance of 2,000 ohms. It can be seen fromthesecurves that stub impedance values are increasedgenerally byuse of the transformer, which providesat least a 2 to 1 improvementfor the longer (greaterthan 10 ft) stubs. The curves also show theimpor-tance of the transformer characteristics for maintain-ing theexpected improvement.

As indicated above, the 1:1.41 transformer also pro-vides idealtermination of the stub for transmission ofsignals from theterminal to the main bus.Impedance at the main bus is:

ZB = Zo + 2Rwhere,

R = 0.75 Zo

ZB = 0.5 Zo +1.5 Zo = 2 Zo ohms

Zo is the characteristic impedance of the data busand ZR is thereflected impedance from the bus tothe stub. Therefore, thetransformer impedancetransformation is:

ZB 2ZoZR = = = Zo(1.41)2 2

Therefore, the coupling transformer specified in1553B providesthe characteristics desired forreducing reflections and maintainingsignal lev-els for systems where long stubs are required.

Figure I-1.6 Transformer Coupled and Direct Coupled Stubs

DESIGNERS NOTES

I-16

Direct coupling can be used for stub connections of3 ft or lessif terminal input impedance is main-tained at the specifiedvalue:Many configurations can be built reliably if carefulattentionis paid to the number, length and location ofthe stubs on the mainbus. It is highly desirable totest a proposed network using acomputer simu-lation and a laboratory test setup. Thecomputer-generated data bus simulation provides more flexibil-ityduring the early design stages. The laboratorymockup with properlengths of main bus and stubs isthe final test of a gooddesign.

1.6 The Most Frequently Asked QuestionsConcerning MIL-STD-1553In an effort to help designers understand MIL-STD-1553, thissection discusses some of the more fre-quently misunderstoodportions of 1553 systems.Since 1553 is a standard and not aspecification, itesta