1、BSI Standards PublicationBS EN 16603-50-13:2014Space engineering Interfaceand communication protocolfor MIL-STD-1553B data busonboard spacecraftBS EN 16603-50-13:2014 BRITISH STANDARDNational forewordThis British Standard is the UK implementation ofEN 16603-50-13:2014.The UK participation in its pre
2、paration was entrusted to Technical Committee ACE/68, Space systems and operations.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its
3、correct application. The British Standards Institution 2014.Published by BSI Standards Limited 2014ISBN 978 0 580 84190 3 ICS 49.140 Compliance with a British Standard cannot confer immunity from legal obligations.This British Standard was published under the authority of the Standards Policy and St
4、rategy Committee on 30 September 2014.Amendments/corrigenda issued since publicationDate T e x t a f f e c t e dEUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 16603-50-13 September 2014 ICS 49.140 English version Space engineering - Interface and communication protocol for MIL-STD-1553B data b
5、us onboard spacecraft Ingnierie spatiale - Interface et protocole de communication pour de bus de donnes embarqu MIL-STD 1553B Raumfahrttechnik - Schnittstellen und Kommunikationsprotokoll fr MIL-STD-1553B Datenbusse in Raumfahrzeugen This European Standard was approved by CEN on 1 March 2014. CEN a
6、nd CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtain
7、ed on application to the CEN-CENELEC Management Centre or to any CEN and CENELEC member. This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language
8、and notified to the CEN-CENELEC Management Centre has the same status as the official versions. CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugosla
9、v Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000
10、 Brussels 2014 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. EN 16603-50-13:2014 EBS EN 16603-50-13:2014Table of contents Foreword 7 1 Scope . 8 2 Normative references . 10 3 Terms, definitions and ab
11、breviated terms 11 3.1 Terms from other standards 11 3.2 Terms and definitions to the present standard 11 3.3 Abbreviated terms. 12 3.4 Conventions 13 3.4.1 Bit numbering convention 13 3.4.2 Sub-address convention . 13 4 Overview 14 4.1 Context . 14 4.2 Approach 14 4.3 Reference architecture . 15 4.
12、3.1 Communication devices architecture . 15 4.3.2 Mapping on CCSDS/SOIS sub-network layer 15 4.3.3 Service model . 17 4.3.4 1553 bus topology . 18 4.4 1553 bus scheduling aspects 19 4.4.1 Bus profiling and scheduling . 19 4.4.2 Bandwidth pre-allocation . 21 4.4.3 Implementation of the bus profile 23
13、 4.5 Description of services 25 4.5.1 Overview . 25 4.5.2 Time service 27 4.5.3 Communication Synchronization service . 31 4.5.4 Distribution and acquisition: Set and Get Data services 34 4.5.5 Data Block Transfer service 41 4.5.6 Terminal Management services 49 EN 16603-50-13:2014BS EN 16603-50-13:
14、20145 Physical Layer requirements . 50 5.1 Overview 50 5.2 General . 52 5.3 Data bus characteristics 52 5.4 Terminal characteristics 52 5.5 Connectors . 53 5.5.1 General . 53 5.5.2 Pin allocation for 15-pin . 54 5.5.3 Pin allocation for remote terminal nominal bus 54 5.6 Transmission method . 55 6 D
15、ata Link Layer requirements . 56 6.1 General . 56 6.2 Data Words and Messages . 56 6.2.1 Data word format 56 6.2.2 Messages . 58 6.3 Terminal operation 59 6.4 Subaddress usage 59 6.5 Message retries 59 7 Services definition 61 7.1 Time service . 61 7.1.1 TimeData primitive 61 7.1.2 TimeSynchronize p
16、rimitive 62 7.2 Communication Synchronization service 63 7.2.1 CommunicationSynchronize primitive 63 7.3 Set Data service . 64 7.3.1 SendData primitive 64 7.3.2 ReadStatus primitive . 66 7.4 Get Data service . 67 7.4.1 ReceiveData primitive . 67 7.4.2 ReadData primitive 69 7.5 Data Block Transfer Se
17、rvice . 69 7.5.1 SendData primitive 69 8 Protocol specification 71 8.1 Overview 71 8.2 Time service . 71 8.2.1 Time Data primitive . 71 EN 16603-50-13:2014BS EN 16603-50-13:20148.2.2 Time Synchronize primitive . 72 8.3 Communication Synchronization service 74 8.3.1 Requirements when the Time Synchro
18、nization service is implemented. 74 8.3.2 Requirements when the Time Synchronization service is not Implemented . 75 8.3.3 BC Requirements for Accurate Message Transfer (optional) . 76 8.4 Set Data service . 77 8.4.1 BC requirements . 77 8.4.2 RT Requirements 77 8.5 Get Data service . 77 8.5.1 BC re
19、quirements . 77 8.5.2 RT requirements . 78 8.6 Data Block Transfer service 78 8.6.1 Data Distribution requirements (BC to RT transfer) . 78 8.6.2 Data Acquisition requirements (RT to BC transfer) 83 8.7 Terminal Management services 89 8.7.1 RT monitoring . 89 8.7.2 RT Health data word definition 90
20、8.7.3 Terminal configuration commands 91 8.7.4 Data wrap around . 92 9 Test and verification . 93 9.1 Test specification 93 9.2 Tests traceability . 93 9.3 Test references . 93 Annex A (informative) Tailoring guidelines . 94 A.1 Scope . 94 A.2 Tailoring options and parameters 94 A.2.1 Overview . 94
21、A.2.2 Step 1: Function and service selection 94 A.2.3 Step 2: Services configuration . 94 Annex B (informative) Unreferenced requirements in MIL-STD-1553B 99 Bibliography . 100 Figures Figure 3-1: Bit numbering convention . 13 Figure 4-1: Architecture of typical communication devices with MIL-STD-15
22、53B I/F . 16 EN 16603-50-13:2014BS EN 16603-50-13:2014Figure 4-2: CCSDS/SOIS communication stack architecture 16 Figure 4-3: Service model 17 Figure 4-4: 1553 Bus topology 18 Figure 4-5: Examples of 1553 bus redundancy scheme . 19 Figure 4-6: Process of Bus Profiling . 20 Figure 4-7: Example of sync
23、hronous access (pre-allocated, populated) . 22 Figure 4-8: Examples of asynchronous access (pre-allocated, unpopulated) . 22 Figure 4-9: Typical implementation of 1553 messages sequence on BC 23 Figure 4-10: Typical communication frame decomposition on BC 24 Figure 4-11: Services dependencies 26 Fig
24、ure 4-12: Time Service steps . 28 Figure 4-13: Time Service 29 Figure 4-14: Time distribution and synchronization . 30 Figure 4-15: Communication Synchronization scenarios 31 Figure 4-16: Communication Synchronization 32 Figure 4-17: Communication Frame duration adjustment methods . 33 Figure 4-18:
25、Set Data service . 36 Figure 4-19: Get Data service. 39 Figure 4-20: Data Distribution Transfer, BC to RT. . 45 Figure 4-21: Data Distribution timing with Best Effort QoS 45 Figure 4-22: Data Distribution timing with Verified Length QoS 46 Figure 4-23: Data Acquisition Transfer, RT to BC . 47 Figure
26、 4-24: Data Acquisition timing with Best Effort QoS 48 Figure 4-25: Data Acquisition timing with Verified Length QoS . 48 Figure 5-1: Bus connectors for separated BCs or RTs . 50 Figure 5-2: Bus connectors for integrated BCs or RTs . 51 Figure 5-3: Bus connectors for separated BCs or RTs connected t
27、o dual buses 51 Tables Table 5-1: Pin allocation for 15-pin Bus Controller 1553 Bus Connector . 53 Table 5-2: Pin allocation for 15-pin Remote Terminal 1553 Bus Connector 53 Table 5-3: Pin allocation for 9-pin Bus Controller or Remote Terminal 1553 Bus Connector 54 Table 5-4: Pin allocation for Remo
28、te Terminal nominal bus 55 Table 6-1: Subaddress allocation . 60 Table 7-1: TimeData primitive definition . 61 Table 7-2: TimeSynchronize primitive definition 62 Table 7-3: CommunicationSynchronize primitive definition . 63 EN 16603-50-13:2014BS EN 16603-50-13:2014Table 7-4: SendData primitive defin
29、ition with predefined transfers (Type I) 64 Table 7-5: SendData primitive definition with pre-allocated bandwidth (Type II) . 65 Table 7-6: ReadStatus primitive definition 66 Table 7-7: ReceiveData primitive definition with predefined transfers (Type I) 67 Table 7-8: ReceiveData primitive definition
30、 with pre-allocated bandwidth (Type II) . 68 Table 7-9: ReadData primitive definition . 69 Table 7-10: SendData primitive definition for the Data Block Transfer Service . 70 Table 8-1: Time Message data words, CCSDS CUC format . 72 Table 8-2: Communication Frame Synchronization Message Data Word . 7
31、5 Table 8-3: Layout of the Distribution Transfer Descriptor (BC to RT, SA 27R) 78 Table 8-4: Layout of the Distribution Transfer Confirmation (BC to RT, SA 27T) 82 Table 8-5: Layout of the Acquisition Transfer Confirmation, ATC (BC to RT, SA 28R) . 85 Table 8-6: Layout of the Acquisition Transfer Re
32、quest, ATR (RT to BC, SA 28T) . 86 Table 8-7: SA 1T: RT_Health 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 soluti
33、ons and identifying requirements for RT and BC type MIL-STD-1553 communication devices. EN 16603-50-13:2014BS EN 16603-50-13:2014 Define normative requirements rather than recommendations. NOTE As a lesson learned from many project experiences, this aims at making sure that deviations on a given mis
34、sion are driven by mission requirements and are tracked at specification time rather than being discovered at integration time which results in delays and generally induce large costs impacts. Enabling the development of spacecraft onboard communication services compatible with the CCSDS/SOIS requir
35、ements. As far as possible, the defined communication requirements are extracted from the experience on existing spacecraft specifications. 4.3 Reference architecture 4.3.1 Communication devices architecture There are three types of communication devices in MIL-STD-1553B data bus systems: Bus Contro
36、llers (BC), Remote Terminals (RT) and Bus Monitors (BM). BM devices are not subject for any additional requirements within this standard but their usage for integration and test is recommended. The Figure 4-1 depicts the reference architecture of typical BC and RT type communication devices with 155
37、3 I/F. Only OSI protocol stack related elements of the communication devices are shown in this view. This can entail units with an existing 1553 I/F design (legacy units), as well as enhanced 1553 communication devices. These units can involve usage of different services, which can be supported by s
38、pecific driver software. The communication devices exchange their data through a time-multiplexed wire-harness medium, which topology is further detailed in clause 4.3.4. 4.3.2 Mapping on CCSDS/SOIS sub-network layer This Standard provides the definition of a set of services that can be mapped on th
39、e Sub-network layer of the CCSDS/Spacecraft Onboard Interface Services communication stack as described in Figure 4-2. The services, as defined in this standard, are directly compatible to the Packet Service, Memory Access Service, Time Distribution Service, Device Discovery Service and Test Service
40、 of the SOIS reference model. For some of these services, additional SOIS-specific control information can be needed. The definition of this control information, as well as the capabilities and requirements of the Data Link Convergence Functions, is outside the scope of this standard. EN 16603-50-13
41、:2014BS EN 16603-50-13:2014Figure 4-1: Architecture of typical communication devices with MIL-STD-1553B I/F Figure 4-2: CCSDS/SOIS communication stack architecture EN 16603-50-13:2014BS EN 16603-50-13:20144.3.3 Service model This clause describes a general model which is used for the definition of s
42、ervices in this standard. Figure 4-3 depicts this general service model. Management entity Capability Service User Underlying Layer Service Interface Expected Service Service Management Interface Figure 4-3: Service model The services defined in this standard describe communication capabilities of s
43、ervice-provider which is provided to service-user at the boundary between service-provider and service-user This capability in its turn relies on certain services expected to be provided by the underlying layer. The interactions between the service-user and service provider constitute “abstract inte
44、rface” at the service boundary. This abstract interface is defined in terms of service primitives which the service-user and the service-provider are allowed to exchange, together with sequencing rules which apply to these exchanges. The UML sequence diagram convention is used throughout this standa
45、rd to illustrate how sequences of interactions are related in time. The OSI convention and terminology is used to represent service-primitives on those UML sequence diagrams. Services are configured and managed by a service management entity. Service primitives are described through their name (e.g.
46、 SendData, ReadStatus), type (e.g. Submit, Deliver or Requestor.Submit, Acceptor.Deliver) and list of parameters (e.g. GroupID, DataLength) Service primitive is represented by an arrow. Arrows located at the left of the vertical line indicate requestor primitives Arrows located at the right of the v
47、ertical line indicate acceptor primitives Arrows directed towards the vertical line indicate submit primitives Arrows directed out of the vertical line indicate deliver primitives Primitives are an abstract, atomic representation of an interaction between service-user and service-provider which are
48、defined in clause 7 of this standard. The primitives and their parameters indicate what information flows between the service-user and the service-provider at their interface. This is not to be confused with an API which is associated with a specific implementation. EN 16603-50-13:2014BS EN 16603-50
49、-13:2014There are three types of parameters associated with each definition of a service primitive Input, Output, and Managed. The CCSDS Draft Recommendation for the encapsulation service CCSDS-133.1-R-1, Red Book, April 2002, provides the following definition for managed parameters: “In order to conserve bandwidth on the space link, some parameters associated with a Service are handled by management, rather than by inline communications protocol. The managed parameters are those which tend to be static for long periods of time, and whose change generally signifie
