Chapter 10 Programming RealTime Abstractions RealTime Systems and

Chapter 10: Programming Real-Time Abstractions Real-Time Systems and Programming Languages © Alan Burns and Andy Wellings

Aim n Show languages support the programming of real-time abstractions Ø Ø Ø Periodic activities Sporadic activities Jitter control Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 2 of 75

Real-Time Threads in the RTSJ n n Unlike Ada, Real-Time Java explicitly distinguishes between threads and real-time threads. Real-time threads have the following attributes: Ø Ø Release parameters Scheduling parameters Memory parameters Processing group parameters Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 3 of 75

Release Parameters n n n The processing cost for each release and its blocking time Its deadline If the object is periodic or sporadic then an interval is also given Event handlers can be specified for the situation where the deadline is missed or the processing resource consumed is greater than the cost specified There is no requirement to monitor the processing time consumed by a schedulable object Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 4 of 75

Release. Parameters Class public class Release. Parameters implements Cloneable{ protected Release. Parameters(Relative. Time cost, Relative. Time deadline, Relative. Time blocking. Term, Async. Event. Handler overrun. Handler, Async. Event. Handler miss. Handler); . . . // methods public Relative. Time get. Cost(); public void set. Cost(Relative. Time cost); . . . } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 5 of 75

Scheduling Parameters n n n An empty class Subclasses allow the priority of the object to be specified and, potentially, its importance to the overall functioning of the application Although the RTSJ specifies a minimum range of real-time priorities (28), it makes no statement on the allowed values of the importance parameter Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 6 of 75

Other parameters n Memory. Parameters Ø n the maximum amount of memory used by the object in an associated memory area Ø the maximum amount of memory used in immortal memory Ø a maximum allocation rate of heap memory. Processing. Group. Parameters Ø allows several schedulable objects to be treated as a group and to have an associated period, cost and deadline Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 7 of 75

An extract from the Realtime. Thread Class package javax. realtime; public class Realtime. Thread extends java. lang. Thread implements Schedulable { public Realtime. Thread(); public Realtime. Thread(Scheduling. Parameters scheduling, Release. Parameters release, Memory. Parameters memory, Memory. Area area, Processing. Group. Parameters group, Runnable logic); . . . public void start(); public void release(); public static boolean wait. For. Next. Period(); public static boolean wait. For. Next. Release(); // note there are AIE interruptible versions of the above. . . } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 8 of 75

Periodic Tasks - Ada task body Periodic_T is Next_Release : Time; Release_Interval : Time_Span : = Milliseconds(. . . ); begin -- read clock and calculate the next -- release time (Next_Release) loop -- sample data (for example) or -- calculate and send a control signal delay until Next_Release; Next_Release : = Next_Release + Release_Interval; end loop; end Periodic_T; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 9 of 75

Periodic Task - POSIX n n n Similar structure to Ada Uses clock_nanosleep which is like delay until in Ada The parameter remaining_time indicates how much time left if thread signals ‘while asleep’ Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 10 of 75

Code #include <signal. h> #include <time. h> #include <pthread. h> #include <misc/timespec_operations. h> void periodic_thread() /* destined to be thread */ { struct timespec next_release, remaining_time; struct timespec thread_period; /* actual period */ /* read clock and calculate the next release time (next_release) */ Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 11 of 75

Code while(1) { /* sample data (for example) or calculate and send a control signal */ clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); add_timespec(&next_release, &thread_period); } } int init(){ pthread_attr_t attributes; pthread_t PT; /* thread attributes */ /* thread pointer */ pthread_attr_init(&attributes); /* default attributes */ pthread_create(&PT, &attributes, (void *)periodic_thread, (void *)0); } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 12 of 75

Periodic Task – Real-Time Java n Represented by a real-time thread with associated periodic release parameters and start time Ø Ø relative, or absolute Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 13 of 75

Periodic. Parameters class public class Periodic. Parameters extends Release. Parameters {. . . public Periodic. Parameters( High. Resolution. Time start, Relative. Time period, Relative. Time cost, Relative. Time deadline, Relative. Time blocking. Term, Async. Event. Handler overrun. Handler, Async. Event. Handler miss. Handler); // methods public Relative. Time get. Period(); public High. Resolution. Time get. Start(); public void set. Period(Relative. Time period); public void set. Start(High. Resolution. Time start); } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 14 of 75

A Simple Model of Periodic Threads public class Periodic extends Realtime. Thread { public Periodic(Periodic. Parameters P) {. . . }; public void run() { boolean deadline. Met= true; while(deadline. Me) { // code to be run each period. . . deadline. Met = wait. For. Next. Period(); } // a deadline has been missed, // and there is no handler. . . } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 15 of 75

Defining a periodic thread n n Loop required but not the explicit calculation of delay So for period 10 ms, deadline 5 ms, 1 ms execution time, starting at absolute time A: { Absolute. Time A = new Absolute. Time(. . . ); Periodic. Parameters P = new Periodic. Parameters( A, // start time new Relative. Time(10, 0), // period new Relative. Time(1, 0), // cost new Relative. Time(5, 0), // deadline null, null ); // no deadline miss/cost overrun handlers Periodic our. Thread = new Periodic(P); //create thread our. Thread. start(); // release it } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 16 of 75

Semantics of wait. For. Next. Period n n Complex, here just the main points given. On a DEADLINE MISS Ø Ø n If there are no handlers, wait. For. Next. Period (w. FNP) will not block the thread in the event of a deadline miss (if returns false immediately). The RTSJ assumes that in this situation the thread itself will undertake some corrective action Where the handler is available, the RTSJ assumes that the handler will take some corrective action and therefore it automatically deschedules the thread n (if appropriate) the handler reschedule thread If deadline met Ø w. FNP returns true at the next release time Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 17 of 75

Aperiodic and Sporadic Activities n Non-periodic activities are classified as either sporadic if there is a minimum inter-arrival time (MIT), otherwise aperiodic. Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 18 of 75

Aperiodics in Ada protected Aperiodic_Controller is procedure Interrupt; entry Wait_For_Next_Interrupt; -- requires pragmas to define the procedure -- to be an interrupt private Call_Outstanding : Boolean : = False; end Aperiodic_Controller; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 19 of 75

Aperiodics in Ada protected body Aperiodic_Controller is procedure Interrupt is begin Call_Outstanding : = True; end Interrupt; entry Wait_For_Next_Interrupt when Call_Outstanding is begin Call_Outstanding : = False; end Wait_For_Next_Interrupt; end Aperiodic_Controller; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 20 of 75

Client task body Aperiodic_T is begin loop Aperiodic_Controller. Wait_For_Next_Interrupt; -- action end loop; end Aperiodic_T; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 21 of 75

Tasks and Events n Two forms of computation Ø Ø n n n Tasks – long lived with state, they repeat Events – one-off, no state Events are said to be triggered, or fired, invoked, or delivered Interrupts are events Timing events happen when a defined clock reaches a specified value Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 22 of 75

Timing Events in Ada n n A means of defining code that is executed at a future point in time Does not need a task Similar in notion to interrupt handing (time itself generates the interrupt) Again a handler is used Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 23 of 75

Timing Events (cont’d) package Ada. Real_Time. Timing_Events is type Timing_Event is tagged limited private; type Timing_Event_Handler is access protected procedure(Event : in out Timing_Event); procedure Set_Handler(Event : in out Timing_Event; At_Time : Time; Handler: Timing_Event_Handler); procedure Set_Handler(Event : in out Timing_Event; In_Time: Time_Span; Handler: Timing_Event_Handler); Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 24 of 75

Timing Events (cont’d) function Is_Handler_Set(Event : Timing_Event) return Boolean; function Current_Handler(Event : Timing_Event) return Timing_Event_Handler; procedure Cancel_Handler(Event : in out Timing_Event; Cancelled : out Boolean); function Time_Of_Event(Event : Timing_Event) return Time; private. . . -- Not specified by the language. end Ada. Real_Time. Timing_Events; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 25 of 75

Time-triggered in POSIX n n n Via signals generated from timers One-shot and period timers can be created Can be associated with any clock Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 26 of 75

POSIX interface to timers #define TIMER_ABSTIME. . struct itimerspec { struct timespec it_value; /* first timer signal */ struct timespec it_interval; /* subsequent intervals */ }; typedef. . . timer_t; int timer_create(clockid_t clock_id, struct sigevent *evp, timer_t *timerid); /* Create a per-process timer using the specified clock as */ /* the timing base. evp points to a structure which contains */ /* all the information needed concerning the signal */ /* to be generated. */ Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 27 of 75

POSIX interface to timers int timer_delete(timer_t timerid); /* delete a per-process timer */ int timer_settime(timer_t timerid, int flags, const struct itimerspec *value, struct itimerspec *ovalue); /* Set the next expiry time for the timer specified. */ /* If flags is set to TIMER_ABSTIME, then */ /* the timer will expire when the clock reaches the /* absolute value specified by *value. it_value */ /* if flags is NOT set to TIMER_ABSTIME, then the timer will */ /* expire when the interval specified by value. it_value passes * /* if *value. it_interval is non-zero, then a periodic timer */ /* will go off every value->it_interval after */ /* value->it_value has expired */ /* Any previous timer setting is returned in *ovalue */ Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 28 of 75

POSIX interface to timers int timer_gettime(timer_t timerid, struct itimerspec *value); /* get the details of the current timer */ int timer_getoverrun(timer_t timerid); /* if real-time signals are supported, * / /* return the number of signals */ /* that have been generated by this timer but not handled */ /* /* /* All the above functions, except timer_getoverrun, return 0 */ if successful, otherwise -1. timer_getoverrun returns the */ number of overruns. When an error condition is returned */ by any of the above functions, a shared variable errno */ contains the reason for the error */ Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 29 of 75

Aperiodic and Sporadic In Java n n Aperiodics considered here Sporadics deferred Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 30 of 75

Aperiodic Parameters public class Aperiodic. Parameters extends Release. Parameters { public static final String arrival. Time. Queue. Overflow. Except; public static final String arrival. Time. Queue. Overflow. Ignore; public static final String arrival. Time. Queue. Overflow. Replace; public static final String arrival. Time. Queue. Overflow. Save; // constructors not shown public String get. Arrival. Time. Queue. Overflow. Behavior(); public void set. Arrival. Time. Queue. Overflow. Behavior( String behavior); . . . } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 31 of 75

A Simple Model of Aperiodic Threads public class Aperiodic extends Realtime. Thread { public Periodic(Periodic. Parameters P) {. . . }; public void run() { boolean deadline. Met= true; while(deadline. Me) { // code to be run each period. . . deadline. Met = wait. For. Next. Release(); } // a deadline has been missed, // and there is no handler. . . } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 32 of 75

Time Triggered Events in Real-Time Java n n n Unlike Ada, the handlers are scheduled The abstract Timer class defines the base class from which timer events can be generated All timers are based on a clock; a null clock values indicates that the Realtime. Clock should be used A timer has a time at which it should fire; that is release its associated handlers This time may be an absolute or relative time value If no handlers have been associated with the timer, nothing will happen when the timer fires Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 33 of 75

Timer package javax. realtime; public abstract class Timer extends Async. Event { // constructors protected Timer(High. Resolution. Time time, Clock clock, Async. Event. Handler handler); // methods public Release. Parameters create. Release. Parameters(); public void destroy(); public void disable(); public void enable(); public Clock get. Clock(); public Absolute. Time get. Fire. Time(); public void reschedule(High. Resolution. Time time); public void start(); public boolean stop(); } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 34 of 75

Timers II n n n Once created a timer can be explicitly destroyed, disabled (which allows the timer to continue counting down but prevents it from firing) and enabled (after it has been disabled) If a timer is enabled after its firing time has passed, the firing is lost The reschedule method allows the firing time to be changed Finally the start method, starts the timer going Any relative time given in the constructor is converted to an absolute time at this point; if an absolute time was given in the constructor, and the time has passed, the timer fires immediately Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 35 of 75

One Shot Timer package javax. realtime; public class One. Shot. Timer extends Timer { // constructors public One. Shot. Timer(High. Resolution. Time fire. Time, Async. Event. Handler handler); // assumes the default real-time clock public One. Shot. Timer(High. Resolution. Time fire. Time, Clock clock, Async. Event. Handler handler); // fire. Time is based on the clock parameter } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 36 of 75

Periodic Timer package javax. realtime; public class Periodic. Timer extends Timer { // constructors public Periodic. Timer(High. Resolution. Time start, Relative. Time interval, Async. Event. Handler handler); public Periodic. Timer(High. Resolution. Time start, Relative. Time interval, Clock clock, Async. Event. Handler handler); // methods public Release. Parameters create. Release. Parameters(); public void fire(); // deprecated public Absolute. Time get. Fire. Time(); public Relative. Time get. Interval(); public void set. Interval(Relative. Time interval); } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 37 of 75

Controlling I/O Jitter n A periodic control task needs to take input from the environment is a very regular way, and similarly produce output with little variation in time Ø Ø Input jitter Output jitter Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 38 of 75

Controlling Input and Output Jitter n n Sensors and actuators are read and written by asynchronous event handlers Work done by a task Processing real-time thread 0 Max Input Jitter Minimum Latency Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 39 of 75 Deadline (Max latency)

Controlling jitter in Ada n n n Use a timing event for input and a separate timing event for output Use a task for processing the input data to produce the output Assume a period of 40 ms in a controller Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 40 of 75

Sensor Reader spec protected type Sensor_Reader is pragma Interrupt_Priority (Interrupt_Priority’Last); procedure Start; entry Read(Data : out Sensor_Data); procedure Timer(Event : in out Timing_Event); end Sensor_Reader; Input_Jitter_Control : Timing_Event; Input_Period : Time_Span : = Milliseconds(40); Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 41 of 75

Sensor Reader body protected body Sensor_Reader is procedure Start is begin Reading : = Read_Sensor; Next_Time : = Clock + Input_Period; Data_Available : = True; Set_Handler(Input_Jitter_Control, Next_Time, Timer'Access); end Start; entry Read(Data : out Sensor_Data) when Data_Available is begin Data : = Reading; Data_Available : = False; end Read; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 42 of 75

Sensor Reader body procedure Timer(Event : in out Timing_Event) is begin -- Reading from sensor interface Data_Available : = True; Next_Time : = Next_Time + Input_Period; Set_Handler(Input_Jitter_Control, Next_Time, Timer'Access); end Timer; end Sensor_Reader; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 43 of 75

Output jitter control n n A type is also defined for output jitter control (Actuator_Writer) Assuming a deadline of 30 ms (period is 40 ms) and max output jitter of 4 ms: SR. start; -- of type Sensor_Reader delay 0. 026; -- ie 26 ms later AW. start; -- of type Actuator_Writer Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 44 of 75

Controlling task type Control_Algorithm (Input : access Sensor_Reader; Output : access Actuator_Writer); task body Control_Algorithm is Input_Data : Sensor_Data; Output_Data : Actuator_Data; begin loop Input. Read(Input_Data); -- process data; Output. Write(Output_Data); end loop; end Control_Algorithm; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 45 of 75

Controlling jitter in POSIX n n Uses timers and threads Following example used three threads with offset release times Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 46 of 75

Three Thread Solution Output thread Processing thread Input thread 0 Max Input Jitter Minimum Latency Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 47 of 75 Deadline (Max latency)

POSIX code typedef struct { struct timespec start; struct timespec period; struct timespec max_input_jitter; struct timespec min_latency; struct timespec deadline; } parameters; void sensor_thread(parameters *params) /* destined to be thread that reads the sensor*/ { struct timespec next_release, remaining_time; /* wait until start time */ next_release = params->start; clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 48 of 75

POSIX code while(1) { /* read sensor data and store in a global data protected by a mutex */ add_timespec(&next_release, &params->period); clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 49 of 75

POSIX code void processing_thread(parameters *params) /* destined to be thread that processes the sensor data*/ { struct timespec next_release, remaining_time; /* wait until first release time */ add_timespec(&next_release, &(params->start), &(params->max_input_jitter)); clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 50 of 75

POSIX code while(1) { /* get data written by input_thread, process data and write the value to be written to the actuator in global data - protected by a mutex */ add_timespec(&next_release, &params->period); clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); /* code to be executed each period here */ } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 51 of 75

POSIX code void actuator_thread(parameters *params) /* destined to be thread that writes to the actuator */ { struct timespec next_release, remaining_time; /* wait until first release time */ add_timespec(&next_release, &params->start, &params->min_latency); clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 52 of 75

POSIX code while(1) { /* get data written by processing_thread, process data and write the value to the actuator */ add_timespec(&next_release, &params->period); clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_release, &remaining_time); /* code to be executed each period here */ } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 53 of 75

POSIX code void init(){ parameters P; struct timespec now; struct timespec init_time; int status; pthread_attr_t attributes_input; /* thread attributes */ pthread_t PTInput; /* thread pointer */ pthread_attr_init(&attribute_input); /* default attributes */ pthread_create(&PTInput, &attribute_input, (void *) sensor_thread, &P); // Similarly for the other threads } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 54 of 75

Controlling Input and Output Jitter n n Sensors and actuators are read and written by asynchronous event handlers The handlers can be given appropriate priorities and deadlines to ensure required jitter constraints are met. Output ASEH Processing real-time thread Input ASEH 0 Max Input Jitter Minimum Latency Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 55 of 75 Deadline (Max latency)

The Sensor Reader public class Sensor. Reader extends Async. Event. Handler { public Sensor. Reader() { super(); } public void handle. Async. Event() { Data =. . . ; synchronized(this) { data. Available = true; notify. All(); } } public synchronized Data get. Data() throws Interrupted. Exception { while(data. Available == false) wait(); data. Available = false return Data; . . . } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 56 of 75

The Control Processing Thread public class Control. System extends Realtime. Thread { public Control. System(Sensor. Reader S, Actuator. Writer A) { super(); SR = S; AW = A; } public void run() { while(true) { try { D = SR. get. Data(); // Process data AW. write. Data(D); } catch (Interrupted. Exception ie) {} } } private int D; private Sensor. Reader SR; private Actuator. Writer AW; } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 57 of 75

The Main Program public class Main { public static void main (String [] args) { Absolute. Time start = Clock. get. Realtime. Clock(). get. Time(); Relative. Time period = new Relative. Time(40, 0); Relative. Time max. Input. Jitter = new Relative. Time(2, 0); Relative. Time min. Latency = new Relative. Time(26, 0); Sensor. Reader S = new Sensor. Reader(); Periodic. Timer PT 1 = new Periodic. Timer(start, period, S); start = start. add(min. Latency); Actuator. Writer A = new Actuator. Writer(); Periodic. Timer PT 2 = new Periodic. Timer( start, period, A); Control. System CS = new Control. System(S, A); CS. start(); PT 1. start(); PT 2. start(); } } Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 58 of 75

Other Approaches to TS n The following slides will consider other approaches to supporting Temporal Scopes Ø Euclid Ø Pearl Ø DSP Ø Esterel Ø Giotto Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 59 of 75

Real-Time Euclid 1. periodic frame. Info first activation time. Or. Event 2. at. Event condition. Id frame. Info n The clause frame. Info defines the periodicity of the process (including the maximum rate for sporadic processes). n The simplest form this can take is an expression in real-time units: frame real. Time. Expn n The value of these units is set at the beginning of the program Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 60 of 75

Periodic Process n n n A periodic process can be activated for the first time by Ø having a start time defined Ø waiting for an interrupt to occur Ø waiting for either of above The syntax for time. Or. Event must, therefore, be one of the following at. Time real. Time. Expn at. Event condition. Id at. Time real. Time. Expn or at. Event condition. Id is a condition variable associated with an interrupt; it is also used with sporadic processes Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 61 of 75

RT Euclid: Example n A cyclic temperature controller with periodicity 60 units (every minute if the time unit is set to 1 second) which become active after 600 units or when a start. Monitoring interrupt arrives real. Time. Unit : = 1. 0 % time unit = 1 seconds var Reactor: module % Euclid is module based var start. Monitoring : activation condition at. Location 16#A 10 D % This defines a condition variable which is % mapped onto an interrupt process Temp. Controller : periodic frame 60 first activation at. Time 600 or at. Event start. Monitoring % import list % % execution part Note: no loop; scheduler % controls the activation end Temp. Controller end Reactor Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 62 of 75

Pearl n n n Provides explicit timing information concerning the start, frequency and termination of processes EVERY 10 SEC ACTIVATE T To activate at a particular point in time (say 12. 00 noon each day): AT 12: 00 ACTIVATE LUNCH A sporadic task, S, released by an interrupt, IRT, is defined by WHEN IRT ACTIVATE S; Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 63 of 75

Pearl n n n or if an initial delay of one second is required: WHEN IRT AFTER 1 SEC ACTIVATE S; A task in Pearl can be activated by a time schedule or an interrupt but not both: AFTER 10 MIN ALL 60 SEC ACTIVATE Temp. Controller; WHEN start. Monitoring ALL 60 SEC ACTIVATE Temp. Controller; The term ALL 60 SEC means repeat periodically, after the first execution, every 60 seconds Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 64 of 75

DPS n n Whereas Pearl, and RT Euclid have associate temporal scopes with processes, and, therefore, necessitate the specification of timing constraints on the process itself, other languages such as DPS provide local timing facilities that apply at the block level In general, a DPS temporal block (scope) may need to specify three distinct timing requirements (these are similar to the more global requirements discussed earlier): Ø delay start by a known amount of time; Ø complete execution by a known deadline; Ø take no longer than a specified time to undertake a computation Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 65 of 75

DPS: Coffee Making Example get_cup put_coffee_in_cup boil_water put_water_in_cup drink_coffee replace_cup n n n Instant coffee The act of making a cup of coffee should take no more than 10 minutes; drinking it is more complicated A delay of 3 minutes should ensure that the mouth is not burnt The cup itself should be emptied within 25 minutes (it would then be cold) or before 17: 00 (that is, 5 o'clock and time to go home) Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 66 of 75

DPS: Coffee Example n Two temporal scopes are required: start elapse 10 do get_cup put_coffee_in_cup boil_water put_water_in_cup end start after 3 elapse 25 by 17: 00 do drink_coffee replace_cup end Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 67 of 75

DPS: Coffee Example n n For a temporal scope that is executed repetitively, a time loop construct is useful: from <start> to <end> every <period> For example, many software engineers require regular coffee throughout the working day: from 9: 00 to 16: 15 every 45 do make_and_drink_coffee Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 68 of 75

Esterel Synchronous Hypothesis: Ideal systems produce their outputs synchronously with their inputs n Hence all computation and communication is assumed to take zero time (all temporal scopes are executed instantaneously) module periodic; input tick; output result(integer); var V : integer in loop await 10 tick; -- undertake required computation to set V emit result(v); end Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 69 of 75

Esterel n n n One consequence of the synchronous hypothesis is that all actions are atomic This behaviour significantly reduces nondeterminism Unfortunately it also leads to potential causality problems signal S in present S else emit S end This program is incoherent: if S is absent then it is emitted; on the other hand if it were present it would not be emitted A formal definition of the behavioral semantics of Esterel helps to eliminate these problems Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 70 of 75

Giotto n n n A language for control applications Output produced at deadline, not before A task is logically executing from release to deadline Example follows, note timing events can be used to produce output Also hardware can be used to only release output at the required time Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 71 of 75

Example – pseudo code sensor port temperature type integer range 10. . 500 port pressure type integer range 0. . 750 actuator port heater type (on, off) port pump type integer 0. . 9 input T 1 type integer range 10. . 500 PI type integer range 0. . 750 output TO type (on, off) PO type integer 0. . 9 Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 72 of 75

Example – pseudo code task temperature input TI output TO temperature_controller task pressure input PI output PO pressure_controller driver temperature_sensor source temperature destination TI function read_temperature driver pressure_sensor source pressure destination PI function read_pressure driver heater_actuator source TO destination heater function write_heater driver pump_actuator source PO destination pump function write_pump mode normal period 20 ports TO, PO frequency 2 invoke temperature driver temperature_sensor frequency 1 invoke pressure driver pressure_sensor frequency 2 update heater_actuator frequency 1 update pump_actuator start normal Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 73 of 75

Summary n n The right abstractions allow real-time software to be produced efficiently But abstractions need to be the right ones, and not hide key properties (eg temporal ones) Ada and Java attempt to stay general purpose Esterel, Giotto etc provide a more restricted computation model Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 74 of 75

Summary n Chapter has addressed the key abstractions of Ø Ø Ø Periodic tasks Sporadic and aperiodic tasks Jitter constrained tasks Real-Time Systems and Programming Languages: © Alan Burns and Andy Wellings 75 of 75