1. CAN bus as payload control bus in telecom applications
OHB System AG
Carsten Siemers, Julio Martin Hidalgo
, CAN in Space Workshop
Sitael S.p.A., Mola di Bari, Italy
CAN bus as payload control bus in telecom applications

2. 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 /

3. 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 /

4. 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 /

5. 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 /

6. 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 /

7. 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 /

8. Data link layer and physical signaling ISO 11898-2
Available standards
ISO
Data link layer and physical signaling
ISO
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 /

9. 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 /

10. 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 /

11. 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 /

12. 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 /

13. 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. 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 /

15. 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 /

16. 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 /

17. 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 /

18. 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 /

19. 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 /

20. 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 /

21. 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 /

22. Currently not needed on telecom payloads
Possible future implementations
CAN FD (ISO :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 )
Fault tolerance achieved by redundancy specified in ECSS-E-ST-50-15C
Time triggered CAN (ISO )
Deterministic CAN e.g. for AOCS applications
Low Power Modes (ISO )
No particular need identified
Complete bus set to “standby”
Contradicting to periodic TM acquisition
Wake up functionality (ISO )
Cold redundant units
Further reduction of discrete commands possible?
CAN bus as payload control bus in telecom applications /

23. µ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 /

24. 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 /

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