cFS' SCH application on RTEMS

[stanislaw]

Hello,

I would like to ask this on behalf of our SW team.

The ECSS software handbook (ECSS-E-HB-40A) describes a few scheduling models appropriate for avionics software. The SCH application provided with cFS seems to implement something similar to a table-driven Cyclic Executive, and RTEMS by default is configured to use a priority-driven preemptive scheduler. Both of these scheduling models are valid in isolation, but in putting cFS on top of RTEMS it seem that we are effectively defining a completely different scheduling policy (cyclic executive) on top of another (fixed priority preemptive), when the RTEMS fixed-priority scheduler coupled with a sound rate-monotonic analysis alone would suffice.

(see also: RTEMS' rate monotonic manager)

Is the SCH application intended to be used when the underlying RTOS already provides sound real-time scheduling capability?

We also appreciate any pointers to the documentation or the slides or anything else where the topic of scheduling in the context of cFS is explained.

Thank you.

[ghost]

Hi,
I don't know if I have an answer for this question, but it has captured my interest.

I can provide some background on the history of SCH:
Earlier FSW systems that cFS is based on typically had a 1553 (or 1773) data bus. These systems had a 1553 application with a cyclical schedule that defined the bus traffic, and that data traffic drove the scheduling of some, but not all tasks. At some point, the schedule functionality was split from the 1553 application, and ended up becoming what SCH is today.
We have still been using the SCH to drive the packet or data scheduling over various busses on our systems, but we also added the scheduling/waking up apps, rather than just scheduling data traffic across a specific bus.
As an example, the SCH table has 1Hz wakeup entries for various cFS apps, and housekeeping telemetry requests. I would have to look back at some legacy code to see how these were scheduled before. I don't think "wake up" packets were included in the 1553 data schedule table.

The RTEMS (and other RTOS priority based preemptive schedulers) will schedule the highest priority task that is ready to run, correct?

In the case of a cFS system using SCH, are we using SCH as a "high level" scheduler and the RTOS priority based preemptive scheduler as an arbiter when multiple apps are ready to run at the same time?

If this is not a valid use case, what would a cFS system look like without SCH? I know that new apps can be written to sleep for a specific time, and just check for SB messages rather than pend, etc, but it would definitely require changes to the suite of cFS apps that are driven by message traffic.

I am curious to know what others think.

Regards,
Alan

[jwilmot]

The cFS SCH just sends SB messages based on a 1Hz schedule and integrates well with the architectural pattern that cFS applications pend on SB messages. For the open source release, it is SCH that provides these messages to wake up applications. For Time Triggered (TT) architectures the message schedule is based on the TT network schedule such that the system is far more deterministic even across distributed processors. This is a key aspect of the Distributed Integrated Modular Avionics (DIMA) architecture very common in flight systems and being used in the Artemis program with cFS. A benefit to scheduling applications this way is that it is OS agnostic and supports many different mission architectures. The SCH app can be mission specific but the message-based application scheduling pattern is important.

[astrogeco]

@stanislaw is the handbook posted somewhere public?

[stanislaw]

https://ecss.nl/hbstms/ecss-e-hb-40a-software-engineering-handbook-11-december-2013/

[astrogeco]

looks like we need an account for access :(

[stanislaw]

Have you checked if there is a strict policy for non-EU? I think the registration itself should be easy.

[thnkslprpt]

looks like we need an account for access :(

I happen to have a copy here: https://github.com/thnkslprpt/awesome-spaceflight-software-best-practices/blob/master/PDF/Coding_Standards/ESA_Software_Safety_Guidebook_(ECSS-E-HB-40A).pdf

;-)