1 / 30

CCSDS-SOIS Fall Meeting 2008, Berlin, Germany Olivier Notebaert – Astrium Satellites – ASG74

SOIS Standard Services for Communications over 1553 Implementation with ECSS-E-ST-50-13C defined services and protocols. CCSDS-SOIS Fall Meeting 2008, Berlin, Germany Olivier Notebaert – Astrium Satellites – ASG74 Convenor of the ECSS Working Group for standardization on 1553 MilBus. Summary.

zilya
Download Presentation

CCSDS-SOIS Fall Meeting 2008, Berlin, Germany Olivier Notebaert – Astrium Satellites – ASG74

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOIS Standard Services for Communications over 1553 Implementation with ECSS-E-ST-50-13C defined services and protocols CCSDS-SOIS Fall Meeting 2008, Berlin, Germany Olivier Notebaert – Astrium Satellites – ASG74 Convenor of the ECSS Working Group for standardization on 1553 MilBus

  2. Summary • Context • The ECSS Working Group and the drafting process • ECSS-E-50-13 Draft-C Standard Overview • Conclusion

  3. ContextMil-Bus in Space Applications • a proven Standard • Well defined physical and data link layers requirements • But does not provide any “sub-network service layer” (according to CCSDS SOIS model) • But does not provide any user level communication protocol • well adapted to spacecrafts Data-Handling • Very good reliability characteristics • Allows deterministic and efficient real-time command/control • Lot of sensors, commercial products and test equipments • Large return on experience in space applications • used successfully for many space applications • Launcher avionics on Ariane 5 and Vega • Spacecrafts control for many platforms and payloads • In-Orbit infrastructure and manned flight for ISS and ATV • still with good perspective • Evolutions are foreseen to allow higher bandwidth and lower power consumptions

  4. Summary • Context • The ECSS Working Group and the drafting process • ECSS-E-50-13 Draft-C Standard Overview • Conclusion

  5. ECSS 1553 Working GroupObjectives and Strategy • Physical layer and Data link layers are well defined by the Mil standard but there are several usage variants • Identify best practices for harmonization • Capitalize the acquired experience on 1553 based systems • Adapt requirements from existing projects and take into account existing communication devices • Several services and communication protocols exist with similar properties • Define a standard set of services and protocols suitable to most 1553 based systems taking into account applications needs • Take into account the sub-network services reference defined by CCSDS/SOIS

  6. ECSS 1553 Working GroupMembers and interfaces • The WG activity started in December 2005 with the initial objective for a Draft standard delivery at the end of 2007 • It is ruled by ECSS standards productions procedures and by an agreed Term of Reference • 8 members involved in on-board 1553 systems from European space agencies and industry ECSSTechnical Authority ECSS secretariat ECSS-E-50 ESA/Industry Working Group CCSDS/SOIS (ESA: Chris Taylor) ECSS-E-50 Engineering panel

  7. study Draft D September 2008 Projects needsand experience ECSS 1553 Working GroupDrafting Process Mil 1553 CCSDS/SOIS Working Group Analysis and Drafting Publication (end 2008) Standard engineering - elaboration and maturation Draft A April 2007 Draft B November 2007 Draft CMay 2008 Edition Editorial review (ECSS Secretariat) Public review Technical review(Industry + ESA) Modeling Verification (ESA) SOIS mapping& prototyping Standard verification activities

  8. Summary • Context • The ECSS Working Group and the drafting process • ECSS-E-50-13 Draft-D Standard Overview • Conclusion

  9. Draft-D OverviewTable of Content • Scope • Normative References • Terms, definition and Abbreviated terms • Overview • Physical layer requirements • Data Link layer requirements • Services definition • Protocol Specification • Test and Verification Annexes A Tailoring guidelines B Unreferenced requirements inMil-Std-1553 C Bibliography

  10. Draft-D OverviewScope • A reference architecture for 1553 systems, a service model and a bus profiling concept are defined • gathering experience of 1553 based projects • aiming at determinism of data bus exchanges thus allowing bandwidth allocation on the bus to ensure: • Guaranteed availability for critical data • Flexibility for asynchronous and sporadic traffic • in Section 4 (Informative) • Harmonisation rules, services and protocols are defined • mapping on SOIS architecture and service model • re-using existing requirements and protocol elements from space projects • in Section 5 to 9 (Normative)

  11. BC Application RT X Application RT Y Application Send User Data Receive User Data Receive User Data Send User Data Receive User Data Send User Data Services W, X,Y,Z Services W, X,Y, Z Services Y, Z Data Link Layer Data Link Layer Data Link Layer ECSS ServicesFunctions:Segmentation,… Elements of Protocol:Block data length, Address tables,… ECSS ServicesFunctions:Segmentation,… Elements of Protocol:Block data length, Address tables,… 1553Functions:Error detection, Delimiting and Synchronisation, … Elements of Protocol:Message length, Start/end Marker, Status Word,… 1553Functions:Error detection, Delimiting and Synchronisation, … Elements of Protocol:Message length, Start/end Marker, Status Word,… 1553Functions:Error detection, Delimiting and Synchronisation, … Elements of Protocol:Message length, Start/end Marker, Status Word,… Physical LayerFunctions: Retry, Error detection… Elements of Protocol: Synch pattern, parity,… Physical LayerFunctions: Retry, Error detection… Elements of Protocol: Synch pattern, parity,... Physical LayerFunctions: Retry, Error detection… Elements of Protocol: Synch pattern, parity,… Remote Terminal (with ECSS Services) Bus Controller Remote Terminal (Legacy) Draft-D OverviewReference Architecture

  12. Draft-D OverviewService Model and CCSDS/SOIS

  13. Draft-D OverviewPhysical and Data Link Layer Harmonisation • The ECSS standard adds specific details for the Physical and Data Link Layers of MIL-STD-1553B • On the Physical layer: • More precise definition of the bus cable impedance (using metric units) • Selection of the transformer-coupled stub connection • Application of bus cable and stub discharge resistances • Definition of the connector interface between the terminals and the bus • On the Data Link Layer • Rules on usage of mode codes • RT to RT messages transfer not allowed • 1553 Standard automatic retry not allowed • Fixes the response timeout (14 µs to 22 µs without bus repeaters) • Provides subaddress usage harmonisation rules and recommendations

  14. Draft-D OverviewPhysical and Data Link Layer Harmonisation • Retry function included in the 1553 standard • It is not often used by space projects for several reasons such as: • In systems used cyclic scheduling (90%), an immediate retry modifies the cyclic scheduling of the bus unless the retry transfer is systematically included within the frame which has a high bandwidth cost • The error rate on 1553 is very low – experience shows that retry’s are almost always application errors (and the retried message also fails) • It is often a system choice to handle errors and retries within the FDIR function (at application level) or within higher level services protocols • In most applications, the highest proportion of the traffic is periodic acquisition data and the system application is tolerant to one acquisition failure (even 2 or more). Retrying immediately is not necessary. • As a result, the ECSS standard does not use the built-in retry of the 1553 standard retry

  15. Draft-D OverviewStandard Services and protocols • Time Distribution and Synchronisation • distribution of time information • Communication Synchronisation • deterministic time multiplexing of data bus messages • Set Data and Get Data • Classical 1553 transfer oriented with additional built-in functions such as segmentation dedicated to direct RT memory access • Data Block Transfer • Packet Transfer oriented service supported by a handshake protocol providing different levels of QoS • Terminal management • Rules and standard data structures in support to the harmonisation of terminal configuration, test and bus management applications

  16. Standard Services and protocolsTime Distribution and Time Synchronisation (1/2) • The On Board Time Master is driving the 1553 Bus controller • Maintains a coherent time data for all users of the service • Remote terminal applications maintain local OBT synchronized through reception of broadcasted messages from OBT Master • The time format is normalized to CCSDS CUC • Time information is distributed at a fixed subaddress (29) • Accuracy is mission dependant (shall be better than 50 µs)

  17. Standard Services and protocolsTime Distribution and Time Synchronisation (2/2)

  18. Standard Services and protocolsCommunication Synchronisation • The standard defines Communication frames which embed all 1553 message sequences within time bounded and synchronized intervals • This supports messages time multiplexing in a deterministic way • It allows to control user services latencies • A bus profile can be implemented for a given mission through: • Communication Frames programming in the Bus Controller at initialization time • Management of Communication Frames and real-time data at run-time • Real-time issues are guaranteed through resource reservation within the bus profile (bandwidth pre-allocation)

  19. Standard Services and protocolsCommunication synchronisation and bus profiling

  20. Standard Services and protocolsCommunication service and protocols • Two main use cases  two services with adapted data transfer protocols: • Data transfer for real-time critical applications (Get/Set) • Asymmetrical service provided on Bus controller only and dedicated to command control of sensors by a central computer • Typically sensor acquisition/distribution of unformatted data • Segmentation included up to a configurable and limited maximum limit(few Kbits) • Easily mapped to SOIS Memory access service • Data transfer for on-board communications (Data Block Transfer) • Symmetrical service provided between users on the Bus Controller and users on Remote Terminals • Asymmetrical protocol due to 1553 Master/slave characteristics • Data bloc transmissions, including segmentation, sequence control, flow control, confirmation, up to a maximum of 4 Kbytes • Easily mapped to SOIS Packet service

  21. Standard Services and protocolsSet Data and Get Data • Classical 1553 data transfer with built-in functions • Provided on the BC side only: • Set Data provides data transfer function from BC to one RT • Get Data provides data transfer function from one RT to BC • Segmentation • A single access to the service allows transmission of more than 32 words (maximum data size is application dependant) • Quality of Service and error detection • The protocol requires that accesses are time-bounded(maximum is one communication frame) • The destination user application ensures timely retrieval of data before it may be overwritten by new data • Error report provided to the service user based on the 1553 status words of the transfers in support to user FDIR application

  22. Standard Services and protocolsExample: Invoked 1553 messages for a Set Data

  23. Standard Services and protocolsData Block Transfer • Capability to transfer data blocks on request of the sender, with completion by a confirmation • Adapted for RT’s that have the capability to handle, segmentre-assemble and store large data structures • Data transfer protocol control • Handshake between sender and receiver • Error controls • Protocol Reset • Quality of Service • Best Effort • No check for correctness of the transferred data • Verified Length • Check that the correct number of bytes has been received • Check for data bus transmission error

  24. Data Block TransferFlat and Deep sub-addressing modes • Flat sub-addressing • Different subaddresses are used to transfer different sections of the transmitted data block. • In this mode the maximum block length that can be transmitted is 1024 bytes • The subaddresses to be used are fixed and defined by the standard (11 to 26) • Deep sub-addressing • A single subaddress is used to transfer different sections of the transmitted data block • Several subaddresses may be used resulting in several channels • In this mode the maximum block length that can be transmitted is 4096 bytes • The subaddress usage is determined by the RT design

  25. Data Block TransferData Transfer control • Protocol data structures to be exchanged across the data bus between BC and RT before and after the transfer of user-data Layout of the Distribution Transfer Descriptor (BC to RT, SA 27R) Layout of the Distribution Transfer Confirmation (BC to RT, SA 27T)

  26. Data Block TransferPerformance / QoS • Data Distribution timing withBestEffort QoS • Possible delay of one or more complete Communication Frames depending on the selected bus profile and the RT application timing. • Maximum performance is one user data block every second Communication Frames • Data Distribution timing with Verified Length QoS • Maximum performance is one user data block every fourth Communication Frames

  27. Standard Services and protocolsTerminal Management • Provides data link layer harmonisation requirements for • RT Health and Monitoring • Capability to receive information concerning health of Remote Terminals across the bus • Alarm Notification • Allows a RT to signal events to the FDIR 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; • Terminal Configuration • Allows the user on BC to be informed on and (re)configure the Remote Terminals • To be extended in support to the CCSDS/SOIS PnP service • The Data Wrap Around Service • Provides support to requirement defined in section 30.7 of MIL-STD-1553B. • It can be used to test BC-to-RT bus connection in support of test services and FDIR applications

  28. Summary • Context • The ECSS Working Group and the drafting process • ECSS-E-50-13 Draft-C Standard Overview • Conclusion

  29. Packet transfer Mapped on Data Block Transfer Memory Access mapped on Get Data and SetData Synchronisation mapped on the Time Distribution and Time Synchronisation services Test Relies on the Data Wrap-Around function as defined in the Terminal management Device Discovery Supported by Get Data and SetData using the Terminal management reserved sub addresses in order to exchange devices configuration data. SOIS subnetwork 1553 services prototyping subnetwork services mapping to ECSS Standard • SOIS Subnetwork Services are all implemented and mapped on the ECSS-E-ST-50-13C defined services and protocols

  30. Conclusion • Using the ECSS-E-50-13 standard draft requirements, a SOIS subnetwork level communication services interface and protocols for 1553 Milbus systems has been defined and implemented • This Standard has completed verification activities and public review • provides feedback on the implementation and performance issues to CCSDS/SOIS and ECSS-E-50 WG • Publication awaited end 2008 Thank you for your attention !

More Related