CAN in Space Workgroup

1
CAN in Space Workgroup

• Status Report
• L. Stagnaro P. Roos

2
Presentation overview

• History
• Workgroup Objectives Planning
• Status
• Overview of key CANOpen features
• CANOpen add-ons for space adaptation
• Resources Contact Points

3
History

• Since the start of the SMART-1 spacecraft
  development and the development of the ESA free
  CAN core (Hurricane), CAN technology had raised
  increasing interest in the European aeronautic
  industry
• Standard CAN needs to be completed with an high
  level protocol and an electrical interface before
  it can be used onto a spacecraft

4
History Contd

• There was the need to provide guidelines for the
  use of CAN in ESA missions, in order to
  standardize its use and prevent the proliferation
  of dialects and custom solutions.
• It was decided to start a workgroup formed by
  member of ESA, Industry and Academia to provide
  the needed recommendations.

5
Workgroup Objectives

• Selection of high level protocol industrial
  standard that most suit the spacecraft on-board
  applications.
• Definition of the electrical/physical interface
  that fulfill the requirements of a spacecraft
  avionics.
• Definitions of a selected number of features to
  complete the standard in aspects that are
  specific of a spacecraft avionics such as
  redundancy.

6
Workgroup Objectives Contd

• The working group will complete the task in one
  year time frame.
• The product of the working group will be a set of
  recommendations that will become part of the ECSS
  standard.
• (1st Draft of recommendation available)

7
Workgroup Planning (1)
2nd Meeting
3rd Meeting
4th Meeting
CAN Workshop (Dec 2002)
1st Meeting (5-6 March 2003)

• Task
• Preliminary definition of services
• Demonstrator specification
• Physical Layer requirements definition
• Output
• 1st Draft available
• Demonstrator Specification

8
Workgroup Planning (2)
2nd Meeting
3rd Meeting
4th Meeting
CAN Workshop (Dec 2002)
1st Meeting (5-6 March 2003)

• Task
• Consolidate the selected services
• Implement services in demonstrator
• Output
• 2nd Draft of recommendation

9
Workgroup Planning (3)
2nd Meeting
3rd Meeting
4th Meeting
CAN Workshop (Dec 2002)
1st Meeting (5-6 March 2003)

• Task
• Implement services in demonstrator (contd)
• Validation tests including physical layer
• Define Device Profiles for typical S/C equipments
• Output
• Draft Device Profiles
• 3rd Draft of recommendation

10
Workgroup Planning (4)
2nd Meeting
3rd Meeting
4th Meeting
CAN Workshop (Dec 2002)
1st Meeting (5-6 March 2003)

• Task
• Implement and validate Device Profiles
• Finalisation of the tests and simulations
• Finalisation of draft recommendation
• Output
• Final draft of recommendation

11
CANOpen

• After an initial investigation among the industry
  standard protocol the CANOpen has been selected.
• From the CAN Justification file
• CANOpen seems definitively the most
  advanced/flexible among the analysed protocols,
  supporting many needed functions. In addition the
  capability of configuring a node is attractive
  for inter-operability of units

12
CAN Industrial presence
13
CANOpen at a glance

• Two main communication objects
• SDO (Service Data Object) for transfer of complex
  and large data
• PDO (Process Data Object) for simple or short
  real-time communication
• Node Object dictionary
• Allow the configuration of a unit for the
  specific network
• Contains information about the unit capabilities
• Device profiles
• Sync message for cyclic coordination
• High accuracy time distribution (1 us)
• Defined Node and Error Handling
• Defines Node state machines
• Predefined error codes
• Specific Unit Codes

14
CANOpen Object Dictionary

• An object dictionary is a node shared memory area
  that can be read/written by any other node on the
  network
• To understand node type, capabilities and
  messages structure (READ)
• To configuring the node for the network in which
  the node is inserted, as for example the data
  period. (WRITE)
• A mandatory set of entry in the dictionary is
  established by the standard device profile to
  which the node belongs.

15
CANOpen Dictionary Example

• Device Profile AOC Sensor/Actuators Interface

16
CANOpen Sync

• Transmission type
• Event driven (spontaneous)
• Polled
• Synchronous cyclic or acyclic

17
CANOpen Network Management

• CANOpen defines a set of services to startup the
  network before commencing the nominal work of the
  system.
• During the network startup each node is
  configured (if needed) and take to the
  operational state.

Reset of Settings
Configuration of the device
Device Operation
Stop of all communication
18
Add-on to CANOpen

• Large Data Unit Transfers
• Optional protocol compatible with CANOpen
• Co-exists with CANOpen
• Reduced overhead compared to CANOpen
• Physical Layer
• Shall be suitable for vast majority of missions
• Insure device-on-bus electrical compatibility and
  device-across-the-industry electrical
  compatibility
• Redundancy
• Management of bus redundancy
• Informative examples to be put in recommendation
  annex
• Relationship between CANOpen Node State Diagram
  and redundancy
• Hot/cold bus and node redundancy

19
Physical Layer

• Mandatory
• ISO-11898 1993 (Automotive) and ISO 11898
  Amendment 11995
• Up to 1Mbps CAN Hi-speed
• Recommendation
• Number of Nodes 32 Minimum
• Bus cabling ISO 11898 compliant
• Connector types
• Optional
• Single-point failure tolerant/Dual Redundant I/F
• High Speed Optical coupler
• Power thru CAN bus connector

20
Resources

• Yahoo group page
• http//groups.yahoo.com/group/CAN_Space/
• Discussion forum
• Web page
• http//users.skynet.be/cotectic/CAN-WG/
• Draft recommendation
• Minutes of Meetings etc. related to the CAN WG
  activities.

21
Contact Persons

• Luca Stagnaro (Chairman)
• luca.stagnaro_at_esa.int
• Peter Roos (Secretary)
• peter.roos_at_esa.int
• Rodger Magness (Physical Layer)
• rodger.magness_at_esa.int
• Patrick Plancke (Head of Computer Data Systems
  section)
• patrick.plancke_at_esa.int