1. ExoMars 2016 Entry Descent Module CAN Bus Application Layer
ESA/SITAEL in CAN Space Workshop June 2017

2. Background
Exomars mission
ExoMars program is an element of the Aurora Exploration Programme, and as such it has as its defining objectives the development of specific technologies aimed towards the exploration of solar system bodies possessing a high potential for the emerging life.
ExoMars Program is pursued as part of a joint cooperation between ESA and Roscosmos, with an important contribution from NASA, to explore Mars and prepare for future planetary exploration mission.
In particular, it is exploited in a two phase mission:
2016 Mission launched March composed of:
Trace Gas Orbiter (TGO) and
Entry Descent and Landing Demonstrator Module (EDM) named Schiaparelli
2020 Mission foreseen July 2020 composed of
Carrier Module (CM)
Descent Module (DM)
Rover Vehicle and a stationary Landing Platform.
The Schiaparelli EDM, the 2020 Rover Vehicle and Descent module use the Can Bus media for most of their units.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

3. Exomars 2016 Schiaparelli CAN Application
Presentation organisation
The presentation covers the design of the CAN Application layer used in EXOMARS 2016 Schiaparelli Entry Descent Module, focusing on following aspects :
Avionic Architecture general/CAN
Peculiar design choices driven by requirements
Testing activities
Measured sizing/timing of the resulting Can Applications
Conclusions and lesson learnt
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

4. Exomars 2016 Schiaparelli CAN Application
Schaiparelli sensors and actuators
Guidance Navigation Control Units
Inertial Measurement Unit (MIMU) connected on a dedicated RS-422 serial line
Radar Doppler Altimeter (RDA) connected on the CAN Bus
Remote Terminal&Power Unit (RTPU) connected on the CAN Bus
RCS command & control;
Entry sensors acquisition;
Pyros actuation
Power distribution and thermal control
Batteries switches
TCS thermistor acquisition heater commanding
Telecommunication:
UHF Tranceiver (UHF) connected on CAN Bus
Science:
Common Electronic Unit of surface scientific instrument (DREAMS) connected on CAN Bus
The CAN Bus is then the main media supporting the EDM mission functionalities both during the EDL and Surface mission phases, with different timing constraints.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

5. Exomars 2016 Schiaparelli CAN Application
Main peculiar requirements introduced for the Schiaparelli EDM
The following 6 points have been identified as peculiar driving requirement for the Schiaparelli CAN Application:
CAN Avionic Architecture with 2 different CAN Busses managed by the same processor unit (AT697)
Each of the 2 CAN busses have a Nominal and Redundant line
3) Timing constraints for RCS commanding and TM acquisition
4) Usage of the SDO for large data transfer (patch dump and instrument science TM)
5) Usage of the CAN Application in a Space SW
6) Integration into an existing framework
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

6. Exomars 2016 Schiaparelli CAN Application:
1) CAN Avionic Architecture
Avionic Architecture foresees 2 different Can Busses named CAN-A and CAN-B each of the two with main and redundant side
4 slave nodes
CAN-A(Surface Platform)
Used to communicate with UHF Transceiver (UHF) and CEU Payload
SYNCH period 100ms
CANB (No more active after landing)
Used to communicate with RTPU and Radar Doppler Altimeter (RDA)
SYNCH period 50 ms
The above slave nodes allocation forced the need to instantiate 2 Master Node Application Software running on the Central Terminal and Power Unit (CTPU) one to master the communication on CAN-A and the other for the CAN-B
RTPU
RDA
CTPU A
UHF P /
L CEU
CAN _
B M
B R
A M
A R
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

7. Exomars 2016 Schiaparelli CAN Application
1) Solution: duplication of the master application
Each of the two instance of the Master CAN ASW are characterized by the following main common design drivers:
Only a subset of standard protocols services requested derived from the CCIPC Design used by all the Slave node of the 2 CAN Buses i.e.
Network management (NMT) protocols:
Module Control Protocol
Heartbeat Protocol
Synchronization Object (SYNC) protocol
Process Data Object (PDO) protocol
Service Data Object (SDO) protocol
This means that neither the Emergency Object (EMCY) nor the Time Stamp Object (TIME) protocols are requested to be implemented.
Reuse of commercial Vector CanOpen Stack with slight customization (e.g. accommodate the coexistence of 2 Master applications, optimise the SDO management on CAN B)
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

8. Exomars 2016 Schiaparelli CAN Application
2) Solution: Redundancy Management
Due to the fact that each of the 2 CAN busses have a nominal and redundant side, a logic to manage the redundancy need to be implemented.
The master node monitors the Heart Beat generated by the slaves as soon as they are switced on and healty.
In case one of the slaves fails to transmit its HB message within a defined time window, the master node tries to communicate with the unit on the redundant line.
This mechanism is called «bus toggling» and is:
repeated until the communication is re-established
for a fixed (odd) number of times.
If the communication is not re-established within the predefined number of toggling:
The Slave that is not transmittimg the HB is considered failed.
All other Slaves continues their activities on the redundant bus.
Otherwise the communication is re-established by all slave nodes on the same side (Nominal or Redundant).
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

9. Exomars 2016 Schiaparelli CAN Application
3) Common driving timing constraints
Despite the different SYNCH period, on both CAN A and B there is the common need to ensure that the commands and the telemetry are sent and collected in a well defined time frame inside a 100 ms cycle. After the SYNCH message: first 70ms  used for collecting PDO from units and receive in case 1 SDO next 30ms used to send PDOs to units This ensure that the commands generated are coherent and computed taking into account the most updated Telemetry acquired.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

10. Exomars 2016 Schiaparelli CAN Application
3) CAN Applications real time architecture
Each of the two CAN Master Applications (A/B) rely on:
one cyclic task activated at 100Hz that manages all the CAN OPEN Stack interfaces,
one async task that is common to both Can A and B, and is used to handle the asynchronous requests such as PUS Telecommands execution.
CAN_B_CYCLIC_TASK Cyclic Task (100 Hz) High priority task (task with highest priority)
CAN_A_CYCLIC_TASK Cyclic Task (100 Hz) High priority task (task with high priority but less than CANB)
CAN_PUS_TASK asynchronous lower priority task (needed to manage ground TCs)
The CAN_B_CYCLIC task has an highest priority because collects the data used from the Guidance and Control algorithms involved in the most critical phases of the EDM mission (i.e. Entry, Descent, and in particular Landing)
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

11. Exomars 2016 Schiaparelli CAN Application
3) Can B driving timing constraints
The CAN Bus B works with a 20 Hz SYNCH in order to support the acquisition of the 20 Hz generated RDA data for the GNC software during the EDL.
The GNC is in charge, among other critical calculations, to compute and perform the RCS commanding during the final landing phase that is the most critical phase of the EDL in terms of timing issues.
In fact this imposes a strong criticality on the synchronization between the GNC and the CANB task:
The GNC Algorithms collect data from the 20Hz and needs two sample of TM data in order to correctly compute the RCS commands
the RCS Thrusters commands need to be sent only after that both execution of the 20 Hz activities are completed (i.e in the second half of the 100 ms cycle) so that they are ready to be executed by the RTPU soon at the begin of in the next CANB Cycle.
RCS command is an SDO containing 9 commands in sequence one for each of the 9 EDM thrusters. The 9 RCS thrusters commands need to be sent together because represent a set of 9 coherent commands evaluated by the GNC algos. They can be only accommodate into 1 18 bytes SDO message. The option of having them spread into several PDO has been discarded because it was risky in case one of the PDO was not sent or delayed.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

12. Exomars 2016 Schiaparelli CAN Application
3) CAN B driving timing constraints
1) 20 Hz GNC and CAN B cyclic task need to be Synchronized: This synchronization mechanism is obtained by the GNC counting the 20Hz task activations and relaying on priority assignments that ensures that the CANB task is activated always before the GNC ones. At all the odd activations of the GNC 20Hz task the algos are executed, at all even activation both algos and Thrusters commands are generated and sent. 2) Customization needed on the Vector CANOpen product in order to optimize the timing for the SDO management.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

13. Exomars 2016 Schiaparelli CAN Application
4) Data Dictionaries Overview
The table here summarises The composition of the data dictionaries to be managed for each unit An the relevant operative Constraints.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

14. Exomars 2016 Schiaparelli CAN Application
4) Multi Block SDO Management protocol definition
All units except RTPU, need to be able to perform patch and dump of its SW image using SDO protocol.
In addition surface platform instrument need the SDO to download its science TM.
RDA OBSW IMAGE size 99 Kbytes
UHF OBSW image size  16 Kbytes
DREAMS image size  1024 Kbytes
DREAMS Science TM size  1 kbyte per TM block
All having size >> of the maximum useful data that can be transferred with SDO block protocol (889 Bytes).
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

15. Exomars 2016 Schiaparelli CAN Application
4) Multi Block SDO Management protocol definition
The SDO transfer protocol in both direction upload and download is initiated by the master node.
A mechanism needed to be designed in order to support this extra Multi block data transfer protocol:
The first available TPDO of each slave node that support the SDO service, maps the “Buffer Support Object” (BSO) .
 the BSO is used by the Slave nodes to indicate:
The buffer status (i.e. ready to be upload/ready to download)
SDO content (i.e. the type of data transferred in upload HK/SC)
Information in the BSO is used by the EDM CTPU OBSW Master to:
packetize the data into the specific packet type (i.e. 3, 254,255) in accordangce to what has been daclared by the slave node
compute the number of SDO blocks expected for the transferring to/from The Slave node.
Download Block SDO protocol
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

16. Exomars 2016 Schiaparelli CAN Application
4) Multi Block SDO Download Management protocol definition
The Master initiate the download of the data block using the standard Init SDO transfer protocol directive. This directive will notify the Slave that it will receive N segments (composing a block) througt the SDO buffer. Being the SDO buffer unique for each slave, once the SDO download is completed, the Slave node need tocopy content from its OD to a local memory area. After having completed this operation the Slave node will notify the Master, using the BSO, that the Download has been completed. This process can be repeated as long as the final total amount of blocks needed to complete the transfer is completed. The arrows in red identify the operation that are not part of the standard SDO block transfer protocol but are services that need to be managed at ASW level.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

17. Exomars 2016 Schiaparelli CAN Application
4) Multi Block SDO Upload Management protocol definition
The Slave node communicate to the Master, using BSO, that it has a buffer ready to be uploaded, and the relevant length.
The Master node start the SDO upload using the standard Init SDO transfer protocol requesting to the Slave M segments (one block).
Being the SDO buffer unique for each slave, once the SDO upload is completed, the Master node will need to copy the buffer content from its OD to a local memory area. All the above steps can be repeated untill all the data are transferred to the master The arrows in red identify the operation that are not part of the standard SDO block transfer protocol and need to be managed at ASW level.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

18. Exomars 2016 Schiaparelli CAN Application
5) Integration into a Space SW i.e. Ground Commandability/Observability
The CAN Master ASW as to guarantee the necessary Ground observability in terms of
Ground commandabilty:
PUS services need to operate directly on the 2 CAN Busses (send direct Commands to units)
Dedicated private PUS service 2 Telecommands defined to support direct
PDO commanding (services 2, ,249 )
SDO Commanding (services 2,250 – 2,251)
Unit’s SW maintenance services to allow upload new SW or patch and dump memory areas
SDO Multi block Download (services 2,253,- 2,254)
Ground observabilty:
All slave nodes produced TM as well as status variable for the master are maintained into a Data pool.
The TM blocks acquired as SDO from DREAMS instrument are instead put into dedicated PUS Science TM packets.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

19. Exomars 2016 Schiaparelli CAN Application
6) Integration of the CAN ASW component into Schiaparelli OBSW framework
The CAN Applications SW, as well as all other EDM ASW components, needed to be integrated into the System Managemen Software (SMS) framework used for the Schiaparelli EDM. The SMS was a «Corba Component Model» (CCM) Based Architecture and so the CAN application has been designed in order to be, as far as possible, compliant with that model. This means in other words, make the SW
component implementation completely transparent to end- user (Ground and other SW components) and to expose to the them, only the interfaces necessary that are called in general Facets (or provided interfaces) and Receptacles (or required interfaces).
CAN Bus
Component
Object Dictionary
Data pool
Generated Event(PUS Service 5)
Managed Event(PUS Service 5)
Required interfaces (including PUS TM Handlers)
Provided interfaces
(including PUS TC Handlers)
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

20. Exomars 2016 Schiaparelli CAN Application
Testing Environment
CAN Application is a category BSW (Critical SW) requiring testing performed at all level:
Unit tested with RTRT tool full branch coverage.
Functional stand alone with on dedicated test bench with CTPU FUMO and CANoe
CTPU Functional Model plus CANoe simulating slave nodes
Functional integrated into EDM OBSW on Software Validation Facility
Full SW testing facility with processor emulator and SW models for slave nodes
Functional integrated into EDM OBSW on Avionic Test Bench (ATB)/Flight Model
HW in the loop for all CTPU and Slave node
CANBUS Trapping always active to post test data analysis
Benchmark for CPU load and performance test on ATB with instrumented OBSW
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

21. Exomars 2016 Schiaparelli CAN Application
Sizing/timing
Memory budget of the CAN Application Components
WCET for CAN BUS Cyclic task measured during Landing phase:
CAN A ms
CAN B ms
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

22. Exomars 2016 Schiaparelli CAN Application
CAN Bus A data traffic and load measurement
During Crouise and EDL
Worst case scenario for BUS load measurment are:
CAN A:
DREAMS
TM SDO
4 events TM and HB PDO
3 TC
maximum data traffic of bits/sec
CTPU
SYNCH and HB
maximum data traffic of 544 bits/sec
CAN BUS A
Unit
Tot bits per second
Bus load
CTPU
544
0,06%
UHF
1800
0,18%
DREAMS CEU
0,00%
Total
0,24%
Total with bits stuffing (+20%)
0,28%
On Mars surface
CAN BUS A
Unit
Tot bits per second
Bus load
CTPU
544
0,06%
UHF
1800
0,18%
DREAMS CEU
18572
1,86%
Total
2,10%
Total with bits stuffing (+20%)
2,5 %
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

23. Exomars 2016 Schiaparelli CAN Application
CAN Bus B data traffic and load measurement
CAN B:
RDA data traffic in operative mode:
TM produced with different rates for a maximum of bits/s
UHF data traffic:
TM produced with different rates for a maximum of 1800 bits/sec
RTPU:
TMs exchanged via PDOs cyclically at 1 Hz
TMs exchanged via PDOs cyclically at 10 Hz
CMDs exchanged via PDOs asynchronously
1 CMD exchanged via SDO
maximum of bits/sec
CTPU
2 SYNCH and HB
maximum of 984 bits/sec
CAN BUS B
Unit
Tot bits per second
Bus load
CTPU
984
0,10%
RDA
11288
1,13%
RTPU
34340
3,43%
Total
4,66%
Total with bits stuffing (+20%)
5,59%
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

24. Exomars 2016 Schiaparelli CAN Application
Conclusions
The experience on the Schiaparelli EDM demonstrates that the selected CAN BUS solution is suitable to support interplanetary and landing mission having evidence from the post flight analysis that no communication error and no reconfiguration has occurred during the whole mission duration. In particular the following aspects can be noticed: CAN Bus is very efficient and easy to setup and manage for sensor acquisition from terminal not implementing PUS standard (such as RTPU), that produce cyclic data with hard timing requirements and using only PDOs both for TM data acquisition and for Commands. CAN Bus is complex and not very efficient for units producing large amount of structured data or requiring large SW uploads for configuration or maintenance purposes(i.e. RDA, UHF and instruments producing Science, images etc.). In fact specific transfer concept of Multi-Block SDO needed to be designed for this purpose. Special attention need to be put in definition of data types into dictionaries because possible endianinty issue may occur if the master and the nodes use different convention.
14-16 June 2017
ESA/SITAEL in CAN Space Workshop

25. Exomars 2016 Schiaparelli CAN Application
Lesson Learnt
As lesson learnt to optimize the CAN BUS performances the following can be suggested:
Use CAN BUS for Sensor Acquisition from non intelligent units
SDO usage should be limited to maintenance and network configuration (as specified into the can CiA standard) relying on PDOs message for all other commanding and acquisition functions.
Force all nodes by requirement to use BYTE “Data Type” for PDO messages into their dictionaries. This will produce several advantages:
simplify the interface definition,
does not limit in any way the internal representation of structured data
make completely transparent the the endianess of the master and slave node computers.
If for any reason the SDO protocol need to be used for large data transfers impose by requirement the maximum size of the block to be 889 Bytes. This figure is derived from the maximum number of bytes that can be transfered by a single SDO Block protocol (7 bytes in127 segments ).
14-16 June 2017
ESA/SITAEL in CAN Space Workshop