1 / 25

CAN bus as payload control bus in telecom applications

OHB System AG Carsten Siemers, Julio Martin Hidalgo 14.06.2017, CAN in Space Workshop Sitael S.p.A., Mola di Bari, Italy. CAN bus as payload control bus in telecom applications. Content. Challenges in telecom payloads Motivation for CAN as payload control bus Available standards

oakes
Télécharger la présentation

CAN bus as payload control bus in telecom applications

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. OHB System AG Carsten Siemers, Julio Martin Hidalgo 14.06.2017, CAN in Space Workshop Sitael S.p.A., Mola di Bari, Italy CAN busaspayloadcontrolbus in telecomapplications

  2. Content • Challenges in telecom payloads • Motivation for CAN as payload control bus • Available standards • System design • Required data rates • Bit time configuration • EMC • FDIR • Higher layerprotocols • Recommendations to ECSS-E-ST-50-15C • Future implementations CAN bus as payload control bus in telecom applications / 14.06.2017

  3. OHB as one of the major satellite manufacturers in Europe • Increased focus on telecom market • Capability to offer full range of satellites with a common configurable platform • SGEO product line • HAG1, EDRS, Electra, H2SAT CAN bus as payload control bus in telecom applications / 14.06.2017

  4. Challenges of telecom payloads • High number of units • Travelling wave tubes, amplifiers, converters, switches etc. • Equipment not developed at OHB • > 60 units • Low requirements from the platform side in terms of data handling • Commanding only during payload configuration • Mostly housekeeping telemetry • No stringent determinism required • Acquisition rates of 1 Hz or less sufficient • Low data rates of less than 25 kbps required • Wide range of payloads • Scalability & flexibility preferred • Key aspects: Price, Lead time, Performance CAN bus as payload control bus in telecom applications / 14.06.2017

  5. Challenges of telecom payloads cont’d • Payload control via discrete commands • High number of lines & control interfaces • Complex harness • Huge manufacturing effort • Huge testing effort • Payload control via “CAN-like” implementations • Non (ISO-) standard implementations • Improvement compared to discrete commands • Performance (e.g. number of nodes) might not be sufficient • Compatibility not guaranteed Need for alternative and standardized solutions CAN bus as payload control bus in telecom applications / 14.06.2017

  6. Motivation for CAN • High number of units possible • Harness length > 100 m possible • Lower power & improved EMC compared to MIL-1553 • Robustness • Inherent failure mechanisms on physical and data link layer • Configurability and scalability • Easy to extend for different payload sizes • Configurable data rates (125 kbps – 1Mbps) • Long industrial heritage • Similar motivation for CAN bus e.g. in automotive industries • High number of IP cores available • Redundancy not implemented by available COTS IP cores • ESA funded developments including redundancy CAN bus as payload control bus in telecom applications / 14.06.2017

  7. Motivation for CAN cont’d • Payload AIT • Simplified unit validation • COTS equipment can be used • Emulation of complete payload panels before integration • Verification of protocol, bus loads etc. • Simplified test of complete payload panels • Payload validation at payload integrator Low design to market time CAN bus as payload control bus in telecom applications / 14.06.2017

  8. Available standards Tailoring to: • Node requirements • Applicable to units / nodes only • E.g. delays, pinout, unit testing etc. • Subsystem requirements • Applicable to complete bus system • E.g. bus topology, harness length, system tests etc. • ISO 11898-1 • Data link layer and physical signaling • ISO 11898-2 • High-speed medium access unit • ISO 16845 • Conformance test suite • CiA (CAN in Automotive) standards • Definition of CANOpen protocol • ECSS-E-ST-50-15C • CANbusextensionprotocol CAN bus as payload control bus in telecom applications / 14.06.2017

  9. System design / required data rates • Exemplary required data rate in mid range telecomapplication: • 30 nodes per CAN bus, 16 byte TM data, 1 Hz acquisition rate • ~ 4 kbps net data rate • Overhead on data link layer to be considered • ID, CRC, stuff bits etc. • Overhead on higher layer protocols • Used bytes per PDO • Request / response or Sync based protocol types (or others) • Overhead caused by constraints of HW/SW Interface • Send lists vs. interrupts • Higher data rates preferred during AIT • Data rate to be chosen limited by physical constraints Data rate of ~ 25 kbps sufficient for operation CAN bus as payload control bus in telecom applications / 14.06.2017

  10. System design / bit time configuration • Harness design • Harness length / propagation delay delimits possible data rate • Up to 30 m harness length • Configuration of bit timing • Total node delay (Tx, Rx, Processing Time) • Determines earliest sampling point • Oscillator tolerances • Determines Synchronization Jump Width (SJW) • Recommendations • Maximum propagation delay • Sampling point between 85 % and 90 % of the bit time • Minimum SJW • Typically, very good oscillators compared to automotive Implementation of 125 kbps or 250 kbps CAN bus as payload control bus in telecom applications / 14.06.2017

  11. System design / FDIR + EMC • FDIR • ISO standard tolerant to several failure cases • Physical layer (broken lines, shorts to ground, etc.) • Data link layer (CRC, error counters) • Cold redundancy sufficient for considered equipment • Two redundancy mechanisms for slave nodes known in space business • Traffic (edge) detection • Heartbeat (as suggested by ECSS-E-ST-50-15C) • Simple failure handling in master node (OBC) • Detection through error counters • Isolation by switching all communication to redundant bus • Node ID validation • Validation of false Node IDs may lead to severe failures • Implementation of parity bits or hamming distance • EMC • Shielded vs. unshielded twisted pair • First evaluations / tests show preference for twisted shielded pair • Bus termination • Simple vs. split mode termination • Reference voltage for split mode termination CAN bus as payload control bus in telecom applications / 14.06.2017

  12. System design / higher layer protocols • Higher layer protocols according to CANOpen / ECSS-E-ST-50-15C • Typically, only 11 bit Identifiers used in CANOpen • Physical & Data Link Layer of CAN allow wide range of higher layer protocols • Protocol preferably as simple as possible • Master / slave protocol solely based on PDOs • Master / slave not aligned to CANOpen • Heartbeat & Sync foreseen for future application • SDOs not yet foreseen • Overall protocol implementation depending on timings, FDIR, HW/SW interfaces etc. CAN bus as payload control bus in telecom applications / 14.06.2017

  13. System design / higher layer protocols cont’d • Master Node sends request via PDO_ID1 CAN bus as payload control bus in telecom applications / 14.06.2017

  14. System design / higher layer protocols cont’d • Master Node sends request via PDO_ID1 • Slave Node receives PDO_ID1 CAN bus as payload control bus in telecom applications / 14.06.2017

  15. System design / higher layer protocols cont’d • Master Node sends request via PDO_ID1 • Slave Node receives PDO_ID1 • Slave Node sends response after processing time CAN bus as payload control bus in telecom applications / 14.06.2017

  16. System design / higher layer protocols cont’d • Master Node sends request via PDO_ID1 • Slave Node receives PDO_ID1 • Slave Node sends response after processing time • Master Node receives response CAN bus as payload control bus in telecom applications / 14.06.2017

  17. System design / higher layer protocols cont’d • Inherent arbitration mechanism of CAN unused • Timings easy to calculate (if processing time is known) • High bus load • High processor load • Polling or interrupts CAN bus as payload control bus in telecom applications / 14.06.2017

  18. System design / higher layer protocols cont’d • Master Node sends all request immediately CAN bus as payload control bus in telecom applications / 14.06.2017

  19. System design / higher layer protocols cont’d • Master Node sends all request immediately • Slave Nodes start sending as bus is free • Priority based arbitration • Responses may be delayed CAN bus as payload control bus in telecom applications / 14.06.2017

  20. System design / higher layer protocols cont’d • Inherent arbitration of CAN used • Timings hard to calculate • Low bus load • Low processor load • Flexible protocol (e.g. w/o predefined send-lists) may be preferred Final implementationdepending on application CAN bus as payload control bus in telecom applications / 14.06.2017

  21. Recommendation to ECSS-E-ST-50-15C / OHB point of view • Limit possible implementations • Only ISO CAN as “state-of-the-art” implementation • Alternative redundancy mechanisms • Traffic / edge detection not covered • Connector types • Only Sub-D 9 covered by ISO and ECSS standards • MDM connectors widely used in space business • Check existing requirements for verification methods / testability • Remove requirements already covered by ISO standards • Clear indications for unit or system level applicability CAN bus as payload control bus in telecom applications / 14.06.2017

  22. Possible future implementations • CAN FD (ISO 11898-1:2015) • Data rate up to 10 Mbps • Closes gap between low speed serial data busses and high speed networks • Currently not needed on telecom payloads • Possible future implementations of platform equipment (e.g. payload interface units / RTUs) • Low-speed, fault-tolerant CAN (ISO 11898-3) • Fault tolerance achieved by redundancy specified in ECSS-E-ST-50-15C • Time triggered CAN (ISO 11898-4) • Deterministic CAN e.g. for AOCS applications • Low Power Modes (ISO 11898-5) • No particular need identified • Complete bus set to “standby” • Contradicting to periodic TM acquisition • Wake up functionality (ISO 11898-6) • Cold redundant units • Further reduction of discrete commands possible? CAN bus as payload control bus in telecom applications / 14.06.2017

  23. Possible future implementations cont’d • µController based implementation • Further distribution of data processing • Exploitation of multi master capability of CAN bus • Reduction of bus load • Reduction of processor load of main computer • Replacement of MIL-1553 by CAN not foreseen • Advantages of CAN w.r.t. power and EMC compared to MIL-1553 • TTCAN or similar could be used to improve determinism of CAN • Expected costs and long MIL-1553 heritage prevail advantages of CAN CAN bus as payload control bus in telecom applications / 14.06.2017

  24. Conclusion • CAN bus as flexible and robust data bus • Three main requirements for competiveness achieved: • Cost: cheap controllers, reduced test effort, usage of COTS equipment • Lead time: good flexibility and scalability, simplified AIT flows • Performance: sufficient data rate for telecom satellites, simple FDIR CAN bus as payload control bus in telecom applications / 14.06.2017

  25. Thanks for your attention! Any questions? CAN bus as payload control bus in telecom applications / 14.06.2017

More Related