Depending on the desired latency and frequency requested it is foreseen to implement the service instances in two ways: • Access via pre-allocated bandwidth with populated content Typica
Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply.
Terms and definitions to the present standard
3.2.1 1553 message data-link layer exchange as defined in clause 3.7 of MIL-STD-1553B
3.2.2 communication device equipment or component connected on a MIL-STD-1553B bus and providing communication functions as a Bus Controller, Remote Terminal or Bus Monitor
NOTE Communication devices are building blocks of the
1553 reference architecture described in clause 4.3.1
3.2.3 communication frame (CF) time interval delimited by two Communication Frame Synchronization messages
NOTE The CF usage is described in clauses 4.4.2.2 and 4.5.3
(informative) and specified in clause 8.3, Communication Synchronization service (normative)
3.2.4 data bus system bus network and communication devices which forms an autonomous whole capable of performing information exchange
3.2.6 time synchronization cycle (TSC) time interval delimited by two Time Synchronization Messages
NOTE The Time Synchronization Message usage is described in the informative clause 4.5.2 and defined by clause 8.2.2, Time Synchronize.
Abbreviated terms
The following abbreviations are defined and used within this Standard:
Abbreviation Meaning ADC acquisition data counter
AOCS attitude and orbit control system
CCSDS Consultative Committee for Space Data Systems
CUC CCSDS unsegmented time code
ECSS European Cooperation for Space Standardization
FDIR failure detection, isolation and recovery
GNSS global navigation satellite system
SDBP spacecraft data bus protocol
SOIS spacecraft onboard interface services (from CCSDS)
SYNCH data bus system synchronization signal
Conventions
Bit numbering convention
The most significant bit of an n-bit field is:
• the first bit transmitted, and
• the leftmost bit on a format diagram
The least significant bit of an n-bit field is:
• the last bit transmitted, and
• the rightmost bit on a format diagram
This convention is illustrated in Figure 3-1
First Bit Transmitted n-bit Data Field
Sub-address convention
SA nT stands for Sub-address #n, Transmit, while SA nR stands for Sub- address #n, Receive
Context
The MIL-STD-1553B notice 2 standard is widely utilized in various spacecraft data links, including commercial and scientific satellites, space exploration vehicles, launchers, and manned flight applications It specifies the physical and data link layer requirements necessary for creating an efficient onboard data bus system that can exchange small data messages of up to 512 bits However, the standard does not address the management of larger data structures or the complex control of data flows needed for advanced communication and synchronization services.
An analysis of on-board data bus systems and communication devices in spacecraft reveals that fundamental communication and synchronization services can be uniformly defined while still allowing for customization to meet specific performance needs Establishing a common framework for these services enhances the potential for reusing communication devices across future missions and serves as a standardized reference for the development and verification of data bus systems.
Approach
The ECSS working group is focused on establishing a standard that identifies the layers, services, and functions of typical communication devices with a 1553 interface, drawing from the collective experience of its participants in various space projects, including science, telecommunications, space exploration, and transportation This approach is designed to enhance the effectiveness and interoperability of communication systems in the space sector.
• Identifying Reference Architectures (Layers, Services, Functions and Elements of protocol) of typical communication devices with MIL-STD-
• Characterizing Services, Functions and Elements of Protocol of each Layer within identified Reference Architectures, using concrete project specifications;
• Selecting candidate items within each Layer for standardization, proposing solutions and identifying requirements for RT and BC type MIL-STD-1553 communication devices
• Define normative requirements rather than recommendations
To avoid delays and significant cost impacts in projects, it is crucial to ensure that any deviations from mission requirements are identified and tracked during the specification phase, rather than at the integration stage This lesson learned from various project experiences emphasizes the importance of proactive management of mission requirements.
• Enabling the development of spacecraft onboard communication services compatible with the CCSDS/SOIS requirements
As far as possible, the defined communication requirements are extracted from the experience on existing spacecraft specifications.
Description of services
Overview
This clause provides an overview of the services defined in this standard within the data-link layer
• Time service which supports the distribution of time information across a 1553 data bus
• Communication Synchronization service which supports time multiplexing of data bus messages in a deterministic way
• Set Data and Get Data services which support non-confirmed data transfers of restricted length with a simple protocol without handshake
• Data Block Transfer service which supports confirmed transfers of data blocks on request of the sender with handshaking supported by a protocol
• Terminal Management services which provide standard functions and structured data in support to the implementation of project specific terminal management
This clause offers an informal overview of the services provided For a comprehensive specification of these services and the definition of message formats, please refer to clause 7 of this standard, which outlines the normative requirements.
The services are interconnected, with the mandatory "Communication Synchronization" service ensuring real-time properties for all other services Additionally, the "Terminal Management" service depends on the "Get/Set" service, highlighting the interdependencies among these functionalities.
“Communication Synchronization” service “Time”, “Get/Set” and, “Data Block Transfer” services are independent from each other but all rely on the
“Communication Synchronization” service The dependency graph is depicted in Figure 4-11
The service primitives offer reporting on service completion based on service capabilities, but do not provide a detailed view of 1553 bus activity, which may limit failure investigation Experience shows that direct analysis of communication errors for Fault Detection, Isolation, and Recovery (FDIR) often fails in projects due to the additional software required, impacting real-time performance Consequently, this standard suggests that specific details for offline FDIR analysis can be obtained through dedicated FDIR services, which may be tailored to individual projects or outlined in other standards.
Time service
The Time service facilitates the distribution of reference time over a 1553 data bus, originating from a central On-Board Time Master at the BC side and extending to multiple On-Board Time Slaves on the RT's sides This distribution occurs periodically through the continuous repetition of two service primitives, TimeData and TimeSynchronize, as illustrated in Figure 4-12 Additionally, these service primitives can be utilized independently if one is not chosen for a specific service-user application.
The On-Board Time Master invokes a TimeData.Submit primitive to request the service provider at BC to distribute a Time Message across the bus to all On-Board Time Slaves This request includes the current time or the time for the next Time Synchronization Message if the TimeSynchronize primitive is also utilized Consequently, a Time Message is broadcasted on the data bus to all RTs, which then deliver the received time to their local On-Board Time Slaves using the TimeData.Deliver primitive Each On-Board Time Slave stores the received time for future use, with the time format being standardized.
During the upcoming Time Synchronization Event, the On-Board Time Master will initiate the Time Synchronize.Submit primitive This action generates a Time Synchronization Message, which is transmitted as a Synchronize mode command via broadcast on the data bus to all RTs, or alternatively, as a distinct signal on a dedicated line.
RT uses the TimeSynchronize.Deliver primitive to inform its service user, the local On-Board Time Slave, of a Time Synchronization Event In response, the On-Board Time Slave can either directly update its local on-board time at the event or implement additional algorithms to maintain synchronization with the reference time.
In case of usage of the TimeSynchronize primitive, the process is started by the
BC initiates communication with a Time Message, which is subsequently followed by the first Time Synchronization Message Since RTs can be powered at any time, RT applications are designed to handle any sequence of these two messages effectively.
Record time message present/not present Prepare local timer for next Time Synchronization
Record Time Sync present/not present
Adjust local timer if needed
Record time message present/not present Prepare local timer for next Time Synchronization
Record Time Sync present/not present
Adjust local timer if needed
The On-Board Time Master regulates the occurrence of the TimeSynchronize.Submit primitive, which is generated at a naturally occurring frequency in the time counter In the 1553 data bus reference system outlined in this document, a Time Tick Period of 1 second is utilized.
The On-Board Time Master can operate in both free-running mode and synchronized to a GNSS receiver, allowing for synchronization operations when necessary Two methods are permitted for this synchronization process.
1 The OBT Master adjusts its frequency by speeding up or slowing down such that it within a reasonable time ends up in phase with the GNSS system Typically the adjustment is made until the second ticks coincide and thereafter any coarse OBT setting can take place to keep the spacecraft exactly in phase with the GNSS system
2 The OBT Master locks its frequency to the GNSS clock frequency but keeps running with a fixed offset relative to the GNSS system This offset is then added to the Master OBT time when the time is sent on the 1553 bus With this approach the subsecond part of the distributed time is typically not be zero when the Master OBT is in full sync
The two primitives of this service can function independently For applications needing precise time synchronization, the Time Synchronization Message can be transmitted over a dedicated line, rather than as a 1553 Message Conversely, for applications that require only rough synchronization, the TimeSynchronize primitive can be entirely disregarded Additionally, the accuracy of the synchronization impacts the resolution of the Time Message, with full resolution being relevant only when the Time Synchronization Message is sent through a separate line.
For applications not requiring time distribution, such as simple cyclic control applications, the TimeData primitive can be omitted
To enable the RT application to effectively correlate the two service primitives, the BC must allocate sufficient time for the RT to process a Time Message prior to sending the Time Synchronization Message It is crucial that the BC refrains from sending a new Time Message too soon after the Time Synchronization Message, ensuring that the RT can process the latter without any alteration to its time value These relationships are illustrated in Figure 4-14, depicting the setup and hold times in relation to the Time Synchronization Message.
Figure 4-14: Time distribution and synchronization
An RT application can utilize the RT Health monitoring function to report a missing Time Message or Time Synchronization Message, especially if it deems that the absence of these messages may lead to RT desynchronization.
* TimeData This primitive is used by On-Board Time
Master on the BC to distribute Time Message to all On-Board Time Slaves on the RT’s
* TimeSynchronize This primitive is used by On-Board Time
Master on the BC to distribute Time Synchronization Message to all On-Board Time Slaves on the RT’s
Communication Synchronization service
The Communication Synchronization service supports time multiplexing of data bus messages and series of messages in a deterministic way, allowing determining in advance when a message is transferred on the bus
Data bus communication occurs in intervals known as Communication Frames, each initiated by a Communication Frame Synchronization Message through a Synchronize with Data Word mode command This data word specifies the Communication Frame number The Communication Synchronization Service notifies BC and RT applications of the Communication Frame's commencement, with the BC application receiving this information via a CommunicationSynchronize service primitive.
When utilizing this service alongside the Time Service that employs the TimeSynchronize primitive, Communication Frame N° 0 initiates with the Time Synchronization Message rather than the Communication Frame Synchronization Message Additionally, it is feasible to adjust the duration of the Communication Frames to maintain synchronization with the On-board Time Master, addressing frequency discrepancies between the 1553BC oscillator and the time reference oscillator.
Time Synchronization Message or Communication Frame Synchronization Message application RT
Communication Frame Synchronization Message application RT
Communication synchronization Service with usage of Time Synchronization primitive
Communication synchronization Service without usage of Time Synchronization primitive application BC
Communication Synchronize.Deliver application BC
Time Synchronization Message or Communication Frame Synchronization Message application RT
Communication Frame Synchronization Message application RT
Communication synchronization Service with usage of Time Synchronization primitive
Communication synchronization Service without usage of Time Synchronization primitive application BC
Communication Synchronize.Deliver application BC
The arrival of a Communication Frame Synchronization Message at the RT is signalled to the RT application through CommunicationSynchronize service primitive together with the current frame number
To enhance the accuracy and determinism of message transfers, scheduling individual messages in relation to the start of the Communication Frame is a viable option.
Communication Frame period Loop forever:
Communication Frame Synchronization Message CommunicationSynchronize.
Communication Frame Synchronization Message CommunicationSynchronize.
Communication Frame period Loop forever:
Communication Frame Synchronization Message CommunicationSynchronize.
Communication Frame Synchronization Message CommunicationSynchronize.
* CommunicationSynchronize This primitive is used by all on-board communication devices to synchronize their activities with respect to a common event: the Communication Frame Synchronization Message
• The TimeSynchronize primitive of the Time Service can be supported or not
• The number of Communication Frames per Time Synchronization Cycle or per second is configurable
The TimeSynchronize primitive of the Time Service allows for configurable synchronization between two services This can be achieved by either adjusting the duration of all Communication Frames or modifying the duration of the last Communication Frame prior to the next Time Synchronization Message.
• The capability to control the start time of messages within all Communication Frames can be enabled or disabled
Running with Time Service which utilizes TimeSynchronize primitive
The two methods for synchronizing bus communication with time are illustrated in Figure 4-17, featuring an example where the Bus Controller operates at a slower pace than the Master Time.
The first method adjusts the duration of all Communication Frames to ensure an integer number of frames fits between two time ticks In contrast, the second method modifies only the duration of the last Communication Frame to achieve the same fitting.
Synchronization by adjusting the duration of all frames
Master tick On-board Time
Out-of-sync detected Frame duration adjustment started In-sync detected.
Synchronization by adjusting the duration of the last frame
Master tick On-board Time
Out-of-sync detected Frame duration adjustment started In-sync detected.
Frame duration set to nominal
Frame duration set to nominal
Synchronization by adjusting the duration of all frames
Master tick On-board Time
Out-of-sync detected Frame duration adjustment started In-sync detected.
Synchronization by adjusting the duration of all frames
On-board Time Master tick
Master tick On-board Time
On-board Time Master tick
Out-of-sync detected Frame duration adjustment started In-sync detected.
Synchronization by adjusting the duration of the last frame
Master tick On-board Time
Out-of-sync detected Frame duration adjustment started In-sync detected.
Frame duration set to nominal
Frame duration set to nominal
Synchronization by adjusting the duration of the last frame
On-board Time Master tick
Master tick On-board Time
On-board Time Master tick
Out-of-sync detected Frame duration adjustment started In-sync detected.
Frame duration set to nominal
Frame duration set to nominal
Figure 4-17: Communication Frame duration adjustment methods
Scheduling transfers within the Communication Frame
To facilitate the scheduling of data bus transfers, the BC can optionally implement a mechanism that precisely identifies when transfers occur in relation to the start of the Communication Frame This mechanism aids in bus profiling, enabling designers to accurately position all transfers to avoid time conflicts and ensure that guaranteed latencies are maintained in all operational scenarios.
Distribution and acquisition: Set and Get Data services
The Get and Set Data services enable service-users to transfer limited-size data from a source to a destination in a single access These services facilitate one-directional communication between two service-users in a point-to-point configuration, ensuring that the data is delivered in the same structure as it was at the source Notably, the protocol does not transmit the data block's length, necessitating that both communicating applications (on BC and RT) possess implicit knowledge of the message's length.
The size of data is not limited to one 1553 message
These services are asymmetric and are provided on the BC side only:
• Set Data provides data transfer from BC to one RT
• Get Data provides data transfer from one RT to BC
Although these services are provided on the BC side only, they do imply some indication on the RT side, which depends on the HW/SW implementation of the
These services guarantee the delivery of data at data link layer by relying on the
1553 communication error detection mechanisms; they do not use additional confirmation mechanism within the data link layer
These services are designed to support short, direct Command & Control messages and offer a straightforward segmentation method for upper layer protocols that handle data structures larger than 32-16 bits, eliminating the need for a handshake mechanism.
Depending on the desired latency limit, Set Data service can be supported in two ways on the bus-profile level:
• Type 1: Via pre-allocated bandwidth with populated content
• Type 2: Via pre-allocated bandwidth with unpopulated content
This service ensures timely data delivery to the destination RT, maintaining a bounded timeframe It is crucial for the service-user application at the receiving end to promptly retrieve the delivered data to prevent it from being overwritten by new information.
The Set Data service leverages pre-allocated bandwidth and populated content to deliver instances that meet strict latency requirements and facilitate periodic distribution Additionally, it employs Communication Frames produced by the Communication Synchronization Service.
The SendData.Submit primitive is called by the service user on the BC before the Communication Frame concludes, supplying the identifier for the data transfer within the Bus Profile This request facilitates the transfer of the specified data to the communicating peer on the RT in the subsequent Communication Frame, utilizing predefined transfers supported by the Bus Profile.
After the transfer is completed, the service provider notifies the service user on BC of the data transfer's completion through the SendData.Deliver primitive, including the Communication Frame number at the end of the Communication Frame.
The service-user can then retrieve a status of the transfer at data link layer level through the ReadStatus.Submit primitive
Type 1 service ensures data validity through the data transfer protocol, rather than indicating it within the data itself The application at real-time (RT) can monitor the Communication Frame number in the Communication Frame Synchronization Message or utilize other application-level methods to verify the correct performance of the underlying scheduling scheme.
* SendData This primitive is used by service-user (BC) to transfer data to communicating peer (RT)
* ReadStatus This primitive is used by service-user (BC) to query status of a requested data transfer
• Data length for each SetDataId
This type of Set Data service utilizes pre-allocated bandwidth with unpopulated contents to transfer the data It also utilizes Communication Frame generated by Communication Synchronization Service
The SendData.Submit primitive is called by the service-user on BC before the end of a Communication frame, specifying the destination (one RT with one or more subaddresses), the data to be sent, and its priority level The service-user receives a notification with the identifier of the transfer that carries the requested data through the same primitive This request leads to the transfer of the provided data in the next Communication Frame to the communicating peer on RT, utilizing one of the pre-allocated slots with unpopulated content, as supported by the underlying Bus Profile, which is determined by the data's priority level.
After the transfer is completed, the service provider notifies the service user in BC by sending a SendData.Deliver primitive at the end of the Communication Frame, indicating the Communication Frame number.
The service-user can then retrieve a status of the transfer at data link layer level through the ReadStatus.Submit primitive
To enhance the BC application, the introduction of a GroupId concept is essential A GroupId acts as a virtual channel within the bus profile, enabling the application to establish various priority levels, each with a guaranteed bandwidth This GroupId serves as a key parameter in the SendData.Submit primitive.
* SendData This primitive is used by service-user (BC) to transfer data to communicating peer (RT)
* ReadStatus This primitive is used by service-user (BC) to query status of a requested data transfer
• Data length for each SetDataId, GroupId
Depending on the desired latency limit, Get Data service can be supported in two ways or bus-profile level:
• Type 1: Via pre-allocated bandwidth with populated content
• Type 2: Via pre-allocated bandwidth with unpopulated content
In both cases this service guarantees acquisition of data from the source RT within bounded time
In Type 1 of this service, the destination user application on BC must ensure the timely retrieval of delivered data for processing, as this data can be overwritten by new information from the source (RT).
For both service types, the source user application on RT must ensure that data is provided promptly before it can be accessed by BC.
The validity of data in both service types is guaranteed by the data transfer protocol, rather than being indicated within the data itself The BC application can ensure the proper functioning of the remote terminal and the timely updating of acquired data through the RT Monitoring Service, utilizing commands sent via the Set Data service or other application-level methods.
The Get Data service leverages pre-allocated bandwidth and populated content to deliver instances that meet strict latency constraints and periodicity requirements.
The ReceiveData.Submit primitive is called by the service-user on the BC, initiating communication through the CommunicationSynchronize.Submit primitive of the Communication Synchronization service This process triggers data acquisition from the source RT, utilizing predefined transfers as per the underlying Bus Profile The destination service-user on the BC is informed of new data arrival through the ReceiveData.Deliver primitive, which can be either explicit or implicit, with the latter occurring at the start of the next Communication Frame Subsequently, the service-user accesses data from the service-provider's "data pool" using the ReadData.Submit primitive.
Get Data service can imply some indication for the data source user (i.e for the RT), which depends on the HW/SW implementation of the RT
* ReceiveData This primitive is used to initiate periodic data acquisition process from communicating peer (RT)
* ReadData This primitive is used to retrieve acquired data from data pool of service provider
• List of valid GetData Id
This type of Get Data service utilizes pre-allocated bandwidth with unpopulated contents to achieve provision of those instances of the service which do not have tight “latency” constraints
Data Block Transfer service
The Data Block Transfer Service enables the transfer of Data Blocks upon the sender's request, providing confirmation upon completion It accommodates delimited and synchronized transfers of variable-sized Data Blocks, ranging from 1 byte to a mission-specific maximum of either 1024 bytes or 4096 bytes At the sending side, these Data Blocks are segmented for 1553-messages and de-segmented upon receipt The BC manages the multiplexing and de-multiplexing of Data Block transfers.
The service is designed for "intelligent" RTs that can segment and assemble large data structures while managing hand-shaking For transferring data blocks to and from "non-intelligent" RTs, the recommended services are Get and Set.
The Data Block Transfer Service is capable of handling both Telemetry and Telecommand-Packets in accordance with the Packet Utilization Standard, ECSS-E-ST-70-41 Importantly, the internal structure of a Data Block remains transparent to the service, allowing for the transfer of any type of data.
The Data Block Transfer Service employs a handshake mechanism between the sender and receiver to ensure flow control, confirm reception, and prevent duplicate transfers While the protocol extension does not impose control flow requirements, the control information within the data blocks can be managed at the application layer to implement a control flow mechanism This service guarantees that Data Blocks are delivered in the same sequence as they were sent Additionally, it supports two levels of Quality-of-Service.
• Best Effort, which transfers the data without any check for correctness of the data itself
• Verified Length, which transfers the data with the receiver checking that the correct number of bytes has been received with no data bus transmission errors
Error detection is facilitated by the capabilities of the MIL-1553B Standard When transmission errors occur, they are reported to higher protocol layers within the Bus Controller (BC) or the Remote Terminals (RTs) to support Fault Detection, Isolation, and Recovery (FDIR).
The Data Block Transfer Service includes a protocol reset capability that operates independently for each BC-RT communication link and direction (BC to RT and RT to BC) This reset can be utilized during the initial startup of a communication device or to address communication issues Typically, the sender of a Data Block initiates the reset, with the BC resetting the BC to RT communication and the RT resetting the RT to BC communication As the master in a 1553 data bus system, the BC can also command the RT to reset the RT to BC communication This feature simplifies the process by minimizing the need for complex time-out mechanisms within the RTs, especially when the BC is reconfigured and needs to restart all active communication sessions with the RTs.
For missions requiring guaranteed data delivery, the service user relies on support from the Verified Length Quality-of-Service level.
The Data Block Transfer Service does not support the encapsulation or de-encapsulation of user data structures that exceed the maximum block length For larger data blocks, the necessary service characteristics are ensured at higher protocol layers, utilizing the control structures of these services For instance, if a mission involves TM/TC packets that surpass the maximum block length or requires file transfer, it is recommended to use Service 13 of ECSS-E-ST-70-41 at layers above the Data Block Transfer Service protocol layer.
For transfer of data, two ways of using the 1553 subaddresses are supported:
Flat sub-addressing utilizes various subaddresses to transfer distinct sections of a transmitted data block This mode allows for a maximum transmission block length of 1024 bytes, with the standard specifying the subaddresses to be employed.
Deep sub-addressing allows a single subaddress to transfer various sections of a transmitted data block, with a maximum block length of 4096 bytes The usage of subaddresses is dictated by the design of the RT.
The choice of sub-addressing mode for a specific RT is influenced by its design, allowing the BC to utilize both modes simultaneously for various RTs For particular spacecraft missions, specific subsets of capabilities can be selected.
The service primitives exhibit formal symmetry between a Bus Controller (BC) and a Remote Terminal (RT); however, since all timing and data exchanges are initiated and managed by the BC in accordance with the master-slave architecture of the MIL-Std 1553B data bus system, the timing latency details differ for each Additionally, the activities supporting the protocol within a BC or RT are asymmetric These distinctions will be elaborated upon in the subsequent clauses where applicable.
To distinguish service usage by service-user located on BC side versus service- user located on RT side the following naming convention is adopted:
- a BC-> RT transfer is called a Data Distribution transfer;
Data Block associated with this transfer is called Distribution Data Block
- a RT-> BC transfer is called a Data Acquisition transfer;
Data Block associated with this transfer is called Acquisition Data Block
* SendData This primitive is used to initiate transfer of data from data source to the data destination
• Address configuration table (BC side only)
4.5.5.2 Data Block Transfer control messages:
The Data Block Transfer service requires the exchange of specific control messages between the Bus Controller (BC) and the Remote Terminal (RT) over the data bus prior to and following the user-data transfer Each data transfer compliant with this service begins with the exchange of either:
an Acquisition Transfer Request for RT-to-BC-transfers, or
a Distribution Transfer Descriptor for BC-to-RT-transfers
Acquisition Transfer Confirmation for RT-to-BC transfers or
A Distribution Transfer Confirmation is issued for BC-to-RT transfers upon the completion of data transfer, containing essential details such as data size, flow control, and error status.
The Distribution Transfer Descriptors and Acquisition Transfer Requests consist out of two words each Details are defined in clause 8.6.1 for Distribution Transfer and clause 8.6.2 for Acquisition Transfer
4.5.5.3 Protocol start-up and reset
Before starting communication between the BC and RT, a protocol reset is made A reset of the protocol is not necessary after a switch from bus medium
The Data Distribution protocol reset is initiated by the BC, while the Data Acquisition protocol reset is typically started by the RT However, the BC can also trigger this reset through the Terminal Management service, compelling the RT to commence the protocol reset procedure.
Terminal Management services
Data bus management functions are influenced by the chosen bus topology for a specific mission, which is beyond the scope of this standard Nevertheless, the communication services and 1553 message transfer level functions can offer valuable information to support Data Management System applications, including Failure Detection, Isolation and Recovery, as well as system configuration control.
Terminal Management services ensure data link layer harmonization for RT Health and Monitoring, Alarm Notification, Terminal Configuration, and Data Wrap Around These services utilize the Get Data and Set Data functionalities to enhance operational efficiency.
The RT Health and Monitoring service enables the collection of health information from remote terminals throughout the bus, specifically addressing subsystem alarms that do not directly affect data integrity.
• The Alarm Notification service allows a RT to signal events to the Failure Detection Isolation and Recovery function of the bus management In the
MIL-STD-1553B standard, this is covered by the status bits:
Terminal Flag Bit concerning RT level problems;
Subsystem Flag Bit concerning RT subsystem, including SW for impact on the transferred data;
• The Terminal Configuration service allows the user on BC to (re)configure the Remote Terminals
The Data Wrap Around Service offers essential support as outlined in clause 30.7 of MIL-STD-1553B, facilitating the testing of a single Bus Controller (BC) to Remote Terminal (RT) connection to enhance Fault Detection, Isolation, and Recovery (FDIR) processes.
The Data Wrap Around service is essential for all RTs and BCs, while the implementation of RT Health Monitoring, Alarm Notification, and Terminal Configuration services is optional and can vary based on mission requirements Additionally, the implementation approach for these services may be influenced by specific design considerations for each communication device For instance, a basic RT lacking an internal processor may only provide a limited set of RT status flags with relevant information.
Overview
The physical layer of the 1553 data bus is defined by MIL-STD-1553B, which includes detailed specifications such as the precise bus cable impedance, the selection of transformer-coupled stub connections, the application of discharge resistances for both the bus cable and stubs, and the definition of the connectors used between terminals and the bus.
For the connectors there are three different configurations:
The initial configuration is designed for a single Bus Controller (BC) or Real-Time (RT) system, featuring two connectors, each with one bus This setup is ideal for modular units, where nominal and redundant terminals are situated on separate modules with physical separation A common example of this configuration is found in central spacecraft computers, where each Bus Controller resides on different processor boards.
Nominal BC or RT couplerBus Bus coupler Redundant BC or RT
Figure 5-1: Bus connectors for separated BCs or RTs
The second configuration for an internally redundant bus coupler (BC) or routing terminal (RT) features two connectors, each with two stubs connected to a single bus This setup is ideal for units where nominal and redundant terminals are housed within the same physical module, often with minimal separation A common example is a compact internally redundant sensor, where connector space is constrained.
Nominal BC or RT couplerBus Bus coupler Redundant BC or RT
Figure 5-2: Bus connectors for integrated BCs or RTs
The third configuration involves units connected to two separate, dual-redundant buses, featuring two connectors with distinct stubs for each bus This setup is ideal for modular designs, where nominal and redundant terminals are situated on separate modules with physical separation, yet each module connects to different buses Typical examples include a central spacecraft computer with two Bus Controllers on each processor board and an instrument control computer functioning as a Real-Time (RT) unit on one bus and a Bus Controller (BC) on the other.
Bus 2 Nominal BC couplerBus Bus coupler
Figure 5-3: Bus connectors for separated BCs or RTs connected to dual buses
General
a Physical layer requirements, which are not applicable to legacy devices, shall be identified and provided in an applicability matrix and statement of non-compliance.
Data bus characteristics
a The data bus characteristics including stubs shall be in conformance with
MIL-STD-1553B clauses 4.5.1, 30.10.1 and 30.10.2 with the following precisions:
1 The data bus connection using transformer coupled stubs in conformance with MIL-STD-1553B Figure 9, with stub length not exceeding 6 m
2 The wire-to-wire distributed capacitance not exceeding 98 pF/m
3 The cable power loss not exceeding 1,5 dB/30 m at a sinusoidal frequency of 1 MHz b The nominal data bus cable characteristic impedance, identified in MIL-
STD-1553B clauses 4.5.1.2, should be 75 Ω with a variation of maximum ±5Ω at a sinusoidal frequency of 1 MHz
NOTE This ensures that the bus cables are compliant with
The data bus cable wire must exhibit a resistance to the spacecraft chassis ground ranging from 100 kΩ to 100 MΩ, even in the event of a single open circuit fault in a resistor or cable wire Similarly, the data bus stub wire should maintain the same resistance range to the unit chassis ground under the same fault conditions The data bus is designed to be nominally redundant, adhering to the routing standards outlined in MIL-STD-1553B clause 4.6.2; however, a non-redundant data bus may be chosen for specific applications if needed.
Terminal characteristics
a The characteristics of a bus terminal shall be in conformance with MIL-
STD-1553B clause 4.5.2 and clause 30.10.6 b The electrical isolation between buses shall be in conformance with MIL-
STD-1553B clause 4.6.1 c The stub routing within a terminal shall be in conformance with MIL-STD-1553B clause 4.6.2.
Connectors
General
a Any Stub connection to a terminal shall be made by either of:
1 using 15-pole HDD pin connectors in conformance with ESCC 3401/001 or 3401/002 on the terminal unit
2 using 9-pole DEM pin connectors in conformance with ESCC 3401/001 or 3401/002 on the terminal unit b The pin allocation for a Bus Controller shall be in conformance with Table 5-1 or Table 5-3 c The pin allocation for a Remote Terminal shall be in conformance with and Table 5-2 or Table 5-3
Table 5-1: Pin allocation for 15-pin Bus Controller 1553 Bus Connector
Pin Name Pin Name Pin Name
2 GND or NC 7 NC 12 GND or NC
3 GND or NC 8 NC 13 NC
4 GND or NC 9 NC 14 GND or NC
NOTE 1 NC stands for no connection NOTE 2 GND stands for unit internal signal ground NOTE 3 The bus signalling voltage is considered as the differential voltage between the
Stub signal and the Stub return signal (Stub - Stub return)
Table 5-2: Pin allocation for 15-pin Remote Terminal
Pin Name Pin Name Pin Name
1 Stub 1 6 RT Address[4] MSB 11 Stub 1 return
3 GND 8 RT Address[2] 13 RT Address Parity
5 Stub 2 10 RT Address[0] LSB 15 Stub 2 return NOTE 1 NC stands for no connection
NOTE 2 GND stands for unit internal signal ground NOTE 3 The bus signalling voltage is considered as the differential voltage between the Stub signal and the Stub return signal (Stub - Stub return)
Table 5-3: Pin allocation for 9-pin Bus Controller or Remote
Pin Name Pin Name Pin Name
3 NC 6 Stub 1 return 9 Stub 2 return
NOTE 1 NC stands for no connection NOTE 2 GND stands for unit internal signal ground NOTE 3 The bus signalling voltage is considered as the differential voltage between the Stub signal and the Stub return signal (Stub - Stub return)
Pin allocation for 15-pin
a For Table 5-1 and Table 5-2, the RT address shall be obtained by connecting straps between an RT address or RT Address Parity signal and a GND signal such that:
1 A logical “1” level is defined by an unconnected RT address signal
2 A logical “0” level is defined by a strap between the RT address signal and a GND signal
NOTE For the case of a 9-pole connector no specific address connector is specified b For Table 5-1 and Table 5-2, the current through a strap shall not exceed
1 mA also in a single parts fault case c For Table 5-1 and Table 5-2, there shall be an odd number of straps
NOTE It is then said that the parity is odd.
Pin allocation for remote terminal nominal bus
The pin allocation for the remote terminal nominal bus must adhere to the configurations specified in Table 5-4 Additionally, for configurations 2 and 3 in Table 5-4, the connector arrangement from configuration 1 may be utilized.
Using the configuration 1 connector arrangement for applications in configurations 2 and 3 leads to a doubling of the number of connectors Additionally, for Table 5-4, the RT address must be fully strapped in both connectors, and the address utilized by the RT will be the AND of the two addresses.
The RT can operate independently of the installed connector In cases where the unit has only one RT pair, the RT B/D address pins must mirror the RT A/C address pins Additionally, legacy communication devices may route both nominal and redundant channel stubs through the same connector.
NOTE This routing violates the requirements in ECSS-E-
ST-20 clause 4.2.1.d, and a waiver should be raised when this standard is applicable
Table 5-4: Pin allocation for Remote Terminal nominal bus
Configuration Stub 1 usage Stub 2 usage Address straps
1 (BC) Single BC J1: Nominal channel
(BC A and BC B) J1: BC A Nominal channel
(RT A and RT B) J1: RT A Nominal channel
(Bus 1 and Bus 2) with either of:
Transmission method
a Data shall be transmitted as words on the bus in conformance with MIL-
General
a Data link layer requirements, which are not applicable to legacy devices, shall be identified and provided in an applicability matrix and statement of non-compliance.
Data Words and Messages
Data word format
6.2.1.1 General a The data word formats shall be in conformance with MIL-STD-1553B clauses 4.3.3.5, 30.4 and 30.5
NOTE Requirements in the following clause are precisions to this requirement
6.2.1.2 Additional requirements to MIL-STD-1553B
6.2.1.2.1 Mode commands and mode codes a Mode commands shall be sent using subaddress 31 b The mode code usage shall be in conformance with:
1 Mode code 0: Dynamic Bus Control
NOTE Not recommended, but allowed for specific applications
NOTE Optional, if used to be used for time distribution as defined by this standard
3 Mode code 2: Transmit Status word
NOTE Mandatory with usage in conformance with MIL-
4 Mode code 3 Initiate Self Test
NOTE Not recommended for use
5 Mode code 4: Transmitter Shut Down
NOTE Mandatory if a redundant bus is used with usage in conformance with MIL-STD-1553B clause
6 Mode code 5: Override Transmitter Shut Down
NOTE Mandatory if a redundant bus is used with usage in conformance with MIL-STD-1553B clause
7 Mode code 6: Inhibit Terminal Flag
NOTE Optional with usage in conformance with MIL-
8 Mode code 7: Override Inhibit Terminal Flag
NOTE Optional with usage in conformance with MIL-
9 Mode code 8: Reset Remote Terminal
NOTE This is optional If used see 6.2.1.2.2
10 Mode code 16: Transmit Vector Word
NOTE Optional, if used see 6.2.1.2.3
11 Mode code 17: Synchronize with Data Word
NOTE Mandatory, to be used for communication synchronization as defined by this standard
12 Mode code 18: Transmit Last Command Mandatory with usage in conformance with MIL-STD-1553B clause 4.3.3.5.1.7.13
13 Mode code 19: Transmit Built-in-Test Word
NOTE Not recommended for use
14 Mode code 20: Selected Transmitter Shutdown
NOTE Not recommended for use
15 Mode code 21: Override Selected Transmitter Shutdown
NOTE Not recommended for use
When mode code 8 is activated, both the RT and the subsystem must be reset to their power-up initialized state within a specified application-defined timeframe During this reset process, the RT will not respond to any valid commands.
Mode code 16 can only be activated when a Service Request Bit is set for the corresponding RT Additionally, the content of the vector word associated with mode code 16 is dependent on the specific application.
Non-recommended mode codes should not be issued by the Bus Controller (BC), and the Remote Terminal (RT) must respond to these commands as outlined in clause 4.3.3.5.1.7.1 of MIL-STD-1553B.
6.2.1.2.5 Terminal Status word a The Terminal Status Word bits usage shall be as follows:
1 Bit time 9: Message Error Bit, mandatory with usage in conformance with MIL-STD-1553B clause 4.3.3.5.3.3
2 Bit time 10: Instrumentation Bit., which is set to “0”
3 Bit time 11: Service Request Bit
NOTE Optional, if used see 6.2.1.2.5b
4 Bit times 12-14: Reserved and set to zero
5 Bit time 15: Broadcast Command Received Bit, mandatory with usage in conformance with MIL-STD-1553B clause 4.3.3.5.3.7
6 Bit time 16: Busy Bit Not recommended for use
NOTE A busy condition on an RT is a temporary situation that should not appear in nominal condition RTs are discouraged from setting this bit
7 If the Busy bit is encountered by the BC, notify the condition to the
8 Bit time 17: Subsystem Flag Bit Optional, but if used, use it only be used to signal RT application errors
9 Bit time 18: Dynamic Bus Control Acceptance Bit Not recommended, but allowed for specific applications
10 Bit time 19: Terminal Flag Bit Optional, but if used, use it only be used to signal RT internal errors b If Bit time 11 is used, this bit shall be used by the RT application to signal an Alarm situation
NOTE The alarm situation can be detailed through the transmission of a vector word if the “Transmit Vector Word” option is used.
Messages
a The data words shall be combined into messages in conformance with
MIL-STD-1553B clause 4.3.3.6, 4.3.3.7, 4.3.3.8, 4.3.3.9, 30.6 and 30.8 with the following precisions:
1 the BC response timeout is selectable to a fixed value within the following ranges:
(a) 14 às to 22 às for applications without bus repeaters
(b) 18 às to 30 às for applications with one bus repeater on a bus
2 RT to RT transfers are not used.
Terminal operation
a Terminals operating as Bus Controllers, Remote Terminals or Bus Monitors shall operate in conformance with MIL-STD-1553B clause 4.4, 4.6.3 and 30.3.
Subaddress usage
a The protocol elements defined in this standard shall be mapped on subaddresses as shown in Table 6-1
NOTE 1 For a given RT, all the unused SA of Table 6-1 can be used for the Get Data and Set Data services
NOTE 2 For units not following this standard concerning the Data Block Transfer Service the subaddress allocation can be different
Subaddress allocation may vary for units that do not implement the services outlined in clause 7 For a specific RT that supports the Data Block Transfer Service but does not utilize all reserved subaddresses, these subaddresses can be repurposed Additionally, if the Time Distribution Service is not utilized, subaddress 29 must remain unused, and both subaddresses 0 and 8 are prohibited from use.
NOTE This allows for a bus monitor to uniquely differentiate Command Words from Status Words as the Instrumentation Bit is always ‘0’.