A Flexible Ada Framework for Jitter-Sensitive Mixed-Criticality Real-Time Systems

Real-time computing systems can be characterized as set of concurrent activities, commonly referred to as tasks, that must be executed over time while satisfying specific temporal constraints. These constraints may include requirements such as periodic activation rates or deadlines by which tasks must complete their execution. In order to guarantee that these temporal requirements are met, the scheduling strategy must be predictable and analysable, allowing system designers to verify beforehand that all timing constraints will be satisfied when the system was deployed.

Two main paradigms are commonly employed in the design and scheduling of real-time systems: time-triggered and event-triggered approaches. In time-triggered (TT) systems, task execution is governed by a statically defined schedule that is constructed offline. This schedule specifies precisely when each task starts executing and how long it is allowed to run. In contrast, event-triggered (ET) systems rely on the occurrence of events to activate tasks. The timing of such events may not be known in advance. Some events are periodic in nature, such as the expiration of timer intervals, whereas others may occur asynchronously, for instance when a particular system condition is reached or when an external event is received. During execution, the scheduler dynamically decides which task should run next, typically based on the priorities assigned to the tasks whose activation events have occurred.

Both design paradigms present distinct advantages and limitations, and neither can be considered universally superior. Time-triggered systems provide lower run-time overheads and strong guarantees in terms of runtime predictability since the schedule is fully determined beforehand, which effectively ensures schedulability by construction. However, this approach often leads to increased design complexity and reduced flexibility. In some cases, timing considerations must even be reflected directly in the functional implementation of tasks. For example, when a task’s worstcase execution time exceeds the duration of a schedule slot, its code may need to be partitioned across multiple slots. Although TT systems can handle asynchronous events, doing so usually requires mechanisms such as periodic sampling or more elaborate techniques to reduce reaction latency.

Event-triggered systems, on the other hand, facilitate a clearer separation between functional behaviour and timing management. For instance, a preemptive scheduler can interrupt and resume tasks according to their priorities, allowing long computations to be naturally divided during execution. ET systems also support non-periodic activities in a more direct way. Nevertheless, their dynamic nature introduces uncertainty in timing behaviour and requires dedicated schedulability analysis methods to ensure correctness. In particular, tasks may experience variable release delays due to interference from higher-priority tasks. Such variability can be problematic in certain applications. For example, in digital control systems it may degrade the performance of control algorithms, and in distributed systems it can negatively affect synchronous communication among components.

In previous publications [11, 12], we proposed a framework for the combined execution of time- and event-triggered tasks (TT and ET tasks, respectively). In this framework, TT tasks are released by a time-driven scheduler according to an offline-designed scheduling table, or plan, whereas ET tasks are handled by an underlying priority-based scheduler. The framework was specifically designed for implementation in Ada under the Ravenscar profile [4, 6], and was realised as a Ravenscar-compliant runtime in [10], relying on the fixed-priority preemptive scheduler provided by a modified version of the Ada Run-Time System for the target STM32F4 MCU.

In this framework, TT schedules can be executed at a selectable priority level of the priority scheduler. It can be for example the highest, thus forming a hierarchy where TT tasks take precedence over the rest and hence they suffer minimal release jitter. Alternatively, the highest-priority level can be used for ET tasks, e.g. sporadic tasks handling urgent events, thus granting prompt reaction to them. This degree of flexibility combines the benefits of TT and ET scheduling to handle competing timing requirements of real-time embedded software.

This previous framework defines a model for the TT part of the system. The model uses work slots to denote time intervals of TT activity, mode-change slots to mark the points in the plan when mode changes are possible, and empty slots to denote unused time intervals at the TT level. The time not used for the execution of TT activities is automatically made available to lower-priority tasks by the underlying priority scheduler. The TT model also introduces concepts such as sliced sequences of TT jobs, or synchronisation slots for ET tasks that further its expressiveness.

While the model proposed in our previous work provides a flexible way to combine time-triggered and event-triggered activities, many modern embedded applications must also support functionalities with different levels of criticality. This has led to the emergence of mixed-criticality systems [5].

Mixed-criticality systems (MCS) are characterised by the coexistence of functionalities with different levels of criticality within the same computing platform. Tasks are therefore assigned a criticality level reflecting the severity of the consequences in case their timing requirements are violated. In this context, different estimates of the worst-case execution time may be associated with each task, typically increasing with the assumed level of assurance. During system operation, the detection of execution-time overruns may trigger a change in the system criticality level. When such events occur, the system must adapt its behaviour in order to guarantee the timing requirements of higher-criticality tasks, possibly by reducing the service provided to lower-criticality activities.

Although relatively flexible, the model proposed in our previous studies exhibited certain shortcomings inherent to static schedules. On the one hand, the assignment of time slots to TT tasks was fixed. In other words, regardless of the system conditions, the maximum execution time available for a given task had to be specified statically in the schedule. If system conditions changed as a result of an event, as occurs in mixed-criticality systems, the only possible adaptation mechanism was to perform an operational mode change, with the corresponding modification of the static schedule.

On the other hand, although the presence of mode-change slots allowed schedule modifications to be performed more flexibly than in classical cyclic executives [1], the system still had to wait until those slots were reached before its behaviour could be altered, at least that of the time-triggered components.

In order to support mixed-criticality systems that include tasks with jitter-sensitive components, this paper extends the approach proposed in previous studies in two directions. First, we reformulate the task model to incorporate task criticality levels while preserving the notion that certain tasks may contain activities with strict activation requirements. Second, we revise the previously proposed execution support to enable the adaptation of static schedules according to the current criticality level of the system.

The proposed framework provides execution support for mixed-criticality systems combining time- and event-triggered tasks. It does not prescribe the policy used to determine when system criticality level (SCL) changes occur, nor does it enforce schedulability guarantees across all criticality levels. Instead, such guarantees are assumed to be ensured by the offline construction and analysis of the scheduling plan.

The remainder of the paper is organised as follows. Section 2 presents the system model. Section 3 introduces the extensions to the time-triggered model required to support mixed-criticality systems. Section 4 describes the proposed timed mode-change mechanism. Section 5 illustrates the behaviour of the framework through a mixed-criticality execution example. Section 6 presents a brief experimental evaluation of the framework, focusing on the activation delays introduced by the proposed mechanisms. Section 7 discusses related work, and Section 8 concludes the paper.

This section describes the system model assumed throughout the paper. It first introduces the task model used to characterise the workload. Then, the execution model defines how jobs are released and executed within the combined time-triggered and event-triggered framework. Finally, the time-triggered model briefly recalls the structure of the TT scheduling framework introduced in our previous work, which serves as the basis for the extensions presented in this paper.

This section describes the extensions required to support mixed-criticality systems, mainly in the TT scheduler. These extensions address the objectives outlined in the introduction, namely incorporating criticality-awareness into the task and execution models and providing mechanisms to adapt system behaviour according to the current system criticality level (SCL).

The framework focuses on providing execution support for mixed-criticality workloads in a combined TT and ET setting. It deliberately does not define the mechanisms or policies used to trigger changes in the SCL, which are considered application-specific. Instead, the framework provides the necessary mechanisms to support the implementation of different SCL transition protocols. Likewise, the framework does not ensure that all TT tasks meet their timing requirements at all criticality levels. This responsibility is delegated to the offline construction and schedulability analysis of the TT plan for each SCL.

To this end, the proposed framework has been extended along several dimensions, including the integration of system criticality level (SCL) into the execution model, support for multiple execution-time estimates in TT jobs depending on the SCL, and an application-level overrun detection mechanism that may trigger SCL changes. In addition, the framework provides execution-level support for implementing different SCL transition mechanisms, without prescribing the policies that govern when such transitions occur.

To support these extensions, both the internal structures of the TT scheduler and the slot types used to construct TT schedules have been adapted. Figure 2 illustrates the updated hierarchy, attributes, and slot operations introduced to support MCS. Their use is described in the corresponding subsections below, in a bottom-up manner.

In the original model, a mode-change request takes effect exactly at the end of the next mode-change slot in the plan. Although several mode-change slots can be carefully placed in the schedule to ensure that the semantic consistency of multi-frame tasks is preserved, this strict timing restriction limits some practical extensions. One particularly useful capability is the possibility of re-synchronising schedules, for example to compensate for clock drift in distributed applications.

To support this behaviour, the original mode-change semantics is relaxed to allow the requester of a mode change to specify the intended exact time at which the change should take place. If the given time falls within the duration of a mode-change slot, the slot is immediately abandoned and the new plan starts at that point. In this case, the current plan is effectively truncated at the requested time. If the given time falls outside a mode-change slot, then the change takes place at the beginning of the next mode-change slot. Timed mode changes are useful to coordinate the operation of parallel or distributed schedules, or to synchronise a schedule with an external event, not necessarily a time event defined in the plan.

This extension preserves the role of mode-change slots as safe synchronisation points while allowing mode-change requests to target a specific intended time.

A mode-change request overrides any previously pending request; there is no buffering of requests. However, to maintain backward compatibility when precise timing is not required for the mode change, the TT scheduler may react in two different ways to a mode-change request:

• $\mathrm{■}$

  Default mode change – Occurs when the mode change is requested by calling Set_Plan with a single parameter, the next plan to execute. The change takes effect at the end of the first mode-change slot occurring after the request.

• $\mathrm{■}$

  Timed mode change – Occurs when the call to Set_Plan includes a second, optional parameter specifying the intended time for the mode change to occur. If the given time falls within the interval of a mode-change slot, the change becomes effective at that precise time and the slot is aborted at that point, when the new plan starts. If the given time falls outside a mode-change slot, the change takes effect at the beginning of the next mode-change slot, i.e., as soon as possible after the specified time. If no plan is currently running (e.g., at system startup), the new plan starts immediately if no start time is given, or if the specified time lies in the past; otherwise, it starts at the specified time.

In this section we explore the expressiveness and adequacy of the defined TT model for systems with multiple criticality levels. To that end, we use a prototypical application with no specific real-life purpose. The application has two criticality levels, HI and LO, with the usual high- and low-criticality meaning.

The top part of Figure 4 shows the TT plan followed by this application. It is formed by 12 slots of fixed slot size, for a total plan duration of 1650 ms. Slot boundaries are marked with short segments in the upper side of the plan. Since work slots are distributed throughout the schedule, the empty part in most of the work slots is used to avoid introducing dedicated empty slots. Darker grey boxes represent time allocated only to HI criticality tasks. A lighter grey indicates LO criticality time. White areas denote spare time in the plan. Some slots are of different work size depending on the criticality level. Such slots (e.g. the third of the plan, marked with Id. 3) are depicted as a light-grey box of the work duration for LO criticality mode, followed by a dark grey box indicating the additional time available in HI criticality mode. Hence the available time for this TT task in HI criticality is 50 ms.

The line on top indicates the Work_Id used by the slot. The last slot, tagged with a curly arrow inside the slot, is a mode-change slot. However, in this application, it has the effect of an empty slot, since we do not replace or re-synchronise this plan. The Ada code used to generate this TT plan using the TT_Utilities package is provided in Appendix C.

The bottom part of Figure 4 shows the task structure used by the application. There are two tasks, Seq_1 and Seq_2, that executes multiple jobs using TT slots. They have a so called IMs-F structure, one of the patterns defined in [12]. The name indicates that the sequence has an initial part glued to a sliced mandatory part, and then the job completes with a final part. Hence the name, from Initial, Mandatory sliced and Final parts. The initial part in the IMs-F pattern ends with a call to the API service Continue_Sliced to transform the work slot into a continuation slot until the end of it. So the sliced sequence starts in the IMs part. In addition to the time spent in the initial slot, Seq_1 may use two additional slots for the mandatory sliced part. Note that the last slot of the sliced sequence is not a continuation slot, because it requires overrun control, rather than simply holding the task if it is still running at the end of the slot. The sequence Seq_2 uses just one additional slot for the Ms part.

Task Seq_1 is of criticality HI, so it is taken regardless of the current SCL. In LO criticality, the Ms and F parts have slots of a shorter work duration, but they are given extra time during HI criticality. Task Seq_2 is of LO criticality, hence it is only taken if the SCL is LO at time 50 ms. If there is a change to HI during the execution of Seq_2, then the task cycle is allowed to run to completion, even though it uses LO criticality slots. Tasks Wk_3, Wk_4 and Seq_5 are testers of proper managing of criticality levels by the scheduler. Works Wk_3 and Wk_4 are single job TT tasks, i.e., they just use one regular work slot for their unique jobs. Task Wk_3 is of HI criticality, and Wk_4 is LO. Task Seq_5 implements another complex task pattern formed by an initial part that uses a sync slot to release an ET task, which may optionally require a final part at the TT domain. In the new framework, this task uses a unified Work_Id = 5 for both the initial synchronised part and the final TT part, since both belong to the same execution sequence.

Figure 5 illustrates a possible system execution, where the active criticality level of each task is indicated by the grey shading of its executed jobs. The application starts at LO criticality level. The SCL may then be changed at two points of the plan. We have programmed Seq_1 so that once every two iterations of the plan, it causes an overrun of its LO work duration at the end of the mandatory sliced part. The overrun handler simply changes the SCL to HI, so that the task immediately continues execution using the extended time for that level. We also check that task Seq_2 runs to completion, unaffected by the SCL change in the middle of the task cycle. And the same for the task Seq_5: the optional final part is taken if the Sync’ed initial part so decided, even when Seq_1 raises the SCL in between the initial and final parts of Seq_5. However, task Wk_4 does not execute, since the SCL is already HI when it reaches its initial slot. Missed task releases are signalled with a green downward arrow in Figure 5.

The other point where the SCL may change is due to the effect of Wk_3, which blindly sets the SCL to LO at the end of its only job. As Figure 5 shows, tasks Seq_1 and Wk_3 start the second round at HI criticality level. Task Seq_1 does not change its active CL until the end of its task cycle, since the SCL is changed externally to LO by task Wk_3. Task Wk_4 also starts normally, but at LO criticality level, since the SCL has returned to LO before its TT slot is reached. In contrast, task Seq_2 is not executed at all, since the SCL is HI when the task reaches its initial slot. This behaviour follows the rules defined in Section 3.3.

To approximately quantify the scheduler overhead in our implementation of the model [14], and grasp an idea of the scheduler performance, we have measured the release delays incurred by the tasks in any possible combination of ending and starting slots. In the new version of the TT scheduler, the handling of Next_Slot and End_Of_Work events has been separated into distinct handlers. As a result, slot termination behaviour is determined by whether the task must be suspended at the end of the slot (i.e., in continuation slots, labeled as Hold) or has already completed before the end of the slot (Others). Slot activation, in turn, depends on both the slot type and whether it corresponds to the initial slot of a sequence. The maximum job release delays measured on an STM32F4 Discovery board running at 168 MHz, with clock interrupt period configured as $10\mu s$, are reported in Table 1.

Table 1 shows that processing task suspension prior to activating the next slot increases the release delay by up to 8 $\mu$s. The maximum observed delay is 32.07 $\mu$s and occurs when a slot marking the start of a task cycle is also a continuation slot, as this case involves the largest number of scheduler operations.

In the previous version of the framework, the longest release delay recorded on the same board was 36.7 $\mu$s, slightly higher than the current value. At first sight, one might expect the previous version to exhibit lower overhead, given its simpler execution model. However, the measurements indicate the opposite. This difference is due to a custom modification in the current runtime implementation of Timing Events, which allows the start time of the TT plan to be resynchronised with the system periodic clock. This prevents an extra periodic tick from being inserted when the timing event is programmed.

Although the times shown for each type of activation in Table 1 are very stable (with less than 0.4 $\mu$s variation between minimum and maximum values), differences in the amount of work performed across the cases result in a 12.08 $\mu$s variation between activation types; a much wider range than in the previous framework.

To compare the overhead of the proposed framework, standard Ada mechanisms for task activation have also been evaluated using the same run-time. Table 2 reports the results obtained when a task is activated via a Protected entry or through a Suspension Object controlled by a Protected Object. For each case, the release delay is measured both for immediate activation and for activation triggered from a Timing Event handler. Given that timing events are used together with suspension objects in the TT scheduler implementation, the resulting overhead of our proposal can be estimated to lie between 10 and 20 $\mu$s.

To the best of our knowledge, there is no previous work proposing variable-duration slots in a TT model definition. Neither have we found the extended semantics of mode-change slots presented in this paper.

The issue of bringing mixed criticality to TT systems has been previously addressed from different perspectives. In [15] and [8], the authors propose methods to build static schedules so that they guarantee a combination of requirements, among which is the criticality level. The static nature of the schedules obtained by these methods ultimately requires the plan to allocate slots for all tasks, despite their criticality. Hence in these frameworks there is no real concept of system criticality level as a mechanism to reduce the demand of low-criticality tasks when the system is in a higher-criticality level.

A less static approach to mixed-criticality in TT systems is proposed in [3]. Rather than a single TT schedule for all tasks of all criticality levels, multiple modes (schedules) are defined, one for each criticality level. With one defined schedule per level, criticality-aware workload balancing is possible via mode changes. The authors assume the mode-change transition to be immediate. This is an assumption we cannot make in our model, as it would break the semantic consistency of multi-frame tasks if there are ongoing task cycle at the time of the mode change. In our proposed model, one could place mode-change slots at points that do not break any task cycle. But letting an overrunning task to immediately transition to a higher criticality level and continue execution, as we are proposing, is a more effective response to the event while the mode-change slot is reached. The consistency of task cycles is preserved by the rules described in Section 3.3.

A third approach to the issue is proposed in [16], based on the slot-shifting technique [7]. The slot-shiting technique analyses a static legacy TT plan to find spare times in the plan for insertion of sporadic or aperiodic workload by shifting (delaying) the release of TT tasks to a point where they remain schedulable, thus promptly leaving time for ET tasks, at the expense of release jitter for TT tasks. This technique requires an online mechanism to handle changes of criticality. In our combined ET-TT scheduling framework, the planned TT tasks are never explicitly delayed by the scheduler, although they will be naturally delayed if ET urgent tasks are assigned a higher priority than the TT scheduler.

In previous publications, we defined a hierarchical architecture for the execution of systems combining event- and time-triggered workloads. The ET workload is scheduled by an underlying priority scheduler and the TT workload is executed by a purely time-triggered scheduler running on the same runtime support. The architecture helps simplifying the TT plan, since the ET workload can be moved out of it, and it also opens the possibility of collaboration between both scheduling domains. Along with the architecture definition, we provided a library of useful programming patterns for multi-frame TT tasks, and ET tasks that synchronise with the TT plan; and a library of utilities to define slots and build TT plans [14].

In this work, we have focussed on the TT part of the model to make it more flexible and expressive, so that it makes it possible for the static plan to adapt to mixed criticality systems. We have identified and applied a relatively small number of changes to the original model, with promising initial results demonstrated by an illustrative example. We have also defined the rules that help preserve the semantic consistency of multi-frame tasks when a change in the criticality level catches them in the middle of a task cycle.

With the proposed changes, the originally proposed model has gained: (i) the flexibility of variable-duration slots and timed mode changes; and (ii) criticality awareness and user-defined handling of overruns, for user-defined criticality management. In our view, the model opens the possibilities of TT schedules to cope with time-varying requirements in a way that does not seem achievable in the more classic, purely static TT framework.

As future work, we plan to extend the framework to support mixed-criticality management in the event-triggered domain. Event-triggered tasks are already supported through a priority-based scheduler and may be activated in coordination with the time-triggered plan, thereby inheriting a degree of mixed-criticality control. However, this support is currently limited, as activations are strictly driven by the TT plan and cannot follow independent periodic or sporadic patterns. In addition, execution overrun detection is not available in the ET domain due to the constraints of the Ravenscar profile, which prohibits execution-time monitoring. We further envision the introduction of a flexible event-triggered plan to regulate multi-frame execution and provide more expressive activation and control mechanisms in the ET domain. Providing such capabilities would enable a more uniform integration of TT and ET components under mixed-criticality assumptions.