BepiColombo MIL-STD-1553B Bus Protocol...

Specification BepiColombo

Doc. No: BC-ASD-SP-00016 EADS Astrium GmbH of 87 Issue: 2 File: BC-ASD-SP-00016_2_MIL-Bus-Specification.doc Date: 06.08.2007

Change Record

Issue Date Sheet Description of Change Release 1 15.02.07 all first issue for SRR Data Package 2 06.08.07 all Second issue, completely restructured and reworked:

• Usage of Mode-Codes and Status Word Bits • Framing Scheduling • Time Synchronisation • Data/Block Transfer Protocol • Mil-Bus FDIR



Table of Contents

1 INTRODUCTION..................................................................................................................8 1.1 Scope .....................................................................................................................................8 1.2 Objective of Document........................................................................................................9 1.3 Summary Description .......................................................................................................10 1.4 Acronyms & Abbreviations ..............................................................................................11 1.5 Definitions of Terms ..........................................................................................................12

2 DOCUMENTS......................................................................................................................14 2.1 Applicable Documents.......................................................................................................14 2.2 Applicable Standards ........................................................................................................14 2.3 Reference Documents ........................................................................................................14

3 PHYSICAL LAYER............................................................................................................15 3.1 Bit and Field Numbering Conventions ............................................................................15 3.2 BepiColombo MIL-STD-1553B Bus Topology ...............................................................15 3.3 Physical Level Requirements............................................................................................17

4 DATA LINK LAYER ..........................................................................................................18 4.1 Bus Controller Functions and Operation........................................................................18 4.2 Remote Terminal Functions .............................................................................................19

4.2.1 RT Initialisation .......................................................................................................19 4.3 Message and Word Formats.............................................................................................20

4.3.1 Command Word.......................................................................................................20 4.3.1.1 Remote Terminal Address Field ..........................................................................20 4.3.1.2 Transmit/Receive (T/R) Bit Field ........................................................................22 4.3.1.3 Subaddress / Mode Field.......................................................................................22 4.3.1.4 Data Word Count / Mode Code Field..................................................................26 4.3.2 Data Words...............................................................................................................32 4.3.3 Status Words ............................................................................................................32 4.3.3.1 Message Error Bit .................................................................................................33 4.3.3.2 Instrumentation Bit...............................................................................................34 4.3.3.3 Service Request Bit................................................................................................34 4.3.3.4 Broadcast Command Received Bit ......................................................................35 4.3.3.5 Busy Bit ..................................................................................................................35 4.3.3.6 Subsystem Flag Bit ................................................................................................36 4.3.3.7 Dynamic Bus Control Acceptance Bit .................................................................36 4.3.3.8 Terminal Flag Bit ..................................................................................................37 4.3.3.9 Status Word Reset/Update ...................................................................................37



5 TRANSFER LAYER ...........................................................................................................38 5.1 Message Formats and Timing ..........................................................................................38

5.1.1 BC to RT Data Message (Receive Message) ..........................................................39 5.1.2 RT to BC Data Message (Transmit Message) .......................................................40 5.1.3 Mode Command without Data Word Message .....................................................40 5.1.4 Mode Command with Data Word from RT Message...........................................41 5.1.5 Mode Command with Data Word from BC Message...........................................41 5.1.6 Broadcast BC to RT Command Message ..............................................................42 5.1.7 Broadcast Mode Command with Data Word from BC Message ........................42 5.1.8 Message Timing Requirements...............................................................................43 5.1.9 Message Validation ..................................................................................................44 5.1.10 Max Busy Bit Set Times ........................................................................................44 5.1.11 Data Wrap-Around................................................................................................45

5.2 General Requirements ......................................................................................................45 5.2.1 Communication with Non-Packet Terminals........................................................45 5.2.2 Communication with PUS-Packet Terminals and MMO ....................................46

5.3 Frame Scheduling..............................................................................................................47 5.3.1 Frame Timing...........................................................................................................49 5.3.2 Frame Synchronisation ...........................................................................................51 5.3.3 Frame Utilisation .....................................................................................................52 5.3.4 BC Message Sequence Control ...............................................................................54 5.3.5 Bus Loading..............................................................................................................55

5.4 Time Synchronisation .......................................................................................................56 5.4.1 Synchronise Mode Command Procedure ..............................................................57 5.4.2 PPS-based Synchronisation Procedure..................................................................58

5.5 Block Transfer Protocol....................................................................................................58 5.5.1 General......................................................................................................................58 5.5.2 BC to RT Block Transfer (Command Distribution).............................................61 5.5.3 RT to BC Block Transfer (Data Acquisition)........................................................63

5.6 Event Data Acquisition .....................................................................................................65 5.7 Commanding and Data Acquisition of Non-Packet Terminals.....................................68

5.7.1 MPO-PCDU, MTM-PCDU, DST, MORE (tbc) and BERM (tbc) ......................68 5.7.2 MPO-SADE, MTM-SADE and APME (HGA & MGA)......................................70 5.7.3 IMU ...........................................................................................................................72 5.7.4 MPCU-CPS-I/O (TBC)............................................................................................73

5.8 Commanding and Data Acquisition of PUS-Packet Terminals ....................................75 5.9 Commanding and Data Acquisition of MMO.................................................................77

5.9.1 MMO Telemetry Acquisition..................................................................................77 5.9.2 MMO Commanding.................................................................................................79

6 MIL-BUS FDIR (TBC)........................................................................................................81 6.1 Error Processing on BC Hardware Level .......................................................................81 6.2 Error Processing on BC Software Level .........................................................................83 6.3 Mil-Bus Failure Isolation Procedure ...............................................................................84



List of Figures

Figure 3.2-1: BepiColombo MIL-STD-1553B Bus System Topology.......................... 16

Figure 4.3-1: MIL-STD-1553B Word Types & Formats............................................... 20

Figure 4.3-2: Transmit Vector Word Transfer ............................................................... 30

Figure 5.1-1: Information Transfer Formats .................................................................. 38

Figure 5.1-2: Broadcast Information Transfer Formats ................................................. 39

Figure 5.1-3: BC to RT Data Message Format and Timing........................................... 39

Figure 5.1-4: RT to BC Data Message Format and Timing........................................... 40

Figure 5.1-5: Mode Command without Data Word Message Format and Timing ........ 40

Figure 5.1-6: Mode Command with Data Word from RT Message Format and Timing41

Figure 5.1-7: Mode Command with Data Word from BC Message Format and Timing41

Figure 5.1-8: Broadcast BC to RT(s) Data Message Format and Timing ..................... 42

Figure 5.1-9: Broadcast Mode Command with Data Word Message Format and Timing42

Figure 5.3-1: Mil-Bus Scheduling (Major Frame / Minor Frame / Message Slot) ........ 48

Figure 5.5-1: Block Transfer Descriptor Words ............................................................ 60

Figure 5.5-2: BC to RT Block Transfer (simplified) ..................................................... 61

Figure 5.5-3: RT to BC Block Transfer (simplified) ..................................................... 63

Figure 6.2-1: Recovery as a Function of 1553B Error Conditions ................................ 84

Figure 6.3-1: Mil-Bus Failure Isolation procedure (simplified) .................................... 85



List of Tables

Table 4.3-1: RT Address Allocation .............................................................................. 21

Table 4.3-2: Sub-Addresses Allocation for BepiColombo ............................................ 23

Table 4.3-3: MIL-STD-1553B Mode Code Requirements for BepiColombo ............... 27

Table 4.3-4: Vector Word Format for Aperiodic Message Demand from RT............... 31

Table 4.3-5: Vector Word Format for Aperiodic Action Demand from RT.................. 31

Table 4.3-6: Status Word Bit usage for BepiColombo .................................................. 33

Table 5.3-1: MPO Framing/Phasing Requirements (TBC)............................................ 53

Table 5.3-2: MTM Framing/Phasing Requirements (TBC)........................................... 54

Table 5.3-3: MMO Framing/Phasing Requirements (TBC) .......................................... 54

Table 5.4-1: RT Synchronisation Procedure Allocation ................................................ 56

Table 5.4-2: MIL-STD-1553B SCET Distribution Format ........................................... 57

Table 5.7-1: TM Data Trigger Command Word ............................................................ 69



1 Introduction

BepiColombo is an Interdisciplinary Cornerstone Mission to the planet Mercury, in collaboration between ESA and ISAS/JAXA of Japan. It consists of two scientific orbiters, the Mercury Planetary Orbiter (MPO) and the Mercury Magnetospheric Orbiter (MMO), which are dedicated to the detailed study of the planet and of its magnetosphere.

The mission will commence in 2013 with the launch of the Mercury Composite Spacecraft (MCS) on Soyuz Fregat. Following a long interplanetary cruise, powered by the Mercury Transfer Module (MTM), the Mercury Planetary Orbiter (MPO) and the Mercury Magnetospheric Orbiter (MMO) will be delivered to their planetary orbits in 2019. The nominal mission will be completed by the end of 2020 with a possible extension of one more year.

The key challenges of the mission are to provide a safe transfer of the spacecraft carrying the scientific instruments to Mercury and to ensure successful science operations of both orbiters under extreme environmental conditions.

1.1 Scope Based on the applicable MIL-STD-1553B Notice 4 standard [SD-1], this specification comprises the contractually relevant requirements and constraints for the BepiColombo command/control data communications bus.

This includes:

• The performance requirements of subject hardware and software.

• The design and interface requirements of the MIL-STD-1553B system.

• The testing and verification requirements.

This specification covers the MIL-STD-1553B protocol extensions (network, transport, and service layers) in order to give comprehensive requirements specification of the MIL-STD-1553B system necessary for the BepiColombo mission.

Requirements within this document are shown in an italic font. Each requirement is preceded by a summary line that contains the following fields, delimited by "/".

• Doors Requirement Number

• Created From

• Verification Method

The Doors Requirement Number has the form "BUS-xxx" where xxx is a unique number assigned consecutively.

The Created From field shows the parent requirement or "Created" if the requirement is created at this level.

The Verification Method codes are as follows:



• D - Definition

• S - Similarity

• R - Review

• A - Analysis

• I - Inspection

• T - Test

If tables are considered as part of the requirement they are referenced clearly in the text and inserted after and separated from the requirement table and are managed as free text attached to the identifier requirement.

The trace to the upper level requirements (Upper Links), shall be managed using the following format:

• AAA-NNN where AAA is a label assocoated to the upper document and NNN the requirement identifier of this upper level.

• or CREATED keyword if the requirement has no link with upper level.

All document elements not presented in the format explained above are not requirements and will not be verified or tracked.

1.2 Objective of Document The document in hand is the basis for the design of all BepiColombo MCS units connected to the MPO-, MTM- and MMO-MIL-STD-1553B-bus which are used as common serial data busses for communication between the OBC, executing the Central Software (CSW), and the

• STR-1, STR-2, STR-3, IMU, BERM, MPO-PCDU, MPO-SADE, APME, DST-1, DST-2, KaT (MORE)

• MTM-PCDU, MTM-SADE, MPCU (MEPS and CPS-I/O)

• MMO

The specification provides the applicability of the requirements to the following BepiColombo items:

• On-board Computer (OBC) that is the unique Bus Controller (BC) within the BepiColombo MIL-STD-1553B system. The OBC provides the physical/signal and the data link layers and supports the network layer.

• Central Software (CSW) that executes the higher levels of protocol on the BC side.

• Mil-Bus Terminals (RT) defined as PUS-Packet Terminals which receive packets from and send packets to the BC.

• Mil-Bus Terminals (RT) defined as Packet Terminal (MMO) which receive packets from and send packets to the BC.



• Mil-Bus Terminals (RT) defined as Non-Packet Terminals which are adapted via low-level protocol based on Mil-Bus messages.

• Harness that encompasses all the MPO, MTM, MMO cabling system elements from the Bus Controller to all the Remote Terminals: connectors, cables, shields, couplers, terminators, stubs.

The document comprises the contractually relevant technical requirements and constraints for the MIL-STD-1553B data bus so enabling the different parties involved to design, develop and test their part with respect to the common data bus.

Consequently the document establishes the performance as well as design and interface requirements for the OBC as Bus Controller (BC), the Remote Terminals (RTs) and the Central Software (CSW).

The conceptual basis of this document is the establishment of a MIL-1553B protocol for BepiColombo with a complexity as low as possible but fulfilling all higher level system requirements. This is aimed to suport cost-saving and flawless implementation on the one hand, and straight forward verification on the other hand. The following rules have been obeyed:

• The protocol omits using all of the features available in the MIL-STD-1553B [SD-1]. E.g. only those bits from the status word have been selected which provide essential information to the bus controller.

• A high degree of determinism is pursued.

• No auto-retry on the protocol level is foreseen (TBC). This is due to the experience that random errors on the MIL-Bus are very rare and persistent errors require system FDIR measures.

1.3 Summary Description This document includes all technical requirements to the specified MIL-STD-1553B items.

• Chapter 1 includes definitions, lists of acronyms and abbreviations.

• Chapter 2 lists references to related documents and standards.

• Chapter 3 provides definition of physical level incl. Bus-Topology and bit/field numbering conventions.

• Chapter 4 specifies the data link layer requirements: BC and RT function, Message and Word formats providing physical addressing and use of Mode-commands and Status Word bits.

• Chapter 5 specifies the Transfer layer requirements, which covers bus configuration, transfer control requirements covering the transport of all anticipated profiles of 1553 messages, Frame scheduling and the synchronisation requirements.

• Chapter 6 provides Mil-bus FDIR requirements.



The BepiColombo On-Board Electrical System makes use of the MIL-STD-1553B bus architecture.

For communication between the On-board Computer (OBC) with the various equipments and Payload, the following dual redundant MIL-STD-1553B bus systems will be implemented onboard BepiColombo:

• MPO-1553B-Bus dedicated to the communications with MPO platform equipments (incl. payloads KaTranslator, BERM)

• MTM-1553B-Bus dedicated to the communications with the MTM platform equipments

• MMO-1553B-Bus dedicated to the communications with the MMO (Payload)

This document defines all MIL-1553B-Bus interface protocol relevant requirements up to the protocol extensions to properly use the bus on system level.

No electrical connection between these three Mil-Buses exists.

No functional connection between these three Mil-Buses exists within the scope of this protocol specification.

As a result, the item designer finds all 1553 relevant requirements in this document plus in [SD-1] and [SD-2].

The design and interface requirements on signal level of the MIL-STD-1553B system are covered in chapter 3.6.4 of [AD-1] applying to

• On-board Computer (OBC) as Bus Controller (BC)

• Mil-Bus Terminals (RT) defined as PUS-Packet Terminals

• Mil-Bus Terminals (RT) defined as Packet Terminal (MMO)

• Mil-Bus Terminals (RT) defined as Non-Packet Terminals

• Harness that encompasses all the MPO, MTM, MMO cabling system elements from the Bus Controller to all the Remote Terminals: connectors, cables, shields, couplers, terminators, stubs.

Data entities transferred to and from "Packet Terminals" are termed "block" for distinction from PUS packets. The detailed structure of blocks is specified in this document.

Unless specific items require distinction of the three busses, all definitions and requirements apply for all of them.

1.4 Acronyms & Abbreviations APME Antenna Pointing Mechanism Electronics

BC (1553) Bus Controller

CPS-I/O Chemical Propulsion Subsystem Input/Output

CSW Central Software



FDIR Failure Detection, Isolation and Recovery

GDIR General Design & Interface Requirements Specification

HK Housekeeping

ICD Interface Control Document

MEPS Mercury Electric Propulsion Subsystem

MPCU MTM Propulsion Control Unit

MMO Mercury Magnetometer Orbiter

MPO Mercury Planetary Orbiter

MTM Mercury Transfer Module

MTL Mission Timeline

OBC On-board Computer

OBT On-Board Time

PCDU Power Control & Distribution Unit

RT (1553) Remote Terminal

SA Subaddress

SADE Solar Array Drive Electronics

SCET SpaceCraft Elapsed Time

STR Star Tracker

TC TeleCommand

TM TeleMetry

DST Deep SpaceTransponder

1.5 Definitions of Terms For general definitions and terms refer to [SD-1] and [SD-2].

In addition the following definition of terms and additional explanations apply:

Aperiodic: Events occurring at indefinite or unscheduled time periods. This term is used to describe the timing of messages that are not assigned a regular transmission update rate. “Asynchronous” is another word used to express the same condition.

Central Software: That software that is dedicated to spacecraft management, operations execution, AOCS, payload management, data management, etc. This distinguishes Central Software from the central computer (OBC) and its Basic Software providing basic Bus Controller functionalities.



Data Wrap-Around: Many RTs include a “data wrap-around” function, in which data words sent to the RT with a receive command are send back to the bus controller with a subsequent transmit command.

Fail-Safe Timer: MlL-STD-1553B requires (4.4.1.3 of 1553B) that every RT or BC contain a hardware timer to prevent any transmission on the bus longer than 800 us. Since no valid transmission is longer than 660 us, only a failure in the terminal could result in a transmission of 800 us or longer. The fail-safe timer is required to prevent such a failure from causing a continuous transmission on the bus and thus rendering it (the bus) unusable for other transmissions.

Frame Structure: The frame structure of the multiplex data bus consists of a major frame of 1second in duration which is composed of eight minor frames of 125 ms in duration.

Example of frame allocation: Within each minor frame, all data to be transmitted at a 8-Hz rate are transmitted at the beginning of the frame. During each odd-numbered minor frame, following the transmission of the 8-Hz data, all 4-Hz data transfers occur. During minor frames 4 and 8, following transmission of the 8-Hz data, all 2-Hz data transmissions occur. All 1-Hz data transmissions occur during minor frames 2 and 6, in order to evenly distribute the1-Hz data load.

The frame structure is specified, including major and minor frame times, and transfers to occur in each of the frames. The specified structure accommodate the maximum update rates required for time critical messages, while at the same time providing an adequate schedule reserve for error recovery procedures, synchronization, aperiodic message traffic, and system growth.

Illegal Commands: A valid command that is not implemented in the receiving RT.

Message: In 1553 terms, a message is a part of an information transfer format, such as 1 to 32 data words. A message may also refer to the entire transmission by both bus controller and responding remote terminal, which includes not only the data words but the overhead. This second usage is more correctly called an information transfer format.

Mode Code: A means by which the bus controller can communicate with the multiplex-bus-related hardware in order to assist in the management of the information flow.

Mode Command: An information transfer format with the subaddress/mode field in the command word set to indicate that the next following field is a mode code. An RT that implements Mode Commands is required to know that a subaddress/mode field in a Command Word equal to 00000 or 11111 defines a Mode Command, and that, in this case, the Word Count field is to be treated as the Mode Code rather than the number of words.

Polling: This is the method of communicating with multiple terminals within a system to determining information transfer priorities or servicing needs. RTs might be polled to determine whether they have aperiodic or high priority messages to transmit, state of health, or capability of accepting bus control.



2 Documents

2.1 Applicable Documents

BUS-23/Created/

[AD-1] BC-ASD-SP-00001, BepiColombo General Design and Interface Requirements (GDIR)

2.2 Applicable Standards

BUS-20/Created/

[SD-1] MIL-STD-1553B Notice IV, Digital Time Division Command/Response Multiplex Data Bus.

BUS-21/Created/

[SD-2] MIL-HDBK-1553A Multiplex Applications Handbook, Department of Defense, that shall be applied as follows:

• Section 100: RT Validation Test Plan shall apply and Remote Terminal Contractors shall use it to certify the conformance of their RTs.

• All the other sections contain guidelines and examples.

2.3 Reference Documents

[RD-1] BC-ASD-IF-00019, BepiColombo Space-to-Ground Interface Control Document (SGICD) Vol. 2 (Generic Packet Structure)

[RD-2] ECSS-E-70-41A, Telemetry and telecommand packet utilization, 30 January 2003



3 Physical Layer

3.1 Bit and Field Numbering Conventions The general Bit numbering and priority conventions defined in [SD-1] are defined in [AD-1] (GDI-2734, -2735).

BUS-409/Created/T

For 2-byte information, "byte 0" shall represent the most significant byte and "byte 1" the least significant byte. "Byte 0" (starting from the left) shall be transmitted first.

BUS-410/Created/T

For 4-byte information, "byte 0" shall represent the most significant byte of the high order word, the low order word shall start at "byte 2" with the least significant byte being "byte 3". "Byte 0" (starting from the left) shall be transmitted first.

BUS-413/Created/T

For a 32-bit floating-point value, "byte 0" shall represent the byte containing the sign bit and the exponent most significant bits, "byte 3" shall represent the least significant bits of the mantissa (according to IEEE-STD-754).

BUS-414/Created/T

For a 64-bit floating-point value, "byte 0" shall represent the byte containing the sign bit and the exponent most significant bits, "byte 7" shall represent the least significant bits of the mantissa (according to IEEE-STD-754).

3.2 BepiColombo MIL-STD-1553B Bus Topology The BepiColombo MIL-STD-1553B bus system/topology implements three separate, each dual-redundant, data busses as shown in Figure 3.2-1:

• one for the BepiColombo MPO,

• one for the MTM and

• one for the MMO.

BC and RT's are connected to the data bus through transformer coupled stubs.



MPCU

CPS-I/O

STR-3

STR-2

OBC

PM-BPM-A

MTM-SADEMTM-PCDU

MPO-SADEMPO-PCDU

C

MTMBC

N R

MPOBC

N R

MM

OBC N

R

MTMBC

N R

C

Z

C C ZC CC C

Z

MMO

RT

NR

C

Z

CC C

DST-1

MPO1553B-Bus C

DST-2

C

KaT

CC CC ZCC

STR-1

CC

IMU

Z

C

C C C

C C

Test

MM

OB

C

NR

UmbilicalConnectors

UmbilicalConnectors

MMO 1553B-Bus

C

BERM

SkinConnectors

MTM 1553B-Bus

APME

MPOBC

N R

Test

SkinConnectors

C

BA

BARTN R

RTN R

BARTN R

RTN R

BARTN R

RTN R

BARTN R

RTN R

RTN R

RTN R

RTN R

RTN R

RTN R

RTN R

RTN R

RTN R

RTN R

BA

RTN R

RTN R

BA

RTN R

RTN R

MEPS

C C

BA

RTN R

RTN R

Figure 3.2-1: BepiColombo MIL-STD-1553B Bus System Topology

BUS-276/Created/R

Each BepiColombo MIL-STD-1553B-bus system and participant shall be compliant to the redundancy concept as defined in chapter 3.6.4 of [AD-1].

BUS-282/[SD-1]/T,R

Signals shall only be allowed to appear on one of the two 1553 Data Buses at a time.

Note: Failure recovery on higher software level will lead to switch over to redundant bus.

BUS-280/[SD-1]/T

The RT shall have the capability to distinguish on a message basis which of the redundant bus is in use.

(Hence no dedicated discrete signal from BC to RTs shall be required for bus selection designation between bus A and bus B.)

BUS-734/Created/T,R

No RT to RT Data Transfer shall be implemented.



3.3 Physical Level Requirements

The physical level requirements

• electrical signal characteristics

• cables, connectors, transformer-coupled stubs

• RT address connector

• shielding etc

for BepiColombo MIL-STD-1553B bus systems are defined in [AD-1] chapter 3.6.4.



4 Data Link Layer

4.1 Bus Controller Functions and Operation

BUS-733/Created/T

The (redundant) Onboard Computer (OBC) shall act as the Bus Controller (BC).

BUS-403/Created/T

The BC shall be able to send Mil-Bus messages to the units or instruments working as Remote Terminals (RT) on the Mil-1553B-busses.

At least the following Mil-1553B-bus data transfer functions shall be provided:

• BC to RT Data Transfer

• RT to BC Data Transfer

• Mode Command without Data Word

• Mode Command with Data Word from RT (Transmit)

• Mode Command with Data Word from BC (Receive)

• Broadcast for frame synchronisation

BUS-281/[SD-1]/T

The BC shall have the capability to use either of the two buses for communication on message basis.

This means that the BC shall have the capability to distinguish on a message basis which bus is in use.

BUS-405/Created/T

The BC shall support the RT Subaddress Allocation as defined in section 4.3.1.3 of this document

BUS-404/Created/T

The BC shall support Mode Commands as defined in section 4.3.1.4 with the corresponding patterns.



4.2 Remote Terminal Functions

BUS-16/Created/T

All spacecraft units or instruments connected to the Mil-1553B-busses shall act as Remote Terminals.

BUS-58/Created/T

All RTs shall operate in response to valid commands received from the BC.

BUS-59/Created/T

No RT shall speak on the 1553 Data Bus unless spoken to first by the BC and specifically commanded to transmit.

BUS-94/Created/T

Each RT shall support the RT Subaddress Allocation as defined in section 4.3.1.3 of this document.

BUS-84/Created/T

The RTs shall support Mode Commands as defined in section 4.1.4.4 with the corresponding patterns.

BUS-128/Created/T,R

RTs shall support broadcast messages.

4.2.1 RT Initialisation

BUS-273/[SD-1]/T

Remote terminals shall sample the terminal address wires during power-on or reset.

BUS-272/[SD-1]/T

The RT shall perform a parity test upon the wired terminal address. Odd parity shall be used in checking the parity of the wired terminal address. Further details are defined in chapter 3.6.4 of [AD-1].

BUS-274/[SD-1]/T

If the parity of the wired terminal address is found incorrect, the terminal shall stop initialisation and no command messages shall be responded.



4.3 Message and Word Formats The MIL-STD-1553B word formats - Command Word, Data Word and Status Word - as defined in [SD-1] and applied by [AD-1] are recalled in Figure 4.3-1:

Figure 4.3-1: MIL-STD-1553B Word Types & Formats

BUS-743/[SD-1]/T

Word Validation shall be implemented as defined in [SD-1], section 4.4.1.1.

Note: A command word, which fulfills the above criteria, is declared valid but might be declared illegal if it is operationally wrong.

4.3.1 Command Word The Command Word is defined in [SD-1] and applied by [AD-1].

4.3.1.1 Remote Terminal Address Field Each RT connected to a Mil-1553B-bus has a unique address which allows the BC to communicate with the selected equipment. The address 0 is reserved, address 31 is used for broadcast.

The RT Address shall be configurable via an exernal connector of the RT equipment as required by [AD-1], para. 3.6.4.7.



BUS-86/[SD-1]/T

The Remote Terminal Address field shall be used to address the required RT in accordance with [SD-1].

BUS-268/Created/T

The RT address allocation for BepiColombo shall be as defined in Table 4.3-1 (TBC). RT Address

[hex (dec)] Parity

Bit MPO-1553B-

bus RT MTM-1553B-

bus RT MMO-1553B-

bus RT 00000 (0) 1 reserved reserved reserved

00001 (1) 0 MPO-PCDU_A MTM-PCDU_A MMO A 00010 (2) 0 MPO-PCDU_B MTM-PCDU_B MMO B 00011 (3) 1 MPO-SADE_A MTM-SADE_A reserved

00100 (4) 0 MPO-SADE_B MTM-SADE_B reserved

00101 (5) 1 APME_A MPCU_MEPS_A reserved

00110 (6) 1 APME_B MPCU_MEPS_B reserved

00111 (7) 0 reserved MPCU_CPS_A reserved

01000 (8) 0 reserved MPCU_CPS_B reserved

01001 (9) 1 DST-1 reserved reserved

01010 (10) 1 DST-2 reserved reserved

01011 (11) 0 KaT (MORE) reserved reserved

01100 (12) 1 BERM reserved reserved

01101 (13) 0 IMU A reserved reserved

01110 (14) 0 IMU B reserved reserved

01111 (15) 1 reserved reserved reserved


10001 (17) 1 STE-1 reserved reserved














11111 (31) 0 common

address for broadcast

common address for broadcast

common address for broadcast

Table 4.3-1: RT Address Allocation



4.3.1.2 Transmit/Receive (T/R) Bit Field

BUS-89/[SD-1]/T

The usage of the Transmit/Receive (T/R) bit shall be in accordance to [SD-1], para 4.3.3.5.1.3.

Transmit/Receive (T/R) bit defines the action required from the RT:

• T/R bit set to logical 0 indicates that the RT shall receive data from the BC

• T/R bit set to logical 1 indicates that the RT shall transmit data to the BC

4.3.1.3 Subaddress / Mode Field

BUS-91/Created/T

The allocation of subaddresses shall be as defined in Table 4.3-2 (TBC).



Subaddress (SA) RT to Transmit [T] RT to Receive [R] Dec Bin T/R-bit = 1 T/R-bit = 0

0 00000 Reserved for Mode Commands Reserved for Mode Commands 1 00001 TM Data buffer 1 TC Data buffer 1 2 00010 TM Data buffer 2 TC Data buffer 2 3 00011 TM Data buffer 3 TC Data buffer 3 4 00100 TM Data buffer 4 TC Data buffer 4 5 00101 TM Data buffer 5 TC Data buffer 5 6 00110 TM Data buffer 6 TC Data buffer 6 7 00111 TM Data buffer 7 TC Data buffer 7 8 01000 TM Data buffer 8 TC Data buffer 8 9 01001 TM Data buffer 9 TC Data buffer 9

10 01010 TM Data buffer 10 TC Data buffer 10 11 01011 TM Data buffer 11 TC Data buffer 11 12 01100 TM Data buffer 12 TC Data buffer 12 13 01101 TM Data buffer 13 TC Data buffer 13 14 01110 TM Data buffer 14 TC Data buffer 14 15 01111 TM Data buffer 15 TC Data buffer 15 16 10000 TM Data buffer 16 TC Data buffer 16 17 10001 Reserved Reserved 18 10010 Reserved Reserved 19 10011 Reserved Reserved 20 10100 Reserved Reserved 21 10101 Reserved Reserved 22 10110 Reserved TM Data Trigger Command 23 10111 Reserved Reserved 24 11000 Health Status from RT Health Status from BC 25 11001 Event message data buffer Reserved 26 11010 Event Request (TBD) Event Confirmation (TBD) 27 11011 Reserved Time (SCET) message from OBC 28 11100 TM Data Transfer Request TM Data Transfer Confirmation 29 11101 TC Data Transfer Confirmation TC Data Transfer Request 30 11110 Data Wrap-around Read Data Wrap-around Write 31 11111 Reserved for Mode Commands Reserved for Mode Commands

Table 4.3-2: Sub-Addresses Allocation for BepiColombo

The subaddresses shall be used as described below:

BUS-98/Created/T

Mode Command (SA 0, 31)

The use of subaddress 0 and 31 (dec) shall be according to [SD-1].

BUS-420/Created/T

TM Data Send (SA 1 - 16 T)

This subadress(es) shall comprise the nominal Telemetry data. The MSByte shall be transmitted first.



BUS-811/Created/T

TC Data Receive (SA 1 - 16 R)

This subadress(es) shall comprise the nominal Telecommand data. The MSByte shall be transmitted first.

BUS-812/Created/R

Reserved (SA 17 - 23 T, 27 T)

Unused transmit SA.

BUS-813/Created/R

Reserved (SA 17 - 21 R, 23 R, 25 R)

Unused receive SA.

BUS-889/Created/T

TM Data Trigger Command from BC (SA 22 R)

The BC shall provide via this SA a trigger command to dedicated RTs for starting the preparation of their periodic Housekeeping Data to be acquired in the fixed section of the subsequent Minor Frame allocated.

BUS-814/Created/T

Health Status from RT (SA 24 T)

Via this SA the RT shall provide HK-Data and status data about the RT unit (TBC).

BUS-815/Created/T

Health Status from BC (SA 24 R)

To be defined.

BUS-816/Created/T

Event Message Data (SA 25 T)

To be defined.

BUS-817/Created/T

Event Request (SA 26 T)

To be defined.



BUS-818/Created/T

Event Confirmation (SA 26 R)

To be defined.

BUS-819/Created/T

Time (SCET) Message (SA 27 R)

To be defined.

BUS-820/Created/T

TM Packet Transfer Request (SA 28 T)

The RT shall provide via this SA the request for a TM Packet transfer.

BUS-821/Created/T

TM Packet Transfer Confirmation from BC (SA 28 R)

The BC shall provide via this SA the confirmation for a TM Packet transfer to the RT.

BUS-822/Created/T

TC Packet Transfer Confirmation from RT (SA 29 T)

The RT shall provide via this SA the confirmation for a TC Packet transfer to the BC.

BUS-823/Created/T

TC Packet Transfer Request from RT (SA 29 R)

The BC shall provide via this SA the request for a TC Packet transfer to the RT.

BUS-824/[SD-1]/T

Data Wrap-around Read (SA 30 T)

This SA shall be used for implementation of Data Wrap-around (transmit) as specified in [SD-1, Not.II §30.7].

BUS-825/[SD-1]/T

Data Wrap-around Write (SA 30 R)

This SA shall be used for implementation of Data Wrap-around (receive) as specified in [SD-1, Not.II §30.7]



BUS-826/Created/R

Subaddress Allocation for non-intelligent Remote Terminals (Non-Packet-RTs):

For non-intelligent Remote Terminals (which do not handle TM/TC-Packets) the same Subaddresses as for Packet-RTs shall be used for standardized functionalities.

4.3.1.4 Data Word Count / Mode Code Field The Data Word Count Field indicates the quantity of data words to be transferred to/ from the BC.

To be used as defined by to [SD-1] § 4.3.3.5.1.5. as required by [AD-1].

Mode codes are defined by the standard to provide the Bus Controller (BC) with data bus management and error processing / recovery capability. Mode Codes are with a data word, other mode codes are without data word. The mode codes are defined by bit positions 15-19 of the Command Word. The most significant bit (bit 15) can be used to differentiate between the two mode code groups. When a data word is associated with the mode code, the Transmit/Receive (T/R) bit of the Command Word determines if the data word is transmitted or received by the RT.

BUS-101/Created]/T

In case the Subaddress Field is set to '00000' or '11111' the BC and RTs shall support Mode Code Commands as defined in Table 4.3-3.



T/R-Bit

Mode Code

hex (dec)

Function Assoc. Data Word

Broad-cast

allowed

BepiColombo BC/RT

Applicability

1 00000 (0) Dynamic Bus Control (not implemented / illegal)

No No not used

1 00001 (1) Synchronise No Yes mandatory

1 00010 (2) Transmit Status Word No No mandatory

1 00011 (3) Initiate RT Self-Test No Yes mandatory

1 00100 (4) RT Transmitter Shutdown No Yes mandatory

1 00101 (5) Override RT Transmitter Shutdown No Yes mandatory

1 00110 (6) Inhibit Terminal Flag No Yes optional

1 00111 (7) Override Inhibit Terminal Flag No Yes optional

1 01000 (8) Reset RT No Yes mandatory

1 01001 (9)

to 01111 (15)

Reserved / illegal No TBD not used

1 10000 (16) Transmit Vector Word Yes No optional

0 10001 (17) Synchronise with Data Word Yes Yes mandatory

1 10010 (18) Transmit Last Command Word Yes No optional

1 10011 (19) Transmit RT BIT Word Yes No optional

0 10100 (20) Selected Transmitter Shutdown Yes Yes not used

0 10101 (21) Override Selected Transmitter Shutdown Yes Yes not used

1 or 0

10110 (22) to

11111 (31) Reserved / illegal Yes TBD not used

Table 4.3-3: MIL-STD-1553B Mode Code Requirements for BepiColombo

BUS-104/[SD-1]/T

RT shall implement and respond to valid Mode Commands defined in Table 4.3-3 above as required by [SD-1], para. 4.3.3.5.1.7.

BUS-301/Created/T,R

Use of Mode Code Commands marked as not used or optional (if not implemented in a RT) shall be handled as illegal messages.

BUS-439/Created/T,R

The mode codes specified as optional shall be used if and only if they are demonstrated as necessary for the BC-RT operations of an off-the-shelf RT unit that will not be functionally modified for the BepiColombo project.

No use of these mode codes shall be claimed for equipment where no implementation of these mode codes exist or where these mode codes are offered but are not identified as necessary for the BC-RT operations.



Important note: in other words, if no RT equipment requires the use of the "Service Request" bit and "Transmit Vector Word" mode code for asynchronous transfers, these MIL-STD-1553B features will not be used on-board BepiColombo.

The above restriction is justified by the fact that for each of the highlighted optional mode codes there exist other, more generic, MIL-STD-1553B mode codes or cyclic message transfers that can answer the underlying need. For instance, "Transmit Vector Word" can be replaced with a cyclic receive command that analyses a data word from the RT.

4.3.1.4.1 Synchronise

BUS-441/[SD-1]/T

Implementation of Mode Command "Synchronise" shall comply to [SD-1], para. 4.3.3.5.1.7.2.

4.3.1.4.2 Transmit Status Word

BUS-107/[SD-1]/T

Implementation of Mode Command "Transmit Status Word" shall comply to [SD-1], para. 4.3.3.5.1.7.3.

4.3.1.4.3 Initiate RT Self-Test

BUS-57/[SD-1]/T

Implementation of Mode Command "Initiate RT Self-Test" shall comply to [SD-1], para. 4.3.3.5.1.7.4.

4.3.1.4.4 RT Transmitter Shutdown

BUS-109/[SD-1]/T

Implementation of Mode Command "RT Transmitter Shutdown" shall comply to [SD-1], para. 4.3.3.5.1.7.5.

BUS-111/[SD-1]/T

The shutdown transmitter shall not generate any bus activity until the mode code is overridden by either an "Override Transmitter Shutdown" mode code or a "Reset RT" mode code received on the non-shutdown bus.



4.3.1.4.5 Override RT Transmitter Shutdown

BUS-113/[SD-1]/T

Implementation of Mode Command "Override RT Transmitter Shutdown" shall comply to [SD-1], para. 4.3.3.5.1.7.6.

4.3.1.4.6 Inhibit Terminal Flag & Override Inhibit Terminal Flag (Optional)

BUS-828/[SD-1]/T

If "Inhibit Terminal Flag" and "Override Inhibit Terminal Flag" mode codes are necessary for operation of an RT unit the implementation of these Mode Commands shall comply to [SD-1], para. 4.3.3.5.1.7.7 resp. para. 4.3.3.5.1.7.8.

4.3.1.4.7 Reset Remote Terminal

BUS-115/[SD-1]/T

Implementation of Mode Command "Reset Remote Terminal" shall comply to [SD-1], para. 4.3.3.5.1.7.9.

BUS-116/Created/T

Receipt of the "Reset RT" mode code shall re-enable all shutdown transmitters. This reset shall apply to the RT electronics only: the host electronics or computer shall be unaffected.

BUS-117/Created/T

The RT shall ensure that no disturbances of message exchanges occur after the "Reset RT" because of residual RT data or flags.

If a remote terminal cannot respond normally while undergoing reset, the busy bit must be set in the status word. The RT must be capable of receiving the next valid command.

4.3.1.4.8 Transmit Vector Word (optional)

BUS-968/Created/T,R

For BepiColombo project, service request of RT shall be handled using the Event Data acquisition protocol as defined in section 5.6 of this document.

However, for heritage equipments Service request using the "Service Request Bit" and "Transmit Vector Word" mode code for RT aperiodic operation may be granted upon request.



BUS-119/[SD-1]/T,R

If "Service Request Bit" and "Transmit Vector Word" mode code are necessary a RT unit, the RT shall implement and respond to valid "Transmit Vector Word" mode code as required by [SD-1], para. 4.3.3.5.1.7.11.

Figure 4.3-2 illustrates the use of the Transmit Vector Word command in association with the Service Request Bit.

“0”

Figure 4.3-2: Transmit Vector Word Transfer



BUS-120/Created/T,R

The format of the Vector Word associated with an aperiodic message demand from the RT shall be as specified in the Table 4.3-4.

Bit No. Field Name Description 0 Format Flag Shall be set to logic "0" to indicate "asynchronous message demand"

1 - 4 Reserved reserved: shall be set to logic "0" 5 T/R Shall be set to a logic "1" to indicate that the requested message is a

transmit command. (Logic "0" indicates a receive command request.) 6 MSB

to Subaddress contain the subaddress of the required message 10 LSB

11 MSB

to Word Count contain the word count of the required message 15 LSB

Table 4.3-4: Vector Word Format for Aperiodic Message Demand from RT

BUS-122/Created/T,R

The format of the Vector Word associated with an aperiodic action demand from the RT shall be as specified in the Table 4.3-5.

Should a RT use this Vector Word format, the "User defined" bit content and meaning shall be specified by the RT supplier in the RT Unit Interface Control Document (ICD).

Bit No. Field Name Description 0 Format Flag Shall be set to logic "1" to indicate "asynchronous action demand" 1 MSB

to Notification Flag User defined 15 LSB

Table 4.3-5: Vector Word Format for Aperiodic Action Demand from RT

BUS-451/Created/T,R

If there is only one possible message or action for an RT that asserts the "Service Request" bit, then the BC shall know what action is required without any need for "Transmit Vector Word" mode command. The RT Unit ICD submitted by the RT contractor shall specify that message/action (TBC).

4.3.1.4.9 Synchronise with Data Word

BUS-52/[SD-1]/T

Implementation of Mode Command "Synchronise with Data Word" shall comply to [SD-1], para. 4.3.3.5.1.7.12.



BUS-53/Created/T

The Data Word shall contain synchronisation information for the RT as defined in section 5.3.2 of this specification.

4.3.1.4.10 Transmit Last Command Word (optional)

BUS-135/[SD-1]/T,R

If "Transmit Last Command Word" mode code is necessary for the operations of an RT unit, RTs shall implement and respond to valid "Transmit Last Command Word" mode code as required by [SD-1], para. 4.3.3.5.1.7.13.

4.3.1.4.11 Transmit RT Built-In-Test (BIT) Word (optional)

BUS-137/[SD-1]/T,R

If "Transmit RT BIT Word" mode code is necessary for the operations of an RT unit, RTs shall implement and respond to valid "Transmit BIT Word" mode code as required by [SD-1].

4.3.1.4.12 Prohibited Mode Codes

BUS-139/Created/T,R

The BC shall not transmit the mode codes specified as "Not used" in Table 4.3-3.

BUS-140/[SD-1]/T,R

The BC shall not transmit the reserved mode codes designated in [SD-1], nor any mode code not defined in [SD-1].

BUS-141/Created/T,R

If a RT receives a prohibited mode command, the RT shall not alter the state of the RT unit.

4.3.2 Data Words The Data Word Format shall be as defined by [SD-1] § 4.3.3.5.2. as required by [AD-1].

4.3.3 Status Words

BUS-145/[SD-1]/R

After the reception of any Mil-1553B-bus message (except broadcast message ), the RT shall respond with a status word which shall be in accordance with [SD-1], para. 4.3.3.5.3.



BUS-444/Created/R

The Status Word Flags/Bits as specified in Table 4.3-6 shall be supported: RT Status Bits Bit

Time Bit Setting Status indication Applicable

Message Error Bit 9 '0': absence of Error (default) '1': presence of Error

indicates that message failed to pass RT's validity tests

Yes

Instrumentation Bit 10 Set to '0' always used to distinguish between Command Word and Status Word

No

Service Request Bit 11 0': no service requested (default)'1': service requested

indicates that RT requests predefined action (see "Transmit Vector Word" mode code)

Yes

Reserved 12-14

Set to '000' always

Broadcast Command Received Bit

15 0': no Broadcast Cmd received (default) '1': Broadcast Cmd received

indicates that preceding valid command was a broadcast command

Yes

Busy Bit 16 0': not busy (default) '1': busy

indicates that the RT is unable to receive or transmit in response to a BC command

Yes

Subsystem Flag Bit 17 '0': absence of Error (default) '1': presence of Error

indicates a subsystem/RT fault Yes

Dynamic Control Acceptance Bit

18 Set to '0' always Function not implemented No

Terminal Flag Bit 19 0': absence of a Fault Condition (default) '1': presence of a Fault Condition

indicates an RT fault Yes

Table 4.3-6: Status Word Bit usage for BepiColombo

BUS-146/Created/T,R

The Status Word bits at bit times 10, 12, 13, 14, 17, 18 and 19 shall be set to a logical "0" by RT.

BUS-446/Created/R

The use of the Service Request bit, Subsystem Flag bit, the Busy bit, and the Terminal Flag bit shall be defined by each RT in its User Manual or ICD.

4.3.3.1 Message Error Bit

BUS-148/[SD-1]/T,R

The Message Error Bit shall be implemented and used as defined in [SD-1].

BUS-149/Created/T

When a RT detects an error and sets this bit, none of the data received within the message shall be used.



BUS-477/[SD-2]/T

If an RT that is designed with this option detects an illegal command and the proper number of contiguous valid data words as specified by the illegal command word, it shall respond with a status word only, setting the Message Error bit.

BUS-478/[SD-2]/T

Any data word(s) associated with a valid receive command that does not meet the word validation checks (sync, Manchester, format, parity), or an error in the data word count, shall cause the RT to set the Message Error bit in the status word to a logic one and suppress the transmission of the status word.

BUS-479/[SD-2]/T

The suppression of the transmission of the Status Word by an RT because of a message error as defined above shall generate a "no response time-out" on the BC side. This no response time-out condition shall be recorded in the communication memory for later retrieval by the BC software (TBC).

4.3.3.2 Instrumentation Bit

BUS-153/Created/T,R

The Instrumentation Bit shall always be set to logical "0". It shall not be used in conjunction with a logical "1" in the MSB of the Command Word subaddress field to distinguish between a Command Word and a Status Word.

4.3.3.3 Service Request Bit

BUS-156/[SD-1]/T

If the Service Request bit is necessary for the operations of an RT unit, it shall be implemented and used as defined in [SD-1].

BUS-200/Created/T

The RT shall ensure that once the Service Request bit is set to logical "1", the Vector Word is immediately available.

BUS-461/[SD-2]/T,R

The Service Request bit shall not be used to identify service requests for periodic message transmissions.



BUS-450/Created/R

The use of the "Service Request" bit shall be submitted to the same restrictions as those specified for the "Transmit Vector Word" mode code.

BUS-204/Created/T

The BC shall acquire data from the RT about service request by sending a "Transmit Vector Word" command to the RT.

BUS-452/Created/R

The Vector Word shall define the action requested by the RT unit. The RT Unit ICD submitted by the RT contractor shall specify vector word meaning.

BUS-207/Created/T,R

The RT shall maintain the current contents of the Vector Word until a subsequent and different valid command has been received.

BUS-201/Created/T

The Service Request bit shall be reset to logical "0" when, and only when, the RT has received the Transmit Vector Word mode command for the active service request and the Vector Word has been transmitted.

BUS-205/Created/T,R

If the Service Request bit is still set to a logical "1" in a second or subsequent response to the same service request, the Service Request bit shall be disregarded by the BC.

4.3.3.4 Broadcast Command Received Bit

BUS-158/[SD-1]/T,R

The Broadcast Command Received bit shall be implemented and used as defined in [SD-1].

4.3.3.5 Busy Bit

BUS-160/[SD-1]/T,R

If used by an RT, the Busy bit shall be implemented and used as defined in [SD-1], Notice II, §30.5.3.

BUS-161/Created/T,R

The Busy bit by a Remote Terminal (RT) shall only be used in pre-defined conditions:



• RT unit power-up, reset and initialisation: predictable, triggered from BC that shall manage the delay before interrogating the RT.

• RT unit self-test in progress: predictable, triggered from BC that shall manage the delay before interrogating the RT.

• RT self-test in progress: predictable, triggered from BC that shall manage the delay before interrogating the RT.

• The terminal goes busy for an unusual length of time or under unusual conditions: it indicates a possible overload condition or a RT unit executing a non-interruptible operation.

Busy times shall be provided by the RT unit contractor so as to determine the effects on data latency on system level.

BUS-454/Created/T

The BC shall determine the busy condition:

• immediately upon status response.

• or, at the latest, at the end of the current minor frame (TBC).

4.3.3.6 Subsystem Flag Bit

BUS-164/[SD-1]/T

For equipment(/subsystem) providing the capability for self-test and connected to the bus as RT, the Subsystem Flag bit shall be implemented and used as defined in [SD-1].

BUS-165/Created/R

Preferably RT equipment failures shall be reported as data words e.g. Event data accessible from the relevant subaddress instead of using the Subsystem Flag bit (tbc).

4.3.3.7 Dynamic Bus Control Acceptance Bit

BUS-167/[SD-1]/T

Dynamic Bus Control function shall not be implemented on BepiColombo. Hence the Dynamic Bus Control Acceptance Bit shall always be set to logical "0".

BUS-168/Created/T

The Bus Controller shall ignore a received Status Word that would contain the Dynamic Bus Control Acceptance Bit in the Status Word set to logical "1".



4.3.3.8 Terminal Flag Bit

BUS-170/[SD-1]/T,R

For RT providing the capability for self-test, the Terminal Flag bit shall be implemented and used as defined in [SD-1].

4.3.3.9 Status Word Reset/Update

BUS-739/[SD-1]/T

Status word bit reset shall be implemented as defined in [SD-1].

It is to be noted that:

• Status is constructed on a message by message basis on receipt of each valid command word. Remote terminals are required to store the status word between valid command words so that it is available for interrogation using the transmit status word mode code.

• It is recommended that the terminal flag bit and subsystem flag bit, having once been set, should remain set until a reset remote terminal mode command is received or a power-up initialization occurs.

• The inhibit terminal flag mode code locally suppresses the terminal flag bit in the status word so preventing failures of the RT from being reported in that way.

The above three facilities allow an orderly error handling and recovery approach to be accomplished by the bus controller using the information associated with error analysis data contained within the status word or other data associated with the RT (e.g. last command word and BIT word).



5 Transfer Layer

BUS-180/Created/T,R

The BC shall only Transmit/receive messages to/from RTs which have the status "Active" (powered, ready to be commanded...). This status shall be retrieved from a corresponding look-up table (Bus Configuration Table).

5.1 Message Formats and Timing

BUS-174/Created/T

The Bus Controller and Remote Terminals shall implement and use these message as specified in [SD-1] para 4.3.3.6 and defined below to satisfy the system's requirements for data transfers between BC and the RTs.

The message formats transmitted on the Mil-1553-Bus shall be in accordance with the structures given in the sections below. No message formats, other than those defined below shall be used.

The exchange of data over the MIL-STD-1553B is based on message transmissions.

The MIL-STD-1553B standard defines 10 types of message transmission formats as recalled in Figure 5.1-1 and Figure 5.1-2. All of these formats use the three (3) word types previously defined.

Figure 5.1-1: Information Transfer Formats



Figure 5.1-2: Broadcast Information Transfer Formats

BUS-181/Created/T,R

The following Transfer Messages shall not be used onboard BepiColombo (TBC):

• RT to RT Transfers as defined in [SD-1], para 4.3.3.6.3.

• RT to RT Transfers (Broadcast) as defined in [SD-1], para 4.3.3.6.7.2.

• Mode Command without Data Word (Broadcast) as defined in [SD-1], para 4.3.3.6.7.3.

5.1.1 BC to RT Data Message (Receive Message)

BUS-596/[SD-1]/T

The BC shall issue a Receive Command followed by the specified number of Data Words. The Command and Data Words shall be transmitted in a contiguous fashion with no inter-word gaps.

The RT shall, after word / message validation, transmit a Status Word back to the BC.

See Figure 5.1-3.

This message sends data from the BC to the addressed RT.

BC to RT Transfer:

Receive Command Data Word ... Data Word ** Status

Word # Next

Command Word

20μsec + N * 20μsec + 12μsec + 20μsec + 48μsec = 740μsec (for N=32) **: response time, #: intermessage gap

Figure 5.1-3: BC to RT Data Message Format and Timing



5.1.2 RT to BC Data Message (Transmit Message)

BUS-725/[SD-1]/T

The BC shall issue a Transmit Command to the RT.

The RT shall, after transmit command validation, transmit a status word back to the BC, followed by the specified number of data words. The status and data words shall be transmitted in a contiguous fashion with no inter word gaps.

See Figure 5.1-4.

This message sends data from the addressed RT to the BC.

RT to BC Transfer:

Transmit Command .**. Status

Word Data Word ... Data Word # Next

Command Word

20μsec + 12μsec + N * 20μsec + 20μsec + 48μsec = 740μsec (for N=32) **: response time, #: intermessage gap

Figure 5.1-4: RT to BC Data Message Format and Timing

5.1.3 Mode Command without Data Word Message

BUS-726/[SD-1]/T

The BC shall issue a mode command to the RT using a mode code specified in Table 4.3-3.

The RT shall, after command validation, transmit a status word. (No data words are sent)

See Figure 5.1-5.

This Message is sent from the BC to the addressed RT to control the RT.

Mode Command without Data Word:

Mode Command ** Status

Word # Next

Command Word

20μsec + 12μsec + 20μsec + 48μsec = 100μsec **: response time, #: intermessage gap

Figure 5.1-5: Mode Command without Data Word Message Format and Timing



5.1.4 Mode Command with Data Word from RT Message

BUS-728/[SD-1]/T

The BC shall issue a mode command to the RT using a mode code specified in Table 4.3-3. The RT shall, after command validation, transmit a status word followed by one data word. The status word and the data word shall be transmitted in a contiguous fashion with no inter word gap.

See Figure 5.1-6.

This message sends a data word from the addressed RT to the BC, e.g. to provide housekeeping information.

Mode Command with Data Word (Transmit):

Mode Command ** Status

Word Data Word # Next

Command Word

20μsec + 12μsec + 20μsec + 20μsec + 48μsec = 120μsec **: response time, #: intermessage gap

Figure 5.1-6: Mode Command with Data Word from RT Message Format and Timing

5.1.5 Mode Command with Data Word from BC Message

BUS-745/[SD-1]/T

The BC shall issue a mode command to the RT using a mode code specified in Table 6.2-5, followed by one data word. The command word and the data word shall be transmitted in a contiguous fashion with no inter word gap.

The RT shall, after command and data word validation, transmit a status word back to the BC.

See Figure 5.1-7.

This Message is sent from the BC to the addressed RT to control the RT.

Mode Command with Data Word (Receive):

Mode Command Data Word ** Status

Word # Next

Command Word

20μsec + 20μsec + 12μsec + 20μsec + 48μsec = 120μsec

**: response time, #: intermessage gap

Figure 5.1-7: Mode Command with Data Word from BC Message Format and Timing



5.1.6 Broadcast BC to RT Command Message

BUS-746/[SD-1]/T

The BC shall issue a Receive Command Word with 11111 in the RT address field followed by the specified number of Data Words.

The Command Word and Data Words shall be transmitted in a contiguous fashion with no gap.

The RTs with the broadcast option shall, after necessary validation, set the Broadcast Command Received Bit in the Status Word as specified in BUS-158 and shall not transmit the status word.

See Figure 5.1-8.

This message sends data from the BC to the RTs (broadcast).

BC to RT(s) Transfer:

Receive Command Data Word ... Data Word #

Next Command

Word

20μsec + N * 20μsec + 48μsec = 708μsec (for N=32)


Figure 5.1-8: Broadcast BC to RT(s) Data Message Format and Timing

5.1.7 Broadcast Mode Command with Data Word from BC Message

BUS-748/[SD-1]/T

The BC shall issue a Receive Command Word with 11111 in the RT address field and a Mode Code specified in Table 4.3-3, followed by one Data Word.

The Command Word and Data Word shall be transmitted in a contiguous fashion with no gap.

The RT(s) with the broadcast options shall, after necessary validation, set the Broadcast Command Received Bit in the Status Word as specified in BUS-158 and shall not transmit the status word. See Figure 5.1-9.

This message sends data from the BC to the RTs (broadcast).

Broadcast Mode Command with Data Word (Receive):

Mode Command Data Word #

Next Command

Word

20μsec + 20μsec + 48μsec = 88μsec


Figure 5.1-9: Broadcast Mode Command with Data Word Message Format and Timing



5.1.8 Message Timing Requirements Messages are separated by a period known as the intermessage gap, which is measured from mid-bit zero crossing of the last bit of the preceding Message to the mid-bit zero crossing of the next command word sync. In other words the intermessage gap consists of 0.5 µs of the parity signal, the number of microseconds of dead-bus (zero voltage on the bus) between words, and 1.5 µs of the sync signal. Hence, the dead-bus time is the intermessage gap time minus 2µsec.

The timing requirements on word level are fully according to [SD-1] as required by [AD-1] and given here as summary:

Data Bus Bit-Rate: 1 Mbps

Word Length: 20 bits (3 sync, 16 data bits, 1 parity bit) => ≅ 20µsec

BUS-184/[SD-1]/T

The Intermessage Gap to be provided by the Bus Controller (BC) shall comply to [SD-1], para 4.3.3.7.

Note: minimum Intermessage Gap of 4 μs.

BUS-185/Created/T

For BepiColombo the maximum Intermessage Gap shall be 48 µsec (TBC).

BUS-359/[SD-1]/T

The Response Time to be provided by the Bus Controller (BC) shall comply to [SD-1], para 4.3.3.7.

Note: Response Time between 4 to 12µsec.

BUS-183/[SD-1]/T

The Minimum No-Response Time-out shall comply to [SD-1], para 4.3.3.9.

Note: Minimum No-Response Time-out of 14 µs.

BUS-380/Created/T

The Bus Controller shall provide in addition the following programmable "No-Response Time-Out" values:

• 19 µs +/- 1 µs (TBC)

• 27 µs +/- 1 µs (TBC)



5.1.9 Message Validation

BUS-753/[SD-1]/T

Message Validation shall be fully according to [SD-1], para 4.4.3.

5.1.10 Max Busy Bit Set Times

BUS-191/Created/T,R

If a Remote Terminal (RT) is to delay further messages while executing a previous received message, the RT shall set the Busy bit in the Status Word.

BUS-192/Created/T

The busy time shall be measured from the zero crossing of the parity bit of the last word of the previous message to the zero crossing of the first command word sync which is accepted and whose status response has the busy bit set to logical "0".

BUS-193/[SD-2]/T,R

The maximum RT busy time following the receipt of a valid "Reset RT" mode command shall be 5 ms.

BUS-455/[SD-2]/T,R

The maximum RT busy time for RT self-test shall be 100 ms.

BUS-194/[SD-2]/T,R

The maximum RT busy time following power application shall be 500 ms.

BUS-195/[SD-2]/T,R

The maximum RT busy time for all other allowed busy conditions shall be 50 µs.

BUS-460/Created/T,R

The BC shall notify RT busy conditions to the central software.

BUS-196/Created/T,R

When scheduling periodic message transfers, if the BC detects a Busy bit set in an RT Status Word, it shall behave as follows:

• no retry of the message shall be performed.

• it shall continue with normal periodic message traffic of the next RT.



5.1.11 Data Wrap-Around

BUS-504/Created/T

RTs shall provide a receive subaddress to which one to N data words of any bit pattern can be received. RTs shall provide a transmit subaddress from which a minimum of N data words can be transmitted. N is equal to the maximum word count from the set of all messages defined for the RT. A valid receive message to the data wrap-around receive subaddress followed by a valid transmit command to the data wrap-around transmit subaddress, with the same word count and without any intervening valid commands to that RT, shall cause the RT to respond with each data word having the same bit pattern as the corresponding received data word. A data wrap-around receive and transmit subaddress shall be implemented as defined in BUS-91 i.e at subaddress 30.

BUS-503/Created/T

The BC shall implement the capability to perform wrap-around testing at RT subaddress 30, in which data words sent to the RT with a receive command are send back to the BC with a subsequent transmit command.

5.2 General Requirements

5.2.1 Communication with Non-Packet Terminals

BUS-45/Created/T

The Non-Packet Terminals within the BepiColombo project are (see also Figure 3.2-1):

MPO-1553B-Bus: MPO-PCDU, MPO-SADE, APME, DST-1, DST-2, KaT, BERM, IMU

MTM-1553B-Bus: MTM-PCDU, MTM-SADE, MPCU (MTM-CPS-I/O)

MMO-1553B-Bus: MMO

BUS-60/Created/T

For commanding (incl. data acquisition trigger commands) the BC shall issue Mil-1553B-bus Receive Commands, followed by up to 32 data words in specific formats, to certain fixed subaddress(es).

BUS-61/Created/T

For data acquisition, the BC shall issue Mil-1553B-bus Transmit Commands to fixed subaddress(es) in response of which the RT shall transmit the requested data words (up to 32 data words).



BUS-993/Created/T

The TC-Block length shall be limited to maximum 512 words (1024 octets).

BUS-994/Created/T

The TM-Block length shall be limited to maximum 512 words (1024 octets).

5.2.2 Communication with PUS-Packet Terminals and MMO

BUS-63/Created/T

The Packet Terminals within the BepiColombo project are (see also Figure 3.2-1):

MPO-1553B-Bus: STR-1, STR-2, STR-3 as PUS-Packet Terminals

MTM-1553B-Bus: MPCU (MEPS) as PUS-Packet Terminals

MMO-1553B-Bus: MMO (Packet Terminal, Non-PUS)

Data entities transferred to and from packet terminals are termed “blocks”.

TC-Blocks are transferred from the BC to RTs.

TM-Blocks are transferred from a RT to the BC.

BUS-65/Created/T

The BC and the Packet-RTs shall support the transfer of blocks of variable length, these blocks are constraint to PUS Source Packets (except MMO).

BUS-69/Created/T

The TC-Blocks length shall be limited to maximum

• MPO-1553B-Bus: 248 octets

• MTM-1553B-Bus: 248 octets

• MMO-1553B-Bus: 234 octets (TBC)

BUS-70/Created/T

The TC-Blocks shall be chopped into Messages of 32 data words for the transfer on the Mil-1553B-bus. The messages making up a TC-Block Transfer shall not be interleaved by messages of any other transfers.



BUS-71/Created/T

The TM-Blocks length shall be limited to

• MPO-1553B-Bus: 4112 octets

• MTM-1553B-Bus: 4112 octets

• MMO-1553B-Bus: 4096 octets (TBC)

BUS-72/Created/T

The TM-Blocks shall be chopped into messages of 32 data words for the transfer on the 1553 Data Bus. The messages making up a TM-Block Transfer shall not be interleaved by messages of any other transfers.

BUS-74/Created/T

In case of any failure during a block transfer, retransmission of complete blocks shall be performed only. No retransmission of parts of a block is foreseen.

BUS-75/Created/T

Successful transfer of a block shall be acknowledged to the sending instance.

5.3 Frame Scheduling

BUS-348/Created/T,R

The Mil-Bus activities shall be structured into major frames, minor frames and message slots.

The scheduling of each BepiColombo MPO, MTM, MMO MIL-STD-1553B bus shall be implemented in accordance with the following framing requirements and shown in Figure 5.3-1:

Note: The figure shows as an example only a sequence and allocation of TM/TC Transfers in the Fixed and Disposable Section.



Major Frame n Major Frame n+1Major Frame n-11 2 3 4 5 6 7 1 2 3 4 5 6 71 2 3 4 5 6 7

1 sec

Minor Frame

125 msec

000

1 2 30 4 ..... m Message Slots

Synchronisation

Fixed Section Disposable Section

x .....

IMU Functional DataSTR Functional Data

APME Periodical CommandingSADE Periodical Commanding

PCDU Trigger/Data AcquisitionDST Trigger/Data Acquisition

MORE Trigger/Data AcquisitionBERM Trigger/Data Acquisition

- STR event handling - PCDU Nominal Commanding - DST Nominal Commanding - STR Nominal Commanding - SADE/APME Nominal Commanding & Data Acquisition - MORE Nominal Commanding - IMU Commanding & Data Acquisition (if required) - BERM Nominal Commanding & Data Acquisition - STR Data Acquisition (e.g. TM-Packets up to 4096 bytes)

Duration fixed butindividual for minor frame Possible bus

deadtime (margin)

Minor Frames

Figure 5.3-1: Mil-Bus Scheduling (Major Frame / Minor Frame / Message Slot)

BUS-46/Created/T

The cyclic BepiColombo spacecraft Mil-1553B Data Bus Protocol shall have a deterministic, periodic structure, which is synchronized with the central on-board time, implemented in the OBC.

BUS-47/Created/T

The Mil-1553B-Protocol shall be based on a 1 second period called “Major Frame”.

BUS-48/Created/T

Each Major Frame shall be divided into 8 equidistant Time-Slots of 125 msec called “Minor Frames”, each containing a number of MIL-STD-1553B messages. These messages shall occur in a Minor Frame within a defined timing structure called "Message Slots".

BUS-49/Created/T

Each Minor Frame shall be organised in two sections.

• A "Fixed Section" comprising a fixed sequence of Mil-Bus Transfers (messages) that shall be executed at the beginning of a minor frame (i.e. periodical messages).

• A "Disposable Section" comprising Mil-Bus Transfers to be added, triggered by asynchronous events (e.g. commanding, error handling or transfer of periodic TM of lower priority) to be executed after the fixed part has finished.



BUS-50/Created/T

The start of a minor frame shall be triggered by a OBC hardware real-time clock which also controls the on-board software cycles to achieve high synchronisation between hardware and software activities and to avoid any jitter and accumulation of timing errors.

This real-time clock and the start of the master frame shall be synchronized to the high precision Pulse Per Second (PPS) signal which is derived from the OBT.

5.3.1 Frame Timing

BUS-351/Created/T

Each Minor Frame shall start with the Mode Command "Sync without Data Word" in the first Message Slot (ref. BUS-540).

BUS-352/Created/T

The frame synchronisation shall be followed by the transmission of all the Fixed Section (i.e. periodical) messages to be transferred in that Minor Frame.

BUS-537/Created/T,R

The minor frame Fixed Message transfer definition shall remain the same whichever active (i.e., non-OFF) operational mode the RT unit executes, i.e.:

• On RT side, no constraint shall be imposed by the RT to manage different minor frame scheduling regarding the periodic exchanges.

• On BC side, the data utilisation discrimination vs. operational mode shall be performed on a higher level of software than the MIL-STD-1553B protocol.

BUS-542/Created/T,R

Should an RT unit be OFF, no polling of this RT shall intervene during the relevant minor frame with the following precisions:

• The minor frame shall be without any transfers of messages if the minor frame is 100% dedicated to this RT.

• The synchronisation of the other RT's communication slots with respect to the minor frame start/sync time shall remain unchanged in spite of the OFF state of this RT, i.e., the fact that a RT unit is OFF shall not affect the dynamics of the minor frame for the other RTs sharing this minor frame with the OFF RT unit.

BUS-353/Created/T,R

After the Fixed Section messages, the Bus Controller (BC) shall use the remaining time to transfer Disposable Section messages (i.e. aperiodic, error handling, TM data...).



BUS-539/Created/T

The BC shall queue the tasks to service RTs within a Message Slot, i.e. within a Message Slot the RT servicing tasks shall be worked out one after the other and not at fixed time instants (TBC).

BUS-764/Created/T

Within a Message Slot activity (TC or TM block transfer) the bus line shall not be changed.

BUS-765/Created/T,A

If a TC or TM-Block transfer cannot be completed on one bus and is aborted, then the BC may switch to the other bus (TBC). This means, that the transfer of a new sub-frame activity may be on the other bus accordingly.

BUS-390/Created/T,A

The amount of time required to initiate each Major and Minor Frame shall be estimated. The time required by the BC to set up for frame synchronization, during which it cannot send messages, shall also be included.

BUS-524/Created/T,A

Flexible frame length with provision for overflow shall be avoided by design and construction. Frame overruns shall be processed as an error which leads to the rejection of new aperiodic message requests until frame overruns disappear (TBC).

BUS-538/Created/T,R

During a given minor frame, no other fixed message transfers than those dedicated to the specified RTs shall take place (TBC).

BUS-756/Created/T

For the start of a TM Block Transfer the BC shall check the sizes of the available TM Blocks returned by a RT.

BUS-766/Created/A

At the end of each sub frame a dead time period shall allow the RT to prepare for the following sub frame. The dead time shall be not less than TBD msec (TBC).

BUS-767/Created/T,R

Each Packet-RT shall be polled for availability of TM Blocks and shall receive telecommands as specified in the Polling Sequence Table (PST).



BUS-768/Created/T

To achieve operational flexibility, the PST shall be programmable (TBC).

This allows consideration of operating modes and configuration to avoid unnecessary FDIR activities and to cover situations as

• Set up of bus communication during power-on.

• After resetting a subsystem (related to a certain RT), commanded by OBC or due to subsystem watchdog reset.

• Error recovery.

• etc

BUS-770/Created/T,R

At least the following constraints applying to all programmed PSTs shall be taken into account (TBC):

1. AOCS Control loop activities shall always run in sub-frame tbd.

2. One sub-frame per second will be defined to issue a single low level MIL-Bus command to any RT (for trouble shooting purposes).

3. Each subaddress in each RT shall not be polled more than once per sub-frame.

4. further contraints are tbd.

5.3.2 Frame Synchronisation

"Syncronise with Data Word" Mode Command Procedure:

• exclusively based on Mil-bus message exchange;

• periodic "Synchronisation with Data Word" Broadcast Mode Command issued by the BC at the start of each Minor Frame (no dedicated SCET transmitted).

BUS-540/Created/T

The BC shall issue in the first Minor Frame within each Major Frame the Broadcast Mode Command "Synchronise", transmitted in the first message slot.

The RT can synchronize its activities to the BC activities by evaluating the minor frame count. The overhead on the Mil-bus is negligible ( ~ 4 us/minor frame). RTs which do not need this feature can simple ignore the mode command.



BUS-129/Created/T

The BC shall issue in all other Minor Frames the Broadcast Mode Command "Synchronize with Data Word" to the RTs, transmitted in the first message slot to indicate the start of a Minor Frame.

The Data Word provided with this command shall contain the minor frame number in which the command is transmitted.

BUS-130/Created/T,R

The Data Word provided with the "Synchronize with Data Word" Broadcast Mode Command shall comply to the following format:

Bit times 1 to 3: sync

Bit times 4 to 16: reserved, always set to logical "0"

Bit times 17 to 19: Bit

time Bit

time Bit

time

17 18 19

0 0 0 Minor Frame #0 0 0 1 Minor Frame #1 0 1 0 Minor Frame #2 0 1 1 Minor Frame #3 1 0 0 Minor Frame #4 1 0 1 Minor Frame #5 1 1 0 Minor Frame #6 1 1 1 Minor Frame #7

Bit time 20: Parity

BUS-131/Created/T

The RT shall synchronize its activities to the BC activities by evaluating the minor frame count.

BUS-783/Created/T

RTs which do not need "Synchronize with Data Word" Mode Command Procedure (Broadcast) shall ignore this mode command.

5.3.3 Frame Utilisation

BUS-553/Created/T,A

The MPO-1553B-Bus framing and phasing shall respect the dynamic requirements as expressed in Table 5.3-1 (TBC):



MPO RT unit

[redund.] Minor Frame section

Service Rate

Description Constraints / Comments

IMU-A [hot] IMU-B [cold]

Fixed 8 Hz Functional Data 1 to 4 TBC subsequent data sets(i.e. 32Hz acquisition rate)

Disposable 1 Hz Nominal commanding / data acquisition (HK, Diagnostic)

as required

STR-1 [hot] Fixed 8 Hz Functional Data TM Source Packets Disposable 1Hz Event handling as required Disposable 1Hz Nominal commanding TC Source Packets Disposable 1Hz Data acquisition TM Source Packets STR-2 [hot] Fixed 8 Hz Functional Data TM Source Packets Disposable 1Hz Event handling as required Disposable 1Hz Nominal commanding TC Source Packets Disposable 1Hz Data acquisition TM Source Packets STR-3 [hot] Fixed 8 Hz Functional Data TM Source Packets Disposable tbd Hz Event handling as required Disposable tbd Hz Nominal commanding TC Source Packets Disposable tbd Hz Data acquisition TM Source Packets APME-A [hot] Fixed 2 Hz Periodical Commanding APME-B [cold] Disposable 1 Hz tbc Nominal commanding / data

acquisition (HK, Diagnostic)as required

SADE-A [hot] Fixed 2 Hz Periodical Commanding SADE-B [cold] Disposable 1 Hz tbc Nominal commanding / data

acquisition (HK, Diagnostic)as required

PCDU-A [hot] PCDU-B [cold]

Fixed 0,25Hz to 2Hz

Trigger/Data acquisition TM data shall be ready 350ms (tbc) after receipt of Trigger Cmd

Disposable 2 Hz tbc Nominal commanding DST-1 [hot] Fixed 1 Hz Trigger/Data acquisition TM data shall be ready 350ms

(tbc) after receipt of Trigger Cmd Disposable 2 Hz tbc Nominal commanding DST-2 [hot] Fixed 1 Hz Trigger/Data acquisition TM data shall be ready 350ms

(tbc) after receipt of Trigger Cmd Disposable 2 Hz tbc Nominal commanding KaT (MORE) Fixed 1 Hz Trigger/Data acquisition TM data shall be ready 350ms

(tbc) after receipt of Trigger Cmd Disposable 2 Hz tbc Nominal commanding as required BERM Fixed 1 Hz Trigger/Data acquisition TM data shall be ready 350ms

(tbc) after receipt of Trigger Cmd Disposable 2 Hz tbc Nominal commanding

Table 5.3-1: MPO Framing/Phasing Requirements (TBC)

BUS-620/Created/T,A

The MTM-1553B-bus framing and phasing shall respect the dynamic requirements as expressed in Table 5.3-2:



MTM RT unit


Service Rate


MPCU_MEPS-A

Fixed 1 Hz tbc Functional Data TM Source Packets

[hot] Disposable 1Hz Event handling as required MPCU_MEPS-B

Disposable 1Hz Nominal commanding TC Source packets

[cold] Disposable 1Hz Data acquisition TM Source packets MPCU-CPS-A [hot]

Fixed 8 Hz Commanding Thruster flow control valves, Latch Valves

MPCU-CPS-B [cold]

Disposable 8 Hz tbc Data acquisition Valve Status, Pressure Transducer, Thruster Temperature

SADE-A [hot] Fixed 2 Hz Periodical Commanding SADE-B [cold] Disposable 1 Hz tbc Data acquisition (HK,

Diagnostic) as required

PCDU-A [hot] PCDU-B [cold]

Fixed 0,25Hz to 2Hz

Trigger/Data acquisition TM data shall be ready 350ms (tbc) after receipt of Trigger Cmd

Disposable 0,5 Hz Nominal commanding as required

Table 5.3-2: MTM Framing/Phasing Requirements (TBC)

BUS-621/Created/T,A

The MMO-1553B-bus framing and phasing shall respect the dynamic requirements as expressed in Table 5.3-3:

MMO RT unit


Service Rate


MMO N/A 1 Hz tbc TM Data Blocks 1 Hz tbc TC Data Blocks N/A Event handling

Table 5.3-3: MMO Framing/Phasing Requirements (TBC)

5.3.4 BC Message Sequence Control The transfer of data is subdivided into periodic messages and aperiodic messages (typically event-driven).

A major cycle (or frame) is defined so that all periodic messages are transferred at least once. Minor frames are then established to meet the requirements of the higher update rate messages.



BUS-217/Created/T,R

The Bus Controller (BC) shall provide the host processor software with a service that allows to specify linear sequences of messages that are to be exchanged over the MIL-STD-1553B bus.

BUS-225/Created/T

It shall be possible to initiate BC message sequences as follows:

• upon Real-Time Clock (RTC) interrupt: 1 Hz or 1s Major Frame.

• upon Real-Time Clock (RTC) interrupt: 8 Hz or 125 ms Minor Frame.

• upon host processor software command.

BUS-226/Created/T

It shall be possible to perform the following operations upon host processor software commands:

• to suspend the execution of a sequence #i.

• to insert and execute a new sequence #j.

• to resume and complete the execution of the sequence #i.

BUS-212/Created/R

The Bus Controller (BC) shall provide a Communication Memory (EDAC-protected volatile memory area), dedicated to the MIL-STD-1553B exchanges between the BC software and the Remote Terminals (RTs).

BUS-213/Created/R

The sizing of the Communication Memory shall provide 50% margin (TBC).

5.3.5 Bus Loading

BUS-357/Created/T,A

MPO minor frame loading shall be less than tbd % for worst case.

BUS-554/Created/T,A

MTM minor frame loading shall be less than tbd % for worst case.

BUS-594/Created/T,A

MMO minor frame loading shall be less than tbd % for worst case.



5.4 Time Synchronisation

The following procedures shall apply on board BepiColombo for the purpose of RT time reference synchronisation for all PUS Packet Terminal users and all other users requiring the time reference:

"Syncronise" Mode Command Procedure:

• exclusively based on Mil-bus message exchange;

• distribution of SCET using Receive Command (BC to RT Transfer) followed by a "Synchronise" Mode Command issued by the BC.

PPS-based Synchronisation Procedure:

• based on Mil-Bus message exchange and provision of discrete syncronisation pulse (PPS) to RT;

• distribution of SCET using Receive Command (BC to RT Transfer) followed by discrete syncronisation pulse issued by the BC to the RT.

BUS-781/Created/R

The baseline allocation of the defined Synchronisation Procedures to the Remote Terminals shall be as given in Table 5.4-1:

Mil-Bus RT Unit Syncronise Mode Cmd

Proc.

PPS-based Sync. Proc.

Sync. with DW Mode Cmd Proc.

MPO-1553-Bus STR-1 to -3 N Y N IMU TBD N Y BERM TBD N Y MPO-PCDU N N Y MPO-SADE N N Y APME N N Y DST-1 to -2 N N Y KaT (MORE) N N Y MTM-1553-Bus MPCU-MEPS Y N N MPCU-CPS N N Y MTM-PCDU N N Y MTM-SADE N N Y MMO-1553-Bus

MMO TBD N TBD

Table 5.4-1: RT Synchronisation Procedure Allocation

BUS-370/Created/T

The BC shall provide system time information (SCET) via the Mil-1553B-busses.



BUS-371/Created/T

The SCET distribution over MIL-STD-1553B bus shall have the format as specified in Table 5.4-2 with the time value given in second according to the following equation, consistent with the CCSDS Unsegmented Time Code (CUC) format:

SCET = C1*2563 + C2*2562 + C3*256 + C4 + F1*256-1 + F2*256-2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20Bit Position:

Sync Reserved = 0000 0000 bin P-Field = 0010 1110 bin PData Words:

MSB LSB

Sync Coarse Time C1 (MSB) Coarse Time C2 P

Sync Coarse Time C3 Coarse Time C4 P

Sync Fine Time F1 Fine Time F2 (LSB) P

Table 5.4-2: MIL-STD-1553B SCET Distribution Format

BUS-795/Created/T

The time value contained in the time message shall be the time at the beginning of the next frame. Reference is the beginning of the Mode Command "Synchronise" of Minor Frame 0.

BUS-124/Created/A

The relative accurracy of the time information shall be max. TBD microseconds with respect to the system time of the BC (OBC).

BUS-126/Created/T

The time information shall be a message sent to subaddress 27R (TBC).

BUS-810/Created/T

The BC shall send the information in Minor Frame TBD (Message slot TBD).

5.4.1 Synchronise Mode Command Procedure

BUS-443/Created/T

For time synchronisation using "Syncronise" Mode Command Procedure, the BC shall distribute to the RT, at the specified subaddress, the SCET valid at the next "Syncronise" Mode Command sent over the bus.



The SCET shall be sent during the preceding minor frame allocated to this RT to give sufficient time to the RT for preparing the next re-synchronisation.

BUS-133/Created/T

RTs to be synchronised to SCET using "Syncronise" Mode Command Procedure shall:

• receive the SCET through the specified subaddress with the SCET data word format according to BUS-371,

• re-synchronise the RT unit local time with the pre-loaded SCET upon reception of the "Synchronise" Mode Command (defined by BUS-441).

BUS-973/Created/T

In case no SCET was sent in any of the Minor Frames during the last Major Frame, no resynchronisation shall be performed.

5.4.2 PPS-based Synchronisation Procedure

BUS-786/Created/T

For RTs synchronised using "PPS-based Syncronisation Procedure", the BC shall distribute to the specified subaddress of the RT the SCET, valid at the next discrete Pulse Per Second (PPS) signal sent to the RT.

The SCET shall be sent during a preceeding minor frame to this RT to give sufficient time to the RT for preparing the next re-synchronisation.

BUS-787/Created/T

RTs to be synchronised to SCET using PPS-based Syncronisation Procedure shall:

• receive the SCET through the specified subaddress with the SCET data word format according to BUS-371,

• re-synchronise the RT unit local time with the pre-loaded SCET upon reception of the subsequent discrete Pulse Per Second (PPS) pulse (rising edge).

5.5 Block Transfer Protocol

5.5.1 General

BUS-790/Created/R

A Block is defined as a sequence of data words to be transferred over the Mil-1553B-Bus.



BUS-796/Created/T

The Block Transfer Protocol shall be based on the exchange of two Transfer Descriptor Words between BC and RT for block data request (at start of block transfer) and confirmation of block received (at the end of block transfer).

Dedicated sub-addresses shall be used as defined in BUS-91.

BUS-794/Created/T

The data block itself shall be transferred, initiated and terminated by Transfer Descriptor exchange, as a sequence of Mil-1553B-Bus messages via dedicated RT subaddresses as defined in BUS-91.

BUS-791/Created/T,A

A Block Transfer shall not be interleaved by any other data transfer (TBC).

BUS-793/Created/T

The block of data to be transferred shall be chopped into sections (i.e. Mil-1553B-Bus messages). All sections shall comprise 32 data words except the last one which may have less than 32 words depending on the Block length.

If Block length is an odd number of bytes, the last word shall contain the last byte of the initial data in its most significant bits, the least significant bits shall be set to “0”.

BUS-802/Created/T

The first Transfer Descriptor word "Transfer Size" shall define the length of the compete block to be transferred expressed in number of 16-bit words. The format shall be as given in Figure 5.5-1.

Unused bits (00 to 03) shall be set to logic "0".

BUS-803/Created/T

The second Transfer Descriptor word "Transfer Control" shall hold the Transfer type, the Transfer status, the Transfer Flow Control bits and the Block Count. The format shall be as given in Figure 5.5-1.

Unused bits shall be set to logic "0".



Transfer Size

Bit position 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

Transfer Control

Bit position 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

Number of 16-bit words of block

TransferType

TransferStatus

TransferControl Block Count

Transfer size: 1..0809 hex 0

Number of 16-bit words No transfer

Transfer type: 00 bin 01 bin

= use only subaddress 1 = increment subaddress 1 to 16

Transfer status: 00 bin 01 bin 10 bin 11 bin

= no error = transmission error = protocol error = reserved

Transfer Flow control:

00 bin 01 bin 10 bin 11 bin

= no request = request = transmission finished = protocol reset

Block Count: 1..0F hex To be incremented by 1 for each block request (starting value 00 hex), roll over after reaching 0F hex

Figure 5.5-1: Block Transfer Descriptor Words

BUS-805/Created/T,R

The protocol supports two different transfer types which shall be fixed for a RT:

• case 1: the TM or TC data are written/read to/from subaddress 1 (limited to 4112 bytes)

• case 2: the sub-address is incremented by one after the transfer of a Mil-bus message (32 words) from one to 16 (total length of data block limited to 1024 bytes).

BUS-799/Created/R

Data integrity of received data on block level (e.g. contiguous message sequence counter) is not verified by this Mil-bus protocol, since failures during data transfer are monitored on message level.

BUS-801/Created/R

No retry of block transfer, neither in part or complete, is foreseen on Mil-bus protocol level, except TM block retention on RT side on BC request (TBC).



5.5.2 BC to RT Block Transfer (Command Distribution)

BUS-806/Created/T,R

The BC shall be responsible for limiting the TC block length to the maximum number of words.

BUS-807/Created/T

The BC shall queue the TC blocks if there are more TC blocks with the same destination waiting for transmission.

BUS-808/Created/T

The BC to RT Block Transfer shall be implemented according to the procedure (steps) defined below and shown in Figure 5.5-2 (Simplified Flow Control Diagram).

BC sends TC data to RT buffer(s) at SA 1(-16)

New count Id?

Time-out

RT reads and checks Transfer Descriptor at SA 29and checks block count against previous one.

BC sends TC Transfer Descriptor to RT at SA 29(TC Transfer Request)

RT reads TC data at SA 1(-16) acc to transfer size

RT stores updated Transfer Descriptor at SA 29(TC Transfer Confirmation)

End of TransferEnd of Transfer

BC reads and evaluates Transfer Descriptorsof TC Transfer Confirmation

Yes

No

RTBC

Start of TransferStart of Transfer

BC waits for TC Transfer Confirmation (SA 29)

Figure 5.5-2: BC to RT Block Transfer (simplified)



BUS-897/Created/T

Step 1:

The BC shall send the command data block (TC-Packet) to the RT by issuing a number of Receive Command Messages according to the number of words to be transmitted and the Transfer Type (preselected for the RT) to the relevant TC Data Buffer(s) beginning at sub address 1.

BUS-898/Created/T

Step 2:

The BC shall prepare the TC Data Transfer Request by sending the Transfer Descriptor Words to RT subaddress 29.

First the Transfer Size Word with the number of 16 bit words of the block, followed by the Transfer Control Word providing Transfer Type (predefined for RT), Transfer status=00bin, Transfer Flow control = 01bin and Block Count incremented by one.

BUS-899/Created/T

Step 3:

The RT shall read the TC Data Transfer Request on subaddress 29 (interrupt or polling).

BUS-900/Created/T

Step 4:

The RT shall check if the TC Data Transfer Request is a new one by comparing the received Block Count against the previous one.

BUS-901/Created/T

Step 5:

If it is a new TC Data Transfer Request, the RT shall read the block data from the Mil-1553B-bus buffers (TC Data Buffers) into memory.

BUS-902/Created/T

Step 6:

The RT shall update the TC Data Transfer Confirmation providing the corresponding Transfer Descriptor Words in sub-address 29:

• Transfer Size Word: number of 16 bit words received

• Transfer Control Word: Transfer type (predefined), Transfer Status=00bin, Transfer Flow control = 10 bin, Block Count = counter of block received.



BUS-903/Created/T

Step 7:

The BC shall poll the TC Data Transfer Confirmation Descriptor Words from sub-address 29 and evaluate the transfer flow.

5.5.3 RT to BC Block Transfer (Data Acquisition)

BUS-830/Created/T

The RT to BC Block Transfer shall be implemented according to the procedure defined below and shown in Figure 5.5-3 (Simplified Flow Control Diagram).

RT stores TM data to TM buffer(s) at SA 1(-16)

New count Id?

Time-out

RT reads and checks Transfer Descriptor at SA 29and checks block count against previous one.

RT stores TM Transfer Descriptor at SA 28(TM Transfer Request)

BC reads TM data at SA 1(-16) acc to transfertype and transfer size

RT sends Transfer Descriptor at SA 28(TM Transfer Confirmation)

End of Transfer End of Transfer

RT evaluates Transfer Descriptorof TM Transfer Confirmation

New valid count Id and request

Valid, but oldcount Id

BC RT

Start of Transfer Start of Transfer

RT waits for TM transfer Confirmation (SA 28)

Invalid requestor protocol reset

Figure 5.5-3: RT to BC Block Transfer (simplified)



BUS-904/Created/T

Step 1:

The RT shall store the data block (TM-Packet) into the TM Data buffer(s) at dedicated subaddress(es) as defined in BUS-91, beginning at SA 1.

BUS-905/Created/T

Step 2:

The RT shall prepare the TM Data Transfer Request by storing the corresponding Transfer Descriptor Words in subaddress 28:

• First the Transfer Size Word with the number of 16 bit words of the block

• then the Transfer Control Word defining Transfer type (predefined for RT), Transfer status = 00bin, Transfer Flow control = 01bin and Block Count incremented by one.

BUS-911/Created/T

Step 3:

The RT shall wait for the TM Data Transfer Confirmation from the BC (Receive Command Message providing Transfer Descriptors). If no transfer confirmation is received within TBD ms (time-out), the RT shall abort the block transfer and generate an exception report (TBC).

BUS-906/Created/T

Step 4:

The BC shall poll the TM Data Transfer Request at subaddress 28 by issuing a related Transmit command (2 words) to acquire the Transfer Descriptor Words.

BUS-907/Created/T

Step 5:

The BC shall check if the TM Data Transfer Request is a new one. This shall be done by checking the acquired Transfer Control Word for Transfer Flow control == 01bin and comparing the received Block Count against the value of the previous block received.

BUS-908/Created/T

Step 6:

If it is a new and valid request, the BC shall read the data block (TM-Packet) from the RT by issuing a number of Transmit Command Messages according to the number of words to be transmitted (defined in Transfer Size Word) and the Transfer Type (Transmit Control Word) from the relevant TM Data Buffer(s) beginning at sub address 1.



BUS-909/Created/T

Step 7:

The BC shall evaluate the status words of the Transmit Command Messages and send the updated Transfer Descriptor Words to the TM Data Transfer Confirmation RT subaddress 28. The Transfer Descriptor words shall provide


• Transfer Control Word: Transfer type (predefined), Transfer Status=00bin, Transfer Flow control = 10 bin, Block Count = counter of block received.

BUS-910/Created/T

Step 8:

The RT shall evaluate the transfer flow using the TM Data Transfer Confirmation Words at sub-address 29.

5.6 Event Data Acquisition

BUS-896/Created/T

Event Data/Messages shall consist of small messages sent by the RT for reporting an event which requests an immediate reaction from the OBC equipment management or FDIR.

BUS-935/Created/T

Event Messages shall fit into one Mil-1553B-Bus message (max. 32 words). The individual format of the Event Message shall be defined in the specific equipment ICD.

BUS-922/Created/T

The Event Message Handling Protocol shall be based on the exchange of two Event Transfer Descriptor Words between BC and RT for Event Data Request (start of transfer) and confirmation of Event Message received (end of transfer).

Dedicated sub-addresses shall be used as defined in BUS-91 (Event Data Transfer Request on SA 26 T, Event Data Transfer Confirmation on SA 26 R).

BUS-923/Created/T

The first Event Transfer Descriptor word "Transfer Size" shall define the Event Message length to be transferred expressed in number of 16-bit words. The format shall be as given in Figure 5.5-1 with the following deviations:

• Bits 10 to 15 shall define the number of 16bit words in the range 001 to 020 hex.

• Bits 00 to 09 are reserved and shall be set to logic "0".



BUS-924/Created/T

The second Event Transfer Descriptor word "Transfer Control" shall hold the Transfer type, the Transfer status, the Transfer Flow Control bits and the Block Count. The format shall be as given in Figure 5.5-1 with the following deviations:

• Transfer type always set to 00bin (only SA 25 for Event data)

• Block Count shall be used as Event Message counter following the same priciple rules.

• Bits 02, 03, 08 to 11 are reserved and shall be set to logic "0"..

BUS-914/Created/T

The followingEvent Data Transfer Protocol shall apply to handle events:

BUS-915/Created/T

Step 1:

The RT shall store the Event Message data into the Event Message Data buffer at dedicated subaddress 25.

BUS-916/Created/T

Step 2:

The RT shall prepare the Event Data Transfer Request by storing the corresponding Event Transfer Descriptor Words in subaddress 26:

• First the Transfer Size Word with the number of 16 bit words

• then the Transfer Control Word defining Transfer type (always 00bin), Transfer status = 00bin, Transfer Flow control = 01bin and Event Message Count incremented by one.

BUS-917/Created/T

Step 3:

The RT shall wait for the Event Data Transfer Confirmation from the BC (Receive Command Message providing Transfer Descriptors).

If no transfer confirmation is received within TBD ms (time-out), the RT shall abort the block transfer and generate an exception report (TBC).

BUS-918/Created/T

Step 4:

The BC shall poll the Event Data Transfer Request at subaddress 26 as defined in the PST for a new request by issuing a related Transmit command (2 words) to acquire the Event Transfer Descriptor Words.



BUS-919/Created/T

Step 5:

The BC shall check if the Event Data Transfer Request is a new one. This shall be done by checking the acquired Event Transfer Control Word for Transfer Flow control == 01bin and comparing the received Event Message Count against the value of the previous Event Message received.

BUS-920/Created/T

Step 6:

If it is a new and valid request, the BC shall read the Event Message from the RT at SA 25 by issuing a Transmit Command Messages with the length as defined in the request.

BUS-921/Created/T

Step 7:

The BC shall evaluate the status words of the Transmit Command Messages and send the updated Event Transfer Descriptor Words to the Event Data Transfer Confirmation at RT subaddress 26. The Transfer Descriptor words shall provide


• Transfer Control Word: Transfer Status=00bin, Transfer Flow control = 10 bin, Event Message Count = counter of Event Message received.



5.7 Commanding and Data Acquisition of Non-Packet Terminals

5.7.1 MPO-PCDU, MTM-PCDU, DST, MORE (tbc) and BERM (tbc)

BUS-833/Created/R

The following requirements shall be applicable for MPO-PCDU, MTM-PCDU, DST-1, DST-2, MORE (tbc) and BERM (tbc).

BUS-841/Created/T

Nominal commanding shall be performed at the beginning of the fixed cycle with a frequency of 2 Hz to each of the relevant units using the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document.

BUS-929/Created/T

For nominal commanding, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.

BUS-842/Created/T

For nominal commanding a dedicated subaddress (SA 1 up to SA 16) shall be used.

BUS-895/Created/T

The maximum length of a nominal command data block shall not exceed 1 message (on 1 subaddress with up to 32 words (16 bit)).

BUS-843/Created/T

Nominally no commanding shall be foreseen between the TM Trigger Command and the corresponding TM Data acquisition.

BUS-834/Created/T

The periodic, functional housekeeping data preparation of the RT shall be started by a dedicated "TM Data Trigger Command" from BC to RT.

BUS-890/Created/T

The TM Data Trigger Command shall be a Receive Command (BC to RT Transfer) Message comprising one Data Word.



BUS-891/Created/T,R

The data word of the TM Data Trigger Command shall be used to identify the different trigger command functions as defined in Table 5.7-1.

To be defined.

Table 5.7-1: TM Data Trigger Command Word

BUS-835/Created/T

The TM Data Trigger Command shall use a dedicated sub-address 23, common to all RTs.

BUS-893/Created/T

TM Data Trigger Commands shall be transfered at the beginning of the Minor Frame Fixed Section to each of the relevant units.

BUS-836/Created/T

After the RT has received the TM Data Trigger Command and a delay time of 350ms (TBC), the data shall be available for acquisition until the next TM Data Trigger Command is sent to the RT.

BUS-894/Created/T

After the TM Acquisition delay time defined in BUS-836, the BC shall acquire the Telemetry data from the RT in the Fixed Section of a Minor Frame.

BUS-930/Created/T

For Telemetry data acquisition, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.

BUS-837/Created/T

Predefined for each RT, a dedicated subaddress (SA 1) or a series of dedicated subaddresses (SA 1 up to SA 16) as defined in BUS-91 shall be used for data transmission.

The RT shall indicate it's Transfer type in the Transfer Descriptor Transfer Control Word accordingly.



BUS-838/Created/T

The maximum length of the Telemetry data shall be 16 messages (on 16 sub-addresses with up to 32 words each) or 512 words (16 bit).

BUS-839/Created/T

The data shall include a wraparound counter or flag allowing to determine the validity of the acquired data; Additionally, for the applicable protocol, the validity is indicated by the update of the ‘Block Count’ field within the Transfer Control word of the Transfer Descriptor.

BUS-840/Created/T

The frequency of the acquisition/triggering shall be selectable from 0,25 Hz to 2Hz.

BUS-844/Created/T,R

If required, diagnostic or aperiodic data shall be transmitted (RT to BC) on the same sub-address(es) as used for the periodic, functional data using the same transfer protocol.

BUS-845/Created/T,R

The transfer of diagnostic or aperiodic data shall be performed in the Minor Frame Disposable Section following the nominal commanding.

BUS-855/Created/T,R

If required, Event data (message) shall be acquired from the RT by the BC in the Disposable Section of a Minor Frame using the Event Message Handling Protocol as specified in section 5.6 of this document.

5.7.2 MPO-SADE, MTM-SADE and APME (HGA & MGA)

BUS-847/Created/R

For MPO-SADE, MTM-SADE and APME (HGA and MGA) the following requirements shall apply:

BUS-851/Created/T

Nominal commanding (e.g. mode commands or update of parameters) shall be performed at the beginning of the Minor Frame Disposable Section at a frequency of 1Hz (tbc).

BUS-925/Created/T

For nominal commanding, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.



BUS-926/Created/T

For nominal commanding a dedicated subaddress (SA 1 up to SA 16) shall be used.

BUS-848/Created/T

Periodical commanding (e.g. position and rate) shall be performed in the Fixed Section of a Minor Frame at a frequency of 2Hz (tbc).

BUS-850/Created/T

For periodical commanding, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.

BUS-849/Created/T

For periodical commanding a dedicated subaddress (SA 1 up to SA 16) shall be used.

BUS-982/Created/T,R

Nominal commanding and periodical commanding shall use different subaddresses (tbc).

BUS-852/Created/T,R

If required, diagnostic or aperiodic data shall be acquired by the BC in the Disposable Section of the Minor Frame following the nominal commanding Minor Frame.

BUS-853/Created/T,R

For transfer of diagnostic or aperiodic data from the RT to the BC, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.

BUS-927/Created/T,R

For acquisition of diagnostic or aperiodic data a dedicated subaddress (SA 1 up to SA 16) shall be used.

Diagnostic and aperiodic data shall use the same subaddress(es).

BUS-856/Created/T,R

If required, Event data shall be acquired from the RT by the BC in the Disposable Section of a Minor Frame using the Event Message Handling Protocol as specified in section 5.6 of this document.



5.7.3 IMU

BUS-932/Created/R

For IMU the following requirements shall apply:

BUS-854/Created/T

IMU Functional Data shall be aquired in the Fixed Section of the Minor Frame with a frequency of 8Hz.

At this rate, 1 up to 4 (TBC) subsequent sets of functional data shall be transfered.

BUS-931/Created/T

For transfer of IMU Functional Data to the BC, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.

BUS-928/Created/T

A dedicated subaddress (SA 1) or a series of dedicated subaddresses (SA 1 up to SA 16) as defined in BUS-91 shall be used for data transmission.


BUS-976/Created/T

IMU commanding shall be performed at the beginning of the Minor Frame Disposable Section at a frequency of 8Hz (tbc).

BUS-977/Created/T

For IMU commanding, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.

BUS-978/Created/T

For IMU commanding a dedicated subaddress (SA 1 up to SA 16) shall be used.

BUS-979/Created/T,R

If required, diagnostic data shall be acquired by the BC in the Disposable Section of the Minor Frame following the IMU commanding Minor Frame.

BUS-980/Created/T,R

For transfer of diagnostic data from the RT to the BC, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.



BUS-981/Created/T,R

For acquisition of IMU diagnostic data a dedicated subaddress (SA 1 up to SA 16) shall be used.

BUS-983/Created/T,R

IMU functional data and diagnostic data shall use different subaddresses (tbc).

BUS-975/Created/T

If required, Event data shall be acquired from the RT by the BC in the Disposable Section of a Minor Frame using the Event Message Handling Protocol as specified in section 5.6 of this document.

5.7.4 MPCU-CPS-I/O (TBC)

BUS-985/Created/R

For MPCU-CPS (dedicated RT for CPS-I/O function inside MPCU) the following requirements shall apply:

BUS-986/Created/T

MPCU-CPS commanding shall be performed in the Fixed Section of the Minor Frame with a frequency of 8Hz.

BUS-987/Created/T

For MPCU-CPS commanding, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.

BUS-988/Created/T

For MPCU-CPS commanding a dedicated subaddress (SA 1 up to SA 16) shall be used.

BUS-989/Created/T

MPCU-CPS Functional Data shall be aquired in the Disposable Section of the Minor Frame with a frequency of 8Hz (TBC).

BUS-990/Created/T

For transfer of MPCU-CPS Functional Data to the BC, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.



BUS-991/Created/T

A dedicated subaddress (SA 1) or a series of dedicated subaddresses (SA 1 up to SA 16) as defined in BUS-91 shall be used for data RT data acquisition.




5.8 Commanding and Data Acquisition of PUS-Packet Terminals

BUS-857/Created/R

For PUS-Terminals STR-1, STR-2, STR-3, MPCU-MEPS (dedicated RT to MTM Electric Propulsion Subsystem) connected to the Mil-1553B-bus the following requirements shall apply:

BUS-797/Created/T

Nominal commanding, i.e. transfer of TC Source Packets, shall be performed in the Disposable Section of the Minor Frame with a frequency of 1Hz (tbc).

BUS-912/Created/T

For transmission of TC Source Packets from the BC to the RT, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.

BUS-858/Created/T

The TC-Block (TC Source Packet) shall be written to RT subaddress 1 only.

The RT shall indicate this Transfer type in the Transfer Descriptor Transfer Control Word accordingly.

BUS-859/Created/T

Nominal TM Data Acquisition (Housekeeping), i.e. transfer of TM Source Packets, shall be performed in the Disposable Section of the Minor Frame with a frequency of 1Hz (tbc).

BUS-863/Created/T

STR functional data, i.e. TM Source Packets, shall be acquired by the BC in the Fixed Section of the Minor Frame with a frequency of 8Hz.

BUS-934/Created/T

MPCU-MEPS functional data, i.e. TM Source Packets, shall be acquired by the BC in the Fixed Section of the Minor Frame with a frequency of 1Hz (tbc).

BUS-933/Created/T

For transmission of TM Source Packets from the RT to the BC, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.

BUS-860/Created/T

The TM-Block (TM Source Packet) shall be read from/provided in RT subaddress 1 only.




BUS-861/Created/T

It shall be the responsibility of the PUS terminal (RT) to manage the priority of the TM to be transferred (e.g. to provide the functional data like attitude and position of the electrical thruster mechanism periodically and with highest priority).

BUS-864/Created/T

Additionally a high priority transfer of event messages requiring immediate on-board reaction shall be provided on dedicated subaddresses as defined in BUS-91.

BUS-862/Created/T

Event data shall be acquired from the RT in the Disposable Section of a Minor Frame.

BUS-865/Created/T

Event data shall be aquired using the Event Message Handling Protocol as specified in section 5.6 of this document. The length of the event data shall be restricted to 32 words of 16bit length (one Mil-1553B-bus message).



5.9 Commanding and Data Acquisition of MMO

The MMO is connected on a dedicated Mil-1553B-bus. Therefore no constraints with respect to other users have to be respected.

BUS-867/Created/T

Telecommands and Telemetry between MMO and MPO (DMS) shall be exchanged in form of data blocks via the MPO-1553B-Bus.

BUS-869/Created/R

No split of Minor Frame into fixed part and disposable part is required for commanding / data acquisition.

BUS-870/Created/T,R

The event handling shall be applied to the separation phase only where the knowledge of health status of the MMO is required by the MPO in order to release the separation sequencer.

BUS-886/Created/T

The MMO shall be ready to accept telecommands TBD sec after power-on, even before producing any telemetry data. After successful activation, the MMO shall enable generation of it's default HK data block.

5.9.1 MMO Telemetry Acquisition

BUS-872/Created/T

Telemetry data blocks generated by the MMO shall be acquired by the MPO (DMS) via the MPO-1553B-Bus.

BUS-939/Created/T

Telemetry acquisition, i.e. transfer of TM-Blocks, shall be performed in the Minor Frame with a frequency of 1 Hz (TBC).

BUS-940/Created/T

For transmission of TM Blocks from the MMO to the BC, the Block Transfer Protocol (RT to BC Block transfer) as specified in section 5.5 of this document shall apply.



BUS-941/Created/T

The TM-Block (Telemetry data block) shall be read from RT subaddress 1 only.


BUS-938/Created/T

The data block shall be embedded by the MPO (CSW) into a Telemetry Source Packet compliant with the BepiColombo packet structure definition as defined in [RD-1].

BUS-887/Created/T

All Telemetry Source packets containing the MMO telemetry data block shall be time stamped with the SCET time (of Telemetry data block acquisition) by the MPO (CSW).

BUS-874/Created/T,R

The first 16 bit of each Telemetry data block generated by the MMO shall be used as MMO Data Type Identifier (further called "Type-ID") to be interpreted by the MPO (CSW) as follows (TBC):

• Type-ID = 0dec: Private Data

• Type-ID <> 0dec: Housekeeping Data

BUS-885/Created/T,R

The HK data block provided by the MMO shall contain all parameters that define the health and safe working status of the MMO allowing monitoring of the correct operation.

BUS-875/Created/T,R

For Housekeeping Data, the Type-ID shall uniquely identify the structure of the related data block.

Detailed definition to be agreed via MMO ICD.

BUS-881/Created/T,R

The MPO (CSW) shall use the MMO Data Type Identifier value to set the Packet Category, Type and Subtype fields of the MPO telemetry packet containing the MMO telemetry data blocks. The Packet Process ID shall be set to a value corresponding to the MMO spacecraft.

BUS-882/Created/T

MMO telemetry data blocks with data type identifier value set to 0 (Private Data) shall be complemented to a Standard TM Source Packet by the MPO (CSW).



BUS-883/Created/T

The generation of telemetry data blocks by the MMO spacecraft shall be consistent with the acquisition rate on the MMO-1553B-Bus as defined in this document.

BUS-942/Created/T

MMO Event data shall be aquired using the Event Message Handling Protocol as specified in section 5.6 of this document.

BUS-992/Created/T

The length of the event data shall be restricted to 32 words of 16bit length i.e one Mil-1553B-bus message (TBC).

5.9.2 MMO Commanding Telecommand data blocks provided by MMO will be embedded by the BepiColombo ground segment into MPO Service 2 TC packets as per [RD-1] with the Applicaton Process ID (APID) corresponding to the MMO.

BUS-877/Created/T

The MPO (CSW) shall extract the MMO Telecommand Data Block from the MPO TC Source Packet and transmit it over the MMO-1553B-Bus to the MMO spacecraft.

BUS-868/Created/T

Commanding, i.e. transfer of TC Blocks, shall be performed in the Minor Frame with a frequency of 1 Hz (TBC).

BUS-936/Created/T

For transmission of TC Blocks from the BC to the MMO, the Block Transfer Protocol (BC to RT Block transfer) as specified in section 5.5 of this document shall apply.

BUS-937/Created/T

The TC-Block (Telecommand data block) shall be written to RT subaddress 1 only.

The Transfer type bits in the Transfer Descriptor Transfer Control Word shall be set accordingly.

BUS-880/Created/T

The MMO shall always be able to receive, process and distribute the Telecommand data blocks sent with the maximum data rate as specified within this document, regardless of the data block sizes.



BUS-888/Created/T,R

A telecommand data block shall contain one and only one telecommand function.



6 Mil-Bus FDIR (TBC)

BUS-950/Created/R

The Mil-Bus FDIR requirements apply to all BepiColombo Mil-Bus systems, i.e. MPO-1553B-Bus, MTM-1553B-Bus and MMO-1553B-Bus.

BUS-757/Created/A,R

No change of spacecraft redundancy configuration shall be performed on Mil-Bus FDIR protocol level.

6.1 Error Processing on BC Hardware Level

This section focuses on the BC side processing of errors that would occur during message transfers.

A valid data reception for a non-broadcast message requires a status response, whereas an invalid data reception suppresses the status response but requires certain other actions. As stated in the standard, the message command word has been validated and the error occurs in the data word portion of the message. The withholding or suppression of the status response alerts the BC error detection logic (no response time-out error) to the fact that an incomplete message has occurred and some level of error recovery must occur. The setting of the message error bit in the status word that remains in the RT will provide additional information to the error recovery logic only if the BC requests the status word using the appropriate mode code.

Message Error bit / No response time-out: As the BepiColombo real-time message transfer is basically built upon a continuous, sequential management of periodic transfers from/to minor frame subaddresses, no retry nor "Transmit Status Word" mode command can be inserted. Therefore, during the communication slots dedicated to periodic message transfers, a Message Error bit set by an RT would not be seen by the BC. Instead, a "no response time-out" error would be recorded by the BC hardware.

Loopback errors: Loop-back is provided that permits testing as close to the BC output as possible (Bus Coupler not covered). Results are posted in the response block that is available to the host. Syndrome bits are reporting command validity tests equivalent to those performed by the RT.

BUS-964/Created/T

The BC shall check the response received to messages sent to the RT to identify and correct the loss or corruption of a single message (e.g. occurrence of noise on the bus).



BUS-960/Created/T

The BC shall check the response received to messages sent to the RT to detect errors that affect a single RT / data bus interface and automatically switch to the redundant interface (if available by bus topology).

BUS-961/Created/T

The BC shall check the response received to messages sent to the RT to detect errors that affect a single RT irrespective of the Mil-Bus interface used and raise a corresponding event to higher level FDIR.

BUS-962/Created/T

The BC shall check the response received to messages sent to the RT to detect errors that affect a single BC / data bus interface and automatically switch to the redundant interface (if available by bus topology).

BUS-965/Created/T

The BC shall check the response received to messages sent to the RT to detect errors due to physical bus damage and switch to the redundant bus if available.

BUS-759/Created/T,R

The above shall be achieved by checking the Status Word availability and content, and the presence of the associated data words (No checking of data word content).

BUS-231/Created/T

No retry shall automatically be attempted by the BC unless instructed otherwise by the central software.

BUS-945/Created/T

The BC shall collect at least the following Mil-Std-1553B Status Word bit error conditions from the RT:

• Message Error Bit

• Service Request Bit (as required)

• Busy Bit

• Subsystem Flag Bit (as required)

• Terminal Flag Bit (as required)



BUS-946/Created/T

The BC shall collect (and store into communication memory) the following error conditions from the bus interface for Mil-Bus FDIR:

• No response time-out: covering the cases when RT does not generate Status Word following assertion of the Message Error bit.

• BC Loopback errors: errors affecting the transmitted message detected by the BC itself (bus coupler not covered).

• RT response errors: errors affecting the transmitted message detected by the RT (TBC)

• RT Status Word: Busy bit and Message Error bit with restriction regarding the Message Error bit during periodic transfers.

BUS-947/Created/T

The following Mil-Bus FDIR related commands shall be provided for usage by on-board functions and ground control (TBC):

• Switch-over to bus A (nominal)

• Switch-over to bus B (redundant)

• Enable Mil-Bus automatic switch-over

• Disable Mil-Bus automatic switch-over

Detailed format of these commands to be agreed via OBC Hardware/Software ICD.

BUS-952/Created/T

The BC shall provide the active/switch status of bus A / bus B to the on-board functions and ground control.

6.2 Error Processing on BC Software Level

BUS-484/Created/A,R

The BC software shall use the errors defined in BUS-946 for determining the next FDIR action to be undertaken.

BUS-958/Created/T

The Mil-Bus error conditions detected by the BC shall be reported to higher level FDIR.

BUS-473/Created/T

Upon error occurrence, no retry shall be attempted and the minor frame operations shall continue until the last message transfer has been completed.



BUS-505/Created/T

Any message that has failed - protocol or no response - shall not be retransmitted during the same minor frame in which that message was originally sent.

BUS-483/Created/T

No "Transmit Status Word" mode command shall be issued by the BC upon "no response time-out" error during the execution of the minor frame periodic message transfers.

BUS-486/Created/T,R

The BC software shall analyse the errors logged by the BC hardware in the communication memory (ref. BUS-946), establish a "Fault Report (most probable failure cause)" and undertake "FDIR action on bus level" as shown in the Figure 6.2-1:

Error condition Fault Report (most probable failure cause)

FDIR action on bus level

For only one RT: Loopback = OK; repeated "No response time-out" errors or "RT response errors".

Unique RT suspected; RT fails to respond with a valid transmission for consecutive commands.

Complete minor frame and continue major frame; Suspend transfers with that RT.

For several RTs on same bus: Loopback = OK; repeated "No response time-out" errors or "RT response errors".

Bus Coupler and bus suspected; Common items on communication path.

Switch to redundant bus at the latest at next major frame keeping the same processor on BC side.

Repeated "Loopback errors" for several RTs Bus Controller suspected. Report to system level FDIR.

Repeated Busy bits RT unit (overload, non-interruptible task, etc.)

Report to system level FDIR.

Figure 6.2-1: Recovery as a Function of 1553B Error Conditions

6.3 Mil-Bus Failure Isolation Procedure

BUS-948/Created/T

The BC shall use bus A as the default transfer medium.

BUS-949/Created/T

If bus A was used and the BC Mil-Bus FDIR function detects/isolates a bus error on bus A, an automatic and global (all message exchange with all RTs connected to this bus) switch to bus B shall be performed (bus reconfiguration).

BUS-951/Created/T

No automatic bus reconfiguration from bus B to bus A shall be implemented.

In other words, if a further failure is isolated on bus B, no automatic recovery shall be triggered and the traffic shall be maintained on bus B.



A report shall be generated and provided to higher level FDIR function.

BUS-954/Created/T,R

The isolation of the bus failure shall be an automatic procedure performed by the BC. A simplified flow control diagram is given in Figure 6.3-1.

Error flag update

EvaluateMil-Bus Errors

Major Frame cycle on Bus A

No Error Send test command on Bus BMil-Bus Error

Evaluate test

Send test command on Bus A(to eliminate spurious noise error)

Evaluate test

Bus B not OK(not usable)

Bus B OK

Bus A not OK

Bus A OK(error disappeared)

(RT Transmision Error,RT No-Response Time-out..)

Continue on Bus A Switch to Bus B

Figure 6.3-1: Mil-Bus Failure Isolation procedure (simplified)

BUS-955/Created/T

For failure isolation, the BC shall sample the status of bus B via dedicated asynchronous messages whilst the main traffic remains on bus A.

BUS-956/Created/R

A bus failure is confirmed if bus B is sampled OK whilst bus A is sampled as failed.

BepiColombo MIL-STD-1553B Bus Protocol...

Documents

Transcript of BepiColombo MIL-STD-1553B Bus Protocol...