Real time operating-systems


Published on

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Real time operating-systems

  1. 1. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM requirements of the system and ensure that the system performance is both1. Introduction correct and timely. There are three types of time constraints: Timeliness is the singlemost important aspect of a real -time  Hard: A late response is incor rect and implies a system failure.system. These systems respond to a An example of such a system isseries of external inputs, which arrive of medical equipment monitoringin an unpredictable fashion. The real- vital functions of a human body,time systems process these inputs, take where a late response would beappropriate decis ions and also generate considered as a failure.output necessary to control theperipherals connected to them. As  Soft: Timeliness requirementsdefined by Donald Gillies "A real-time are defined by using an averagesystem is one in which the correctness respons e time. If a singleof the computations not only depends computation is late, it is notupon the logical correctness of the usually significant, althoughcomputation but also upon the time in repeated late computation can result in system failures. Anwhich the result is produced. If the example of such a systemtiming constraints are not met, system includes airlines reservationfailure is said to have occurred." systems.  Firm: This is a combination of It is essential that the both hard and soft t imelinesstiming constraints of the system are requirements. The computationguaranteed to be met. Guaranteeing has a shorter soft requirementtiming behaviour requires that the and a longer hard requirement.system be predictable. For example, a patient ventilator must mechanically ventilate the patient a certain amount in a given time period. A few The design of a real -time seconds delay in the initiation ofsystem must specify the timingSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 1
  2. 2. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM breath is allowed, but not more than that. Most real -time systems interface with and control hardware directly. The software for such systems One need to distinguish is mostly custom -developed. Realbetween on -line systems such as an -time Applications can be eitherairline reservation system, which embedded applications or nonoperates in real-time but with much less -embedded (desktop) applications. Realsevere timeliness constraints than, say, -time systems often do not havea missile control system or a telephone standard peripherals associated with aswitch. An interactive system with desktop computer, namely thebetter response time is not a real-time keyboard, mouse or conventionalsystem. These types of systems are display monitors. In most instances,often referred to as soft real time real-time systems have a customizedsystems. In a soft real -time system version of these devices.(such as the airline reservationsystem) late data is still good dat a.However, for hard real -time systems, The following tablelate data is bad data. In this paper we compares some of the key features ofconcentrate on the hard and firm real- real -time software systems with othertime systems only. conventional software systems.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 2
  3. 3. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMFeature Sequential Concurrent Real Time Programming Programming Programming Predetermined Multiple sequential Usually composed order programs executingExecution of concurrent in parallel programsNumeric Independent of Generally Dependent onResults program dependent on program execution execution speed program execution speed speedExamples Accounting, UNIX operating Air flight controller payroll systemSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 3
  4. 4. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM1.1 Real-time Programs:The Computational Model A simple real -timeprogram can be defined as a program Pthat receives an event from a sensorevery T units of time and in the worstcase, an event requires C units ofcomputation time. Assume that the processingof each event must always be completedbefore the arrival of the next event (i.e.,when there is no buffering). Let thedeadline for completing thecomputation be D. If D < C, thedeadline cannot be met. If T < D, theprogram must still process each event ina time O/ T, if no events are to be lost.Thus the deadline is effectivelybounded by T and we need to handlethose cases where C O/ D O/T.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 4
  5. 5. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM as well as DMA cycle stealing are often problematic when2. Design issue of Real determining process executionTime Systems timing [4].  An operating system must have a Real-time systems are predictable behavior in alldefined as those systems in which the situations. Often the common-correctness of the system depends not purpose operating systems, likeonly on the logical result of UNIX, are too large and complex,computation, but also on the time at and they have too muchwhich the results are produced [17]. A unpredictability. Thus, a specialcommon misconception is to consider, microkernel operating systemsthat real-time computing is equivalent to like the Chorus microkernel [9]fast computing. In traditional non-real- have been designed for real-timetime computer systems, the performance purposes.goal is throughput: as many tasks shouldbe processed as possible in given time Also traditionalperiod. Real-time systems have a programming concepts and languagesdifferent goal to meet: as many tasks as are often not good for real-timepossible should be executed so, that they programming. No language constructwill complete and produce results before should take arbitrary long to execute,their time limit expires. In other words, and all synchronization, communication,the behavior of real-time system must be or device accessing should bepredictable [16] in all situations. expressible through time-bounded constructs [19]. However, despite all these real-time requirements could be To achieve predictability, solved, a human factor - the real-timeall components of the real-time system programmer - can always causemust be time bounded. A predictability unpredictability to the system. To assistof the system depends on many different the programming process, numerousaspects. methods have been produced for real- time system design, specification, verification, and debugging [5].  The computer hardware must not introduce unpredictable delays into program execution. For example, caching and swappingSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 5
  6. 6. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM Typically, a real-time 1. Absolute consistencysystem consists of controlling system between the state of the environmentand a controlled system. The controlled and the controlling system. Thesystem can be viewed as the controlling systems view from theenvironment with which the computer environment must be temporallyinteracts. The typical real-time system consistent, it must not be too old.gather information from the varioussensors, process information andproduce results. The environment for 2. Relative consistencyreal-time system may be highly in among the data used to derive otherdeterministic. Events may have data. Sometimes, the data items dependunpredictable starting time, duration and on each other. If a real-time system usesfrequency. However, real-time system all dependent values, they must bemust react to all of these events within temporally consistent to each other.prespecific time and produce adequatereaction. There are several possibilities to maintain temporal To guarantee, that a real- consistency. The state of thetime system has always a correct view environment is often scanned inof its environment, a consistency must periodical basis and an image of thebe maintained between them. The environment is maintained in theconsistency is time-based. The controlling system. A timestampcontrolling system must scan its methodology is often used to figure outenvironment fast enough to keep track validity of the systems image of thechanges in the system. The adequate environment.fastness depends on application. Forexample, sensing a temperature needsoften slower tempo than sensing a A typical real-time systemmoving object. consists of several tasks, which must be executed in simultaneous manner. Each task has a value which is gained to the The need to maintain system if a computations finishes inconsistency between the environment specific time. Each task has a deadline,and the controlling system leads to the which indicates a time limit, when anotion of temporal consistency. result of the computingTemporal consistency has twocomponents [12]:SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 6
  7. 7. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM becomes useless, ie. gains sight of the scanning device. If thezero or negative value to the system. object is not recognized, it can beFurthermore, a task may have some rejected or rescanned later. Thus, anvalue after the deadline has been operation loses its value after a certainexpired. time period, but no harm will occur due to failure. A typical example of soft deadline is a combined operation The deadlines have been sequence. The whole sequence has adivided into three types: hard, soft and firm deadline, but if some of thefirm deadlines. The hard deadline components of the sequence miss theirmeans, that a task may cause very high deadlines, the overall sequence mightnegative value to the system, if the still be able to make its deadline.computation is not completed beforedeadline. Opposite to this, in a softdeadline, a computation has the As a summary, the timingdecreasing value after the deadline, and requirements for real-time systems canthe value may become zero at later time. be expressed as following constraints toIn the middle of these extremes, a firm the processing [5]:deadline is defined: a task loses its valueafter deadline, but no negativeconsequence will occur. Figure 1 plots 1. Response time, deadline:the value versus time behavior for the system must respond to thedifferent deadline types. A real-time environment within a specified timesystem must guarantee, that all hard after input (or stimuli) is recognized.deadlines and as many as possible ofother deadlines are met. 2. Validity of data: in some cases, the validity of the input or output Examples of deadline types is a function of time. That is, someare quite intuitive. A typical example of stimulus and the corresponding responsehard deadline can be found from the become obsolete with time, and the timesystem controlling the nuclear power interval for which data is valid must beplant: adding coolant to the reactor must accounted in processing done before temperature gets toohigh. A typical example for firmdeadline can be found from the industry 3. Periodic execution: inautomation. A real-time system attempts many control systems, sensors collectto recognize a moving object. An object data at predetermined time intervals.can be scanned only, when it is in theSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 7
  8. 8. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM real-time behavior is often essential when designing a safety critical system. 4. Coordinating inputs andoutputs: in some applications, input datafrom various sensors must besynchronized. Otherwise, decisionswould be made based on inconsistentinformation. An example of real-time 3. Schedulingsystem is simplified unmanned vehiclesystem (SUVS) [20]. The SUVScontrols a vehicle with no assistance To support timeliness in afrom a human driver. It periodically real-time system, a special real-time taskreceives data from sensors such as the scheduling methods have beenspeedometer, temperature sensor, and introduced. Traditional real-timedirection sensor. It controls the vehicle research has been concerned to uniby generating appropriate signals to processor scheduling. As a complexityactuators, such as the accelerator, brake and scale of real-time system grows, theand steering wheel. processing power of real-time system is increased by adding new processors or by distribution. These issues introduce Decisions are made based several new concepts to schedulingon the current inputs from the sensors research, numerous schemes have beenand the current status of the road and the introduced for multiprocessor andvehicle. Decisions must be made within distributed scheduling. In this section,a specified time. The events can occur we discuss two main principles for real-very unexpectedly. Lets think about a time scheduling, a scheduling paradigmscenario, where an obstacle suddenly and a priority inversion problem.falls into the road. The braking andsteering decisions must be done within ashort time period to avoid crashing. 3.1 Scheduling paradigmsThese decisions must also besynchronized and the status of the roadand other traffic must be taken intoaccount. Thus, most of tasks in SUVS The simplest real-timehave a hard deadline. This is typical in scheduling method is not to schedule atmany safety critical systems [6, 7]. A all. This method sounds dummy, but in many real-time systems, only one taskSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 8
  9. 9. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMexists. A common example is a typicalprogrammable logic. Programmablelogics are widely used in the industry Depending on particularautomation. A programmable logics systems behavior, the differentprogram is executed periodically. scheduling paradigms have beenDuring every execution, the program introduced [13]:reads all inputs, makes simplecalculations and sets appropriateoutputs. Same program is executed at 1. Static table-drivenevery time, and a state of the system approaches: These perform staticdepends on internal variables set in the schedulability analysis and the resultingprevious runs. However, interrupts can schedule (table) is used at run time tobe used to catch asynchronous events, decide, when a task must beginbut an advanced processing must be execution. This is a highly predictablemade within standard run periods. approach, but it is very inflexible, because a table must always be reconstructed, when a new task is added In more advanced real-time to the system. Due to predictability, thissystems, several simultaneous tasks can is often used when absolute hardbe executed. Every task may have deadlines are needed.different timing constraints and theymay have a periodic or an aperiodicexecution behavior. The periodic 2. Static priority-drivenbehavior mens, that a task must be pre-emptive approaches: These performexecuted within prespecific time static schedulability analysis, but unlikeintervals. When a task has an aperiodic in the previous approach, no explicitbehavior, it will execute, when an schedule is constructed. At run time,external stimulus occurs. In a typical tasks are executed "highest priorityreal-time systems, both type of tasks first". This is a quite commonly usedexists. However, all aperiodic tasks can approach in concrete real-time systems.always be transformed to periodic. Atask structure of the system describes,when the tasks can be started. Many 3. Dynamic planning-basedsystems have a static task structure, approaches: Unlike the previous twowhere tasks are installed during system approaches, feasibility is checked at runstartup and no new tasks can be started time. A dynamically arriving task isafterwards. In dynamic task structure, accepted for execution only if it is foundtasks can be started and ended during feasible.system uptime.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 9
  10. 10. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM 4. Dynamic best effort runnable. When the higher priority taskapproaches: Here no feasibility checking becomes eligible, it is always started tois done. The system tries to do its best to run. The task with a lower priority ismeet deadlines, but a task may be pre-empted, the task is released from aaborted during its execution. processor in favor to higher priority task. Unfortunately the mostscheduling problems are NP-complete. A priority inversionHowever, many good heuristic problem arises, when a lower priorityapproaches have been presented. Thus, task has reserved a shared resource. If anumerous algorithms have been higher priority task needs the sameintroduced to support these scheduling resource, the resource cannot beparadigms. Algorithms are either based acquired, because it is already reservedon the single scheduling paradigm or by another task. This forces the higherthey can spread over several paradigms. priority task to block, which may lead toThese algorithms include least common the missing of its deadline. Also themultiply (LCM) method, earliest deadlock situation is possible. Figure 2deadline first (EDF) method, rate illustrates an execution sequence, wheremonotonic (RM), and many others. A a priority inversion occurs. A task T3survey of scheduling methods is found executes and reserves a resource. Ain [13]. higher priority task T1 pre-empts task T3, but wants to allocate a resource3.2 Priority inversion reserver by task T3. Then, task T2problem becomes eligible and blocks task T3. Because the task T3 cannot be executed, In a multitasking the resource remains reservedenvironment, the shared resources are suppressing task T1 to run. Thus, theoften used. The usage of these resources task T1 misses its deadline due tomust be protected with a well-known resource conflict.methods, like semaphores and mutexes.However, a priority inversion problem[14] arises, if these methods are used in Several approaches havereal-time system with a pre-emptive been introduced to rectify the prioritypriority-driven scheduling. In priority- inversion problem. The use of prioritydriven scheduling, the eligible task with inversion protocols is one approach. Thea highest priority is always executed. basic idea of priority inversion protocolsThe task is eligible, when it is not is that when a task blocks one or morewaiting for any event, so when it is higher priority tasks, it ignores itsSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 10
  11. 11. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMoriginal priority assignment and Early systems consisted of a smallexecutes its critical section at the highest number of processors performingpriority level of all the tasks it blocks. statically determined set of duties.After exiting its critical section, the task Future systems will be much larger,returns its original priority. Figure 3 more widely distributed, and will beillustrates, how a priority inversion expected to perform a constantlyproblem presented in the figure 2 can be changing set of duties in dynamicsolved with a priority inheritance environments. This also sets moreprotocol. Again, the task T3 executes requirements for future real-timeand reserves a resource, and a higher operating systems.priority task T1 wants to allocate thatresource. As a result of priorityinheritance, the task T3 inherits priority Real-time operatingof T1 and executes its critical section in systems need to be significantlythat priority. Thus, the task T2 cannot different from those in traditional time-pre-empt task T3 and the resource is sharing system architectures becausereleased after a critical section is they have to be able to handle thefinished. Now the task T1 can acquire added complexity of time constraints,resource and it is completed to its flexible operations, predictability anddeadline. dependability.4. Real-time operatingsystem 5. Real-time operating system requirements and Real-time operating basic abstractionssystems are an integral part of real-timesystems. Examples of these systems areprocess control systems, flight controlsystems and all other systems that In real-time systems,require result of computation to be operating system plays a considerableproduced in certain time schedule. role. The most important task of it is toNowadays real-time computing schedule system execution (processes)systems are applied to more dynamic and make sure that all requirements thatand complex missions, and their the system is meeting are filled. In thistiming constraints and characteristics chapter we will introduce some generalare becoming more difficult to manage. terms used in operating systems and real-time systems:SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 11
  12. 12. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM5.1 General terms Real-time operating One common denominatorsystems require certain tasks to be in real-time systems seems to be that allcomputed within strict time constraints. designers want their real-time systemsTime constraints define deadline, the to be predictable. Predictabilityresponse time in which the computation means, that it should be possible tohas to be completed. There are three show, demonstrate, or prove thatdifferent kinds of deadlines; hard, soft requirements are met subject to anyand firm. Hard deadline means that if assumptions made, for example,the computation is not completed before concerning failures and workloads. Indeadline, it may cause a total system other words predictability is alwaysfailure. Soft deadline means that subject to the underlying assumptionscomputing has a decreasing value made.[2]after the deadline but not a zero ornegative number. If firm deadline ismissed, the value of task is lost but For static real-timeno negative consequence is occurred. systems in deterministic, stable environments we can easily predict the overall system performance over large Fault tolerance, the time frames as well as predict thecapability of a computer, subsystem performance of some individual task.or program to withstand the effects of In more complicated, changing,internal faults, is also a common nondeterministic environment , forrequirement for real-time operating example a future system of robots co-systems. operating on Mars, it is far more complicated task to predict in design phase, how the system is actually going to act in its real environment. In Several real-time systems operating system level system must becollect data from their environment at designed to be so simple, that it ispredetermined time intervals which possible to predict worst-case situationsrequires periodic execution. in execution. 5.3 Temporal consistency5.2 PredictabilitySASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 12
  13. 13. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM The controlling systemmust scan its environment fastenough to maintain a correct view ofit. If that is taken care of, it can besaid that consistency is achievedbetween real-time system and itsenvironment. This leads to notion oftemporal consistency [6], which has twocomponents;  Absolute consistency, which is achieved between the controlling system and the state of the environment if the systems view of the environment is temporally consistent.  Relative consistency, which is achieved if data items dependent of each other in the system are temporally consistent to each other.  Temporal consistency is usually maintained by periodically scanning the environment and maintain an image of the environment in the controlling system.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 13
  14. 14. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM operating system are also usually 6. Real-time operating based on microkernel architecture and must support these main functional areassystem structure [1]: When systems have  process management andbecome larger and unwieldy, they are synchronizationdifficult to comprehend, develop and  memory managementmaintain.  inter process communication  I/O A recent trend inoperating system development consistsof structuring the operating system as 3.2 Structure of thea modular set of system servers CHORUS systemwhich sit on top of a minimal kernel,microkernel, rather than using thetraditional monolithic kernel, inwhich all functionality of the system Microkernel basedis provided. Figure 3.1 presents operating systems are like stripped downmonolithic kernel of the UNIX system timesharing operating systems with only[7]. minimal functionality. In figure 3.2 microkernel of the CHORUS system is presented [7]. 3.1 Monolithic kernel ofthe UNIX system In real-time operating systems microkernels are used to achieve strict timing requirements. The The idea in microkernel- structure of system must be compact,based operating systems are that all unnecessary functionality must bethose functions which are needed stripped down and execution time of auniversally, by every component of the single task must be minimized. In real-system, form the microkernel. Other time operating systems reaction timefunctionality is handled outside thekernel and they can be speciallytailored for each application.Notations close and open system arealso used for this purpose. Real-timeSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 14
  15. 15. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMhas to be short and the scheduling They can be divided into 3algorithm to be executed must be fast categories :and very simple.  small proprietary kernels6.1 Basic abstractions Usually current real-time  real-time extensions to commercialoperating systems support following timesharingbasic abstractions with slight operating systemsdifferences between different systems: Task : The basic unit of resource  research kernels.allocation. This includes /actor addressspace and access to the systemresources. Thread : The basic unit of 7.1 Small Proprietaryexecution. Usually executed in the Kernelsaddress space of a single task. Port : A one-way communicationchannel implemented as a message The small, proprietaryqueue. kernels are often used for small embedded systems when very fast and highly predictable execution must be Port set : A group of ports. Port guaranteed. The kernels are oftenset has usually only one queue. stripped down and optimized to reduce the run-time overhead caused by the Message : Collection of data kernel. The usual characteristics of theseobjects used in communicating between kernels are [13]:threads.  fast context switching.7. Real Time OperatingSystem Types  small size and stripped-down functionality.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 15
  16. 16. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM  quick response to external applications, such as instrumentation, interrupts. communication front ends, intelligent peripherals, and process control. Since the application are simple, it is relatively  minimized intervals, easy to determine, that all timing when interrupts are disabled. constraints are met. As complexity of the system increases, it becomes more and more difficult to map all timing,  fixed or variable computation time, resource, and value sized partitions for memory requirements to a single priority for each management. task. In these situations demonstrating predictability becomes very difficult.  ability to lock code Because of these reasons, some and data into memory. researchers believe, that more sophisticated kernels are needed to address timing and fault tolerance  special sequential constraints. Recently there are efforts to files for data accessing. produce scalable kernels. The smallest level of support is a microkernel, and the support can be broaden by demands ofTo deal with timing requirements, the the application. An example of this type kernel should provide a priority of kernel is the Chorus microkernel [9], scheduling mechanism and a bounded which can be scaled from a simple execution time for most primitives. For embedded microkernel to a full timing purposes, the kernel should POSIX/UNIX support. maintain a real-time clock and provide special alarm and timeout 7.2 Real-time Extensions services, as well as primitives for delay To Commercial by a fixed amount of time. In general, the kernel also performs multitasking Timesharing Operating and intertask communication and Systems synchronization via standard well- known constructs such as mailboxes, events, signals, and semaphores. The second approach to the Additionally, the kernel should support real-time operating system is the real-time queuing methods such as extension of commercial products, like delivering messages by a priority order. extending UNIX to RT-UNIX, or These kernels are suitable for small POSIX to RT-POSIX. The real-time SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 16
  17. 17. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMversions for commercial operating 7.3 Research Kernelssystems are generally slower and lesspredictable than proprietary kernels, butthey have a greater functionality and abetter software development The third category of real-environments. time operating system is research kernels. These kernels are used in research purposes to develop and demonstrate new features to the real- However, there are various time operating systems. Trends in theproblems when attempting to convert a current research in real-time operatingnon-real-time operating systems to a systems include developing real-timereal-time version [3]. For example, in process models, developing real-timeUNIX interface, problems exist in synchronization primitives, searchingprocess scheduling. These problems are solutions for timing analysis, developingdue to nature of the nice and set priority support for fault tolerance, investigatingprimitives as well as round robin object-oriented approaches, providingscheduling policy. Furthermore, timer support for multiprocessor as well asfacilities in unix are too coarse, memory distribution, and attempting to formallymanagement is too complex, and define a microkernel. There areinterprocess communication facilities do numerous research project addressingnot support fast and predictable these issues. A survey of these projectscommunication. Also implementation is found in [13].issues used in the UNIX operatingsystem restrict itsuse for real-time purposes. These issuesinclude intolerable overhead, nonpreemptability of the kernel, and internalFIFO queues. As a result, extendingcommercial timesharing operatingsystem for real-time purposes is not afeasible approach, especially when harddeadlines are needed.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 17
  18. 18. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM flexible real-time operating system, including:  Viewing the execution of a task as8. Designing a reflective a random process where taskarchitecture for a real- could be blocked at arbitrary points during its execution for antime operating system indefinite time. In critical real- time environments each task is well defined and can be analyzed There are several issues a priorithat has to be taken into accountwhen designing and building a real-timeoperating system; meeting functional,  Assuming that little is knownfault tolerance and timing about the tasks a priori, so thatrequirements are complex tasks. One little semantic informationmethod in building a complex and about them is utilized at runflexible real-time system is to use the time. In real-time systems, thenotion of reflective architecture [5]. A software should be able to makesystem based on reflective use of important semanticsarchitecture is one that reasons about information about the applicationand reflects upon its own current tasks.state and that of the environment todetermine the right course of action.  AttemptSeveral current real-time systems ing to maximize throughput orcontain the same basic paradigms minimize average response time.found in timesharing operatingsystems. They are usually onlystripped down and optimized versions of These metrics are nottime-sharing operating systems. primary metrics for real-time systems.Although they stress fast mechanisms System could have a good averagesuch as fast context switching and response time and still miss everyability to respond to external deadline, resulting a useless system.interrupts quickly, they retain somemain abstractions of timesharingsystems, which should be taken into In traditional systemsaccount when designing a complex and computation solves some application problem such as sorting a file or filteringSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 18
  19. 19. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMimportant signals from radar returns. In other and to systemreflective system we can consider a modes.system to have a  Time requirements (deadlines, periodscomputational part and reflective part. etc.)Computational part acts like in thetraditional systems, but reflective part ofthe system exposes the system state  Time profiles, such as theand semantics of the application to worst-case execution timesdecide what to do, for example infiltering process to choose the mostappropriate filter.  Resource needs  Precedence constraints 5.1 Design issues Thereexists also several opposing factors,that make the design even more  Communicationcomplex. The desire for predictability requirementsversus the need for flexibility tohandle non-deterministic environments,failures and system architecture, the  Objectives or goals of theneed for efficient performance and low systemcost versus understandability etc.Flexible real time system architecture  Consistency and integritycannot be based on handcraft constraintssolutions because of their complexityand requirements. When building areal-time system based on a reflective  Policies to guide system-architecture means that first we must wide schedulingidentify reflective informationregarding the system. This informationincludes:  Fault tolerance requirements  Policies to guide tradeoff  Importance of task, analyses group of tasks and how tasks importance relates toSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 19
  20. 20. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM  Performance monitoring possible to perform adaptive information management of redundancy. Implementation structures in the When tasks priorities are operating system retain this fixed, a fixed-priority scheduling information and primitives mechanism, provided by most real- allow it to be dynamically time kernels, works properly. Still changed. When many more complex systems require implementing a real-time dynamic priorities. Dynamic priorities operating system based on can be dynamically calculated for reflective architecture, we example with some weighted formula need to use real-time that combines different information programming languages. e.g. deadline and resource needs. First we need a high-level Systems with fixed priorities are not programming language that able to handle dynamic priorities is capable of specifying properly. reflective information such as timing requirements and In order to deal with the need for guarantees with predictability versus flexibility, there is respect to these requirements. a need for multilevel, multi-dimensional An example of this is scheduling algorithms [5]. These Spring-C, which is used in algorithms explicitly categorize the Spring -system performance, including when there is implementation [3]. In system degradation or unexpected general, this language is C events. Algorithms are multi- -based programming dimensional, because they have to language with support for consider all resources needed by a timing specifications and task, not just CPU time, and they guarantee semantics. Then must consider precedence constraints we need a language to and communication requirements. support system description. They are multi-level algorithms, That should provide means because tasks are categorized into four to perform careful, detailed classes; critical (missing the deadline and accurate timing analysis. causes a total system failure), Third, we require notation essential (these tasks have hard for specifying fault-tolerance deadlines, but the tasks are not critical), requirements on a task-by- soft real-time (task value drop after task basis, where it is deadline but not to zero or negative number), and non-real-time (noSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 20
  21. 21. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMdeadlines). When task arrives, This paper gives anscheduling algorithm uses the reflective overview of the real-time system issues.information about active tasks and The main concept in all real timecreates a full schedule for them and systems is predictability. Thepredicts if some of them is going to miss predictability depends on numeroustheir deadlines. If deadlines would be different aspects, hardware, operatingmissed, error handling can occur before system, programming languages, andthat happens. program design and implementation methods. The real-time system must also have a temporally consistent view of the environment it belongs to. The consistency can be addressed as terms of Many real-time systems absolute and relative consistency. Therequire strict fault tolerance in order tasks in real-time systems may haveto operate in complex, highly variable arbitrary deadlines. The deadlines haveenvironment. A three-level framework been divided into three categories,for defining fault tolerance depending on how the system is affectedrequirements is presented. At the if a deadline is missed. These categorieshighest level of the framework is the are hard, firm and soft deadlines.overall design process. That includesspecification of the physical inputs andoutputs from and to the external world, To support timeliness andfirst specification of the important predictability, the different schedulingfunctional blocks in the system, the methods have been produced forflow of data and interactions among uniprocessor systems as well asthem, a definition of timing multiprocessor and distributed systems.requirements (periods, deadlines and Tasks in real-time systems can haveresponse times), identification of each periodic or aperiodic behavior, andfunctions criticality, and specification several scheduling paradigms have beenof mode changes. At the second level of produced to support different systemthe framework redundancy of the types. When resources need to besystem is managed. On third level allocated in real-time systems, a priorityof the framework is the actual inversion problem may arise. Thecoding of the application modules priority inversion may cause the task tothemselves. These three levels must lose its deadline. Several prioritybe consistent with each other. inheritance protocols have been introduced to solve the priority inversion9. Conclusion problem.SASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 21
  22. 22. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEM Real-time operating system Helsinki, Dept. of Computer Science,is an integral part of real-time system. Helsinki, FinlandReal-time operating system offers toolsto guarantee predictability. The small,proprietary kernels have been stripped [3] B. Furht, D. Grostick, D. Gloch, G.out and optimized for real-time Rabbat, J. Parker, and M. Mc Roberts.purposes. These kernels may be scalable Real-Time Unix Systems Design andfrom simple embedded systems to Application Guide. Kluwer Academicoffering full POSIX/UNIX support. Publishers,Also commercial timesharing operatingsystems can be extended to meet thereal-time requirements, but these are not [4] W. Halang. Implication on suitableoften applicable for real-time multiprocessor structures and virtualperformance requirements. Also several storage management when applying aresearch kernels were introduced. These feasible scheduling algorithm , in hardkernels are used to develop and real-time environments. Softwaredemonstrate new real-time system Practice and Experience, 16(8):761-769.features. Real-time database is anexample case of real-time system. It [5] K. Kavi and S. Yang. Real-timecombines database and realtime system design methodologies: Anconcepts. These concepts include introduction and a survey. Journal ofhandling a database schema, efficient Systems and Software, 18(1):85-99data management support,transactionality, failure recoverymechanisms, data temporality, and real- [6] Mathai Joseph, Real -time Systems:time access to data. Specification, Verification and Analysis, Prentice Hall International, London References[1] R. Abbott and H. Garcia-Molina.Scheduling real-time transactions. ACM [7] Bran Selic, Turning Clockwise:SIGMOD Record, 17(1):71-81 Using UML in the Real -Time Domain, Communications of the ACM,[2] P. Elovaara and K. Raatikainen.Evaluation of concurrency controlalgorithms for realtime databases. [8] K. Ramamritham and J. Stankovitc.Report C-1996-52, University of Scheduling algorithms and operatingSASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 22
  23. 23. A SEMINAR REPORT ON REAL TIME OPERATING SYSTEMsystem support for real-time systems.Proceedings of the IEEE, 82(1):55-67,.[9] K. Ramamritham. Real-timedatabases. Distributed and paralleldatabases,.[10] J. Bacon. Concurrent systems.Addison-WesleySASI INSTITUTE OF TECHNOLOGY & ENGINEERING Page 23