Parametric schedulability analysis of a launcher flight control system under reactivity constraints

03/18/2019 ∙ by Étienne André, et al. ∙ 0

The next generation of space systems will have to achieve more and more complex missions. In order to master the development cost and duration of such systems, an alternative to a manual design is to automatically synthesize the main parameters of the system. In this paper, we present an approach on the specific case of the scheduling of the flight control of a space launcher. The approach requires two successive steps: (1) the formalization of the problem to be solved in a parametric formal model and (2) the synthesis of the model parameters with a tool. We first describe the problematic of the scheduling of a launcher flight control, then we show how this problematic can be formalized with parametric stopwatch automata; we then present the results computed by IMITATOR. We compare the results to the ones obtained by other tools classically used in scheduling.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Real-time systems combine concurrent behaviors with hard timing constraints. An out-of-date reply is often considered as invalid even if its content is correct. For critical real-time systems, if a time constraint is violated, then the consequences can be disastrous. Thus, a formal verification phase is essential in order to statically guarantee that all the tasks will be executed in their allocated time, and that the system will return results within the times guaranteed by the specification.

Assessing the absence of timing constraints violations is even more important when the system can be hardly controlled once launched. This is especially true in the aerospace area, where a system can only very hardly be modified or even rebooted after launching.

While verifying a real-time system is already a notoriously difficult task, we tackle here the harder problem of synthesis, i. e., to automatically synthesize a part of the system so that it meets its specification. The next generation of space systems will have to achieve more and more complex missions. In order to master the development cost and duration of such systems, an alternative to a manual design is to automatically synthesize the main parameters of the system.

Contribution

In this paper, we address the specific case of the scheduling of the flight control of a space launcher. Our approach requires two successive steps:

  1. the formalization of the problem to be solved in a parametric formal model and,

  2. the synthesis of the model parameters with a tool.

We first describe the problematic of the scheduling of a launcher flight control, then we formalize this problematic with parametric stopwatch automata, and third we present the results computed by the IMITATOR tool. We compare our results with the ones obtained by other tools classically used in scheduling. A key aspect is the verification and synthesis under some reactivity constraints: the time from a data generation to its output must always be less to a threshold. The solution we propose is compositional.

We propose here a solution to the problems using an extension of parametric timed automata (PTAs), an extension of finite state automata with clocks and parameters [AHV93]. PTAs are notoriously undecidable (see [And19] for a survey), despite some decidable subclasses (e. g., [HRSV02, BL09, AL17, ALR18]), notably in the field of scheduling real-time systems [CPR08, And17]. In spite of these undecidability results, we show that this formalism is handful for solving concrete problems—such as the one considered here.

Outline

After discussing related works in Section II, Section III presents the problem we aim at solving. Section IV recalls parametric stopwatch automata. Sections VI and V expose our modeling, while Section VII gives the results obtained. Section VIII makes a comparison with additional tools of the literature (solving only a part of the problem). Section IX concludes the paper.

Ii Related works

Scheduling

A long line of works in the last four decades has been devoted to the problem of scheduling analysis of real-time systems with various flavors. Several analytical methods were proposed to study the schedulability for a particular situation. Such analytical methods need to be tuned for each precise setting (uniprocessor or multiprocessor, scheduling policy, absence or presence of offsets, jitters, etc.). Most of them do not cope well with uncertainty. For example, in [BB97], three methods for the schedulability analysis with offsets are proposed. In [BB04], an efficient approach for testing schedulability for (rate monotonic) in the case of (uniprocessor) analysis is proposed, through a “parameter” (different from our timing parameters) to balance complexity versus acceptance ratio.

Scheduling with model checking

Schedulability with model checking is a trend that started as early as the first works on timed model checking (e. g., [WME92, AHV93, AD94, YMW97, CC99]), and grew larger since the early 2000s. On the negative side, the cost of state space explosion often prevents to verify very large real-time systems. On the positive side, they allow for more freedom, and can model almost any system with arbitrarily complex constraints; in addition, despite the cost of state space explosion, they can be used to verify small to medium-size systems for which no other method is known to apply.

A natural model to perform schedulability analysis is (extensions of) timed automata (TAs) [AD94]. In [AM01, AM02, AAM06], (acyclic) TAs are used to solve job-shop and scheduling problems. This allows to model naturally more complex systems which are not captured so easily in traditional models of operation research.

In [NWY99, FKPY07, And17], task automata are proposed as a formalism extending TAs to ease the modeling (and the verification) of uniprocessor real-time systems: in some cases, the schedulability problem of real-time systems is transformed into a reachability problem for standard TAs and it is thus decidable. This allows to apply model-checking tools for TAs to schedulability analysis with several types of tasks and most types of scheduler.linecolor=blue,backgroundcolor=blue!25,bordercolor=bluelinecolor=blue,backgroundcolor=blue!25,bordercolor=bluetodo: linecolor=blue,backgroundcolor=blue!25,bordercolor=blueÉA: remove if space needed?

In [SLS14], hierarchical scheduling systems are encoded using linear hybrid automata, a model that generalizes TAs. This approach outperforms analytical methods in terms of resource utilization. In [SL14], linear hybrid automata are used to perform schedulability analysis for multiprocessor systems under a global fixed priority scheduler: this method is more scalable than existing exact methods, and shows that analytical methods are pessimistic.

In [FLSC16], a schedulability analysis method is introduced using the model of timed regular task automata (using under-approximated WCETs) and then using nested timed automata (which is exact).

The problem we solve here shares similarities with analyses done in [FBG10, MLR10]. An important difference between [FBG10, MLR10] and our case study comes from the fact that, here, there are two distinct notions of “thread” and “processing”, while in [FBG10, MLR10] there was only one notion called “task”. Most importantly, none of these works consider timing parameters.

Scheduling with parameters

When some of the design parameters are unknown or imprecise, the analysis becomes much harder. Model checking with parameters can help to address this. In [CPR08], PTAs are used to encode real-time systems so as to perform parametric schedulability analysis. A subclass (with bounded offsets, parametric WCETs but constants deadlines and periods) is exhibited that gives exact results. In contrast, our work allows for parameterized deadlines; in addition, reactivities are not considered in [CPR08].

In [FLMS12], we performed robust schedulability analysis on an industrial case study, using the inverse method for PTAs [ACEF09] implemented in IMITATOR. While the goal is in essence similar to the one in this manuscript, the system differs: [FLMS12] considers multiprocessor, and preemption can only be done at fixed instants, which therefore resembles more Round Robin than real . In [SSL13], we showed that PTAs-based methods are significantly more complete than existing analytical methods to handle uncertainty. In [SAL15], we solved an industrial challenge by Thales using IMITATOR.

In [LPPR13], the analysis is not strictly parametric, but concrete values are iterated so as to perform a cartography of the schedulability regions. However, the resulting analysis of the system is incomplete.

In [BHJL16], timed automata are “extended” with multi-level clocks, of which exactly one at a time is active. The model enjoys decidability results, even when extended with polynomials and parameters, but it remains unclear whether concrete classes of real-time systems can actually be modeled.

Finally, Roméo [LRST09] also allows for parametric schedulability analysis using parametric time Petri nets [TLR09].

11todo: 1[MLR10]22todo: 2[FBG10]

Iii Description of the system and problem

The flight control of a space launcher is classically composed of three algorithms:

  • The navigation computes the current position of the launcher from the sensor’s measurement (such as inertial sensors);

  • The guidance

    computes the most optimized trajectory from the launch pad to the payload release location;

  • The control orientates the thruster to follow the computed trajectory.

Due to the natural instability of a space launcher, strict real-time requirements have to be respected by the implementation of the flight control: frequency of each algorithm and reactivity between the sensor’s measurement acquisition and the thruster’s command’s sending.

The case study described in this paper is a simplified version of a flight control composed of a navigation, a guidance, a control and a monitoring algorithms (also called processings). Each processing has a name and a required period. A processing can potentially read data from the avionics bus (“in” data) and / or write data to the same avionics bus (“out” data). Fig. 1 shows an example of such system (all the numerical data provided in this paper are only examples which do not correspond necessarily to an actual system).

1processing Navigation (Meas     : in)  is period (5ms);  end;
2processing Guidance                    is period (60ms); end;
3processing Control    (Cmd      : out) is period (10ms); end;
4processing Monitoring (Safeguard: out) is period (20ms); end;
Figure 1: An example of a flight control system

Iii-a Threads and deterministic communications

Processings are allocated on threads run by the processor. In our setting, all the thread’s periods are harmonic, i. e., a thread period is a multiple of the period of the thread just smaller (they pairwise divide each other).

In addition, in order to ensure the determinism of the scheduling (which facilitates the verification of the system), the threads work in a synchronous manner:

  • The inputs of a thread are read at its start (no inputs are read during the execution of the thread)

  • The outputs of a thread are provided at its deadline (no outputs are provided during the execution of the thread)

Figure 2: The communication between threads

Fig. 2 shows the way data are exchanged between two threads. The fast thread (in yellow) has a period of 1. This period defines the time granularity of the system (this implies that the offset of the fast thread is 0 and that its deadline is 1). On this example, the slow thread (in blue) has an offset of 1 (its start is delayed of 1 cycle compared to the start of the fast thread) and a deadline of 8. The communication between the fast thread and the slow one is performed immediately at the end of the first execution of the fast thread. In order to ensure the determinism and taking into the priority between the threads, the communication between the slow thread and the fast thread is performed at the deadline of the slow thread, i. e., at the end of the cycle 9 (offset + deadline).

Iii-B Reactivities

To ensure the controllability of the launcher, a reactivity is required between a data read from the avionics bus (a measurement) and a data written to the avionics bus (a command). Several paths are potentially possible between a read data and a written data. Fig. 3 shows an example of such reactivities.

1reactivity Meas -> Navigation -> Guidance  -> Control -> Cmd       is 150ms;
2reactivity Meas -> Navigation -> Control              -> Cmd       is 15ms;
3reactivity Meas -> Navigation -> Monitoring           -> Safeguard is 55ms;
Figure 3: Some typical reactivities

We want to solve the scheduling problem of periodic processing under precedence and reactivity constraints, as in [FBG10]. Reactivities too must follow the deterministic communication model from Section III-A. Consider the reactivity “Meas Navigation Guidance Control Cmd” depicted in Fig. 4 (the values of periods and WCETs are not necessarily the ones given in our case study). Due to the data being communicated at the end of each thread only, the Guidance processing (marked with “G” in green) does not receive the data from the third execution of the Navigation processing (marked with “N” in red), as the data of the third Navigation will be sent at the end of the thread T1 period, but from the second execution of Navigation. Therefore, in Fig. 4, the only path of interest is the path of the data starting from the second execution of Meas, going to the second execution of Navigation, then going to the (only) execution of Guidance, and then finishing in the third execution of Control, before being written to the third occurrence of Cmd. Also note that the data output by the first execution of Navigation are successfully sent to T2 at the end of the first period of T1, but will be overwritten by the second occurrence of Navigation, and are therefore not of interest for the computation of reactivities.

Figure 4: Determinism and reactivities

Iii-C Processings and assignment into threads

A WCET (worst case execution time) is measured or computed for each processing. An example is given in Fig. 5.

1processing wcet Navigation (1ms);
2processing wcet Guidance   (15ms);
3processing wcet Control    (3ms);
4processing wcet Monitoring (5ms);
Figure 5: Example of Worst Case Execution Times

An important problem is to find a proper assignment of the processings into threads, with their respective periods. A solution to this problem consists on a set of cyclic threads on which the processings are deployed. In our setting, these threads are scheduled with a preemptive and fixed priority policy (). A thread has a name and is defined by the following data:

  • a rational-valued period;

  • a rational-valued offset (with offset period), i. e., the time from the system start until the first periodic activation;

  • a rational-valued (relative) deadline (with deadline period), i. e., the time after each thread activation within which all processings of the current thread should be completed;

  • a rational-valued major frame (or “MAF”). A MAF defines the duration of a pattern of processing activation;

  • a set of processings deployed in the thread. Different processings may be executed at each cycle. However, after a MAF duration, the same pattern of processings is repeated.

Iii-D Formalization

A real-time system is viewed here as a set of threads , a set of processings and a set of reactivities . A thread generates a possibly infinite stream of processings .

A thread is periodic, and characterized by a 5-tuple , where corresponds to the period, to the offset, to the deadline, defines the duration of a pattern of processing activation , and defines a subset of processings of allocated to .

A processing is characterized by two values and . When a processing is activated, it executes for at most time , and has to terminate within the relative period .

These definitions are illustrated in Fig. 6.

Figure 6: Real-time characteristics of the system

A reactivity is of the form where denotes a precedence constraint of , and is the maximum time of reactivity for : the end of the thread containing the last processing of the precedence sequence has to be completed before the deadline .

Definition 1.

A system is schedulable if

  • , the end of occurs before .

  • , the end of thread containing the last processing of occurs before .

Iii-E Description of the case study

We give here the values for the case study of interest.

Iii-E1 Processings

The processings considered corresponds to the lists:

  • (Navigation) =

  • (Control) =

  • (Monitoring) =

  • (Guidance) =

Iii-E2 Threads

The threads considered corresponds to the lists:

  • =

  • =

  • =

Iii-E3 Reactivities

The reactivities (end-to-end flow) considered correspond to the lists:

  • where = (Navigation, Guidance, Control) and = 150.

  • where = (Navigation, Control) and = 15.

  • where = (Navigation, Monitoring) and = 55.

Iii-F Objectives

1thread T1 is
2  period     (5ms);
3  offset     (0ms);
4  deadline   (5ms);
5  maf        (10ms);
6  processing (when 0 => (Navigation);
7              when 1 => (Navigation; Control));end;
(a) T1
1thread T2 is
2  period     (20ms);
3  offset     (0ms);
4  deadline   (20ms);
5  maf        (20ms);
6  processing(Monitoring);
7end;
(b) T2
1thread T3 is
2  period     (60ms);
3  offset     (0ms);
4  deadline   (60ms);
5  maf        (60ms);
6  processing (Guidance);
7end;
(c) T3
Figure 7: A typical solution of the flight control scheduling problem

In order to simplify the scheduling problem, we have considered in this paper a pre-allocation of processings on threads, as specified in Fig. 7: that is, Navigation and Control are allocated on T1, while Monitoring and Guidance are allocated on T2 and T3, respectively. In addition, Navigation is executed at every period of T1, while Control is executed (after Navigation) on odd cycles only; this is denoted by the when 1 syntax in Fig. 6(a). The offsets and deadlines of each thread are unknown; that is, the values in Fig. 7 are not part of the input of the problem. The flight control scheduling problem consists thus in computing the offsets and deadlines of each thread in order to fulfill the required reactivities.

Let us summarize the problems we address in this paper. Our problems take as input:

  1. a flight control system i. e., a list of processings with their period, and their input or output data (for example Fig. 1);

  2. a set of reactivities (for example Fig. 3);

  3. a set of WCET for the processings (for example Fig. 5);

  4. an allocation of processings on threads (for example Fig. 7).

A solution to this problem is a set of threads with their period, offset, deadline and MAF (the MAF can in fact be obtained immediately from the period). A solution is correct if the set of reactivities is schedulable (as in Definition 1).

The first problem is to formally verify a solution to the problem:

scheduling verification problem: Input: a flight control system, a set of reactivities, a set of WCET, an allocation of processings on threads, and a solution Problem: formally verify that is schedulable.

The second problem is to synthesize solutions to the problem:

scheduling synthesis problem: Input: a flight control system, a set of reactivities, a set of WCET, an allocation of processings on threads Problem: exhibit correct solutions.

Recall that our synthesis problem still considers as input the periods, therefore offsets and deadlines are the main results of interest.

Iv Parametric stopwatch automata

Clocks, parameters, constraints

We assume a set  of clocks, i. e., real-valued variables that evolve at the same rate. A clock valuation is a function . We write for the clock valuation assigning to all clocks. Given , we define the reset of a valuation , denoted by , as follows: if , and otherwise. Given a valuation , and , we define the time-elapsing of  by  except for clocks in , denoted by , as the clock valuation such that

We assume a set  of parameters, i. e., unknown constants. A parameter valuation is a function . We denote . A guard  is a constraint over defined by a conjunction of inequalities of the form or , with , and . Given a guard , we write  if the expression obtained by replacing in  each  by  and each  by  evaluates to true.

Parametric stopwatch automata

Parametric timed automata (PTA) extend timed automata with parameters within guards and invariants in place of integer constants [AHV93]. For many real-time systems, especially when they are subject to preemptive scheduling, parametric timed automata are not sufficiently expressive. As a result, we will use here an extension of PTA with stopwatches [CL00], namely parametric stopwatch automata [SSL13].

Definition 2 (Psa).

A parametric stopwatch automaton (PSA) is a tuple , where:

  • is a finite set of actions,

  • is a finite set of locations,

  • is the initial location,

  • is a finite set of clocks,

  • is a finite set of parameters,

  • is the invariant, assigning to every a guard ,

  • is the stop function , assigning to every a set of stopped clocks,

  • is a finite set of edges where  are the source and target locations, is a guard, , and is the set of clocks to be reset.

Stopwatch automata can be composed as usual using parallel composition on synchronized actions. Note that our clocks are shared by default, i. e., a same clock (i. e., with the same name) can be read, stopped or reset in several automata. The same applies to parameters.

Given a parameter valuation  and PSA , we denote by the non-parametric structure where all occurrences of a parameter  have been replaced by . Any structure is also a stopwatch automaton [CL00]. If for all , then by assuming a rescaling of the constants (multiplying all constants in by their least common denominator), we obtain an equivalent (integer-valued) TA, as defined in [AD94].

Let us now recall the concrete semantics of stopwatch automata.

Definition 3.

Given a PSA , and a parameter valuation , the semantics of is given by the timed transition system (TTS) , with

  • ,

  • ,

  • consists of the discrete and (continuous) delay transition relations:

    1. discrete transitions: , if , and there exists , such that , and ).

    2. delay transitions: , with , if .linecolor=blue,backgroundcolor=blue!25,bordercolor=bluelinecolor=blue,backgroundcolor=blue!25,bordercolor=bluetodo: linecolor=blue,backgroundcolor=blue!25,bordercolor=blueÉA: Laurent: j’ai un peu improvisé pour les stopwatches ici, n’hésite pas à jeter un coup d’œil

V Specifying the system

Since the seminal work of Liu and Layland in [LL73], plenty of methods and tools have been designed to verify real-time systems. However, while some aspects are reasonably easy (, no mixed-criticality), the problem we address here is not typical for several reasons:

  • offsets may be non-null;

  • threads periods are harmonic;

  • the executed processings may differ depending on the cycle;

  • the reactivities must always be met, and therefore define new, non-classical timing constraints;

  • and, perhaps most importantly, the admissible values for deadlines and offsets may not be known. Only the global end to end reactivity is specified.

As a consequence, we choose to follow a model checking based method. Model checking is known for being more expressive than analytical methods, at the cost of performance or even decidability. We show here that, although we use an undecidable formalism, we do get exact results for the instance of the problem we considered.

We present in the remainder of this section our modeling of the verification and the synthesis problem using parametric stopwatch automata. This formalism has several advantages. First, it is handful to model concurrent aspects of the system (different threads and processings running concurrently). Second, stopwatches can be used to model preemption. Third, parameters can be used to model the unknown constants, and solve the synthesis problem.

V-a Architecture of the solution

A modular solution

To model the system, we use the concurrent structure of parametric stopwatch automata to allow for a modular solution: that is, each element (thread, processing, scheduling policy) and each constraint (reactivity) is defined by an automaton. These automata are then composed by usual parallel composition on synchronization actions.

This makes our solution modular in the sense that, in the case of a modification in the system (e. g., the scheduling policy), we can safely replace one automaton by another (e. g., the scheduler automaton with another scheduler automaton) without impacting the rest of the system.

Encoding elements and constraints as automata

We model each processing activation as an automaton. These automata ensure that processings are activated periodically with their respective period, and initial offset.

In addition, we create one automaton for each thread: the purpose of these automata is to ensure that the processings associated with each thread are executed at the right time. In the case of our concrete problem, we assign both the Navigation and Control processings to the T1 thread, the monitoring process to T2 and the guidance processing to T3.

The reactivities also follow the concept of modularity. That is, each reactivity is tested using a single automaton. By testing, we mean that a reactivity fails iff a special location is reached. Therefore, ensuring validity of the reactivities is equivalent to unreachability of these special locations.

Finally, we specify a scheduler automaton which provides the scheduling between the different threads (in the case of our problem, recall that the scheduling policy is fixed priority scheduling ().

We give more details on each of these automata in the following.

33todo: 3dire quelque chose sur les actions de synchronisation ; parler d’activation / start / finish

V-B Modeling periodic processing activations

Each processing is defined by a period and an offset. To model the periodicity of the processings, we create one automaton for each processing activation. This automaton simply performs the activations in a periodic manner. Activations are modeled by a synchronization action, used to communicate with other automata (typically the thread automaton).

In addition, the period processing activation automaton detects whether a processing missed its (implicit) deadline equal to its period; that is, we assume that a processing that has not finished by the next period is a situation to be avoided.

Each such automaton features a single clock.

Figure 8: Automaton

We present in Fig. 8 the example of the automaton, modeling the periodic activation of the Control processing. This controller contains a clock and one parameter . Note that the period is known beforehand, and is therefore not strictly speaking a parameter, but that makes our solution both more generic and more readable (in IMITATOR, a parameter can be statically instantiated to a constant before running the analysis).

The initial location is : from then, the first occurrence of Control is immediately activated (action ), and the automaton enters the location. Then, exactly every time units (guard ), another instance of Control is activated.

V-C Modeling threads

stop

stop

stop

stop