Fundamentals of Realtime Systems

September 14 by Bina

We undertsand from earlier discussions that a realtime is required to produce correct response within a pre-determined deadline or time limit.

Besides the time limits, here are some common characteristics of RTS:

1. RTS are often multitasking. Several processes cooperate to carry out the overall job. Divide RTS problem into tasks as a design strategy.
2. The RTS tasks are often periodic in nature. E.g. Fuel injection system in an automobile
3. Tasks are deadline driven. Deadlines can be starting deadline or ending deadline or both. Can you think of examples for these tasks? Look in the automobile domain.
4. RTS scheduling is a critical component in the design of an RTS. Whereas general purpose operating systems operate on FCFS scheduling, an RTS uses a variety of scheduling to meet the realtime requirements.
5. Tasks can be assigned priority allowing for priority-based scheduling.
6. RTS allow event-driven preemption and are often involved with handling events. Events arise from interrupt signals indicating the arrival data at an input port or ticking of a hardware clock, or an error status alarm.
7. Unpredictability in inputs/stimulus: Being event-driven, RTS are required to handle unpredictable nature of their environment.

Functional Design Requirements

Describes the explicit operations to be performed by the RTS. If you consider the climate control system in an automobile:

Sense temperature: T1
Compare with user set temperature: Tset
If T1 > Tset, start cold air fan 
Else if T1 < Tset, start hot air fan

Non-functional Requirements

Describes the quality of the operations.
Example: Need to control temperature within 0.3 degree error

• Accuracy
• Precision
• Reliability
• Safety
• Response time
• Responsiveness
• Predictability
• Deadlines

Task Characteristics

Each task Ti is characterized by the following temporal parameters:

• Precedence constraints: specify any tasks need to precede other tasks.
• Release or arrival time: r(i,j): jth instance of ith task
• Response time: time between activation and completion
• Absolute deadline: instant by which task must complete
• Relative deadline: maximum allowable response time
• Period Pi: maximum length of intervals between the release times of consecutive tasks.
• Execution time: the maximum amount of time required to complete a instance of the task assuming all the resources are available.

Lets Design an RTS

So far we have discussed the stringent requirements. Now lets discuss some simple design strategies.

Simple Kernels: Polled Loop

Say a kernel needs to process packets that are transferred into the DMA (Direct Memory Access) and a flag is set after transfer:

for(;;) {
           if (packet_here)
           { 
               process_data();
               packet_here=0;
            }
}

Excellent for handling high-speed data channels, a processor is dedicated to handling the data channel. Disadvantage: cannot handle bursts.

Simple Kernels: Cyclic Executive

Illusion of simultaneity by taking advantage of relatively short processes in a continuous loop:

for(;;) {
          process_1();
          process_2();
          …
          process_n();
}

Different rate structures can be achieved by repeating tasks in the list:

for(;;) {
          process_1();
          process_2(); process_2();
          process_3();
}

Cyclic Executive: Interactive Games

Space invaders:

for(;;) {
           check_for_keypressed();
           move_aliens();
           check_for_keypressed();
           check_collision();
           check_for_keypressed();
           update_screen();
         }
}

check_keypressed() checks for three button pressings: move tank left or right and fire missiles. If the schedule is carefully constructed we could achieve a very efficient game program with a simple kernel as shown above.

Finite State Machine: Co-Routine Kerenls

Consider two processes (co-routines) each with logic defined by respective FSM.

void process_a(void){
for(;;) {
  switch (state_a) {
   case 1: phase_a1(); |
   case 2: phase_a2(); |
….
   case n: phase_an();}}}

void process_b(void){
for(;;) {
  switch (state_b) {
   case 1: phase_b1(); |
   case 2: phase_b2(); |
….
   case n: phase_bn();}}}

Interrupt Driven Systems

Main program is a simple loop. Various tasks in the system are schedules via software or hardware interrupts; Dispatching performed by interrupt handling routines. Hardware and software interrupts.

Hardware: asynchronous Software: typically synchronous

Executing process is suspended, state and context saved and control is transferred to ISR (interrupt service routine)

void main() { 
   init();
   while(TRUE);
}

void int1(void){
  save (context);
  task1();
  retore (context);}

void int2(void){
  save (context);
  task1();
  restore (context);}

What Next? Scheduling the tasks