Introducing critical real-time software design and programming

Frank Singhoff (frank.singhoff@univ-brest.fr)
University of Split, October 2022 (also given in December 2021)


Safety critical systems are systems whose failure or malfunction may result in death or serious injury to people, loss or severe damage to equipment/property. Train, aircraft and automotive are example of safety critical systems. Today, those systems embed large and complex software, both implementing critical features such as fligth control-command, but also implementing non-critical functions such as entertainment.

In this lecture, first we will show how software contribute to critical systems today. Then, we will focus on those who are critical real-time software, i.e. software in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced (Stankovic 1988). We will address the way those applications are supported by operating systems by investigated how they are scheduled, how we can predict application performances and especially their ability to meet deadline. For such a purpose, we will experiment two tools : Cheddar and RTEMS.





All lecture documents are available here:




II.1 Exercise 1, first handouts with Cheddar

To launch Cheddar from Windows, just click on the cheddar.exe file.


The window of the Figure 1 should be displayed:
Fig. 1: Main window of Cheddar


The top part of this window (in gray in the figure) displays the time lines computed during scheduling simulation. The bottom part of this window displays numeric analysis results.

In this section, we will design our first Cheddar model. A Cheddar model is composed of hardware and software entities such as processors or tasks.

Work to do

  1. Download and save the file ex1.xmlv3 in your workspace. With the Cheddar menu File/Open model, load this file into Cheddar.

    Fig. 2: Editing a task component

  2. Once loaded in Cheddar, we want to add tasks with the menu Edit/Software/Task. As shown by Figure 2, a task may have several attributes. The most importants are:
  3. From the file ex1.xmlv3 add 3 tasks with the following attributes:


Fig. 3: A scheduling simulation
Fig. 4: Compute schedulability tests


  • Run analysis with buttons and . button starts a scheduling simulation and the button computes a sample of schedulability tests for a basic periodic task set. Figures 3 and 4 show a screenshot of analysis. We can notice in the time lines that red rectangles show task release times and that horizontal rectangles show when tasks are running.
  • From the scheduling simulation, read the different response times for each task (remind that response time = completion time - release time). For a given task, can you see the response time varying during the scheduling simulation ? Why ? When should we see the shortest response time ? Why ? Finally, verify that all deadline are meet.


    II.2 Exercise 2, automotive case study

    To do this exercise, download and save the file ex2.xmlv3

    We investigate a system embedded in a car which displays various data to the driver. This system is composed of several tasks and we want to verify their deadlines.

    The system is composed of 5 tasks:

    1. Task SENSOR_1 reads every 10 s the speed of the car.
    2. Task SENSOR_2 reads every 10 s the temperature inside the car.
    3. Task SENSOR_3 reads every 40 s the GPS position of the car.
    4. Task DISPLAY_1 produces on a screen every 12 s a summary of the information retrieved by the three sensor tasks.
    5. Finally, tasks DISPLAY_2 displays the map of the current location of the car on another screen. This display is made on request by the driver every 6 s on the worst case.

    An enginer implements all those tasks and run them alone on a RTOS (Real-Time Operating System). After several measurements, he shows that:

    1. Task SENSOR_2 and DISPLAY_1 execution times never exceed 2 s.
    2. Task SENSOR_3 needs between 2 and 4 s to successfully run its code.
    3. Tasks DISPLAY_2 has an execution time of less than 1 s.
    4. Tasks SENSOR_1 has most of the time an execution time of 1 s and sometime of 3 s.

    We assume that all tasks start their first activation at the same time. Furthermore, all tasks must complete their current activation before they have to start the next one.

    We assume an execution platform composed of one processor which provides a preemptive fixed priority scheduler. Priorities range from 0 to 31. 0 is the lowest priority value.

    Question 1:

    Question 2:

    With Cheddar, compute the worst case response time for the SENSOR_1, the SENSOR_2, and the SENSOR_3 task. Do they meet their deadline?




    II.3 Exercise 3, Cross-compiling



    We now work on Linux. Prior to compile any RTEMS program, we must put the RTEMS C cross-compiler in your $PATH shell variable. To do so, launch the following command in your working shell window:

    source rtems.bash

    In this exercise, we experiment the C cross-compiler for RTEMS. On Linux, we will generate programs that are able to run on SPARC/Leon processor architectures.
    Download and save the following file and put it in a directory called EX3.
    1. Compile this first example of C program with the following command:
      make clean
      make
      assuming you are in the EX3 directory.
    2. If everything is OK, you should find a file named o-optimize/sched.exe.
    3. Launch the command file o-optimize/sched.exe : what is the meaning of the displayed information?
    4. Can we directly launch the binary o-optimize/sched.exe from your Unix Shell?
    5. Now, we will use a Leon processor simulator to run this program. This simulator is gracefully provided by the Gaisler Research company (See http://www.gaisler.com). To launch this simulator, call the following command from your Unix Shell:

      $tsim
      tsim>


    6. Now, load the binary into the memory of the simulator with the load command:

      tsim>load o-optimize/sched.exe


    7. Then, finally, run the program with the run command :

      tsim> run
      resuming at 0x40000000
      Max priority for SCHED_FIFO = 254
      Min priority for SCHED_FIFO = 1
      ...
    8. Answer to these questions:
      • What is the name of the C function which is the entry point of the program?
      • Can you say what does this program do?



    II.4 Exercise 4, Fixed priority/Rate Monotonic scheduling and periodic tasks




    Question 1:


    In this exercise, we experiment the fixed priority scheduling with RTEMS. Download and save the following file and put it in a directory called EX4q1.


    Question 2:


  • Now, we work with a new version of the init.c file to experiment a preemptive Rate Monotonic scheduling of the automotive case study. Download and save this new file in the EX4q2 directory.
  • In this program, we assume a set of 5 periodic threads as the Exercise 2 with Cheddar:
    1. Task SENSOR_1 reads every 10 s the speed of the car.
    2. Task SENSOR_2 reads every 10 s the temperature inside the car.
    3. Task SENSOR_3 reads every 40 s the GPS position of the car.
    4. Task DISPLAY_1 produces every 12 s a summary of the information retrieved by the three sensor tasks.
    5. Finally, tasks DISPLAY_2 displays on a second screen the map of the current location of the car. This display is made on request by the driver every 6 s on the worst case.
  • We now write a C program that is running this periodic thread set. For such a purpose, we must replace stars in the init.c file by priority values and periods. Set priority level for each task according to Rate Monotonic.
  • Compile, test and try to understand the resulting scheduling. Is it the same than the one we had with Cheddar?