1. CAN Stack development for Space
Emily Crudo
14/06/2017

2. CAN Network Engineering and SW impact CAN SW for Space current status
Content
CAN Network Engineering and SW impact
CAN SW for Space current status
Experiences: Leonardo, Luxspace
TEC-SW/TEC-ED GSTP

3. CAN Network Engineering and SW impact

4. CAN Network engineering
Network complexity:
Number of Nodes
Master/Slaves
Type of nodes (FPGAs, Microcontrollers, Processors)
Mission profile, amount of data, needed baud rate, ..
Packets dimension
Application SW data production
Time profiling of the data exchanged on the bus

5. CAN Network engineering: HW selection
Processor (GR712/GR740/SCOC3)
Microcontroller
AL Integrated Solution (CANOpen Controller IP Core)
Did you consider the SW?

6. HW Selection and SW impact for intelligent units
1. SW development phase complexity depends on the node and its functions:
Driver
HPL
Application SW CAN manager
SW development effort  ESA Standards applicable to SW development
2. Final Application SW performance:
How the HPL influence the Application SW?
e.g interrupts to be served: number and timing
SW performances  schedulability analysis and the achievable Bus budget

7. CAN SW for Space current status

8. CAN Bus OSI layers and Space SW
1. Physical Layer
2. Data Layer
3. Network Layer
4. Transport Layer
5. Session Layer
6. Presentation Layer
7. Application Layer
Partially implemented in Higher Layer Protocols
CAN Protocol
HLPs: CANOpen DeviceNet
CANOpen protocol
ECSS Specification
No Qualified Lib
2. CANOpen HW solution for slaves node (CCIP core)
3. No other simpler protocol
No Space Qualified driver available

9. ESA Standards applicable to SW development
Specified by ECSS Software Standards ECSS-E-ST-40C : Software Engineering (Tailored by Software Development Plan) ECSS-Q-ST-80C : Software Product Assurance (Tailored by Software Product Assurance Plan)

10. Software Life Cycle Effort VS SW Categories
An idea of the SW Development effort estimation:
Category Lines/Hour
A 0.25
B 1.00
C 3
D From 16 to 32
OBC  Cat B
Payloads  Cat B/C

11. CAN Bus protocol Driver
1. CAN Bus Drivers are needed and are linked to the HW architecture:
can_open
can_close
can_read
can_write
can_get_state
can_start
can_stop
can_flush ….
2. Current OS does not have space qualified drivers for CAN.
(E.g RTEMS)
Processors:
GR712/GR740
SCOC3 ….

12. Higher level protocols
CANOpen
HW implementation (CCIPcore) for the SLAVE
MASTER node need a SW implementation
SW implementation (ECSS-E-ST tailoring)
Using existing commercial implementation
New development
Easier testing: Existing commercial tools for
network emulation and SW testing
Can be too complex for simple data networks
Others
A Simplified protocol with a simpler implementation
Require the development of the testing tools

13. Example: Payload (Cat C) 450h OBC (Cat B) 1350h Payload (Cat C) 1330h
RTEMS drivers (CAN protocol) Number of lines 1350 Max complexity around 20 CANOpen qualification based on commercial implementation (vector, CAN Festival) Number of lines: around 4000 Cyclomatic Complexity: >> 10 (e.g from 40 to 150)
Payload (Cat C) 450h
OBC (Cat B) 1350h
Payload (Cat C) 1330h
OBC (Cat B) 4000h

14. 2 different experiences: Leonardo, Luxspace

15. Experiences Exomars 2020 CANOpen Protocol
Dill&SPDS EU and Remote Terminal Board:
Slaves of the Exomars Rover CAN Network
HW selected for these units: CCIP core
ESAIL
CANOpen Protocol
OBC:
Master network with Payload units
HW: GR712 (with RTEMS)

16. usage of CCIPC DSEU ARCHITECTURE Leon2 based : AT697F + RTAX2000
CAN interface based on SITAEL IPCORE CCIPC 3.9
RTB ARCHITECTURE
FPGA RTAX2000
CAN interface based on
SITAEL IPCORE CCIPC 3.9

17. usage of CCIPC DSEU Configuration:
1 Object Dictionary with 888Bytes buffer for TC
1 Object Dictionary with 888Bytes buffer for TM
8 asynchronous PDO messages are
TCs and TMs are transmitted via SDO block. Two buffer guaranty the TM and TC integrity
Hand shake protocol between Master and Slave nodes: For receiving/ transferring TC/TM is necessary that a proper sequence of transfer IRQs is received/ transmitted, in a proper timing
The transfer of TC has higher priority with respect to TM
RTB Configuration:
16 RPDO, 12 used
16 TPDO, 16 used;
2TPDO are transmitted every 100ms so that all TM PDO are transmitted within 1 s (period 800ms)

18. usage of CCIPC DSEU ASW characteristics:
No communication driver has to be implemented: communication based on shared memory
The communication is based on hand shake:
State machine for TM and state machine for TC shall be implemented by ASW
All cases of unexpected ISR value, unexpected with respect to state machines, or timeout shall be handled
“TM retry” feature shall be implemented for facing the “TC priority” feature
This part needs to be qualified
Difficulty to inject failures for covering qualification of unexpected / timeout ISR
RTB characteristics :
The RTB has no SW: the exchange of info by means of RPDO/ TPDO is completely performed by F/W
I/P version is the same as the DSEU I/P Core for maintenance purpose
The design, programming, simulation, tests started after the DSEU development => Leonardo exploits experience on DSEU
The development, programming and tests phase were very fast with respect to CANOpen for DSEU and did not point out any major problem

19. usage of CCIPC Main issues:
The SITAEL development environment is based on free SW; this from one side reduces the cost of the application, but, on the other side, makes difficult the maintenance on the upgraded free domain SW version. Problem with:
Perl V5.10.0, perl-Tk V
dcf specification and validation is not quite effective (Leonardo generated the dcf from this environment and then forwarded it to the Customer which verifies it in Vector- CANOe environment)
TC and TM have fixed length 888; variable length seems to be available but it was considered by Leonardo a risk to implement, test and qualify it.
TC/ TM Traffic:
Customer declared that in one 100ms window 1TC and 1 TM are allowed. Leonardo experienced that:
For loading a SW image, the better configuration is to send via RVIS 1TC/ 250ms
For dumping, the better configuration is to transmit one TM Dump / 200ms

20. Tailored CANOpen SW Introduction to ESAIL
European SAT AIS Constellation
ARTES 21
LuxSpace is prime contractor
Low cost ESA AIS mission
100 kg
3 axis stabilized platform
High performance AIS payload
High speed C-Band downlink
Launch planned in 2018

21. Tailored CANOpen SW Network Configuration ECSS Tailoring
Heart beat message
Boot message
Node State Machine
Bus selection
Cold redundant bus architecture
Emergency messages
Luxspace
Implementation as per ECSS
currently not used

22. Tailored CANOpen SW
All PDO definitions (mapping/parameters) are hardcoded
SDO´s to configure units and when sending/receiving data not fitting in a PDO.
Current OBC SW implementation metrics:
Total Lines of Executable Code: 1571 lines
Complexity: 10
Max Nesting level: 5
Currently under testing with the different units using CAN

23. TEC-SW/TEC-ED GSTP

24. TEC-SW/TEC-ED GSTP: CAN System & SW Stack consolidation
Objective: to identify necessary complementary requirements by:
gathering the problems in the use of CAN in various missions
clarify identified open issues (e.g. redundancy concept, use of CANOpen, large data unit transfer, boot loader protocol for remote programming, etc)
identifying growth potential for CAN (e.g. CAN-FD, multi-master, asynch control)
Output:
Guidelines on how to use CAN according to the system configuration
Pre-qualified software drivers or test suite
Simplified HPL (independent from the HW execution and from the HW driver) -

25. Contacts
Emily Crudo System Software Engineer Systems, Software and In-Orbit Demonstration Department
ESTEC Keplerlaan 1, PO Box 299 NL-2200 AG Noordwijk, The Netherlands | T | F