SIST EN 16603-50-15:2017

SLOVENSKI STANDARD
01-september-2017
Vesoljska tehnika - Razširitveni protokol CANbus
Space engineering - CANbus extention protocol
Raumfahrttechnik - CANbus-Erweiterungsprotokoll
Ingénierie spatiale - Protocole d'extension du CANbus
Ta slovenski standard je istoveten z: EN 16603-50-15:2017
ICS:
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 16603-50-15
NORME EUROPÉENNE
EUROPÄISCHE NORM
June 2017
ICS 49.140
English version
Space engineering - CANbus extention protocol
Ingénierie spatiale - Protocole d'extension du CANbus Raumfahrttechnik - CANbus-Erweiterungsprotokoll
This European Standard was approved by CEN on 11 May 2017.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Avenue Marnix 17, B-1000 Brussels
© 2017 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16603-50-15:2017 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European foreword . 7
Introduction . 8
1 Scope . 9
2 Normative references . 10
3 Terms, definitions and abbreviated terms . 12
3.1 Terms from other standards . 12
3.2 Terms specific to the present standard . 12
3.3 Abbreviated terms. 16
3.4 Bit numbering convention . 17
3.5 Nomenclature . 17
4 Overview of the standard and principles . 19
4.1 Document organization . 19
4.2 Relationship of CAN Bus Network to existing Architectures . 19
4.3 CANbus network . 20
4.4 Physical layer . 21
4.5 Communication model . 21
4.6 CANopen higher layer protocol . 21
4.7 Time distribution . 23
4.7.1 Overview . 23
4.7.2 SYNC message and protocol . 24
4.7.3 Bit timing . 24
4.8 Redundancy management and monitoring . 24
4.8.1 Overview . 24
4.8.2 Node Monitoring via Node-Guarding or Heartbeat Messages . 25
4.8.3 Bus monitoring and reconfiguration management . 26
4.9 Connectors and pin assignments . 27
4.10 Minimal protocol set . 27
5 Physical layer . 28
5.1 Topology . 28
5.1.1 Physical topology . 28
5.1.2 Maximum bus length and drop length. 30
5.1.3 Number of network devices . 30
5.2 Medium . 31
5.2.1 Cable requirements . 31
5.2.2 Connectors . 32
5.3 Transceiver characteristics . 32
5.3.1 General . 32
5.3.2 ISO 11898-2:2003 transceiver electrical characteristics . 33
5.3.3 Resistance to electrical CAN Network faults. 33
5.3.4 Transceiver isolation . 38
5.3.5 Physical layer implementation based on RS-485 transceivers . 38
5.3.6 Detailed implementation for RS-485 transceiver . 39
5.4 Bit timing . 39
5.4.1 Bit rate 1 Mbps . 39
5.4.2 Other bit rates . 39
5.4.3 Bit timing . 39
5.5 Electromagnetic compatibility (EMC) . 40
5.6 Data link layer . 40
5.6.1 ISO 11898 compliance . 40
5.6.2 Fault confinement . 40
6 CANopen higher layer protocol . 42
6.1 Service data objects . 42
6.2 Process data objects . 42
6.3 Synchronisation object . 42
6.4 Emergency object . 43
6.5 Network management objects. 43
6.5.1 Module control services . 43
6.5.2 Error control services . 43
6.5.3 Bootup service . 43
6.5.4 Node state diagram . 43
6.6 Electronic data sheets . 44
6.7 Device and application profiles . 44
6.8 Object dictionary . 45
6.9 Synchronous communications . 45
6.10 COB-ID and NODE-ID assignment . 45
7 Time distribution . 47
7.1 Time objects . 47
7.1.1 Time code formats . 47
7.1.2 Spacecraft elapsed time objects . 48
7.1.3 Spacecraft universal time coordinated objects . 48
7.2 Time distribution and synchronization protocols . 49
7.2.1 General . 49
7.2.2 Time distribution protocol . 49
7.2.3 High-resolution time distribution protocol . 50
8 Redundancy management . 52
8.1 General . 52
8.2 Node internal bus redundancy architectures . 52
8.2.1 General . 52
8.2.2 Parallel bus access architecture . 52
8.2.3 Selective bus access architecture . 52
8.3 Bus monitoring and reconfiguration management . 53
8.3.1 Bus redundancy management parameters . 53
8.3.2 Start-up procedure . 56
8.3.3 Bus monitoring protocol . 57
9 Minimal implementation of the CANopen protocol for highly
asymmetrical control applications . 60
9.1 COB-ID assignment . 60
9.2 Object dictionary . 60
9.3 Minimal set CANopen Objects . 60
9.4 Minimal Set Protocol . 61
9.4.1 Definitions . 61
9.4.2 Use of data bytes in application layer . 62
9.4.3 Minimal Set Protocol data transmission . 63
9.4.4 PDO transmit triggered by telemetry request. 64
9.4.5 PDO mapping . 64
9.4.6 Network management objects . 65
9.4.7 Special function objects . 65
9.4.8 Communication error object . 66
9.4.9 NMT error control objects . 66
9.4.10 Miscellaneous authorized objects . 66
9.5 Free COB–ID . 70
10 Connectors and pin assignments . 73
10.1 Overview . 73
10.2 Naming convention . 73
10.3 Circular connectors . 73
10.3.1 MIL-C D38999 configuration B: Dual CAN Network. 73
10.3.2 MIL-C D38999 configuration D: Single CAN Network . 74
10.4 Sub-miniature D connectors (9-pin D-sub) . 75
10.5 Sub-miniature D connectors (9-pin D-sub) – RS-485 . 76
11 CANopen standard applicability matrix . 77
11.1 Introduction . 77
Annex A (informative) Electrical connectivity . 88
A.1 Transceivers . 88
A.1.2 Detailed implementation for RS-485 transceiver . 88
A.2 Example Implementation of a RS-485 physical layer . 90
A.3 CAN Network Bus termination . 93
A.4 Bus management and redundancy . 93
A.4.1 Selective bus access architecture . 93
A.4.2 Parallel bus access architecture . 94
Bibliography . 95
Figures
Figure 3-1: Bit numbering convention . 17
Figure 4-1: Relationship between ISO layering, ISO 11898, CiA 301 and ECSS CAN
standard definitions . 20
Figure 4-2: Example of minimal implementation topology . 21
Figure 4-3: Format of hearthbeat message . 26
Figure 5-1: Linear multi-drop topology . 28
Figure 5-2: Daisy chain topology. . 29
Figure 7-1: Format for objects containing the SCET . 48
Figure 7-2: Format for objects containing the Spacecraft UTC . 49
Figure 8-1: Node start up procedure . 56
Figure 8-2: Bus monitoring logic . 58
Figure 8-3: Slave bus selection process, toggling mechanism . 59
Figure 9-1: Unconfirmed Command exchange overview (example with PDO1) . 61
Figure 9-2: Telemetry request exchange overview (example with PDO2) . 62
Figure 10-1: Illustration of a 9-pin D-Sub connector . 75
Figure A-1 : Principle of Isolated CAN Operation . 88
Figure A-2 : RS-485 CAN physical interface for OBC/Bus Master . 90
Figure A-3 : RS-485 CAN physical interface for nodes using single connector for
redundant buses . 91
Figure A-4 : RS-485 CAN physical interface nodes using dual connector for redundant
buses . 91
Figure A-5 : Split (left) and standard (right) Termination schemes. . 93
Figure A-6 : Selective bus access architecture . 94
Figure A-7 : Parallel bus access architecture . 94
Tables
Table 5-1: CAN levels in ISO 11898-2:2003 . 33
Table 5-2 – CAN failure modes and recommended FDIR actions. . 36
Table 8-1: BUS redundancy management parameters for slaves . 54
Table 8-2: BUS redundancy management parameters for master . 55
Table 9-1: Peer-to-Peer objects of the minimal set . 61
Table 9-2: Broadcast objects of the minimal set . 61
Table 9-3: PDO Communication Object description: . 63
Table 9-4: PDO Communication Entry Description: . 63
Table 9-5 PDO Communication Object description: . 64
Table 9-6: PDO Communication Entry Description: . 64
Table 9-7 : SYNC Message Object description: . 65
Table 9-8: SYNC Message Entry Description: . 65
Table 9-9 SYNC used with NMT master Object description: . 66
Table 9-10 SYNC used with NMT master Entry Description: . 66
Table 9-11: CANopen Object dictionary Data Types . 67
Table 9-12: Authorized and Forbidden Object Dictionary Entries of the Communication
profile . 68
Table 9-13 : COB ID -Predefined connection set . 71
Table 10-1 : Signal terminology . 73
Table 10-2: Pin function for MIL-C D38999 configuration B . 74
Table 10-3: Pin function for MIL-C D38999 configuration D . 74
Table 10-4: Pin function for sub D-type with CAN Network . 75
Table 10-5: Pin function for sub D-type with RS-485 CAN Network . 76
Table 11-1: DiA 301 (former CIA DS301) applicability matrix . 78
Table A-1 : Logic Table, RS-485 Driver implementation . 92
Table A-2 : Logic Table, RS-485 Receiver implementation . 92
Table A-3 : Component item values. 92

European foreword
This document (EN 16603-50-15:2017) has been prepared by Technical
Committee CEN-CENELEC/TC 5 “Space”, the secretariat of which is held by
DIN.
This standard (EN 16603-50-15:2017) originates from ECSS-E-ST-50-15C.
This European Standard shall be given the status of a national standard, either
by publication of an identical text or by endorsement, at the latest by December
2017, and conflicting national standards shall be withdrawn at the latest by
December 2017.
Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. CEN [and/or CENELEC] shall not be held
responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request given to
CEN by the European Commission and the European Free Trade Association.
This document has been developed to cover specifically space systems and has
therefore precedence over any EN covering the same scope but with a wider
domain of applicability (e.g.: aerospace).
According to the CEN-CENELEC Internal Regulations, the national standards
organizations of the following countries are bound to implement this European
Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic,
Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
This European Standard specifies requirements for the use of the CAN
(Controller Area Network) data bus in spacecraft onboard applications. These
requirements extend the CAN Network specification to cover the aspects
required to satisfy the particular needs of spacecraft data handling systems.
This standard is one of a series of ECSS standards relating to data link interfaces
and communication protocols e.g. MIL-STD-1553 and ECSS-E-ST-50-5x Space
Wire.
In order to provide a uniform set of communication services across these
standards the CCSDS Spacecraft Onboard Interface Services (SOIS) Subnetwork
Recommendations have been applied as driving requirements for protocol
specification.
The CAN Network has been successfully used for three decades in automotive
and critical control industry. In particular, its use in applications that have
demanding safety and reliability requirements, or operate in hostile
environments have similarities to spacecraft onboard applications.
The CAN Network is being adopted for a variety of space applications and care
has therefore been taken during the drafting of this standard to include existing
experience and feedback from European Space industry.
In addition to the CAN Network data link specifications, this standard also
specifies the optional use of the CANopen standard as an application layer
protocol operating over CANbus.
The set of CANopen specifications comprises the application layer and
communication profile as well as application, device, and interface profiles.
CANopen provides very flexible configuration capabilities.
Scope
This European Standard is applicable to spacecraft projects that opt to use the
CAN Network for spacecraft on-board communications and control. It also
defines the optional use of the CANopen standard as an application layer
protocol operating in conjunction with the CAN Network data link layer.
This standard does not modify the basic CAN Network specification and
complies with ISO 11898-1/-2:2003. This standard does define protocol
extensions needed to meet spacecraft specific requirements.
This standard covers the vast majority of the on-board data bus requirements
for a broad range of different mission types. However, there can be some cases
where a mission has particularly constraining requirements that are not fully in
line with those specified in this standard. In those cases this standard is still
applicable as the basis for the use of CAN Network, especially for physical
layer and redundancy management.
This standard may be tailored for the specific characteristic and constrains of a
space project in conformance with ECSS-S-ST-00.
Normative references
The following normative documents contain provisions which, through
reference in this text, constitute provisions of this ECSS Standard. For dated
references, subsequent amendments to, or revision of any of these publications
do not apply. However, parties to agreements based on this ECSS Standard are
encouraged to investigate the possibility of applying the more recent editions of
the normative documents indicated below. For undated references, the latest
edition of the publication referred to applies.

EN reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms
EN 16603-20 ECSS-E-ST-20 Space engineering - Electrical and electronic
EN 16603-20-07 ECSS-E-ST-20-07 Space engineering - Electromagnetic compatibility
EN 16602-70-08 ECSS-Q-ST-70-08 Space product assurance - Manual soldering of high-
reliability electrical connections
EN 16602-70-26 ECSS-Q-ST-70-26 Space product assurance - Crimping of high-reliability
electrical connections
ESCC 3401/029 Issue 1, Connectors Electrical Rectangular Microminiature,
October 2002 based on type MDM
ESCC 3401/01 Issue 2, Connectors, Electrical, Rectangular, Microminiature,
March 2010 Solder Bucket Contacts, with EMI Backshell, based on
Type MDM
ANSI/TIA/EIA-485-A- Electrical Characteristics of Balanced Voltage Digital
1998 (reaffirmed 28 Interface Circuits.
March 2003)
NOTE: This standard referenced in this document as
RS-485.
DIN 41652-1 (1990-06) Rack and panel connectors, trapezoidal, round
contacts ∅ 1 mm; common mounting features and
dimensions; survey of types
ISO 11898-1:2003 Road vehicles – Controller Area Network (CAN) - Part
1: Data link layer and physical signalling
ISO 11898-2:2003 Road vehicles – Controller Area Network (CAN) - Part
2: High-speed medium access unit
CiA 102 v. 2.0 CAN physical layer for industrial applications
(available from www.can-cia.org)
CANopen Application Layer and Communication
CiA 301 Version 4.2.0
Profile, CAN in Automation
(available from www.can-cia.org)
CANopen electronic data sheet specification
CiA 306 Version 1.3.0
(available from www.can-cia.org)
CAN in Automation - Computation of CAN Bit
iCC 2012
Timing Parameters Simplified - Meenanath Taralkar,
OTIS ISRC PVT LTD, Pune, India
(available from www.can-cia.org)
Connectors, Electrical, Circular, Miniature, High
MIL-DTL-38999
Density, Quick Disconnect (Bayonet, Threaded, and
(formerly MIL-C
Breech Coupling), Environment Resistant, Removable
D38999 Series 3)
Crimp and Solder Contacts, General Specification for.
U.S. Department of Defense. 30 May 2008.
The current reference of this standard is
RS-485
ANSI/TIA/EIA-485-A-1998 (reaffirmed 28 March 2003)

Terms, definitions and abbreviated terms
3.1 Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01
shall apply.
3.2 Terms specific to the present standard
3.2.1 asynchronous data transmission
data transmission from an originating source that is not synchronized to any
clock pulse or external common event
NOTE 1 The data frame is delimited with (e.g.) start and
stop signals. Both communication terminals do
not need to have local clocks synchronized.
NOTE 2 Data transmission systems that foresee
asynchronous data transfer can allow senders
to attempt to transfer data at any time. If two or
more senders send data at the same time then
there is a conflict and an arbitration scheme is
used to determine the order in which the
senders can put their data on the bus. Priority is
then used to differentiate between information
to be delivered urgently, and data whose
delivery is less time critical. When there is a
conflict between two or more senders the one
with highest priority is allowed to send its data
first.
3.2.2 CAN-ID
11- or 29-bit identifier used in the arbitration and control field of the CAN
frame
[CANopen – CiA Standard 301 V4.2.0]
3.2.3 cold redundant bus
redundancy scheme whereby data is only transmitted on one of the available
busses
[CANopen – CiA Standard 301 V4.2.0]
3.2.4 communication bus system latency
time from the source sending a packet to the time when it is received by the
intended destination
3.2.5 cross-strapping
two identical units that are interconnected with the remaining system in such a
way that either unit can provide the required functionality
NOTE In an avionics system, where each unit appears
with its identical backup, cross-strapped units
provide all possible interconnections between
them. For bus-connected systems all bus
connected subsystems, components, and
instruments are cross-strapped to their
respective data buses. The overall system
reliability of a space avionics system is
significantly enhanced by cross strapping, as if
one unit fails a redundant unit can take over
without implying a complete switch-over to a
redundant chain.
3.2.6 cyclic data transmission
see "isochronous data transmission"3.2.11.
3.2.7 dominant and recessive states of CANbus signals
CAN transmission based on differential signal transmission
NOTE In this case, the difference between the CAN
(controller area network) high (CAN_H) and
CAN low (CAN_L) signals are used. Bus
operation is dependent on accurate
interpretation of Dominant and Recessive data
bits within a CAN frame. Signal levels are
reported in Clause 5.3.2 of this standard.
3.2.8 dominant bit level
logical level that when applied to a bus forces the entire bus to the same logical
level
[CANopen – CiA Standard 301 V4.2.0]
3.2.9 hard coded (or Hardcoded) data
embedding what can, perhaps only in retrospect, be regarded as input or
configuration data directly into the source code/read only memory of a
FPGA/device, or fixed formatting of the data, instead of obtaining that data
from external sources
[CANopen – CiA Standard 301 V4.2.0]
3.2.10 hot redundant bus
redundancy scheme whereby data is transmitted simultaneously on all of the
available busses
[CANopen – CiA Standard 301 V4.2.0]
3.2.11 isochronous data transmission
form of synchronous data transmission where similar (logically or in size) data
frames are sent linked to a periodic clock pulse or external common event
NOTE 1 In an Isochronous transmission the sender and
the receiver are synchronized in such a way
that they send/receive during the same time
slots. This implies the existence of an implicit or
explicit time schedule table that needs to be
consistent over the entire network.
NOTE 2 The term is synonymous to cyclic data
transmission (3.2.6) or to Rate Monotonic
Scheduling.
3.2.12 local SCET
time counter implemented and maintained in a node, that is correlated with the
SCET
[CANopen – CiA Standard 301 V4.2.0]
3.2.13 multimaster-capable, event-oriented message
transmission
transmission mode where each node of a communication network can initiate
the transmission of a message as soon as the bus is free
NOTE 1 (see 3.2.7 NOTE). As every node can initiate a
message transfer (multi-master), a direct
message transfer between all nodes of the
network is possible.
NOTE 2 It is expected that each node of a Multi-master-
network is able to autonomously contend the
bus to initiate the transmission of a message. As
it can happen that more than one network node
begins transmission of a message at the same
time, an arbitration process is necessary, which
ensures only one node actually continues with
the transmission of its message.
NOTE 3 Compared to a cyclic message transfer, a
considerably lower bus load or a reduction in
the required data transmission rate results.
3.2.14 NMT master
node in a CANopen network, responsible for managing all other nodes on the
bus using the NMT services
[CANopen – CiA Standard 301 V4.2.0]
3.2.15 NMT slave
node in a CANopen network that is managed by the NMT master using the
NMT services
[CANopen – CiA Standard 301 V4.2.0]
3.2.16 propagation time
critical length of a bus line occurring at the point where the return propagation
delay (tprop(total)) of a signal through a line, equals the transition time(tt) of a
signal (the greater between rise and fall times)
NOTE 1 Network Critical Length = tt = tprop(total)
NOTE 2 typical ISO or RS-485 driver has a 50 ns
transition time, and when considering a typical
twisted-pair transmission line prop delay of 5
ns/m, the return delay for one meter becomes
10ns/m. The critical length becomes 5 m (50 ns /
10ns/m = 5 m), and the max un-terminated stub
length for the network is 1/3rd of the critical
length, or 5/3 m (1,67 m).
[CANopen – CiA Standard 301 V4.2.0]
3.2.17 recessive bit level
logical level that when applied to a bus only has effect on the level of the bus if
there is no driver that simultaneously applies a dominant bit level
[CANopen – CiA Standard 301 V4.2.0]
3.2.18 redundancy master
dedicated node responsible for managing the bus redundancy
NOTE In particular, this includes controlling the
switching from a nominal to a redundant bus in
a cold redundant bus system.
[CANopen – CiA Standard 301 V4.2.0]
3.2.19 redundant bus
bus system that consists of two or more identical physical communication
channels to increase the bus reliability or availability
[CANopen – CiA Standard 301 V4.2.0]
3.2.20 redundant node
node that provides identical functionality as another node connected on the
same physical bus
[CANopen – CiA Standard 301 V4.2.0]
3.2.21 spacecraft elapsed time (SCET)
central time reference that is maintained on-board the spacecraft
NOTE The SCET can be correlated to the ground time,
and may be distributed to other on-board
nodes.
[CANopen – CiA Standard 301 V4.2.0]
3.2.22 synchronous data transmission
data transmission in which a clock defines transmission times for data
NOTE 1 Data transmission from originating source is
triggered (or happens in conjunction with) a
clock pulse or external common event.
NOTE 2 Since start and stop bits for each character are
not needed, more of the transmission
bandwidth is available for message bits.
NOTE 3 See also isochronous data transmission
(3.2.11).
3.3 Abbreviated terms
For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01
and the following apply:
Abbreviation Meaning
controller area network
CAN
Consultative Committee for Space Data Systems
CCSDS
communication object identifier
COB-ID
European Cooperation for Space Standardisation
ECSS
electronic data sheet
EDS
electromagnetic compatibility
EMC
Emergency Object
EMCY
first in first out
FIFO
large data unit transfer
LDUT
least significant bit
LSB
most significant bit
MSB
network management
NMT
open systems interconnection
OSI
printed circuit board
PCB
protocol data unit
PDU
process data object
PDO
receive PDO
RPDO
remote transmission request
RTR
Abbreviation Meaning
service access point
SAP
spacecraft elapsed time
SCET
service data object
SDO
synchronisation object
SYNC
transmit PDO
TPDO
3.4 Bit numbering convention
• The most significant bit of an n-bit field is:
- numbered bit n-1,
- the first bit transmitted,
- the leftmost bit on a format diagram.
• The least significant bit of an n-bit field is:
- numbered bit 0 (zero),
- the last bit transmitted,
- the rightmost bit on a format diagram.
This is illustrated in Figure 3-1.
This convention is the opposite of most ECSS and CCSDS documents. Its choice
is dictated by the bit numbering convention used in the CAN Network
specification.
Bit n-1 (MSB) Bit 0 (LSB)
n-bit Data Field
First Bit Transmitted
Figure 3-1: Bit numbering convention
3.5 Nomenclature
The following nomenclature applies throughout this document:
a. The word “shall” is used in this Standard to express requirements. All
the requirements are expressed with the word “shall”.
b. The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring, recommendations
in this document are either converted into
requirements or tailored out.
c. The words “may” and “need not” are used in this Standard to express
positive and negative permissions, respectively. All the positive
permissions are expressed with the word “may”. All the negative
permissions are expressed with the words “need not”.
d. The word “can” is used in this Standard to express capabilities or
possibilities, and therefore, if not accompanied by one of the previous
words, it implies descriptive text.
NOTE In ECSS “may” and “can” have completely different
meanings: “may” is normative (permission), and
“can” is descriptive.
e. The present and past tenses are used in this Standard to express
statements of fact, and therefore they imply descriptive text.
Overview of the standard and principles
4.1 Document organization
The remainder of this document is organised as follows:
• Clause 5 specifies the CAN Network physical layer;
• Clause 6 specifies CANopen for use over a CAN Network in spacecraft
applications;
• Clause 7 specifies the Time distribution protocol to be used over CAN
Network;
• Clause 8 specifies the CAN Network redundancy management;
• Clause 9 species a minimal protocol set for highly asymmetric
implementations;
• Clause 10 specifies connectors and pin assignments.
In addition to these normative clauses, annexes are provided describing:
• Annex A: CANopen Standard Applicability Matrix
The remainder of clause 4 provides informative information on each of the
normative clauses.
4.2 Relationship of CAN Bus Network to existing
Architectures
Figure 4-1 illustrates the relationship of the CAN Network to the ISO OSI model
(as defined in [2]) and existing ECSS recommendations. The CAN Network
specification covers the Physical and datalink layers of the ISO OSI model. The
related ECSS-E-ST-50-15 standard covers only the physical layer.
CANOpen Device and Application
Profiles
I/O, specialized machines
7 – Layer OSI
CAN-Based CANOpen Transport
End-to-end connections, reliability
Application
and flow control
Path determination and logical
addressing
Presentation
Object Dictionary
Ctrl Protocols (NMT, SYNC, TIME,
EMCY)
Session
Messaging Protocols (SDO and
ECSS-E-ST-50-15C
PDO)
Transport
Logical Link Control (LLC)
Network
- Acceptance Filtering
- Overload Notification
- Recovery Management
Data Link
Medium Access Control (MAC)
CAN CONTROLLER
- data encapsulation/decapsulation
Physical SPECIFICATIONS
- Frame coding (stuffing/de-stuffing)
- Error detection/signaling
- Serialization/deserialization
Physical Signalling
- Bit Encoding/Decoding
- Bit timing/synchronization
ISO Transceiver
Physical Medium Attachment
or
- Driver and Reicever characteristics
RS-485 Space
solution
Medium Dependent Interface
- Connectors/wires
ECSS-E-ST-50-15
- Protections
Recommendations
- Redundancy Management
Figure 4-1: Relationship between ISO layering, ISO 11898, CiA 301 and ECSS CAN
standard definitions
4.3 CANbus network
The Controller Area Network (CAN) is a serial communications protocol which
efficiently supports distributed real-time control with a very high level of
security.
For a detailed and authoritative introduction to the CAN features and
characteristics refer to:
Texas Instrument’s - Application Report SLOA101A – August 2002 – Revised
July 2008 - Introduction to the Controller Area Network (CAN) by Steve
Corrigan [4]
Extensive literature on use of CAN for high reliability command and control
exists. Some of the most interesting articles are reported in the bibliography of
this standard (see [9],[17],[18],[19],[20],[33],[34],[35],[36]).

Defined by Defined by
ISO 11898-2:2003 CiA 301
4.4 Physical layer
Clause 5 lists the requirements related to the physical layer.
4.5 Communication model
The communication model is based on a CAN Network master connected to up
to 126 slave nodes (the number of possible nodes depends on the physical layer
capabilities).
The network is organized in a strict master/slave relationship (see Figure 4-2).
Matching Plug
Prime
CAN Bus Prime
CAN Bus Master Prime
Matching Plug
Redundant
CAN Bus Redundant
CAN Bus Master Redundant
CAN Slave Node i CAN Slave Node j

Figure 4-2: Example of minimal imple
...