+ All Categories
Home > Documents > Slide 3: Real-Time Scheduling By: Dr. Mouaaz Nahas Embedded Systems 802455 Umm Al-Qura University...

Slide 3: Real-Time Scheduling By: Dr. Mouaaz Nahas Embedded Systems 802455 Umm Al-Qura University...

Date post: 15-Dec-2015
Category:
Upload: conor-churn
View: 214 times
Download: 0 times
Share this document with a friend
Popular Tags:
35
Slide 3: Real-Time Scheduling By: Dr. Mouaaz Nahas Embedded Systems 802455 Umm Al-Qura University Electrical Engineering Department 1
Transcript

Slide 3: Real-Time Scheduling

By: Dr. Mouaaz Nahas

Embedded Systems802455

Umm Al-Qura University

Electrical Engineering Department

1

Development Life Cycle (Revision)

2Development Life Cycle

(Waterfall Model)

Embedded system development process

Once the system requirements have been clearly defined and well documented, the first step in the design process is to design the overall system architecture.

Architecture of a system basically represents an overview of the system components (i.e. sub-systems) and the interrelationships between these different components.

3

Embedded system development process (Cont.)

Since embedded engineers are concerned with hardware and software design aspects of the system, they must decide on both the hardware and the software architectures of the intended design.

Douglass (2004) defines architecture as:

“the set of strategic design decisions that affect the structure, behaviour, or functionality of the system as a whole”.

4Douglass, B., P. (2004) “Real Time UML: Advances in The UML for Real-Time Systems”, Addison-Wesley

Embedded system development process (Cont.)

Determining the most appropriate architecture is a key requirement in the design and implementation processes of embedded system.

Embedded systems are designed and implemented as a collection of processes (called tasks).

Tasks share the system resources and interact with the system and/or environment in which they operate.

5

Embedded system development process (Cont.)

The various possible system architectures are then characterised in terms of these tasks.

In embedded system:– If the tasks are invoked periodically under the control of

timer, the system architecture may be described as time-triggered.

– If the tasks are invoked as a response to aperiodic external events, then the system architecture may be described as event-triggered.

6

Embedded system development process (Cont.)

Once the software architecture is identified, the process of implementing that architecture should take place.

This can be achieved using a lower-level system representation such as an operating system or a scheduler.

A scheduler is a very simple operating system for an embedded application.

7

Embedded system development process (Cont.)

As with desktop operating systems, a scheduler has the responsibility to manage the computational and data resources in order to meet all temporal and functional requirements of the system.

A vital role of the scheduler is to organise the operation of the tasks running in the system, so as to guarantee that all timing requirements will be met.

Building the scheduler would require a scheduling algorithm.8

Embedded system development process (Cont.)

Scheduling algorithm provides the set of rules that determine the order in which the tasks will be executed by the scheduler during the system operating time.

Or, scheduling algorithm is the set of rules that, at every moment in the system run-time, determines which task must be allocated the resources to execute.

9

Embedded system development process (Cont.)

Both system architecture and scheduling algorithm are decided in the “design” stage of the embedded system.

In addition, schedule design is also performed in the “design” stage. This includes definition of tasks parameters, such as: task order, initial delay (i.e. phase or offset) and period of each task.

10

Embedded system development process (Cont.)

After the design of the system, implementation will start.

Implementation is the process of translating (converting) design components into actual hardware or software systems.

Embedded systems developers are often concerned with the software implementation of the system.

11

Embedded system development process (Cont.)

Software implementation is the process of converting system specifications into an executable system.

Koch (1999) described the implementation of a system as:

“the way in which the software program is arranged to meet the system specifications”.

12

Koch, B. (1999) “The Theory of Task Scheduling in Real-Time Systems: Compilation and Systematization of the Main Results”, Studies thesis, University of Hamburg.

Real-time tasks

The most important software entity of the real-time embedded system is the process or task which is a computation that is executed by the CPU in a sequential manner.

Most embedded systems are assembled from collections of tasks.

For example, complex systems (such as aircraft control) may have hundreds of tasks, possibly distributed across a number of CPUs (uC’s).13

Real-time tasks (Cont.)

Real-time tasks are divided into three main categories:– Periodic tasks: tasks implemented as

functions which are called at regular intervals (e.g. every millisecond) during some or all of the time that the system is active.

14

T

Timea1 d1 a2 d2 an dna3 d3

Period

Deadline

Starting time

Real-time tasks (Cont.)

– Aperiodic tasks: tasks implemented as functions which may be activated if a particular event takes place. For example, an aperiodic task might be activated when a switch is pressed.

15

Timea1 d1 a2 d2

Starting time (random) Deadline

Real-time tasks (Cont.)

Sporadic tasks: tasks implemented as functions which are called repeatedly at variable intervals. However, the minimum interval between any two successive occurrences of the sporadic task is known.

16

Tm

Timea1 d1 a2 d2 a4 d4a3 d3

Minimum period

Timing constraints

The typical timing constraints associated with each task in real-time systems are:

– Release time: the time after which a task can start its execution. This parameter is sometimes called request time, ready time, or arrival time.

– Deadline: the time before which a task must complete its execution.

17

Timing constraints (Cont.)

Some other timing parameters, which are used to characterise tasks in real-time systems, are:

– Start time: the time at which a task starts its execution.

– Completion time: the time at which a task completes its execution. This parameter is also called finishing time.

18

Timing constraints (Cont.)

– Execution time: the time taken by the processor to execute a task without interruption. This parameter is also called computation time.

– Lateness: the delay between the deadline and the completion time. A task is considered late if its lateness value is positive (completion time > deadline).

19

Timing Jitter

Jitter is a term which describes variations in the timing of activities.

20

Timing Jitter

Jitter is a term which describes variations in the timing of activities.

21

Timing Jitter (Cont.)

For some periodic tasks, such variations are more important than the absolute deadline.

For example, suppose that some activity should occur at times: t = {1.0 ms, 2.0 ms, 3.0 ms, 4.0 ms, 5.0 ms, 6.0 ms, 7.0 ms, …}.

22

Timing Jitter (Cont.)

Suppose, instead, that the activity occurs at times: t = {11.0 ms, 12.0 ms, 13.0 ms, 14.0 ms, 15.0 ms, 16.0 ms, 17.0 ms, …}.

In this case, the activity has been delayed (by 10 ms).

For some applications – such as data, speech or music playback (for example) – this delay may make no measurable difference to the user of the system.

23

Timing Jitter (Cont.)

However, suppose that – for a data playback system – same activities were to occur as follows:

t = {1.0 ms, 2.1 ms, 3.0 ms, 3.9 ms, 5.0 ms, 6.1 ms, 7.0 ms, …}.

In this case, there is a variation in the activity timing which is referred to as jitter.

In real-time embedded systems, various system activities are identified as tasks that need to be performed at precise timing without delays or, more importantly, jitter. 24

Timing Jitter (Cont.)

As previously mentioned, predictability is one of the most important objectives of real-time embedded systems.

One way in which predictable behaviour manifests (proves) itself is in low levels of task jitter.

Jitter can have detrimental impacts on the performance of many applications, particularly those involving period sampling and/or data generation (e.g. data acquisition, data playback and control systems).25

Timing Jitter (Cont.)

For example, Cottet and David (1999) show that – during data acquisition tasks – jitter rates of 10% or more can introduce errors which are so significant that any subsequent interpretation of the sampled signal may be rendered meaningless.

26

Cottet, F. and David, L. (1999), “A solution to the time jitter removal in deadline based scheduling of real-time applications”, 5th IEEE Real-Time Technology and Applications Symposium - WIP, Vancouver, Canada, pp. 33-38.

Timing Jitter (Cont.)

Similarly, Jerri (1977) discusses the serious impact of jitter on applications such as spectrum analysis and filtering.

27Jerri, A.J. (1977), “The Shannon sampling theorem: its various extensions and applications a tutorial review”, Proc. of the IEEE, Vol. 65, pp. 1565-1596.

Hardware architectures

The success of an embedded design depends on the right selection of the hardware platform(s) and the software environment used with the hardware.

Hardware architecture relates mainly to the type of the processor (or microcontroller) platform(s) used and the structure of the various hardware components that are comprised in the system.

28

Software architectures

After deciding on the hardware architecture, an embedded application requires an appropriate form of software architecture.

Locke (1992) states that:“The [software] architecture must be capable of providing a provable prediction of the ability of the application design to meet all of its time constraints.”

29

Locke, C.D. (1992), “Software architecture for hard real-time applications: cyclic executives vs. fixed priority executives”, Real-Time Systems, Vol. 4, pp. 37-52.

Event-triggered (ET) architecture

Tasks are invoked as a response to aperiodic events.

The system takes no account of time: instead, the system is controlled purely by the response to external events, typically represented by interrupts which can arrive at anytime.

Generally, ET solution is recommended for applications in which sporadic data messages (with unknown request times) are exchanged in the system.

30

Time-triggered (TT) architecture

Tasks are invoked periodically at specific time intervals which are known in advance.

The system is usually driven by a globally synchronised clock which is linked to a hardware timer that overflows at specific time instants to generate periodic interrupts.

TT solution can suit many control applications where the data messages exchanged in the system are periodic.

31

Understanding ET and TT: hospital doctor example

A hospital doctor is required to look after a group of seriously ill patients overnight, with a support of some nursing staff.

With ET solution, the doctor might arrange to go to sleep and only if a significant problem occurs with one patient a nurse can waken him up to deal with the problem.

In TT solution, the doctor might set his alarm to ring every hour. 32

Understanding ET and TT: hospital doctor example (Cont.)

When the alarm rings, the doctor wakes up and begins to check the status of all patients in sequence before going to sleep for the rest of the hour.

Using ET solution may cause serious problems. For example, assume that a minor problem occurs with one patient while the doctor is asleep and the nursing staff decide not to waken the doctor but to solve the problem themselves.

33

Understanding ET and TT: hospital doctor example (Cont.)

Few hours later, several patients have minor problems after which the nurses decide to wake the doctor up to look at those problems. Once the doctor sees the patients, he realises that some of them have severe problems and they need surgery.

One consequence of this process is that before the doctor can deal with the first patient, the second one gets very close to death, and so on.

34

Understanding ET and TT: hospital doctor example (Cont.)

One implication of this process is that before the doctor can deal with the first patient, the second one gets very close to death, and so on.

With a TT solution, where the doctor visits all patients at hourly intervals, each patient will be checked and appropriate treatment is hence arranged before serious problems arise. With this process, the doctor’s workload is spread out equally throughout the night making all patients survive without difficulty.

35


Recommended