Abstract

Catastrophes that lead to the loss of human life can be a result of software failure in cars, planes, house appliances etc. Therefore, to reduce such catastrophes, there is need for safety critical scheduling algorithms for real time operating systems. This project investigates operating systems scheduling. We evaluatehow scheduling algorithms have been implemented in some of the existing operating systems with ECos, LynxOS, RTLinux and VxWorks as our case studies. Using POSIX, we install ECOS on Windows XP platform. We use Virtualization to patch Red Hat 7.1 Kernel with RTLinux Kernel that implements Earliest Deadline First and Rate Monotonic Analysis algorithms. The algorithms arecommonly utilised for schedulingin safety critical real time systems.

Contents 1. Introduction.................................................................................................................7 1.1. Overview of Operating Systems (OS)..................................................................7 1.1.1. Operating System Definition.................................................................7 1.1.2. Operating System as Resource manager...............................................8 1.1.3. Operating system as control program...................................................9 1.2. Types of Operating systems................................................................................9 1.3. General Purpose Systems VS Embedded Systems............................................11 1.3.1. General Purpose Systems....................................................................11 1.3.2. Embedded Systems (EMS)...................................................................11 1.4. Real-Time EMS..................................................................................................12 1.5. Hard Real Time VS Soft Real Time Operating Systems.....................................13 2. Scheduling..................................................................................................................15 2.1. Overview of Scheduling....................................................................................15 2.2. Types of Operating System Schedulers............................................................16 2.2.1. Long-term Scheduler...........................................................................16 2.2.2. Mid-term Scheduler.............................................................................16 2.2.3. Short-term Scheduler..........................................................................16 2.3. How Scheduling Works.....................................................................................17 2.4. Scheduling Algorithms......................................................................................17 2.4.1. Scheduling Algorithms for Real Time OS.............................................18 2.5. Safety Critical Scheduling Algorithms...............................................................18 2.5.1. Rate Monotonic Algorithm (RMA).......................................................19 2. 5.2. Earliest Deadline First (EDF)................................................................19 3. Case Study AECOS...............................................................................................21 3.1. Overview of ECos..............................................................................................21

3.2. ECos Implementation of CPU scheduling.........................................................21 3.2.1. Bitmap scheduling...............................................................................22 3.2.2. MLQ scheduling...................................................................................22 3.3. IS ECos a Safety Critical OS................................................................................23 3.4. Ecos Installation using POSIX on Window XP...................................................23 3.4.1. POSIX....................................................................................................23 3.4.2. Cygwin .................................................................................................24 3.4.3. eCos on Windows XP Platform............................................................24 3.4.4. eCos Configuration Tool......................................................................25 3.4.5. Selecting the Kernel Scheduler............................................................28 3.5. Industry deployment of ECos............................................................................29 4. Case Study B-RTLinux and VxWorks..................................................................30 4.1. Scheduling Reviewed........................................................................................30 4.2. RTLinux..............................................................................................................30 5 4.2.1. Scheduling in RTLinux..........................................................................30 4.3. VxWorks............................................................................................................31 4.3.1. Scheduling in VxWorks........................................................................31 4.3.2. Industry deployment of VxWorks........................................................32 4.4. RTLinux Kernel Using virtualisation..................................................................32 4.4.1. Red Hat 7.1 under VMware.................................................................33 4.4.2. Installing VMware Tools......................................................................37 4.4.3. RTLinux Kernel.....................................................................................39 5. Case Study CLynxOS...........................................................................................41 5.1. Overview of LynxOS..........................................................................................41 5.2. LynxOS implementation of CPU scheduling.....................................................41 5.3. Industry deployment of LynxOS........................................................................42 6. Conclusion..................................................................................................................43 Appendix A: References.................................................................................................44

1. Introduction 1.1. Overview of Operating Systems (OS) With the growing technological advancement, nearly everything we work with has a computing element. From baby toys to bank ATMs, we witness the continued deployment of technologies in our everyday life. Most of these technologies contain some sort of operating system to ensure that they operate as expected though this fact is not always known to users of these systems. For example, most people are unaware that cellular phones contain operating systems such as the Nokia Symbian OS and Java- based embedded operating systems. However, avionic systems that help control aircraft, artificial satellites and spacecraft contain more complex operating systems such as LynxOS. The operating systems ensure that communication and navigation management features of avionic systems work as expected to avoid potentially calamitous consequences. The first aim of this mini project is to understand how operating systems work. Thereafter, we shall focus on gaining a detailed understanding of CPU scheduling algorithms for safety critical systems such as those for used in avionics. We shall install eCos on windows XP platform and using virtualisation , we shall patch red hat 7.1 kernel with RTLinux. 1.1.1. Operating System Definition Different people provide varying definitions of the concept of an operating system. Silberschatz Galvin (2004) defines an operating system as a program that is running at all time on the computer (usually called the kernel). According to Wikipedia, an Operating system is a software component of a computer system responsible for the management and coordination of activities and the sharing of the limited resources of the computer. The basic definition above cites keywords such as software and computer system. Computer systems divide software systems into three major classes: 8 system software, programming software and application software. Although the distinction is arbitrary, and is often blurred, operating systems fall in the category of system software. Having considered OS definitionsabove, next we focus on their functionality. 1.1.2. Operating SystemasResource manager A computer system is made of different components and resources. The OS lies between the hardware resources and the application program resources in a four layer structure. Figure 1: Layer Structure of computersystem Given its position in the layered structure, the OS serves as the resource manager. According to Tanenbaum (2007), the operating system provides for an orderly and controlled allocation of processors, memories, and I/O devices among the various programs competing for system resources. Thus, its primary tasks include keeping track of resource usage, granting resource requests, accounting for usage and mediating conflicting requests from different programs and users.

1.1.3. Operating system as control program As a control program, the OS ensures that programs execute without errors and prevents improper use of the computer. It so happens that the CPU can handle only one task at a time yet largely in general purpose computer systems, users may want to perform several tasks in the same duration of time. Concurrent user tasks could include sending email, playing music and software downloads. For multitasking to be achieved, an OS controls which tasks, process and threads would be executed by the CPU at a given time. This is scheduling that we shall look at in more detail in the following sections. 1.2. Types of Operating systems HowStuffworks (2007 )classifies operating systems based on the types of computers they control and the sort of applications they support. Single-user, single task This OS is designed to manage the computer so that one user can effectively do one thing at a time. The Palm OS for Palm handheld computers is a good example of a modern single-user, single-task operating system. The Palm OS has a simple, single- tasking environment to allow launching of full screen applications with a basic, common GUI set.

Single-user, multi-tasking This is the type of OS most people use on their desktop and laptop computers today. Microsoft's Windows and Apple's MacOS platforms are examples of operating systems that will let a single user have several programs in operation at the same time. For example, a Windows user may be writing a note in a word processor, downloading an internet file andprintinga document.
Multi-user 10 A multi-user OS allows many different users to take advantage of the computer's resources simultaneously. The OS must ensure that various user requirements are balanced, and that each of the programs utilised has sufficient and separate resources to avoid a problem with one user affecting the entire community. Unix, VMS and mainframe operating systems, such as MVS, are examples of multi-user operating systems. Real Time OperatingSystem (RTOS) A real-time OS is a multitasking operating system intended for real-time applications. Such applications include embedded systems (programmable thermostats, household appliance controllers, mobile telephones), industrial robots, spacecraft, and scientific research equipment. We shallexplorereal-time operating systems indetail later. Other classifications: GUI VS CLI There are several Internet resources which classify operating system into Graphical User Interface (GUI) OS such as Windows and Command Line Interface (CLI) OS such as typical UNIX. Wikipedia states, that while technically a graphical user interface is not an operating system service, incorporating support for one into the operating system kernel can allow the GUI to be more

responsive by reducing the number of context switches required for the GUI to perform its output functions. Many computer operating systems allow users to install or create any interface they desire. The X Window System in conjunction with GNOME or KDE is a commonly-found setup on most Unix and Unix-like (BSD, GNU/Linux, Minix) systems. A number of Windows shell replacements have been released for Microsoft Windows, which offer alternatives to the included Windows shell, but the shell itself cannot be separated from Windows. 11 As stated above, an Os can allow a user to install or create any interface they desire. However, if a million users created their interfaces, it will be hard to classify Operating Systems based on Interfaces. In addition, if we are to follow the definition of an operating system as a program that is running at all time on the computer (kernel), then a GUI is not a kernel and thus not an operating system. 1.3. General Purpose Systems VS Embedded Systems 1.3.1. General Purpose Systems Timmerman (2007) states that general purpose computers contain a central processing unit and memory (be it volatile, fixed, on chips, on a disk, or a diskette), and run a stored program (software). General purpose computer peripherals include equipment such as monitors, keyboards, mouse, docking stations, printers, scanners, disk drives, tape drives, modems, wireless cards and web cameras. The computers can be programmed to do different kinds of tasks, rather than special purpose computers that are limited by design to a specific task. General purpose computers consist of mainframes, servers and microcomputers (desktops and laptops). 1.3.2. Embedded Systems (EMS) Timmerman (2007) quotes Javids definition of an EMS: "embedded systems is a computer that does not look like a computer." This is a pretty simple and interesting definition of an embedded system. It does not look like a computer so what does it look like? To give this more scientific light the following definition of EMS is adapted in the same publication. An Embedded system (EMS) is an electronic system with dedicated functionality built into its hardware and software. The hardware is microprocessor based and uses some memory to keep the software and data and provides an interface to the world or system it is part of. 12 EMS differ from general purpose systems because (for cost and size reasons) they mostly have less processing capability, use limited memory resources and are much more power aware. Some examples are aircraft flight control systems, car cruise control, traffic light control, and car entertainment systems, factory automation systems, cell Phones, iPod, tablets and kiosks. 1.4. Real-Time EMS

A real-time system responds in a (timely) predictable way to all individual (unpredictable) external stimuli arrivals. The most important word is predictability. The system should respond to each individual external event in a predictable way, this means before the deadline defined in the system requirement. It is important to note that average performance is notthe issue! (Timmerman 2007) Real-time system types An embedded system does not necessarily need to have a predictable behaviour, and in that case it is not a real-time system. In a well-designed RT system, each individual deadline should be met. Deadlines are the maximum time limit for any event.There are different types of real-time systems: Hard real-ti time:deadlines may be missed and can be recovered from. General purpose computers do not have to meet specific deadlines. Instead, the systems requirements are expressed in terms ofaverage performance. 13 1.5. Hard Real Time VS Soft Real Time Operating Systems Silberschatz, Galvin (2004) states that a soft real-time system provides priority of real- time tasks over non real-time tasks. A hard real-time system guarantees that real-time tasks be completed within their required deadlines. For hard real-time systems one can say that the deadline mustbe met. For soft real-time systems one will then say that the deadline should be met.( Timmerman 2007). A safety-critical system is a real-time system with catastrophic results in case of failure. Figure 2: Task Usefulness after Deadline represents the usefulness of a task after a deadline is missed. The curve clearly indicates that the task usefulness automatically drops to 0 if a hard real time deadline is not met. Figure2:TaskUsefulnessafterDeadline 14 The achievement of safety and high quality of service in hard real time systems is a result of a combination of many hardware and software design factors. In the following section we look at scheduling with an emphasis on Safety Critical Scheduling Algorithms for Hard Real TimeOperating Systems. 15 2. Scheduling 2.1. Overview of Scheduling CPU scheduling is a way of determining which processes run when there are multiple processes in some cases with priorities. Scheduling is a key concept in computer multitasking and multiprocessing

and real-time operating system design. Scheduling is handled by the kernel scheduler. In section 1.3 we looked at multi tasking and multi processing Operating Systems that are increasingly on demand. Computer systems are increasing changing from one processor to multi processors given the power advantage multiple processors have over single processors. Multitasking and multiprocessing demand effective CPUtask scheduling. As stated above, scheduling is carried out by the Operating System Scheduler. The scheduleris concerned mainly with: Turnaround bee submitted until the first response is produced. -Time a process has time -Time it takes from when a request was

In real-time environments, such as mobile devices, for automatic control in industry (for example robotics), the scheduler must also ensure that processes can meet deadlines. This is crucial for keeping the system stable and safe. 16 2.2. Types of Operating System Schedulers Stallings (2004) identifies different types of schedulers. These include long-term, mid- term or medium-term and short-termschedulers. 2.2.1. Long-term Scheduler The long-term, or admission scheduler, decides which jobs or processes are to be admitted to the ready queue. Typically for a desktop computer, there is no long-term scheduler as such, and processes are admitted to the system automatically. However, this type of scheduling is crucial for a real-time operating system, as the system's ability to meet process deadlines may be compromised by the slowdowns and contention resulting from the admission of more processes than the system can safely handle. 2.2.2. Mid-term Scheduler The mid-term scheduler is present in all systems with virtual memory. It temporarily removes processes from main memory and places them on secondary memory (such as a disk drive) or vice versa. This is commonly referred to as "swapping out" or "swapping in" (also incorrectly as "paging out" or "paging in"). 2.2.3. Short-term Scheduler The short-term scheduler (dispatcher) decides which of the ready, in-memory processes are to be executed next following a clock interrupt, an IO interrupt, an operating system call or another form of signal. This scheduler can be preemptive, implying that it is capable of forcibly removing processes from a CPU when it decides to allocate that CPU to another process, or non-preemptive, in which case the scheduler is unable to "force" processes off the CPU.

17 2.3. How SchedulingWorks A task can have three states: running, ready, blocked. Only one task per CPU is running at a time. Most tasks are blocked, most of the time and other are in ready state. Schedulers use list data structures. The choice of data structure depends on the maximum number of tasks that can be on the tasks ready list The data structure of the ready list in the scheduler is designed to minimise the worst- case length of time spent in the scheduler's critical section, during which pre-emption is inhibited, and, in some cases, all interrupts are disabled. The critical response time, sometimes called the fly back time, is the time it takes to queue a new ready task and restore the state of the highest priority task. 2.4. Scheduling Algorithms A scheduling algorithm is the method by which threads, processes or data flows are given access to system resources (e.g. processor time, communications bandwidth). The need for a scheduling algorithm arises from the requirement for most modern systems to perform multitasking (execute more than one process at a time) and Multiplexing (transmit multiple flows simultaneously). The main purposes of scheduling algorithms are to minimise resource starvation and to ensure fairness amongst the parties utilising the resources. In safety critical systems, scheduling algorithms should ensure that tight deadlines are met.

2.4.1. SchedulingAlgorithmsforReal Time OS The algorithms discussed in the following section have been deployed by real-time systems like VxWorks and LynxOS. Sections 3 to 5 will cover case studies of real time operating systems that have implemented these and other algorithms. Round-robinscheduling Round-robin (RR) is one of the simplest scheduling algorithms for processes in an operating system. It assigns time slices to each process in equal portions and in order, handling all processes without priority. Round-robin scheduling is both simple and easy to implement, and starvation-free. First-in-first-out (FIFO) scheduling The scheduler runs the task with the highest priority first. If there are two or more tasks that share the same priority level, they get scheduled in order of their arrival completing the first arrived task first before continuing with the next one. Each task is occupying the CPU until it finishes or another task with higher priority arrives. 2.5. Safety Critical Scheduling Algorithms A hard real-time system guarantees that real-time tasks be completed within their required deadlines. A safety-critical system is a real-time system with catastrophic results in case of failure.

Most of hard real time systems are safety critical. Safety critical scheduling algorithms are implemented in apre-emptivescheduler. Pre-emptive scheduling: Pre-emption is the act of temporarily interrupting a task being carried out by a computer system, without requiring its cooperation, and with the intention of resuming the task at a later time. Such a change is known as a context switch. Pre-emptive time slicing: The period of time for which a process is allowed to run in a pre-emptive multitasking system is generally called the "time slice". The scheduler is run

once every time slice to choose the next process to run. If the time slice is too short then the scheduler will consume too much processing time. Below we look at the different algorithms that address the hard deadline requirements of hard realtime systems Safety Critical systems 2.5.1. Rate MonotonicAlgorithm(RMA) RMA is a procedure for assigning fixed (static) priorities to tasks to maximize their schedulability. A task set is considered schedulable and deterministic if all tasks meet all deadlines all the time. How it works Assign the priority of each task according to its period, so that the shorter the period the higher the priority. If Task 1 period is shorter than the period of Task 2, the higher priority is assigned to Task 1. RMA is an optimal static-priority algorithm. If a task set cannot be scheduled using the RMA algorithm, it manynot bescheduled using other static-priority algorithm. One major limitation of fixed-priority scheduling such as RMA is that it is not always possible to fully utilise the CPU. Even though RMA is the optimal fixed-priority scheme, it has a worst-case schedulable bound of: Wn = n * (21/n - 1) where n is the number of tasks in a system. As you would expect, the worstcase schedulable bound for one task is 100%. But as the number of tasks increases, the schedulable bound decreases, eventually approaching its limit of about 69.3%. 2.5.2. Earliest Deadline First(EDF) EDF is a dynamic scheduling algorithm used in real-time operating systems. It places processes in a priority queue such that when an event occurs (task finishes, new task 20 released, etc.) the queue will be searched for the process closest to its deadline so that process is executed next. On preemptive uniprocessors, EDF is an optimal scheduling algorithm. If a collection of independent jobs, each characterised by an arrival time, an execution requirement, and a deadline, can be scheduled such that all the jobs complete by their deadlines, the EDF will schedule this collection of jobs such that they all complete by their deadlines.

When periodic processes have deadlines that are equal to their periods, EDF has a utilisation bound of 100% thus guaranteeing that all deadlines are met provided that the total CPU utilisation is not more than 100%. However, when the system is overloaded, the set of processes that will miss deadlines is largely unpredictable (it will be a function of the exact deadlines and time at which the overload occurs.) Instead, most real-time computer systems use fixed priority scheduling (usually rate- monotonic scheduling). With fixed priorities, it is easy to predict that overload conditions will cause the lowpriority processes to miss deadlines, while the highest- priority process will still meet its deadline. 21 3. Case Study A ECOS 3.1. Overview of ECos eCos (embedded configurable operating system) is as an open source, royalty-free, real- time operating system. ( ecos.sourceware 2008) eCos is designed to be customisable to application requirements of run-time performance and hardware needs. It is programmed in the C programming language, and has compatibility layers and APIs for POSIX. eCos was designed for devices with memory size in the tens to hundreds of kilobytes, or with realtime requirements. It can be used on hardware with too little RAM to support embedded Linux, which currently needs a minimum of about 2 MB of RAM, not including application and service needs. 3.2. ECos Implementation of CPU scheduling ECos has two kinds of schedulers implemented; bitmap and MLQ (Multi Level Queue) scheduling. Both of them support preemption. It is possible to extend the eCos kernel to handle other schedulers as well. Both schedulers use numerical priority levels that range from 0 to 31 where 0 is the highest priority. According to Salenby and Lundgren (2006), MLQ scheduling also supports SMP (Symmetric Multiprocessing). Symmetric multiprocessing involves a multiprocessor computerarchitecture where two or more identical processors can connect to a single shared main memory. 22 3.2.1. Bitmap scheduling Bitmap scheduling consists of a queue with threads that are loaded into memory. Each thread in the queue has an associated priority. There are 32 different priority levels available and each priority level can only be associated with one thread. This limits the amounts of total of queued threads in the systems to 31 (one being the idle thread). The scheduler always runs the thread with the highest current priority. The scheduler can be configured with or without preemption. If preemption is enabled and a thread with a higher priority than the current running thread enters the queue, the scheduler will thenpreemptand run the thread with the highest priority.

Analysis of bitmap scheduling Because of the simplistic design of the scheduler (consisting only of a simple priority queue) finding the highest prioritised thread and switching to that will be fast and thus the dispatch latency will be low. The simplistic design also makes it easy to predict system behaviour, spawning the possibility for a deterministic system overall. As noted above, the schedule is constrained to 31 threads in the system. 3.2.2. MLQ scheduling The MLQ scheduling is a bit more complicated than bitmap scheduling. Instead of just having one queue for all threads and all priorities, this scheduler uses a set of queues where every queue contains a number of threads all with the same priority. Each queue has its own scheduling algorithm that by default is a time slicing algorithm that shares the CPU among the threads in the queue equally. The different priority levels may have different schedulers. These queues are scheduled by a normal priority queue where higher priority queues are scheduled first. The threads are divided into the different priorities based on some property of the thread. This scheduler also supports preemption. MLQ also has support for multiple processors with SMP (Symmetric Multiprocessing) whereeach processorusing its own scheduler. 23 Analysis of MLQ scheduling A more complicated scheduling algorithm makes the dispatch latency slightly higher than with bitmap scheduling. The MLQ scheduler contains more advanced features than the bitmap scheduler. This allows the developer to build systems with a distinct separation of background and foreground tasks, where tasks have different time requirements. Since this scheduler uses a more advanced algorithm it is harder to predict system behaviour, which makes this scheduler hard to use when trying to create a deterministic system. In contrast to the bitmap scheduler, the MLQ scheduling can handle asmany threads as can fit into the memory. 3.3. ISECos aSafetyCritical OS With a limited number of tasks, eCos should be configured with the bitmap scheduler. With this choice the systems can be made deterministic and, therefore, be suitable for hard real time systems. It, thus,would qualify to be safety critical. With a large number of tasks with different time requirements eCos MLQ is good in handling large amounts of diverse tasks. Systems handling large amounts of diverse tasks are most times not considered to be hard real time system but in event that such as system is hard real time, then eCos may not guarantee predictability. Thus, it would not be safety critical. 3.4. Ecos Installation usingPOSIX on Window XP 3.4.1. POSIX Portable Operating System Interface (POSIX) is the collective name of a family of related standards specified by the IEEE to define the application programming interface (API), along with shell and utilities interfaces for software compatible with variants of the Unix 24

operating system (IEEE 2001). However, the standard can apply to any operating system. 3.4.2. Cygwin Cygwin is a Linux-like environment for Windows. It consists of two parts: A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality. A collection of tools which provide Linux look and feel. The Cygwin DLL currently works with all recent, commercially released x86 32 bit and 64 bit versions of Windows, with the exception of Windows CE (Cygwin 2007). 3.4.3. eCoson WindowsXPPlatform. In order to install ECos under windows XP, POSIX Cygwin tool is a requirement and thus it was first installed. Detailed steps to install Cygwin and ecos are available at the from http://www.cygwin.com/setup.exe. Note when installing Cygwin Selected additional packages: gcc, make, sharutils, tcltk, wget are required if it is going to be used for Ecos.To select these packages See Figure3 : Selecting Cygwin Packages Figure3: Selecting Cygwin Packages 25 Installing eCos Under cygwin bash shell: Use Command below to download. wget --passive-ftp ftp://ecos.sourceware.org/pub/ecos/ecos-install.tcl See Figure 5 : Using Cygwin to download and install Ecos. Figure4: Using Cygwin to download and install Ecos. 3.4.4. eCos Configuration Tool The eCos Configuration Tool is a graphical tool to help configure and build a custom version of the eCos operating system. In setting up the Ecos configuration tool there were a couple of hardships. After several attempts trying to install the config tool that was downloaded from http://ecos.sourceware.org , it was discovered that the tool was not working on window XP. When started, it could pop up a screen and the screen would immediately disappear after a few seconds. i.e. the window would crash. A new tool was downloaded from www.ecoscentric.com/ . This new tool when started could pop up error messages of unread dll(s) for cygwin . To solve this issue, the cygwin ddl were copied and placed in the Windows folder (C:/Windows) and in the root folder of cygwin (C:/cgwin) and the root folder of ecos (C:/cygwin/opt/ecos). The errors stopped 26 popping up and the configuration tool screen was latter attained. See Figure 5: Ecos Configuration tool start under Windows XP Figure5: EcosConfigurationtool start under Windows XP Configuration Template Building the configuration template foraparticular hardware platform enables you to specify which features ofeCos to add. The configuration template was developed with theeCos kernel. SeeFigure 6: Building the Ecos Template forKernel

27 Figure6: Building the Ecos Template for Kernel Pentiumprocessors Using i386 architecture, you can chooseto enable featuresforPentiumCPU. TheeCos installation was done onPentiumdual core thus it was important to specify featuresfor Pentiumprocessors. SeeFigure7: SpecifyingPentium CPU features 28 Figure7: Specifying Pentium CPU features 3.4.5. Selecting the Kernel Scheduler As discussed earlier, eCos implementsBitmap scheduler and Multi Level Queue Scheduler. You can select which scheduler to work with. SeeFigure8: Ecos Kernel 29 Figure8: Ecos Kernel 3.5. Industrydeployment ofECos Numerous companies are using eCos, and many successful products have been launched running eCos, including the Brother HL-2400 CeN network color laser printer, Delphi Communiport, and the Iomega Hip Zip Digital Audio Player. 30 4. Case StudyB-RTLinux and VxWorks 4.1. SchedulingReviewed In section 2, we discussed scheduling and different scheduling algorithms for hard real time system which included Earliest Deadline First and Rate-Monotonic scheduling. Our case study for Ecos does not have a direct implementation of these algorithms but it is possible to modify Ecos to use EDF scheduling. RTLinux and VxWorks are some of the successful hard real-time operating systems on the market today. Therefore, they offer good examples of how efficient scheduling can be implemented using these algorithms. 4.2. RTLinux RTLinux (or Real-Time Linux) is an extension of Linux to a real-time operating system. RTLinux supports hard real-time (deterministic) operation through interrupt control between the hardware and the operating system. Interrupts needed for deterministic processing are processed by the realtime core, while other interrupts are forwarded to the non-real time operating system. The operating system (Linux) runs as a low priority thread. First-In-First-Out (FIFOs) pipes or shared memory can be used to share data between the operating system and the real-time core.

4.2.1. Scheduling in RTLinux RTLinux allows users to write their own scheduler to be used at runtime but give the user a choice of three different standard algorithms. 1. Simplepriority driven scheduler; 2. Rate monotonic (RM) scheduler; and 3. Earliest Deadline First (EDF) scheduler. 31 4.3. VxWorks VxWorks is designed for use in embedded systems. Unlike "native" systems such as Unix, VxWorks development is done on a "host" machine running Unix or Windows, cross-compiling target software to run on various "target" CPU architectures. The key features of the current VxWorks OS are a multitasking kernel with preemptive and round-robin scheduling and fast interrupt response. 4.3.1. Scheduling in VxWorks All work carried out in VxWorks is in the form of tasks. Each task can be in one of four different states; ready, delay, pending and suspend state. Ready tasks are available for running. Delayed tasks are sleeping for a set amount of time. Pending tasks are waiting for a resource to be available. The suspended state is what newly created tasks are set to until they get activated. Since this is usually done when the task is created, this state is primarily used for debugging purposes. VxWorks uses a priority based preemptive round-robin scheduling algorithm. Each task has a priority level between 0 and 255 where 0 is the highest priority and 255 the lowest priority. If a task with higher priority than the task currently running in the CPU is called, the scheduler suspends the first task and sets the CPU to running the second task. If the second task has the very same priority level as the first task, round-robin scheduling is provided. As mentioned earlier, a task can also turn into a pending state, for example if a resource for that task is not available. The scheduler then swaps back to a task with lower priority until the resource becomes available again. VxWorks also supports the POSIX API for real time threads, which makes available both the above described round robin as well as FIFO scheduling. VxWorks scheduling is thus flexible and adapts easily to the needs of the customer. 32 4.3.2. Industry deployment of VxWorks VxWorks has been deployed in a number of products including the Honda Robot ASIMO, the Airbus A400M Airlifter, the Boeing 787 airliner, the Mars Reconnaissance Orbiter, thePhoenix Mars Lander. Figure 9:NASA MarsReconnaissanceOrbiter Figure9:NASA MarsReconnaissanceOrbiter Wikipedia Photo 4.4. RTLinux Kernel Using virtualisation

As discussed in section 4.2, RTLinux is a hard real-time Operating system that implements Earliest Deadline First and Rate Monotonic Scheduling. In this section we shall use virtualization VMware Server 2.0 to install Red Hat Linux 7.1 and configure RTLinux Kernel. Virtualization refers to the abstraction of computer resources: Platform virtualization separates an operating system from the underlying platform resources. VMware is a virtualization tool. VMware 2.0 provides a web interface using tomcat web server. 33 Vmare was installed under Windows XP Professional base operating system. See Figure 10: WMWare 2.0 with web Access . A new virtual server for Red Hat 7.1 was created using ISO images that were placed in the virtual CD/DVD drive. It is also possible to install Red Hat Linux 7.1 in a virtual machine using the standard Red Hat distribution CDS. As you go through the steps to create a Red Hat virtual Machine you specify memory and Processors,hard disc, CD, Network Properties as Bridged. 4.4.1. Red Hat 7.1under VMware 1. A Red Hat Virtual machine was created using VMware management interface. Detailed Steps from the link below can be of great help http://www.virtuatopia.com/index.php/Creating_VMware_Server_2.0_Virtual_Mac hines Figure10: WMWare2.0 with web Access Note At the stage of configuring CD/DVD, ISO images was chosen and added to the virtual CD Drive. Figure 11: Using ISO image for Red Hat Virtual Machine, demonstrates the different item that would have to be specified while setting up the virtual machine. 34 Figure11: UsingISO image for Red Hat Virtual Machine 2. After creating the Red Hat virtual machine, a browser plug-in was added to Firefox to be able to access the Remote control panel of the machine otherwise VMware gives this message below when you try to use the control panel in a browser that lacks the plugin. (See Figure 13 : Notice to installplug-in for remote Console) Figure12: Notice to install plugin for remote Console 3. The VMware Management Interface was used to verify that the virtual machine's devices are set up as expected before starting the installation. If you install the guest operating system from a physical CD-ROM disc, the CD-ROM drive is connected to the virtual machine. Otherwise in this project, the First ISO image was inserted in the virtual CD. The virtual machine should start booting from the Virtual CD or Physical CD and the installation process will begin. 35

While going through this installation there are a couple of error message got due to compatibility issues with the infrastructure on which this was running. The challenge was to figure out a solution to the several errors. Many errors were related to the virtual server database inventory. Red Hat Linux 7.1 was installed using the graphical mode installer ( See Figure 13: Graphical Installation of Red Hat with VMWare Remote Console) which you may choose when you first boot the installer. There is also an option of text mode installer. At the Red Hat Linux 7.1 boot prompt, you are offered the following choices: To install or upgrade a system in graphical mode To install or upgrade a system in text mode, type: text <ENTER>. To choose the text mode installer, type text followed by Enter. Note: In going through this installation of Red Hat under virtualization the X-Window system should be skipped until when VMware tools are installed in the guest operating system. When X-Window system was installed without VMware tools, the remote console was flickering to the screen and disappearing every two seconds making it impossible to do anything. 36 Figure13: Graphical Installation of Red Hat with VMWare Remote Console 4. After the first steps, the installation steps were followed as could be for installation on a physical machine. Some important choicesmade included - It is Very important that when installing Red Hat you perform a Custom install and select Development, Kernel Development, Utilities, and Select Individual Packages. At the Individual Package Selection screen, go to Development --> Languages and select compat-egcs. Next go to Development --> Libraries and select compat-glibc. Select any other packages you wish to install and continue the installation. To be sure of the selection in this project all development packages were selected. Note: selection of ALL comes with need for more storage requirements. Selection Generic VGA compatible was chosen, Generic VGA is recommended if you not sure of the VGA of your machine. This installation was done on a laptop machine. close of the configuration, Generic Standard VGA, was chosen. 37 -Window installation was skipped. As mentioned earlier, VMware guest tools will be needed if the XWindow is to be used. After the completion of installation of the Red Hat Linux 7.1 the guest operating system, the virtual machine was started using the remote console. (See Figure 14: Starting Red Hat in Remote consoleusing textmode.) Figure14: Starting Red Hat in Remote consoleusing textmode. 4.4.2. Installing VMware Tools

Though the configuration of the RTLinux Kernel does not require a graphical interface for a typical Unix user, a graphical interface is handy for none Unix users. To have the graphical interface, you need to install VMware tools. As noted earlier, while going through tests in this project, whenever Red Hat was started in graphical mode, it could not load the Graphical interface but instead it could load the Command Line which flickered on the screen every few seconds. This was a result of missing VMware tools that enable the X-Window system on UNIXplatforms. 38 Note: With a Red Hat Linux 7.1 guest, VMware Tools are installed from the Linux console. The following steps were found close to achieving the graphical interface but may need to be adjusted from one platform to another. 1. Download the VMware tools for Linux guest operating systems. The file for the VMware tools was an ISO image. Which was added to the virtual CD and loaded mounted Note that the VMware tools ISO may by default have been placed in (C:/Program Files /Wmare) . In this case no freshdownload is required. 2. Use these commands under root account on red hat 7.1 ( See Figure 15 : Installing VMware tool under Red Hat Guest) mount /dev/cdrom /mnt cd /tmp tar zxf /mnt/VMware-linux-tools.tar.gz umount /mnt Figure15: Installing VMware tool under Red Hat Guest 3. Procceed tothe VMware web interface andused VMware Tools installer. Thenproceed to the console panel and used the commands cd VMware-tools-distrib ./VMware-install.pl 39 On running ./VMware-install.pl the installer asked a few questions about directory paths where to place files such as binary files. The default paths where used in this project. Though there was a challenge of the installation aborting at some stage in the process. After successful installation of the VMware tools you can StartX and your graphical environment is expected to work though not guaranteed to work! 4.4.3. RTLinux Kernel After successful installation of Red Hat 7.1 guest OS under VMware server, the RTLinux Kernel was configured. 1. DownloadingRTLinux 3.1and Linux 2.4.4 Using wget -- Wget is apackage for retrieving files using HTTP, HTTPS and FTP. It is a non-interactivecommand line tool, so it may easily be called from scripts, cron jobs, terminals without X- Windows support (See Figure 16: Using Wget for RTlinux for Red Hat Virtual Machine) Download RTLinux 3.1:rtlinux-3.1.tar.gz http://seg.ee.upatras.gr/ootcp/RTLinux%203.1/rtlinux-3.1.tar.gz Download the Linux 2.4.4 kernel: linux-2.4.4.tar.gz http://seg.ee.upatras.gr/ootcp/RTLinux%203.1/linux-2.4.4.tar.gz Figure16: Using Wget for RTlinux for Red Hat Virtual Machine 40

2. Unpack the files Unzip/ unTar the downloaded files (See Figure 17 : Unpacking File for Rtlinux and Linux Kennel 2.4) Use the command rm -rf /usr/src/rtlinux mkdir /usr/src/rtlinux cd /usr/src/rtlinux tar - xzf /var/tmp/linux-2.4.4.tar.gz tar -xzf /var/tmp/rtlinux-3.1.tar.gz Figure17: Unpacking File for Rtlinux and Linux Kennel 2.4 3. Patch the kernel (See Figure 18 : Patching LinuxKernelwith RTLinux) cd linux patch-p1 < /usr/src/rtlinux/rtlinux-3.1/kernel_patch-2.4.4 Figure18: Patching Linux Kernelwith RTLinux 41 5. Case StudyC LynxOS 5.1. Overview of LynxOS LynxOS RTOS is a Unix-like real-time operating system from LynuxWorks (formerly "Lynx Real-Time Systems"). Sometimes known as the Lynx Operating System, LynxOS features full Portable Operating System Interface (POSIX )conformance and, more recently, Linux compatibility. LynxOS is mostly used in real-time embedded systems, in applications for avionics, aerospace, the military, industrial process control and telecommunications (Wikipedia 2007). LynxOS components are designed for absolute determinism (hard real-time performance), which means that they respond within a known period of time. Predictable response times are ensured even in the presence of heavy I/O due to the kernel's unique threading model, which enables interrupt routines to be extremely short and fast. Lynuxworks the developers of LynxOS holds a patent on the technology that LynxOS uses to maintain hard real-time performance. Patent #5,469,571 was granted to LynuxWorks November 21, 1995: "Operating System Architecture using Multiple Priority Light Weight kernel Task-based Interrupt Handling." 5.2. LynxOS implementation of CPU scheduling Meeting hard real time performance requirement is a difficult challenge faced by designers of embedded systems. Many multiple input-output (I/O) devices and system processes gives rise to complexities in timing and can degrade system performance. As

42 we discussed above, the ECos bitmap scheduler works well as hard real-time OS with deterministic behaviour when handling few tasks. However, as tasks increase, the deterministic behaviour will be lost with MLQ scheduler in ECos. LynuxWorks developed "Priority based quantum"a new way of managingkernel threads and priority processing, and was awarded a patent (US Patent 5469571) for its technology, which is part of the LynxOS real-time operating system. Scheduling policies used by LynxOS are: 1. FIFO (First-In, First-Out); 2. Standard POSIX FIFO policy. A preemptible fixed priority scheduler; 3. Round robin; and 4. Proprietary Lynx scheduling policy named "Priority based quantum" "Priority based quantum" is similar to round robin policy, except that a configurable time quantum is defined for each level of priority. Put differently, the length of the time- slice is not fixed but is a variable for each priority level. The scheduler works with a total of 512 priority levels, 256 for user tasks and 256 for kernel threads. 5.3. Industry deployment ofLynxOS LynxOS is mostly used in real-time embedded systems, in applications for avionics, aerospace, the military, industrial process control and telecommunications. Below is one of the recent deployments of LynxOS for Airbus A380 Superjumbo Flight Test and Simulation . The Airbus A380 Superjumbo jet is a double-deck, wide-body, four-engine airlinerthe largest Airbus yet, seating 555 passengers. 43 6. Conclusion The importance of software in every aspect of life is growing. As discussed in this mini project report, some of the systems we interface with are safety-critical. Failure of software could cause catastrophic consequences for human life in such systems. It is hard to imagine the Airbus 380 crushing with full board! Imagine the antilock brake system (ABS) in your car failing at the time you need it most. We reemphasize the quote In, Embedded Systems: Definitions Taxonomies, where Prof. Dr. Martin Timmerman , quotes Javids definition of an EmS: "embedded systems is a computer that does not look like a computer." In addition, we reemphasize that For hard real-time systems the deadline mustbe met. For soft real-time systems the deadline should be met. How the deadlines are met is a result of my design factor among which is the scheduler. Rate monotonic and Earliest deadline First are two scheduling algorithm popular with Hard Real time systems. Using our cases studies we discovered that ECos could meet hard real-time requirements with its Bitmap Scheduler but would not be able to be deterministic with MLQ scheduling. Rtlinux is a typical demonstration of deployment of EDF and Rate Monotonic. RTLinux supports hard real-time (deterministic) operation through interrupt control between the hardware and the operating system. VxWorks deploys a multitasking kernel with pre- emptive and round-robin

scheduling and fast interrupt response. LynxOS a safety critical (hard real time ) has largely been defined as hard deterministic. Thus, it meets hard real-time requirements with its patented approach to scheduling. 44 Appendix A: References 1. Andrew Tanenbaum (2001)Modern Operating Systems 2nd Edition 2. Silberschatz Galvin (2004)Operating systems concepts 7th edition 3. Wikipedia 4. HowStuffworks (2007)(www.computer.howstuffworks.com/operating-system3.htm) 5. Prof. Dr. Martin Timmerman(2007)Embedded Systems: Definitions Taxonomies 6. Anthony J. Massa (2002 )Embedded Software Development with eCos http://www.phptr.com --By Anthony J. Massa2002 7. http://www.cotsjournalonline.com/home/article.php?id=100164&pg=1 8. Gustav Salenby and Daniel Lundgren(2006 ) ,Comparison of scheduling in FreeRTOS and 9. eCos Glossary : Cheap56.com 10. Cygwin-http://www.cygwin.com/ 11. Ecocentric --http://www.ecoscentric.com/ 12. Free Ecos-http://www.ecos.sourceware.org/ 13. Daniel Forsberg Magnus Nilsson (2006)Comparison between scheduling algorithms in RTLinux and VxWorks 14. Rtlinux -http://www.rtlinuxfree.com/ 15. Virtualization http://www.virtuatopia.com/index.php/Creating_VMware_Server_2.0_Virtual_Machine s 16. Benjamin Ip COMS (2006)Performance Analysis of VxWorks and RTLinux , Benjamin Ip COMS W49952, Languages of Embedded Systems Department of Computer Science, Columbia University, NY 17. http://www.lynxworks.com 18. Stallings, William (2004).Operating Systems Internals and Design Principles (fifth