This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing

IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING 1

CAN implementation and performance for

Raman Laser Spectrometer (RLS) Instrument
on Exomars 2020 Mission
L. Seoane, C. Díaz, J. Zafra, S. Ibarmia, C. Quintana, C. Pérez, A. Moral, A. Araujo

Abstract— The use of CAN bus in space applications has increased during the last fifteen years. The need of standardizing not
only the physical and link layers but also the higher layers protocol to meet spacecraft specific constraints or requirements, such
as bus redundancy management, node monitoring and synchronization, has aroused. Therefore, a Working Group on CAN bus
was stablished by ESA in collaboration with European Industry and Space Agencies, whose effort gave as result the publication
of ECSS-E-ST-50-15C in 2015. This standard defines CAN protocol extensions for space use and specifies the optional use of
the CANopen standard as higher layer to be used over CAN bus. The ExoMars Mission was chosen as spreadhead for the
application of this standard. The present paper provides an experience report on this novel standardized use of CAN/CANopen
in Space, in particular in the Raman Laser Spectrometer (RLS) that will be boarded into the Rover of ExoMars 2020. Even
though RLS makes use of considerably long science telemetries (up to around 2Mbytes) CAN has been designated as its only
data interface. We report on software, hardware and data transmission performances, as well as brief description on
redundancy and synchronisation of this CAN implementation.

Index Terms— CAN, CANopen, Command and control, Raman Laser Spectrometer (RLS), Exomars, Space technology
systems

——————————  ——————————

1 INTRODUCTION

T HE number of space applications using Controller

Area Network (CAN) bus [1] [2] has grown during the
last years with divergent nonstandard implementations.
This has happened because the original CAN Specification
from Bosh [1] only specifies the OSI (Open System Inter-
connection) Data Link layer [3] and space applications also
need to implement higher OSI level layers to manage re-
dundancy, data block transfer, synchronization, etc. to op-
erate CAN as a spacecraft data bus.
The data bus is one of most critical parts of a control and
data handling system, since it serves as the interface be-
tween spacecraft controller and the individual peripherals
and payloads. Reliability, robustness, low power con-
sumption, low mass requirements, multi-master and
broadcast capabilities, automatic retransmission of mes-
sages or simple wiring (only two wires) are some of the
well-known features provided by CAN that makes this bus
especially suitable for space-based applications. Addition-
ally, it has been broadly used and validated in automation,
and there are available abundant test and simulation tools.
Both circumstances, the lack of a complete standard and
the good characteristics of CAN for space use, have caused
CAN bus had been used in numerous past applications
with bespoke higher communication protocols.Most of
times the applications were developed from scratch, what
makes difficult or impossible to re-use them across differ-
ent projects.
Thus, a standardization effort led by European Space
Agency in cooperation with European Industry and Na-
tional Space Agencies was performed, and as result, the
ECSS-E-ST-50-15C [4] standard was published in 2015.
This standard extends the original CAN network specifi-
cation to cover the aspects required to satisfy the particular
needs of spacecraft data handling systems, including the
optional use of CANopen [5] as higher layer protocol.
CANopen is an open standard with highly flexible con-
figuration capabilities developed for motion-oriented ap-
plications. Currently it is used in several domains, such as
medical equipment, off-road vehicles, maritime or railway
applications. The core of this protocol is the “Object Dic-
tionary”, a sort of database where the communication
characteristics and the data involved in this communica-
tion are stored. It is also the interface between the device
application and the CAN bus.
Beyond the well-founded available testing tools, CAN-
open has been selected to be included in the CAN bus
standardization for space applications. It provides a set of
services that are in line with the needs required by this
kind of applications, such as device discovery service,
packet service, memory access service, synchronization
service and test service [6].
One of the first missions implementing the ECSS-E-ST-
50-15C standard is ExoMars, and this is the first mission in
using the optional CANopen higher layer over CAN bus
as specified in the standard. This CAN/CANopen protocol
was selected to be used in the Entry Descending and Land-
ing Demonstrator Module (EDM), which was launched in
the first part of the ExoMars Mission (2016), likewise in the
Descending Module and the Rover Module, which belong
to the second part of the mission to be launch in 2020.
This paper presents the experience of using the Exo-

xxxx-xxxx/0x/$xx.00 © 200x IEEE Published by the IEEE Computer Society

2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing
2 IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING
Mars CAN/CANopen protocol on RLS [7], one of the Pas-
teur Payload instruments onboard the Rover Module of
Exomars 2020 [8]. The Pasteur Payload instruments are
dedicated to exobiology and geochemistry research. In or-
der to help to accomplish this goal, RLS will collect the
scattered light emitted by a Raman laser on a Martian sam-
ple and analyze the spectral information received by the
spectrometer to determine the molecular structure and
composition of a compound, and the final identification
and characterization of the Martian molecules, minerals,
and rocks.
RLS makes use of the ExoMars CAN/CANopen proto-
col as its only data inface to accomplish its scientific pur-
pose, including the transmission of large telemetries up to
around 2Mbytes.
Considering that, the use of CANopen in European
space applications is increasing and ExoMars is the first
mission using it, this RLS experience report is expected to
be useful for future CAN/CANopen implementations.
2 THE CANOPEN BASICS
CANopen is a flexible standardized higher layer proto-
col application for distributed automation systems based
on CAN.
CANopen is built around the concept of an Object Dic-
tionary (OD), the interface between the application soft-
ware and the CANopen protocol stack. The OD consists on
a lookup table where configuration data and every com-
munication and application parameters are described.
Each entry may be read and written to by other CANopen
nodes.
Data transfer is done through two different methods:
 The service data objects (SDO):
Each network node implements a server that
handles read/write requests to its object dictionary.
The CANopen master nodes act as clients to that
servers and always start the transfer. This method
is based on a master-driven polling, which adds
protocol overhead.
When using SDOs, there are three possible com-
munication modes:
o “Expedite transfer” which consists of one
SDO request and one SDO response. This
is only suitable for accesses to Object Dic-
tionary entries that are up to 4-bytes long.
o “Segmented transfer” which consists of an
SDO initiation request and response and
then one pair of request and response for
each 7-byte segment.
o “Block transfer” which is an optimized
transfer mode for Object Dictionary entries
that contain large amounts of data. In this
transfer mode, up to 889 bytes (segmented
into 127 messages with each 7 bytes) are
combined into one data block.
 The Process data objects (PDO):
Process data represents data that can be chang-
ing in time and so, the overhead added by SDO may
be unacceptable. Within PDOs, each node sends its
2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
own data, without needing to be polled by the
CANopen master.
There are two types of PDOs: transfer PDOs
(TPDOs) and receive PDOs (RPDOs). A TPDO is
the data coming from the node (produced) and a
RPDO is the data coming to the node (consumed).
CANopen also allows Network Management services
to control the communication state of individual nodes,
Emergency Notification, Time stamping services, synchro-
nization services, and Error control.
3 SCOPE
The nature of any space-based Mission require technol-
ogies that provide high reliability, even more for those that
imply certain level of real time and/or autonomy, such as
ExoMars 2020, its Rover and instrumentation. The hostile
environment, in which everything must work, is normally
translated into constrained behavior, bandwidth and per-
formance.
In the framework of the Exomars mission, RLS opera-
tion comprises from basic configuration tasks, to long last-
ing scientific activities [9] [10]. The instrument will be ana-
lyzing Mars samples until, at least, 218 sols after the de-
scent to Mars. This implies a large set of various data to be
shared between the instrument, the Rover, and ground.
The telecommands to be executed by the instrument, the
Housekeeping and Scientific telemetry acquired by RLS
will be transferred though a CAN interface.
4 IMPLEMENTATION OF CAN/CANOPEN IN RLS
4.1 Architecture
The data interface architecture for the Rover Module
was designed including two CAN buses, one for the Plat-
form and other for the Payload. RLS is one of the eight
nodes of the Payload Bus (PL Bus).
All the nodes of this PL Bus implement the same high-
level protocol on top of the CAN data link layer; this pro-
tocol is CANopen. With the aim to make CANopen com-
ply with specific Mission requirements, a specific tailored
CANopen was defined for the PL Bus by TAS-I (Thales
Alenia Space). Among other things, the PL Bus was de-
fined as a redundant bus, with a main and a redundant
channel, working at 1Mbps.
Figure 1 - CAN Topology on Exomars
The redundancy architecture implemented is “selective
bus access”, consisting on a single CAN controller interfac-
ing the CANBus network via two transceivers, each one for
each bus channel, providing communication on only one
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing
AUTHOR ET AL.: CAN IMPLEMENTATION AND PERFORMANCE FOR RAMAN LASER SPECTROMETER (RLS) INSTRUMENT ON EXOMARS 2020 MISSION
channel at a time. Among the PL Bus nodes, two act as
master in the communication. These are the main and re-
dundant Rover Onboard Computers (OBC-A and OBC-B),
but both nodes never are active at the same time. The rest
of the nodes, including RLS, act as slaves.
For PL Bus nodes, CAN/CANopen protocol is allowed
to be carried out completely by hardware or by a mix of
hardware and software. In the first case, by means of the
Sitael “CANopen Controller IP Core” (CCIPC) [11] [12]; in
the second case, using an ASIC which contains the Hurri-
cane IP CAN Bus Controller Core to implement the Data
Link Layer and including the CANopen functionality in
the user processor software.
The development of the CCIPC controller has been sup-
ported by ESA in the framework of the ExoMars program
and the IP core is currently included in the ESA IP Cores
Library. This core is delivered with certain tools that allow
a flexible and configurable way to embed it into different
FPGA vendors.
The RLS CANBus is based on the CCIPC controller, which
implements in Hardware all the ExoMars CANopen func-
tions. It is designed to act as Slave node in a CANopen net-
work, Server node for SDO Download and Upload ser-
vices, Producer and Consumer node for PDO and Heart-
beat services and Consumer of SYNC message. This con-
troller is embedded in a reprogrammable Flash Microsemi
ProAsic FPGA. For the physical layer, RS-485 transceivers
are used.
The controller is managed by SW running on a SPARC
V8 microprocessor, an integrated circuit (IC) outside the
FPGA. The communication between microprocessor and
FPGA is done through registers in the FPGA that are
mapped in the I/O memory area of the microprocessor.
Thus, the FPGA behavior is controlled by writing/reading
by SW the content of specific addresses that each FPGA
register has assigned.
Figure 2 - CCIPC architecture on RLS
4.2 CCIPC: Can Controller IP Core
The IP Core GUI tool distributed with the CCIPC con-
troller allows different configurations of the controller for
several host interfaces. For RLS the Generic I/O (CCIPC
GENIO) has been chosen. This is a generic memory-like in-
2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
3
terface in which an arbiter module manages the communi-
cation between microcontroller and CCIPC. This interface
allows the software running on the microprocessor to ac-
cess to CCIPC from the I/O section of the microprocessor
memory controller.
CCIPC distinguishes three logical areas:
1. a configuration memory, implemented within the con-
troller, that collects the CCIPC configuration and sta-
tus register,
2. “ROM memory” area dedicated to store the default
values for CANopen PDOs Communication and Map-
ping parameters. This is used also for CANopen Ap-
plications Objects that have to be loaded after power-
on or when the CANopen Reset Node or Reset Com-
munication services are required
3. “RAM memory” area assigned to maintain PDO Map-
ping Parameters and Application object data.
In RLS, the “ROM memory” and “RAM memory” areas
are accommodated in FPGA on-chip RAM.
Figure 3 - CCIPC memory regions
CCIPC controller expects all processor read/writes to
be 32 bits wide, but RLS implements this data interface
with only 16 bits because no more pins were available in
the FPGA. Therefore, some glue logic has been added to
the FPGA implementing a 32/16bits databus adapter,
which convers two FPGA databus access into one CCIPC
data access. This also has some impact in the SW side and
timing performance, since each CCIPC access has to be
dealt as two FPGA accesses.
CCIPC offers three interrupt output lines called
TRX_IRQ, SYNCH_IRQ and ERR_IRQ, through which
some events are signaled. The TRX_IRQ indicates the re-
ception of Initiate SDO transfer message, successful elabo-
ration of an SDO transfer, successful elaboration of asyn-
chronous TPDO or RPDO and NMT state transition, the
SYNCH_IRQ is used to signal the successfully completion
of the Synch message reception and the ERR_IRQ line in-
forms that an EDAC error, CAN bus Error, SDO error,
PDO error or Bus switch error has been detected.
The CCIPC IRQ status register and the IRQ mask-clear
register are available to manage these interrupts.
The following tables depict the interface between the
OBSW and the CAN within the FPGA.
Control and status registers are used to manage the
CCIPC interrupts to signal the availability or need for data
transfers.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing

4 IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING

CCIPC also has an additional line to inform on recep- The rest of the telemetries are sent asynchronously.
tion of the Synch message, activating this line for a single Once the action triggered by the received telecommand
clock cycle. RLS design does not use this last additional finishes, the corresponding TM is sent reporting the result
line (although its value is available in a FPGA register) and of the execution and any other relevant information. How-
multiplexes the three CCIPC IRQ lines in only one line (im- ever, there are two exceptions:
plemented in the FPGA block called “Glue logic”). In this 1. Events TM (RLS_TM_EVENTS), used when an un-
way, only one IRQ regarding to the CAN interface is man- expected happening needs to be shared with the
aged by the microprocessor. Rover Platform or Ground for failure isolation and
For RLS, on the FPGA, the CCIPC controller, the data processing.
RAM/ROM memory and the Arbiter to handle the access 2. Six synchronous housekeeping TMs (4
to this memory (from CCIPC or SW) are implemented. As RLS_TM_TEMPERATURES and 2
well, some glue logic is added for the 32/16bits databus RLS_TM_POWER_OUTPUTS). They report on the
adapter and CCIPC IRQ lines multiplexing in just one, instrument health and thermal status.
which will be connected to the microprocessor where the Event telemetries can be sent at any time, since RLS
RLS SW is executed. sends them just at the moment the events happen, and syn-
The digital CAN protocol data used by the controller in- chronous housekeeping TMs are sent at 0,1Hz with current
terfaces the physical CAN bus through RS-485 transceivers. instrument voltages, currents and temperatures since the
One transceiver is used for the main bus and a different one payload is powered on.
for the redundant bus.

4.3 Telecommands (TCs) and Telemetries (TMs)

With the CANopen protocol, each TC/TM is managed
as a write/read operation into/from the payload object
dictionary. All needed parameters for TCs and TMs are
mapped into the RLS object dictionary.
As a brief overview, RLS TCs include information to:
 Change the operational mode to manage the
SW state machine,
 Control Instrument subunits and their status
(switch the laser on/off, move the stepper mo-
tor, activate/deactivate the thermal control)
 Run scientific operations (image acquisition, al-
gorithms execution)
 Configure parameters,
 Carry out predefined test,
 Abort an operation or accomplish a reset,
 Access to memory for patching/dumping.

Figure 5 - RLS Telemetry List

For each message to be sent or received by RLS, the most

appropriate CANopen service is chosen (PDO or SDO).

4.4 Process Data Objects (PDO)

Figure 4 - RLS Telecommand list
All the TCs are acknowledged by RLS after a validity
check against the current operational mode and the ex-
pected format and values. The acknowledgement is done
by RLS sending a RLS_TM_ACCEPTANCE telemetry.
PDOs are messages with a data field between one and
eight data bytes long. RLS implements PDOs mainly for
TC and housekeeping TM.
RLS, as Producer and Consumer node for PDO, man-
ages Transmit Process Data Objects (TPDOs) and Receive
Process Data Objects (RPDOs). From the point of view of a
slave node as RLS, a TPDO is a message sent to the net-
work, it means, a TM, and a RPDO is a message received
from the network, that is, a TC.
Each RLS PDO must be defined in the RLS object dic-
tionary and in the Rover OBC master dictionary. RLS
RPDOs are linked to OBC TPDOs and RLS TPDOs to OBC
RPDOs by means of the COB-ID parameter.

2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing

AUTHOR ET AL.: CAN IMPLEMENTATION AND PERFORMANCE FOR RAMAN LASER SPECTROMETER (RLS) INSTRUMENT ON EXOMARS 2020 MISSION
5

PDO definition encompasses communication parame- not multi-block transmissions for telecommands.
ters and mapping parameters. The communication param-
eters include the COB-ID and the transmission type of the
CAN message. The mapping parameters assign which ob-
jects from the object dictionary will be transmitted or re-
ceived within each PDO and their location inside the CAN
message.
RLS, as a PDO producer, composes the data field of a
TPDO in accordance with its TPDO mapping. It takes the
current data of the variables to be transmitted from its ob-
ject dictionary and copies these into the data field of the
TPDO before the CAN message (PDO) is sent.
The triggering mechanish chosen by RLS for PDOs
transmissions, is asynchronous for all TPDOs, except six
TPDOs in which a synchronous transmit trigger is used in
order to send housekeeping TM periodically each 10s.
As a PDO Consumer, RLS based on RPDO COB-ID and
mapping record, copies the received data bytes into its ob-
ject dictionary entries. RLS SW, by means of polling or in-
terrupt handler, realizes a TC has come and processes it.
Based on the Transmission Type parameter, all RPDOs
are configured to be processed immediately upon recep-
tion.
The CCIPC foresees up to 4 TPDOs and 4 RPDOs for
each node occupied by the CCIPC. In this way the user is
able to define a number of TPDOs and RPDOs included in
the range [1:4*NodeID count]. Since RLS occupies eight
nodes, the instrument can define up to 32 TPDOs and 32
RPDOs, but only 21 TPDOs and 18 RPDOs are finally used. Figure 6 - SDO Block Download Protocol for ExoMars

4.5 Service Data Objects (SDO)
SDOs are used for the SDO client node to access to the
SDO server’s object dictionary. Since the Rover OBC im-
plements the SDO client and RLS the SDO server, the
Rover OBC can read (“SDO Upload”) and write (“SDO
Download”) the RLS object dictionary entries.
Within RLS, the selected SDO service type is SDO Block
Transfer, where up to 889 bytes (segmented into 127 mes-
sages with each 7 bytes) are combined into one data block.
RLS defines an 888bytes long buffer for SDO Upload
service and other different buffer with the same size for
SDO Download service. During SDO Block transfers, one
of this buffer will be written or read.
RLS implements this service to transfer long messages
mainly for science data and patching purposes.
SDO data transfer is an acknowledged service that is in-
itiated by the SDO client. Every SDO CAN message has al-
ways an eight bytes long data field, bits of the data field
that are not required are set to 0.
SDO Block Download is divided into three communica-
tions stages, as depicted in Figure 6:
 Initiate Block Download, where the client requests
from the server to use block transfer mode for a
download.
 Download Blocks, in which the client sends data
segments and expects one response per block.
 End of Download Block, what finishes the transfer.
RLS during its operation utilizes only standalone block
messages during SDO Block Download; that is, there are
Message contents of SDO Block Download is as in the
Figure 7.
Figure 7 - SDO Block Download format
An SDO Block Upload is divided in the following four
stages, as shown in Figure 9:
 Buffer Support Object (BSO) transmission, where
RLS sends a specific TPDO (defined at mission level
and required to be mapped as TPDO0) to request
the client to start a SDO Block Upload.
 Initiate Block Upload, in which the client requests
the server to use block transfer mode for an upload.
 Upload Blocks, where the client receives data seg-
ments from the server and returns one response per
block.
 End of Download Block, what finishes the transfer.
SDO Block Upload messages comply with the format
depicted in Figure 8.
Figure 8 - SDO Block Upload format
Where Block Type indicates the SDO Block transfer type
(Download or Upload), Instrument ID the RLS node iden-

2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing
6 IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING
tifier, TM Type ID identifies the TM and Sequence Flag dis-
tinguish between a standalone block and the first, interme-
diate or last block in case of multi-block transmission.
Figure 9 - SDO Block Upload Protocol for ExoMars
To transfer more than one block, the full SDO Block
Download or Upload sequence should be repeated as
many times as necessary.
Both SDO Block Download and Upload processes fol-
lows to [5] except for BSO. The content of the BSO PDO
message can be seen in Figure 10.
Figure 10 - BSO message format
4.6 Network Management
RLS works as slave node in Network Management ser-
vice. Through this service, the master (the Rover OBC) is
in charge of managing the status of each slave in the CAN
network.
The Network Management services supported by RLS
and implemented by CCIPC are:
 Start Remote Node to enter in “Operational” state.
 Stop Remote Node to enter in “Stop” state.
 Enter Pre-Operational to enter in “Pre-Opera-
tional” state.
 Reset Node to enter in “Reset Application” state.
 Reset Communication to enter in “Reset Commu-
nications” state.
 Bootup Service, signaling to the master the end of
2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
the “Initialization” phase.
 Heartbeat Event service.
4.7 Redundancy Management
Bus redundancy is managed by CCIPC based on the
Heartbeat service. When CCIPC does not receive the
Heartbeat message from the master node, it generates an
event. When the number of generated events reach the
Ttoggle value, a bus switch is accomplished. The maxi-
mum number of bus switches is defined by the Ntoggle
value. Once this number of switches is achieved, RLS
keeps working on the same bus until the instrument is
powered off.
Ttoggle and Ntoggle values are defined in the Manufac-
turer-specific profile area of the Object Dictionary.
On the other hand, CCIPC sends periodically a Heart-
beat message, indicating RLS is alive to the master node. If
RLS´s Heartbeat message or some other slave´s Heartbeat
message is missing, the master could decide to change it-
self from one bus to the other. In this case, after Ttoggle
missed master Heartbeats, all slaves should move to the
same bus.
4.8 Synchronization
The Rover OBC acts as SYNC producer, broadcasting
the synchronization object periodically each 100ms, and
RLS as SYNC consumer. The Synchronization Object pro-
vides the basic network clock.
RLS does not need any special synchronization. Never-
theless, the SYNC is used by RLS SW to provide a more
deterministic behavior; asynchronous TM transmission al-
ways starts a fixed elapsed time of 5ms after receiving
SYNC. This avoids any overlapping with synchronous
TMs, which are sent from SYNC to SYNC+3ms. Each SDO
sent in the first half of this window, is processed in the
same window by the Rover OBC. So, any RLS SDO block
should be processed in the same SYNC window that it is
sent.
4.9 Time distribution
The Exomars Rover Module PL Bus does not support
the CANopen TIME object. Instead, for time distribution a
PDO called Rover Elapsed Time (RET) is sent from the
Rover OBC. This PDO is required to slave nodes like RLS
to be mapped as RPDO0. The time format used is the
CCSDS Unsegmented Time Code (CUC).
4.10 The Object Dictionary
CCIPC supports a limited set of Object Dictionary entries.
These entries belong to one of the following CANopen
standard objects: Communication profile area (where gen-
eral communication objects, RPDOs and TPDOs objects
and their mapping are defined), Manufacturer-specific
profile area (where specific CCIPC parameters are de-
fined), Read-Write Area (where RLS TCs and TMs are de-
fined).
Within CCIPC the data types of the objects are pre-de-
fined. The only available data types are Variable (U8, U16
or U32 single value), Record (object composed by a combi-
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing
AUTHOR ET AL.: CAN IMPLEMENTATION AND PERFORMANCE FOR RAMAN LASER SPECTROMETER (RLS) INSTRUMENT ON EXOMARS 2020 MISSION
nation of Variables) and Array (object composed by a com-
bination of Variables of the same data type).
In RLS, the CCIPC object dictionary is embedded in the
boot software code and copied to the CCIPC “ROM” when
the boot code starts running. After this ROM is loaded, the
boot software must release the CCIPC from reset and after
approximately 15ms the CCIPC will be active and ready to
use.
5 ONBOARD DATA HANDLING AND SW DESIGN
The RLS SW design is based on a five-mode state ma-
chine, where transitions from one mode to another are trig-
gered by telecommands; that is, CAN messages sent from
the CAN master node, the Rover OBC.
Two SW entities follow this state machine: The Boot
Software (Boot SW) and the Application Software (App
SW). Both entities never work at the same time, after in-
strument power-on, the Boot SW starts the “Initialization”
mode, and once a transition to another mode is requested
by means of the correspondent telecommand, the App SW
starts its execution. The App SW implements the rest of the
modes, and the Boot SW does not run again until a Reset
Telecommand is received or the instrument is powered off
and on again.
Thus, the state machine is controlled by the Rover
through CAN messages (TCs) sent by the CAN master
node. The reception of these messages is handled in differ-
ent way by Boot SW and App SW. The former implements
polling, active sampling of CCIPC registers, while the lat-
ter uses the microcontroller interrupt mechanism, with all
the CCIPC interrupts coming from the same interrupt line.
5.1 CAN usage description on RLS Onboard
procedures
The usage of the data interface by the onboard Software
differs from one procedure to another. While the bootup
procedure would set and prepare the infrastructure, the
more complex scientific activities would intensify the ex-
change of data. This section shows some sequence dia-
grams and numbers relative to CAN performance.
The use of SDO for sending large amounts of science
data could be considered as the main characteristic of the
RLS CAN implementation.
SDO was not mainly developed to do this. SDO was
thought to access the client to the server´s object dictionary
for service purposes like configuration and, consequently,
it is not the most efficient bus for large data transmission.
However, since for the server is possible to access to all
the Object Dictionary, it is also possible to access to a big
data buffer object implemented in the OD and, in this way,
to read or write its content. This is how RLS works; receiv-
ing TCs means the client to write in an OD´s buffer and
sending TMs means the client to read in an OD’s buffer.
The main goal of the instrument is to collect and trans-
mit scientific data coming from Mars samples, and this im-
plies to transmit it through CAN PL Bus. For that, an oper-
ation procedure is defined, called RLS_SampleMeasure-
ment Task. The overhead added by the Exomars
2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
7
CAN/CANOpean protocol over the PL Bus, for this pro-
cedure is assessed, by analyzing the number of useful bits
which are transferred via the bus against the total number
of transferred bits. Furthermore, a similar analysis for the
main maintenance procedure is accomplished. This proce-
dure allows App Software updates, and it is called
RLS_Patching Task.
For the assessment, the tasks are decomposed in actions,
and these actions in TCs and TMs. Then, these TCs and
TMs are converted to CANopen messages and, finally,
these CANopen messages are translated to CAN messages,
which are what really will be transferred through the CAN
PL Bus.
Neither retransmission nor bit stuffing are considered
in this assessment. Only Data CAN messages regarding
RLS_SampleMeasurement and RLS_Patching tasks. Heart-
beat messages, SYNC messages, RLS synchronous TMs
(PDOs sent each 10s) and RLS_TM_Events are skipped of
this analysis.
A CAN Data Frame format including one data byte
(Byte 1) is shown in Figure 11.
Figure 11 - Raw CAN Data Frame for 1 Byte of real data
Since the number of data bytes can be from one to eight,
and the rest of the bits are mandatory independently of the
number of data bytes, overhead decrements when the
number of data bytes increases following Figure 12.
Figure 12 - Data bits vs Transferred bits
The assessment is done in the following sections consid-
ering the data bytes transmitted for the main scientific ac-
tivity (RLS sample measurement activity) and the main
maintenance activity (RLS patching).
5.2 CAN performance on RLS main scientific
activity
The RLS_SampleMeasurement task comprises:
1. Rover moving SPDS (Figure 15) to allocate the
Martian sample under the RLS field of view. This
step does not imply any Rover-RLS message;
SPDS is completely independent from RLS.
2. RLS_SetLaser Action is then performed, where
the laser is switched on and its signal is stabilized.
3. The sequence follows moving SPDS one-step for-
ward, what does not transfer any RLS-Rover mes-
sages to the bus.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing

8 IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING

4. RLS_SingleSpotAcquisition Task is then per-

formed to acquire one spot of the sample in the
refillable container (Figure 13).

Figure 13 - RLS Single Spot Acquisition

5. The first of these Actions is RLS_SetFocus, which

moves RLS IOH (Internal Optical Head) into z-
axis, either automatically or by forcing to a spe-
cific position in order to focus the sample and
maximizes in this way the received Raman signal. Figure 14 - RLS_SampleMeasurent CAN messages
6. RLS_EstimateAcquisition_Parameters Action is
executed. Within this Action, RLS executes the This activity has been simulated for the following use
procedure to estimate the Number of images to case:
average (Nav) and the Integration time (Ti), in-  20 spots
cluding operation like Saturation process, Fluo-  5 images per spot
rescence Removal, Estimation Parameters and  CCD subwindowing for size 5x2048.
Store parameters for next acquisition. With 37 messages being exchanged and a total of
7. Then, the Rover performs the RLS_ToIAlgo Ac- 3597720 bytes, the obtained result is 0.5865 Data Bits/CAN
tion, where the 'traces of interest detection' algo- Bits rate.
rithm is run. This algorithm analyses the refer- A complete block diagram for the RLS_SampleMeas-
ence frames, obtained during RLS_Estimate- urement Activity is depicted in Figure 15.
AcquisitionParameters Action, looking for peaks
that fall into spectral regions of interest. This Ac-
tion does not require to transfer any CAN mes-
sage to the bus.
8. Once this action is finished, RLS accomplishes the
RLS_ImageAcquisition Action to make RLS Ac-
quire Frames.
9. Then, the Rover performs the RLS_Accumulate
Action to execute 'Accumulation' algorithm, what
is meant to average Nav (Output parameter of
RLS_ImageAcquisition Action) frames obtained
from Raman after an acquisition.
10. After that, it is also the Rover in charge of execut-
ing the RLS_Precompress Action to remove scien-
tific data headers and join several frames in order
to allow the final compression and the RLS_Com-
pression Action to accomplish the final data com-
pression algorithm. These last three Actions do
not involve any CAN message transfers.

All the CAN messages transferred during the

RLS_SampleMeasurement Task are shown in Figure 14.

Figure 15 - RLS_SampleMeasurement Activity

2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing

AUTHOR ET AL.: CAN IMPLEMENTATION AND PERFORMANCE FOR RAMAN LASER SPECTROMETER (RLS) INSTRUMENT ON EXOMARS 2020 MISSION
9

considered the time taken in sending a SDO Block Down-

During testing, we have found that the transmission of load.
the content of a SDO Block Upload (127 data segments)
takes RLS 25.087ms. This corresponds to 323.992kbps of
Data Bits and 551.799kbps of CAN Bits. That gives 0.5871
6 CONCLUSION
Data Bits/CAN Bits. The CAN bus application on the scientific space in-
strument RLS has been presented.
5.3 CAN performance on RLS main maintenance Besides reliability, robustness, low power consump-
activity tion and low mass requirements among other good char-
acteristics provided by CAN, RLS takes advantage of using
The RLS_Patching task comprises: CANopen as higher layer.
1. Once a block is received via the SDO service, it is In RLS, CANopen protocol is managed by CCIPC con-
stored on memory. This is repeated for every troller, allowing onboard software applications to rely on
block. a generic service to transfer data through the CAN bus
2. After every block is stored, a Reset of the Instru- which is also responsible for the data segmentation.
ment is performed. The use of CANopen allows network management,
bus redundancy and synchronization services within the
All the CAN messages transferred during the network. Regarding communication protocols, the use of
RLS_PatchMemory Task are herein summarized in Figure data-oriented communication through PDOs is useful for
16. short TCs and TMs, while service-oriented communication
via SDOs is implemented in RLS for long science data TMs
and some long TCs, as patching.
During RLS development, we have found several is-
sues related to: understanding the meaning and values of
some Object Dictionary entries; dealing with all the inter-
rupts provided by CCIPC multiplexed in only one micro-
processor input line; and managing the endianness, since
CCIPC works in Little-endian and the Exomars protocol is
defined as Big-endian.
Some overhead could be avoided using other protocol
really defined for long data transfers, and higher data rates
may be achieved. Nevertheless, this overhead is accepted
for applications like RLS and the complexity to manage an-
other different interface is avoided.
Figure 16 - RLS_PatchMemory CAN messages Although some improvement could be done, like in-
creasing the CCIPC working frequency from 10MHz to
Considering this activity has been simulated for the 16MHz (maximum frequency allowed by datasheet) or im-
following use case: plementing CANopen on CAN FD (Flexible Data-Rate) to
 256KB patched avoid overhead impact increasing the bit-rate when just
 Rover Vehicle Interface Simulator acting as the one node is transmitting, this CAN implementation is cur-
Rover with predefined routines rently being successfully tested with RLS EQM (Engineer-
With 1012 TC/TMs being exchanged and a total of ing Qualification Model) and FM (Flight Model).
264659 bytes, the obtained result is 0.58712 Data Bits/CAN
Bits rate.
ACKNOWLEDGMENT
The authors wish thank to the entire team in charge of the
development of the Raman Laser Spectrometer, its hard
work and good working environment during all these
years.

REFERENCES
[1] Bosch, “CAN Specification” Version 2.0, Sept. 1991
[2] ISO 11898-1:2003(E), “Road vehicles – Controller area network
(CAN) – Part 1: Data link layer and physical signalling“ Road
vehicles – Controller area network (CAN) – Part 1: Data link
Figure 17 - RLS_PatchMemory Activity layer and physical signaling
[3] Information technology – Open Systems Interconnection – Basic
During testing, we are using an electrical ground sup- Reference Model: The Basic Model. ISO/IEC Standard 7498-
port equipment (EGSE) that simulates the Rover OBC, but 1:1994(E)
its performance is not exactly the same; so, we have not [4] CANbus extension protocol. ECSS Standard ECSS-E-ST-50-15C.

2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TETC.2018.2874643, IEEE
Transactions on Emerging Topics in Computing
10
1 May 2015
[5] CiA 301, “CANopen application layer and communication pro-
file”, Version: 4.2.0, 21 February 2011
[6] A.Viana “CAN Bus for Modern Spacecraft Control Systems”,
Proceedings of DASIA 2011 DAta systems in aerospace: 17-20
May 2011 San Anton, Malta. Noordwijk, ESA Communications.
(Conference proceedings)
[7] Fernando Rull et al., “The Raman Laser Spectrometer for the Ex-
oMars Rover Mission to Mars”, ASTROBIOLOGY, vol. 17, Numbers
6 and 7, 2017
[8] Jorge L. Vago et al., “Habitability on Early Mars and the Search
for Biosignatures with the ExoMars Rover”, ASTROBIOLOGY,
vol. 17, Numbers 6 and 7, 2017
[9] C.Diaz et al., “Raman Laser Spectrometer adaptative operation
for Mars Exploration”, presented at IAC-13,A3.P.29, 2013
[10] A.G. Moral et al., Raman Laser Spectrometer (RLS) Instrument
for 2020 ExoMars Mission, presented at Instrument Planetary
Probe Workshop#14 – ID 411, 2017
[11] M. Caramia et al., “The CANopen Controller IP Core: Implemen-
tation, Synthesis and Test Results”, Proceedings of DASIA 2011
DAta systems in aerospace: 17-20 May 2011 San Anton, Malta.
Noordwijk, ESA Communications. (Conference proceedings)
[12] CCIPC - Datasheet. Sitael. CAS-CCIPC-DTS-0001. Issue 17.
Laura Seoane (Ferrol, Spain – 1979) received her Master Degree in
Telecommunication Engineering from the University of Vigo, Spain,
and her Postgraduate Specialization in Satellite Communication and
M. Eng. In Electronic Systems from the Polytechnic University of Ma-
drid, Spain. Currently she is finishing her PHD on CAN applications
for small satellites. After a half-year stage at the European Space Re-
search and Technology Centre (ESTEC) in 2004, she joined to INTA
in 2005. There, she has worked at INTA for the Small Satellites Pro-
gram during 10 years, participating in Nanosat-01 (launched in 2004),
Nanosat-1B (launched in 2009) and IntaµSat-1 (stopped in Phase C
due to budget restrictions) satellites development and operations.
During these years, she was involved in system engineering, AIV ac-
tivities, electronic design and satellite operations, mainly. In 2015 she
joined to the RLS instrument development, as software designer.
Since 2016 she is responsible of the RLS Software.
Carlos Díaz (Madrid, Spain - 1982) Computer Scientist by the Univer-
sity Carlos III of Madrid, Spain, Master Degree in Space Technology
in 2009, and currently a PhD student in physics by University of Val-
ladolid. After 3 years working in several developments with artificial
intelligence, switched to the Space industry in 2009, to join the Flight
Software group at INTA, and soon started working for the develop-
ment of the RAMAN Spectrometer for ExoMars. After 7 years as the
SW and Operation responsible, involved in the design and implemen-
tion of ground, AIV and onBoard Software for this project, he changed
his job to start working for the European Southern Observarory (ESO),
as part of the Control SW group for the Extreme Large Telescope
(ELT).
Jesús Zafra (Jaén, Spain - 1986). Telecommunications Engineer
(2010) by the University of Seville, Spain. He worked for 5 years
(2011-2016) for Moog GmbH (Böblingen, Germany) as HW Engineer
in the Motion Controls department designing and manufacturing PLCs
for the industry. He joined INTA in 2016. Since then, he is working as
Software Developer in RLS (Raman Laser Spectrometer), an instru-
ment onboard ESA ExoMars mission to be launched in 2020. At pre-
sent, his work at INTA includes SW PA and SW testing with RVIS
(Rover Vehicle Interface Simulator).
Sergio Ibarmia (Madrid, Spain – 1976) received his B.S. and M.S. in
Atomic, Nuclear and Molecular physics in 2003 from the Madrid Com-
plutense Univesity (UCM). He joined the Dept. of Atomic Physics of
the UCM as an intern researcher to study the Ultra High Energy Cos-
mics Rays for the Pierre Auger Observatory. In 2005, he moved to the
Spanish National Institute for Aerospace Technology (INTA), first as
2168-6750 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
IEEE TRANSACTIONS ON EMERGING TOPICS IN COMPUTING
intern, and later as senior space radiation engineer in the Space Pro-
grams Dept. His work at INTA has included radiation shielding design
for space missions, radiation hardness assurance and component
testing and development of high-energy particles simulation tech-
niques for total dose effects, non-ionizing damages and single event
effects modeling. In addition, he also works developing computing
software for radiation simulation, and lately, embedded control appli-
cations for space scietific instruments.
César Quintana (Las Palmas de G.C., Spain - 1987). Telecommuni-
cation Engineer (2010) by the University of Las Palmas de G.C.,
Spain, and Master in Space Science and Techonology by the Univer-
sity of Alcala de Henares. He worked during two years with an
Esteban Terradas Grant for the development of a Spanish nanosatel-
lite. Aftherwords, he had a trainee at ESAC (European Space Astron-
omy Center) at Villafranca in the frame of CESAR´s project. (Cooper-
ation through Education in Science and Astronomy Research) in
colaboration with Cebreros (ESA) and Robledo (NASA) Deep Space
Stations. At present, he is working as Software Engineer in RLS (Ra-
man Laser Spectrometer), an instrument onboard ESA ExoMars mis-
sion to be launched in 2020.
Carlos Pérez Canora (Madrid, Spain - 1977). Master degree in phys-
ics (5 years - 2005) by Autonoma University of Madrid, PhD student
in physics (2 years - currently) by Valladolid University and Master in
Satellite communications by University Complutense of Madrid. He
worked 3 years for Macanus as product assurance engineer, 2 years
for Indra Spain as software engineer and joined INTA in 2007. He has
worked during 2 years as software engineer in MIRI project (James
Webb - NASA) and since 2009 as System engineer in RLS (Exomars
- ESA) project related with Mars exploration. Along these years he
presented several papers in conferences related with optics, photonis,
astronautical and planetary missions.
Andoni G. Moral (Madrid, Spain – 1976) Master Degree in Aeronautic
Engineering (Space Vehicles) at Polytechnic University of Madrid,
Spain. Currently finishing a PhD on Raman Spectroscopy for Plane-
tary Exploration. Started his career as AIT engineer and PA assistant
at Lidax S.L., becoming company AIV Manager for INTA's JSWT MIRI
Telescope Simulator project for three years, and Project Manager in
several satellites acceptance/qualification programs (HISPASAT 1E,
EXPRESS AM4, YAHSAT 1B, YAHSAT 1A, ARABSAT 5B...) for
EADS CASA (Astrium) Spain. In 2009 joined INTA as RLS (Raman
Laser Spectrometer for 2020 ExoMars) AIV Responsible, and Tech-
nical support for RLS Laser development and RLS Optical Head Unit
focusing mechanism qualification. Since 2015 he is RLS Instrument
Project Manager, AIV Responsible and Optical Head Unit Responsi-
ble; and Spanish National Project Manager for the RLS International
Consortium.
Alvaro Araujo (Madrid, Spain -1978) received his Diploma (M.Sc.) in
Telecommunication Engineering from the Universidad Politécnica
deMadrid in 2001 and his Ph. D. on 2007 from the same University.
Currently he is serving as Associate Professor in the Electronic Engi-
neering Department at the Escuela Técnica Superior de Ingenieros de
Telecomunicación of the Universidad Politécnica de Madrid where he
carries out both research and teaching activities. He was a post-doc-
toral researcher at Berkeley Wireless Research Center (BWRC) at the
University of California at Berkeley. His main research and develop-
ment fields are in embedded systems focusing on Wireless Sensor
Networks, Wireless Neural Nerworks and Cognitive networks.