The Hardware Platform

Introduction to Real-Time Sys­

tems

"On fait la science avec des faits, comme on fait une maison avec des pierres : mais une accumulation de faits n'est pas plus une science qu’un tas de pierres n’est une maison."

(“Science is built up of facts, as a house is with stones. But a collection of facts is no more a science than a heap of stones is a house.”) _____________________________________________________ Henri Poincaré

“There’s a lady who’s sure ail that glitters is gold And she ’s buying a stairway to heaven. When she gets there she knows, if the stars are ail close With a Word she can get what she came for. Andshe’s buying a stairway to heaven."

Led Zeppelin

Contents___________________________________________________

2.1 Introduction... 10 2.2 The Application Layer... 13

2.2.1 Characterization of a Real-Time Task... 13 2.2.2 Sequential and Parallel tasks... 18 2.2.3 Static and Dynamic Task Systems... 19

2.3 The Real-Time Operating System... 21

2.3.1 TheScheduler... 22 2.3.2 Time Management... 25 2.3.3 Discrete-Time Systems... 27

2.4 The Hardware Platform... 29

2.4.2 Memory Architecture... 30

2.5 The Problem of Task Préemptions and Migrations... 33 2.6 Outline and Goals of the Thesis... ... 34

Abstract

Nowadays, many applications hâve real-time requirements. These Systems for which the time at which the results are available is as important as the correctness of these results, are referred to as real-time Systems. We can find such Systems in domains as diversified as the télécommunications, bioengineering, chemistry, nuclear, spatial or automotive in- dustry. The potential applications of the real-time scheduling theory are therefore large and manifold. However, they ail hâve common déterminant properties that can easily be enumerated and modeled.

In this first introduction chapter, we propose a brief description of the real-time Sys­ tems. Of course, entire books are dedicated to this subject and we do not intend to cover each and every aspect of such a large topic. However, we présent some ex amples of these Systems that are more widely used every day. We provide the vocabulary needed to understand the following chapters and explain how these Systems can be modeled so as to enable researchers to design efficient real-time scheduling algorithms. Some of the challenges in real-time scheduling theory are also introduced.

2.1 Introduction

In the first chapter, we briefly introduced the concept of real-time scheduling for mul- tiprocessor Systems using the example of a manager in a company organizing the work of his team. We however pointed ont that this situation is not the main purpose of the real-time scheduling theory. In fact, the results presented in this thesis essentially intend to be utilized in computing Systems and more particularly in embedded Systems. Indeed, the number of such Systems is growing every day. We find them in almost any device with automatic features such as cars, airplanes, smartphones, télévisions, radio receivers, microwave ovens,...

But what is exactly an embedded System?

Barr [2007] defines an embedded System as “a combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a ded-icated function.” The keywords here are “dedicated function”. Hence, an embedded System is often contrasted with general purpose computers which can be programmed by the end-user to execute any kind of applications [Heath 2003; Barr 2007]. From this définition, we should understand that an embedded System is not limited to small devices such as phones or radio receivers. It can be any System with a well defined purpose such as the température controller of a power plant or the air traffic control System in an airport.

Nowadays, many embedded Systems hâve real-time requirements. That is, they hâve to carry out tasks within fixed amounts of time which will later be defined as being the task deadlines. Such Systems that we will refer to as real-time Systems are divided in three broad categories:

Hard Real-Time Systems. In hard real-time Systems, we cannot afford to miss any task deadline. If a task missed its deadline then the security of the System, the environ­ ment or the user would be jeopardized. Typical examples of hard real-time Systems are the medical implants such as pacemakers which keeps the patient healthy, or the terriperature controller of a power plant which may ultimately cause the explosion of the central if the température is not regulated at a predefined frequency. Other examples are the anti-lock braking System (ABS) or the airbag controller in a car which both hâve to react sufficiently fast to prevent the passengers from being huit in case of an emergency braking or an accident. The results after deadline misses in hard real-time Systems are not always so catastrophic. Nevertheless, the total failure of the System may lead to huge money loss due to repair and maintenance

t'.

2.1. INTRODUCTION

costs.

Soft Real-Time Systems. A soft real-time System is the complété opposite of a hard real- time System. If a task misses its deadline in a soft real-time System then it does not directly impact the System safety and the application can simply keep on running. Even though the deadlines do not hâve to be mandatorily respected, these Systems are real-time as they use real-time scheduling techniques to ensure some quality of service. Hence, application designers can for instance provide some tasks with higher priorities on other tasks and thus favor their complétions.

Firm Real-Time Systems. Firm real-time Systems are neither soft nor hard real-time Systems but are lying somewhere in-between. In firm real-time Systems, tasks are allowed to miss some deadlines. However, the number of successive deadline misses is upper bounded in order to keep a certain quality of service, lypically, firm real-time Systems are Systems that hâve to keep a given quality of service to please the end-user but will not cause failure or endanger the user safety if some task deadlines are missed. Audio-video decoders such as DVD or Blu-Ray players are typical examples of firm real-time Systems. Indeed, ending the decoding of an audio or video frame a little bit later than the predefined deadline will dégradé the quality of service experienced by the user but it will not jeopardize its safety neither the correct operation of the System.

In this thesis, we will only consider the scheduling of hard real-time Systems. We therefore présent scheduling algorithms ensuring that no deadline will ever be missed. Note that scheduling algorithms for hard real-time Systems also work for the scheduling of soft or firm real-time Systems since real-time constraints are stronger in hard than in firm or soft real-time environments. Thus, the solutions presented in this thesis can be used for the scheduling of any kind of real-time System. Nonetheless, because ail task deadlines do not hâve to be necessarily respected, soft or firm real-time Systems may envisage to overload the System, thereby executing more tasks than normally accepted by the platform. For the same reason, they may consider to use techniques improving the response time of non real-time tasks which might be executed on the same platform than the real-time application [Caccamo and Buttazzo 1998; Buttazzo and Caccamo 1999; Bernat et al. 2001 ; Liu et al. 2006]. However, these practices might cause deadline misses. They are therefore completely prohibited with hard real-time Systems.

Figure 2.1 : Real-time System with an RTOS acting as an interface between the application layer and the hardware platform.

• An application layer which is constituted of ail the tasks that should be executed. • A real-time operating System (RTOS) which makes the scheduling decisions and

provides services to the application layer (e.g., communication tools, timers ...). • A hardware platform which includes the processors (among other things such as

memories, communication networks, etc.).

As shown on Figure 2.1, the real-time operating System acts as an interface between the hardware platform and the tasks of the application layer. Hence, it is the real-time op­ erating System that décidés when a task can be executed on which processor (sometimes called CPU for central processing unit). It is also the operating System that configures and manages the platform and the services it may provide. Therefore, the application can be developed independently of the platform on which it will run since the tasks never directly interact with the hardware and only the operating System needs to know the hard­ ware properties. This three-layers model accelerates the product development cycle since