Prototyping of CCSDS SOIS services on 1553 Bus

1. Prototyping of CCSDS SOIS services on 1553 Bus Sev Gunes-Lasnet, Olivier Notebaert Astrium Satellites – Data Processing & Advanced studies – ASG74

2. 1553 SOIS subnetwork services prototyping and porting logic

3. Prototyping & porting feedback • The SOIS sub-network services layer has been developed and validated on the SCoC3 platform • SCoC3 is a Spacecraft Controller on a Chip which includes a LEON3 processor and I/O systems for 1553, SpW and Can. • It has then been ported on the on the RASTA platform • The RASTA platform is part of the ESA reference avionics facility test bench allowing to prototype on-board data handling space applications • The same set of services is supported for the Bus Controller on both platforms

4. Prototyping & porting feedback • Some implementation differences have been introduced during the porting • The origin for of such differences are: • Differences between the MIL-Std-1553B controllers used in SCoC3 and RASTA, in particular the functions accessible through their drivers • The absence of an accurate on-board long-range timer on RASTA while SCoC3 provides a built in HW timer in support of the bus protocol engine and synchronisation service • do not affect the nature of services but impacts: • functions of the underlying communication protocol • performance of the services

5. Prototyping & porting feedback • Implementation differences on Synchronisation service: • For SCoC3 platform • The distributed time data is retrieved from CCSDS Time Manager (CTM) implemented inside SCoC3. • It provides a time conform to CCSDS CUC Time format, i.e. a range of 232 second with a precision of 0.5x 2-24 seconds • This complies to the ECSS-E-50-13 Standard • For Rasta platform • The distributed time data is retrieved from the on-board Leon Timer. • Software managed clock ticks are used to support the time service. • The range and precision of the time depend on the clock ticks configuration. • In our RTEMS configuration, the effective range of the time is about 4000 seconds and the effective precision is 10 ms.

6. Prototyping & porting feedback: • Implementation differences on bus profiling: • For SCoC3 platform • The HW clock signal generated by the CTM is used to automatically drive the cyclical 1553 Communication frame • The clocks are also used to control message sending time inside such frames, allowing the definition and utilisation of time intervals. • For RASTA platform • there is no HW support which can be used to drive the communication frame and message sending. Instead, the software managed timer generates cyclic events, used to launch each communication frame. • This method does not provide the same stability of the cycle duration. • The messages inside a communication frame are transmitted without time control, i.e. they are sent one after another without delay between them. • The definition and exploitation of time intervals as defined in ECSS standard is not really possible.

7. Prototyping & porting feedback: performance • As a result, key elements driving the SOIS subnetwork services performance over MIL-STD-1553 have been identified : • Theoretically, both platforms have similar HW elements to support the sub-network services in a similar way, as each of them integrates a Mil-Std-1553B compliant controller • But several points shall be considered for the performance of a specific implementation of the services on a dedicated platform

8. Prototyping and porting feedback:performance • key elements driving the SOIS subnetwork services implementation performance over MIL-STD-1553: • Bus Controller integration inside the platform, are any features disabled ? • External clock to be used for the bus controller for its synchronisation or message handling • Availaibility of software driver allowing to enhance functional features for the use of the Bus Controller • How about the cost in term of CPU and memory consuming when using such driver ?

9. Drivers related topics (1/2) • SCoC3 runs with a driver for IP1553 provided by Astrium. • All functional features necessary to support the sub-network services and the ECSS protocol are available through this driver. • For RASTA platfom, we use a driver for Actel Core1553BRM • Driver distributed by Gaisler Research with its RTEMS distribution. • The functions provided by this driver do not cover all features of the Actel Core1553BRM. For instance, no support to perform timing control of messages handling is provided

10. Drivers related topics (2/2) • The driver for IP1553 is developed for space on-board software and adapted for such application • For instance, the API and related data structures are defined so that its use is as easy as possible and its CPU consuming is minimized. In addition, error handling is considered. • The driver for the Actel Core1553BRM, can be considered as in a prototype form. • It provides minimum access to 1553 functions without optimisation • It is used as IO device driver, so that it uses standard IO system call, like open, close, ioctl. • Such design introduces an overhead in term of service processing. • The data structures used by the API for its BC message is in a format neither as true 1553 message nor as a data format directly suitable for Actel Core1553BRM controller • Such data structure definition obviously introduces an overhead of the processing on the service using it. • The error handling is in a simple form. Some bugs still exist in the drivers.

11. Prototyping & porting feedback • Preliminary feedback on SOIS : • Status failure and status success • SOIS requires a Success Status without an error code • This is not enough for most 1553 based applications which require that a detailed error 1553 status must go back up to user level (so as to be treated by the FDIR application). • The feedback from 1553 users would claim for an error report delivery to the user of the SOIS subnetwork service • This is implemented on ECSS-1553 Standard through an OR of all status words involved in the 1553 messages supporting the service

12. Preliminary feedback on SOIS services • About the retry function included in the 1553 standard • The ECSS standard does not use the built-in retry function; • Therefore, our reference implementation does not map on the standard 1553 message retry in support of the SOIS guaranteed and assured quality of service • SOIS Packet Transfer service implementation can map on the ECSS verified length QoS of the ECSS Data Block Transfer • This allows upper level (on network management) to manage the retry function for mapping on the SOIS QoS • The messages status could also be used at upper layers to transmit the information on bus errors in support of a retry function

13. Preliminary feedback on SOIS services • Synchronisation issue • The SOIS communication view is mostly asynchronous • Data is fetched upon need – network should be hidden to the user who should not have to care how it is fetched on the data link to end terminal • 1553 systems use mostly synchronous protocols(Such as the one described in ECSS-E-50-13) • The delay between Synchronisation and actual data acquisition/command on the end terminal sensor/actuator defines the real-time performance (e.g. latency, jitter…) of the data transfer • The SOIS end-to-end service performance will depend on the coupling of the user calls with the 1553 synchronisation service. • Users having high determinism and time accuracy requirements (mostly command/control and dependable systems in general) will require such coupling

14. Preliminary feedback on SOIS services • Prototyping & porting feedback preliminary conclusions • All SOIS Subnetwork services have been implemented and verified on the MIL-Std-1553B bus using two different MilBus coupling systems • Performance of the system is being assessed • End-to-end real-time performance of SOIS services on 1553 bus is tightly linked to the implementation of synchronisation between user and the bus system • Overhead due to HW/SW drivers are much more significant than those introduced by the SOIS layered architecture • SOIS subnetwork services should include a interface to report 1553 Status to the user (or to the network management)