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

Challenges in telecom payloads 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 layer protocols Recommendations to ECSS-E-ST-50-15C Future implementations CAN bus as payload control bus in telecom applications / 14.06.2017

Increased focus on telecom market 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

Key aspects: Price, Lead time, Performance 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

Need for alternative and standardized solutions 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

High number of units possible Harness length > 100 m possible 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

Low design to market time 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

Data link layer and physical signaling ISO 11898-2 Available standards 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 CANbus extension protocol 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. CAN bus as payload control bus in telecom applications / 14.06.2017

Data rate of ~ 25 kbps sufficient for operation System design / required data rates Exemplary required data rate in mid range telecom application: 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

Implementation of 125 kbps or 250 kbps 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

ISO standard tolerant to several failure cases 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

Higher layer protocols according to CANOpen / ECSS-E-ST-50-15C 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

Master Node sends request via PDO_ID1 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

Master Node sends request via PDO_ID1 Slave Node receives PDO_ID1 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

Master Node sends request via PDO_ID1 Slave Node receives PDO_ID1 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

Master Node sends request via PDO_ID1 Slave Node receives PDO_ID1 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

Inherent arbitration mechanism of CAN unused 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

Master Node sends all request immediately 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

Master Node sends all request immediately 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

Final implementation depending on application 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 implementation depending on application CAN bus as payload control bus in telecom applications / 14.06.2017

Limit possible implementations 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

Currently not needed on telecom payloads 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

µController based implementation 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

CAN bus as flexible and robust data bus 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

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