Do I Need A Rtos

Published Date: 02 Nov 2017

1.0 INTRODUCTION TO REAL-TIME OPERATING SYSTEMS.

1.1 What is a Real-Time Operating System (RTOS)?

1.2 Do I need a RTOS?

1.3 How do RTOSs differ from General Purpose Operating Systems (GPOSs)?

2.0 EXAMPLE APPLICATIONS.

3.0 MAJOR COMPONENTS MAKING UP A RTOS.

4.0 CHARACTERISTICS AND DESIGN REQUIREMENTS OF A RTOS.

4.1 Key Characteristics

4.2 Design Requirements

4.3 Issues of a RTOS

5.0 COMPARATIVE ASSESSMENT OF COMMERCIALLY AVAILABLE RTOSs.

6.0 CONCLUSION.

7.0 REFERENCES.

1.0 INTRODUCTION TO REAL-TIME OPERATING SYSTEMS.

1.1 What is a Real-Time Operating System (RTOS)?

Operating systems in general are used in computing to manage hardware resources and applications that run on machines. A real time operating system will also perform the same tasks however it is subject to real-time constraints whilst delivering accurate results. This could be deadlines from events or a system response time. RTOS’s must be able to process data instantly as it is received, without any buffering delays or hold ups which could lead to catastrophic consequences depending on the systems purpose. These operating systems are becoming increasingly used in today’s world, in such areas as robotics, cars, cameras, military and many more. There are different types of RTOS known as HRT "hard real-time" and SFT "soft real-time". In a HRT operating system, there is a guaranteed maximum time for the operations performed however in SRT operating systems, it is not possible to guarantee a maximum response time consistently. Depending on the purpose of the system will decide which type of RTOS will be used. If the purpose is for a mobile phone feature then it may not be as crucial and a short delay will work perfectly fine, compared to its use in safety devices where minor delays could be the different between life and death.

1.2 Do I need a RTOS?

RTOS’s are becoming increasingly important and definitely are required in today’s world. It is used to significantly reduce the time it takes to process events, and as we progress, we get more and more impatient so for that reason alone, it’s definitely important but not required. Now when we start talking about RTOS’s and their use in factories, chemical plants and automotive design, it is a requirement. We will look at a few examples to determine the need of real time systems.

Road Traffic Signal Control – Traffic lights work off of timers which will work extremely accurate if not 100%. If the two lights in opposite directions were to miss-time and both turn green, the result could be fatal so we can quickly see how useful RTOS’s are in this field.

Laser printers – The majority of laser printers have embedded microprocessors which control the activities processed. There are many different activities such as a user pressing a command button on the machine, the printer recognises that the ink is low or empty or a paper jam in the machine. The printer will not know how to print different fonts or pictures on a page but is commanded where to print ink on the page in the form of dots. All of these processes are completely within milliseconds, and although not life threatening, it will save people and companies a lot of time and money to avoid delays.

You can start to see that RTOS are extremely important and are definitely required, maybe not for personal computer use but in day to day business and operation.

1.3 How do RTOSs differ from General Purpose Operating Systems (GPOSs)?

As discussed in the previous parts of the introduction, we can see that RTOS’s are time critical therefore the main differences between these two types of OS are dependent on the nature of the system. A comparison would be an ATM machine vs a personal computer. An ATM will have to deliver money to the user within a number of seconds so in this sense, it is time critical, vs. a personal computer which runs multiple tasks and applications at once, and can take several minutes to save a document or file depending on the amount of applications running in parallel.

Task Scheduling – The differences between RTOS and GPOS here is that RTOS’s are always priority based. If there is a high priority process, lower priority processes will be paused until the higher priority process is executed. GPOS are to process as many applications and processes efficiently but not strictly priority based. In a GPOS, there is an option for users to set priorities for certain tasks which will then allocate more processing power, memory and other resources to that task.

2.0 EXAMPLE APPLICATIONS.

Weapons – Many of the new weapon designs feature embedded computing to deliver high performance. A company called BittWare who’s expertise is turn-key integrated signal processing systems developed a ballistic digitiser which was used to monitor ammunition testing. This was a major challenge because the completely system consisted of over 40 boards which all had to meet criteria requirements. The channel capacity of current boards on the market was not going to be enough use for the design. To get around this, BittWare further developed an existing board so that it met the requirements, as well as creating a custom I/P transition module.

Medical Application - One example of RTOS in medical application is an Ultrasound device. The Philips (ATL) Ultrasound device uses Express Logic’s ThreadX® Real-Time Operating System to create software for its Ultrasound systems. Using high-performance processors, Philips Ultrasound are developing next-gen broadband digital beam formers that yield a much higher resolution, and much clearer ultrasound result.

Chemical Plant Control – Chemical Plant Control systems are a type of a control process. In an automated plant, a real-time computer continuously monitors the conditions of the plant. Different conditions such as temperate, pressure are constantly monitored. It will base new readings against current readings and then take action to maintain a stable environment. If the room temperate rises or drops, when the new reading is measured against the current reading, it will take action bring the temperature back to its requirement. The time bounds in chemical plants usually range from a few microseconds to milliseconds.

3.0 MAJOR COMPONENTS MAKING UP A RTOS.

Above is a typical implementation of a RTOS. The component of the system which is actually real-time is the micro kernel, shown in yellow above. The RTOS exports basic components as part of the operating system, a priority based task scheduler, memory management subsystem, a set of timers, and task synchronization facilities. Below we will look at each of the subsystems and components.

The scheduler is usually a simple round robin scheduler which uses priorities. This means that time slices (amount of time that the process will run) are assigned to each process in equal portion and in a circular order. The scheduler will maintain a set of task queues and dependant on the number of priorities which it will support. If a system supports 10 priorities for the tasks, it will maintain multiples of 16 task queues. Each task queue may have ready to run and sleeping. Systems that are simpler may just use one queue for all of the task states however these systems should not have many tasks due to risk of CPU over usage.

Most kernel subsystems will invoke the scheduler but sometimes a timer event cant also invoke the scheduler. The scheduler then scans for the highest priority task that exists and it will run. If there is a new task which is of a higher priority, the current task will be put to sleep until the new task either completes or becomes less of a priority. If a task is of high enough priority, it may lock out the scheduler which then is not able to interrupt the thread running. This would only be used for extremely critical tasks.

The memory manager is often designed to be as simple as possible, simply a slab allocator and collector. Typical RTOS’s have linear physical address space which is then exported to all of the tasks.

One of the most important parts integrated into almost any RTOS is the timer. These are what makes achieving real time performance possible. Timer subsystems can be split into two parts, the timer event generation and the timer ques. The timer event generation is dependant on the timer device driver for which platform it is currently running on. Time events are generated during the compile time of the application. Timer events can then invoke the schedule.

4.0 CHARACTERISTICS AND DESIGN REQUIREMENTS OF A RTOS.

4.1 Key Characteristics

The requirements of the overall application will determine the requirements of the RTOS in most cases so we will cover the key characteristics of the typical RTOS.

Reliability – All systems, specifically embedded systems must be reliable. Certain applications may need to run for set amounts of time without any human interaction and therefore need to be reliable to produce expected results. The amount of reliability and the effects of this will differ between applications depending on the use. To compare two examples, a solar powered calculator which shut off due to light restriction may not be as serious to one user as a company LaserJet printer which shut down and will have major setbacks and costs to the company until it is repaired. Therefore major servers will have a designated amount of downtime which should be aimed at each year, and minimising this of course increases the reliability.

Compactness – Application design constraints and the costs that come with, help to figure out how compact embedded systems can be. Mobile phones have to be designed so that they are small, portable and cheap. Because of these constrains, designers will be challenged to create the right spec for the price and design of the phone.

Scalability – RTOS’s are used in an extremely wide-variety of embedded systems, so they have to be able to be scaled up or down to meet the requirements of different applications. The RTOS should be able to add or remove components, depending on how much functionality is required.

Performance – This is one of the most important characteristics. In a RTOS, the more tasks that need completed, and the shorter the time between each task, the faster the CPU will need to be for the application. Systems will undertake performance testing to ensure that the throughput of the system is fast enough.

4.2 Design Requirements

4.3 Issues of a RTOS

5.0 COMPARATIVE ASSESSMENT OF COMMERCIALLY AVAILABLE RTOSs.

LynxOS – LynxOS is a RTOS which is Unix-like developed by LynuxWorks. It is used mostly in embedded systems used by aerospace, the military, industrial control and telecoms. It was first introduced in 1988. The goals of this system were that the kernel needed to be pre-emptive and re-entrant, which was critical to ensure time critical tasks were executed promptly. It also supported multi-threading. It uses thread priority to manage the processes and has the ability to interrupt threads.