For this assignment, I have been asked to carry out a “comprehensive in-depth study of Real-Time Operating Systems”. Within my essay, I will address a number of things which include, typical requirements, constraints and applications of real-time operating systems, typical characteristics and design requirements for a real-time operating system and I will also present a comparative assessment of commercially available real-time operating systems.

What is a Real-Time Operating System?

Firstly, “A real-time operating system is a computer operating system designed to handle events as they happen.” (Computerhope.com. (2017). What is RTOS (Real-Time Operating System)?) It is an operating system that is capable of reliably executing programs with ‘very specific timing requirements, this is something that is important for many science and engineering projects.” “An Operating System exploits the hardware resources of one or more processors, it also provides a set of services to users. The Operating System manages secondary memory and Input and Output devices for its users.” (William Stallings, 1992) The basic elements that make up an Operating System are the processor, main memory, input/output modules and the system bus. The main role of the processor is to control the operations of the computer and it performs the data processing functions. If there is only one processor, it is usually referred to as the Central Processing Unit(CPU). The main memory stores the data and programs, the memory is usually volatile, however, in contrast, the contents of the disk memory are kept even when the computer is shut down. The input/output modules move data between the computer and external environments. These external environments entail a number of devices such as communication equipment, storage such as hard drives and also terminals. The final element, the system bus provides for communication among the processors, main memory and the input/output modules.

Real-Time Operating Systems and General Purpose Operating Systems

If you need to make sure that certain parts of a program run in a certain amount of time or if the program needs to run consistently for long periods of time it is a good idea that you use a Real-Time Operating System as there would be a need for it. Building a Real-Time Operating System can give the user peace of mind that the program will carry on running without interrupting control processes. (Ni.com. (2017). Do I Need a Real-Time System? – National Instruments). The simple difference between using a General Purpose Operating System and a Real-Time Operating System is ‘whether the system is time critical or not’. A General Purpose Operating System is used for systems that are not time critical such as Windows, Unix and Linux whereas as a Real-Time Operating System is used for time critical systems for instance VxWorks and uCos. (Electronic Circuits and Diagram-Electronics Projects and Design. (2017). Differences between a GPOS (Normal OS) and an RTOS (Real Time OS)

Requirements, Applications and Constraints of a Real-Time Operating System

Requirements

Typical requirements for a Real-Time Operating System include; Architectural requirements. As “distributed architecture allows interactions among remote tasks and devices”, (ManSang Chung, Heonshik Shin, 1991) communications need to be organised for task requests and device services in view of deadlines and importance of the tasks. Another is Logical requirements, “the communication management of data and control amongst hierarchically and vertically related tasks should be performed for synchronization purposes” (ManSang Chung, Heonshik Shin, 1991). The events that are generated at each of the vertical levels have to be processed in a number of different ways in conjunction with the importance of appropriate tasks. There are also functional requirements of a Real-Time Operating System. “The functional aspect specifies requirements of device access mechanisms, these are that device management services should be provided by server tasks performing device management functions” (ManSang Chung, Heonshik Shin, 1991), and that they should be introduced by arrival events of request messages using different strategies and mechanisms according to the importance of tasks.

Applications

“The application of Real-Time Operating Systems reduces significantly the required hardware resources, which results in a decrease of the cost of the device and an increase in its energy saving efficiency and reliability” this was stated by Adam Kaliszan and Piotr Zwierzykowski, in “Application of Real Time Operating System in the Internet of Things”. Due to the application of the Real-Time Operating Systems the software is made up of a ‘number of tasks running in parallel and being in close communication with one another.” With the method that is well-suited with the philosophy of the “Internet of Things”, there is “no need to implement an advanced management panel on the device. This functionality can be implemented in the cloud, on a virtual server” (Adam Kaliszan, Piotr Zwierzykowski, 2016). Mustafa KÕya and Yaúar Becerikli wrote in 2013 that, if you are showing the behaviour of the real time and non-real time Operating Systems, an application needs to be run that creates and runs tree threads inside a process and reviews the order of completion time of the threads at both Linux and Pintos Operating Systems.

Constraints

There are a number of constraints associated with a Real-Time Operating System. To which these include, the limit of tasks, there are a number of limited tasks run at the same time and the concentration of these tasks on the system are on a few applications to avoid errors and other tasks therefore have to wait to be run. Sometimes, there is no time limit to the length of time the uncompleted or non-started tasks have to wait. Real-Time Operating Systems use a lot of resources which can be expensive. There is a low rate for multi-tasking in a Real-Time Operating System as these systems run few tasks at any given time and stay focussed on them. Real-Time Operating Systems uses intricate algorithms to achieve a desired output and it would be difficult to write the same algorithms for a designer, it would also be difficult for the designer to understand such complex algorithms. A further constraint is that a Real-Time Operating System must have a specific device driver and interrupt signals to respond fast to interrupts. Low priority tasks may not get the adequate time needed to run because the system has to maintain a high accuracy rate of the current running programs. Another factor that needs to be considered which may be a constraint to Real-Time Operating Systems is memory management. (IT Release. (2017). What are advantages and disadvantages of real time operating systems – IT Release)

Martin Böhnert and Christoph Scholl from the University of Freiburg, Germany wrote in ‘A Dynamic Virtual Memory Management under Real-Time Constraints’ in 2014, that “we employ efficient data-structures to yield runtimes that are close to traditional static memory management concepts, and at the same time provide the user with the full flexibility of both virtual and dynamic memory management.” Current memory management systems have runtimes that depend on the size of the requested memory. Because of this logic embedded Real-Time Operating Systems abstain from using virtual memory, because “these mechanisms are viewed as a main obstacle to tight estimates of worst-case execution times and thus to an efficient scheduling of processes with deadlines” (Martin Böhnert and Christoph Scholl, 2014). The Real-Time Operating System has five principle storage management responsibilities which consist of; process isolation, the Operating System must “prevent independent processes from interfering with each other’s memory, both the data and the instructions”. Another responsibility is automatic allocation and management, “programs should be dynamically allocated across the memory as necessary. Allocations should be transparent to the programmer” (William Stallings, 1992). Support of modular programming is the third responsibility, “programmers should be able to define program modules, to create, destroy and alter the size of modules dynamically” (William Stallings, 1992). Another, protection and access control, means that the sharing of memory at any level of the memory hierarchy will create the potential for one of the programs to address the memory space of another program. The Operating System must allow parts of memory to be accessed in different ways by various users. The final responsibility is long term storage, “many application programs require a means for storing information for extended periods of time, after the computer has been powered down” (William Stallings, 1992). Typically, Operating Systems meet these five requirements with virtual memory and file system facilities. The file system carries out a long-term store, with information stored in named objects, these are called files. The file is an advantageous approach for the programmer and is a useful element of access control and protection for the Operating System. The definition of virtual memory given to us by William Stallings in Operating Systems: Internal and Design Principles, 8^th edition, is a “facility that allows programs to address memory from a logical point of view, without regard to the amount of main memory physically available” (William Stallings, 1992). Virtual memory conceives to meet the requirement of having a number of user jobs residing in the main memory simultaneously.

Mateus Krepsky Ludwich and Antonio Augusto Frohlich wrote in System-Level Verification of Embedded Operating Systems Components that “The increasing complexity of embedded operating systems is pushing their design to System-Level, leading to the convergence between software and hardware”. In this situation, it would be preferable to certify the system properties properly, irrespective of whether the components are going to be executed in either software or hardware. Symmetric multiprocessing is a term that refers to computer hardware and software architecture and also to the Operating System that utilises the architecture. Multithreading is a “technique in which a process, executing an application, is divided into threads that run concurrently” (William Stallings, 1992). Multithreading is beneficial for kernel processes and structuring applications on a uniprocessor system. In a symmetric multiprocessing system, a number of processes can be run in parallel and this can be convenient for nonthreaded processes. The processor share the same main memory and I/O facilities and all the processors can perform the same functions. “Multi-core processors with a symmetric multiprocessing architecture are widely used in desktop systems and in server system. Such systems contain multiple identical physical processors with the same properties. The broad introduction of multi-core processors poses new challenges for software performance evaluation” (Jens Happe, Henning Groenda, and Ralf H. Reussner, 2009). Symmetric multiprocessing has various advantages over the uniprocessor architecture which include; performance, “more than one process can be running simultaneously, each on a different processor” (William Stallings, 1992), availability is another advantage, if there is a failure of a single process then the system will not come to a standstill. Incremental growth means that the performance of a system “can be enhanced by adding an additional processor” (William Stallings, 1992) and lastly, scaling, vendors are able to offer a variety of products based on the number of processors constructed in the system.

Typical Characteristics, Design Requirements and Issues of a Real-Time Operating System

Characteristics

Two important characteristics of Windows are that it supports threads and it also supports symmetric multiprocessing. Operating Systems programs can run on any available processor and different programs can execute at the same time on various processors. Windows does support the use of multiple threads of execution within a single process. Different server processes may use multiple threads to process requests from more than one user at the same time. Mechanisms are provided by Windows for “sharing data and resources between processes and flexible interprocess communication capabilities” (William Stallings, 1992). Trusted Architecture is a Real-Time Operating System characteristic, this refers to how the architecture “provides a transparent and application-independent system in which trusted services can securely run trusted processes within the environment” (Mohd Anuar Mat Isa1, Jamalul-lail Ab Manan2, Habibah Hashim3, Ramlan Mahmod4, Meor Mohd AzreenMeor Hamzah5, 2012). Linux and Windows architecture design used a Trusted Platform Module as a base of the integrity measurement and verification on the local platform. Another characteristic is Trusted Hardware and Trusted Software, the Trusted Hardware is the hardware executes a trusted protocol. The Trusted Software is the “creation of trust in its special privileges, trust in software design, trust in programming and conventions” (Mohd Anuar Mat Isa1, Jamalul-lail Ab Manan2, Habibah Hashim3, Ramlan Mahmod4, Meor Mohd AzreenMeor Hamzah5, 2012). Trusted Framework is another characteristic that “refers to the framework that defines trusted systems, defines its enforcement, defines how measurements are achieved, defines how trusted processes are monitored, and reported” (Mohd Anuar Mat Isa1, Jamalul-lail Ab Manan2, Habibah Hashim3, Ramlan Mahmod4, Meor Mohd AzreenMeor Hamzah5, 2012). When designing the trusted framework, it requires “knowledge of the target application and hardware design because the trusted framework will directly affect the overall performance” (Mohd Anuar Mat Isa1, Jamalul-lail Ab Manan2, Habibah Hashim3, Ramlan Mahmod4, Meor Mohd AzreenMeor Hamzah5, 2012) of the Real-Time Operating System. Also, there is Security, Trust and Privacy requirements and rules that are able to help reduce the security, trust and privacy problems within a Real-Time Operating System setting.

Design Requirements

There are a number of both hardware and software design requirements. Some of the hardware requirements include architecture, all operating systems are designed for a particular architecture. Although “architecture-independent operating systems and applications exist, most need to be recompiled to run on a new architecture” (En.wikipedia.org. (2017). System requirements). The power of the Central Processing Unit is an essential system requirement for any type of software. “Most software running on x86 architecture define processing power as the model and the clock speed of the CPU. Many other features of a CPU that influence its speed and power, like bus speed, cache, and MIPS are often ignored” (En.wikipedia.org. (2017). System requirements). Memory, all software when it is run is located in the random access memory of any computer. The demands of the application, operating systems, other running processes and supporting software and files are considered only after the memory requirements have been defined. “With secondary storage, hard-disk requirements vary, depending on the size of software installation, temporary files created and maintained while installing or running the software, and possible use of swap space”, (En.wikipedia.org. (2017). System requirements) the use of swap space is used in the case that there is insufficient RAM. Software requirements of a Real-Time Operating System deal with “defining software resource requirements that need to be installed on a computer to provide optimal functioning of an application” (En.wikipedia.org. (2017). System requirements). One of the software requirements is a platform. A computing platform will describe some form of framework in either hardware or software, this then allows the software to run. Common platforms include an operating system or programming languages, a computers architecture and their runtime libraries. Another software requirement is APIs and drivers, “software making extensive use of special hardware devices, like high-end display adapters, needs special API or newer device drivers.” (En.wikipedia.org. (2017). System requirements) An example of this is DirectX, this is a collection of APIs for handling tasks that are related to multimedia on Microsoft platforms. Lastly, web browser is a software requirement, the majority of web applications and software that rely massively upon internet technologies are able to make use of a default browser that is installed on the system.

Issues

Real-Time Computing

I am going to discuss a number of issues that affect Real-Time Operating Systems. “The design and implementation of correct and timely distributed Real-Time Operating Systems is rendered difficult by the existence of the following” (Gerard Le Lann, 1990) physical fundamentals; multiple asynchronous hardware elements, occurrence of faults, finite space, speed and energy levels, and also the passing of time. One of the main challenges in “establishing group communication protocols is to deal with possible fault occurrences” (K.H Kim, 1999). Firstly, it is extremely important to “establish and understand the effective techniques for detecting and recovering faults in Real-Time Operating Systems” (K.H Kim, 1999). As Kim states in Group Communication in Real-Time Computing Systems: Issues and Directions, 1999, “to think that one can try to find effective group communication protocols first and use them to handle component failures is analogous to the thinking that one can find a good house and then use the house to establish a good foundation and a good roof.” “Although multicore technology has many benefits for real-time systems among them, decreased weight and power, fewer cooling requirements, and increased CPU bandwidth per processor multicore chips pose problems that stem from the cores interfering with one another when accessing shared resources” (Lui Sha, Marco Caccamo, Renato Mancuso, Jung-Eun Kim, and Man-Ki Yoon, Rodolfo Pellizzoni, Heechul Yun, Russell B. Kegley and Dennis R. Perlman, Greg Arundale, Richard Bradford, 2016).

Hard Real-Time and Soft Real-Time

“A task is hard real-time if it is creating results are its deadline can cause disastrous consequences on the system”. A task is soft real-time if it producing the outcomes after the deadline has still some utility for the system, however it “causes a performance degradation” (Buttazzo, 2011). “A real-time system consists of both aperiodic and periodic tasks. Periodic tasks have regular arrival times and hard deadlines. Aperiodic tasks have irregular arrival times and either soft or hard deadlines” (Brinkley Sprunt, Lui Sha, John Lehoczky, 1989). The “real-time community” is divided into two section; hard real-time and soft real-time. Christer Eriksson, Henrik Thane and Mikael Gustafsson wrote in “A Communication Protocol for Hard and Soft Real-Time Systems”, that they “propose a hybrid communication protocol, which forms a foundation for interconnection of nodes in a distributed hybrid real-time system. The protocol will enable both hard and soft real-time frames on a broadcast communication bus, yet still guarantees the hard real-time behaviour. The protocol will utilise the communication bandwidth more efficiently”. Real-Time Operating Systems are increasing in complexity and hard real-time and soft real-time applications are becoming more prevalent in general-purpose computing situations. As the figure below shows the “major differences between hard and soft real time systems” (Kanaka Juvva, 1998).

Figure 1: Hard Real-Time vs Soft Real-Time (Kanaka Juvva, 1998)

Aperiodic, Periodic Tasks and Responsiveness

There is a “growing need for scheduling solutions that simultaneously support processes with a variety of different timeliness constraints” (Scott A. Brandt, Scott Banachowski, Caixue Lin, Timothy Bisson, 2003). Hsiang-Kuo Tang, Parmesh Ramanathan, Katherine Compton wrote in Combining Hard Periodic and Soft Aperiodic Real-Time Task Scheduling on Heterogeneous Compute Resources that they would examine scheduling for combinations of hard periodic and soft aperiodic real-time tasks that execute together on heterogeneous Real-Time Operating Systems. They discuss how they will separate the problem into two parts; the first thing they do is “schedule hard periodic tasks offline” and then they “schedule soft aperiodic tasks at runtime because their arrival behaviour may not be known at design time” (Hsiang-Kuo Tang, Parmesh Ramanathan, Katherine Compton, 2011). Tang, Ramanathan and Compton have to assume that all tasks can be executed on all resources, but that “each task has a different execution time on each resource” (Hsiang-Kuo Tang, Parmesh Ramanathan, Katherine Compton, 2011). Their results displayed that the “initial periodic task schedule quality can significantly affect the system’s ability to successfully schedule aperiodic tasks at runtime and minimise their response times. Run-time aperiodic task scheduling can also improve responsiveness by not only choosing a good time and resource for executing an aperiodic task, but also by dynamically rearranging prescheduled periodic tasks to permit incoming aperiodic tasks to complete sooner” (Hsiang-Kuo Tang, Parmesh Ramanathan, Katherine Compton, 2011). Lin, Mitake and Nakajima wrote in “Improving GPOS Real-time Responsiveness using vCPU Migration in an Embedded Multicore Virtualization Platform” that the Performance improvement of General Purpose Operating System’s Real-Time responsiveness is also given while a detailed analysis of the overhead of the Real-Time Operating System v CPU is performed as well. The results showed that “the migration overhead of a Real-Time Operating System v CPU is under an acceptable level. This also means that one can use our approach to improve the GPOS’s performance, while keeping Real-Time Operating System’s Real-Time responsiveness at the same time” (Tsung-Han Lin, Hitoshi Mitake, Tatsuo Nakajima, 2013). To ensure that all time critical tasks meet their specific deadlines, a hard real-time system must execute a set of simultaneous real-time tasks. “The scheduling problem is concerned with the allocation of the resources to satisfy the timing constraints” (Kanaka Juvva, 1998). The figure below gives a representation of taxonomy of real-time scheduling algorithms.

Figure 2: Taxonomy of Real-Time Scheduling,Kanaka Juvva, 1998

Real-Time Scheduling, Determination and User Control

Two types of hard real-time scheduling are, static and dynamic which can be seen from figure 2 above. Static scheduling means that “scheduling decisions are made at compile time” (Kanaka Juvva, 1998). Alternatively, dynamic scheduling “makes its scheduling decisions at run time, selecting one out of the current set of ready tasks” (Kanaka Juvva, 1998). They are adaptive and flexible. Pre-emptive or non-pre-emptive scheduling of tasks is probable with both static and dynamic scheduling. “In pre-emptive scheduling, the currently executing task will be pre-empted upon arrival of a higher priority task. In non-pre-emptive scheduling, the currently executing task will not be pre-empted until completion” (Kanaka Juvva, 1998). A Real -Time Operating System’s “goal is to behave deterministically. Determinism implies two aspects. Firstly, if the process asks for CPU, RAM or communication, it should receive it from the coordination. Secondly, if a failure occurs, the system should know what to do” (En.wikibooks.org. (2017). Embedded Control Systems Design/Real Time Operating systems – Wikibooks, open books for an open world). Determinism can be defined as “operations that are being performed at fixed, predetermined times or within predetermined intervals, it is concerned with how long ‘the operating system delays before acknowledging an interrupt Whether the system has sufficient capacity to handle all requests within required time” (RTOS, C. Brandolese, W. Fornaciari). If a Real-Time Operating System can meet a deadline it is usually said to be a soft Real-Time Operating System but if it “can meet a deadline deterministically it is a hard Real-Time Operating System” (En.wikipedia.org. (2017). Real-time operating system). A lot of Real-Time Operating Systems allow applications themselves “to run in kernel mode for greater Deterministic system call efficiency” and this allow allows the application to “have greater control of the operating environment without requiring operating system intervention” (En.wikipedia.org. (2017). Real-time operating system). One requirement for a Real-Time Operating System is the user control over Operating System policies. The controls are mainly scheduling and many priority levels. Another part that is involved with the requirement of user control is memory support, more specifically in embedded systems, such as pages locked in main memory and also cache partitioning and colouring on multicore systems. User control is much broader in a Real-Time Operating System than in an ordinary Operating System. Other things the user should be able to do include, “specify paging or process swapping, they can decide which processes must reside in main memory and establish the rights of processes” (RTOS, C. Brandolese, W. Fornaciari).

Reliability and Fail-Soft Operation

“The use of Real-Time Operating Systems became an attractive solution to simplify the design of safety critical Real-Time embedded systems. Due to their stringent constraints such as battery-powered, high-speed and low-voltage operation, these systems are often subject to transient faults originated from a large spectrum of noisy sources, among them, the conducted and radiated Electromagnetic Interference. As the major consequence, the system’s reliability degrades” (D. Silva, L.B. Poehls, J. Semião, C. Teixeira, J.P. Teixeira, M. Valdés, J. Freijedo, J.J. Rodríguez-Andina, F. Vargas, 2011). Wireless technologies have in more recent years represented a “huge challenge for the reliability of real-time embedded systems” and to note, that if these systems are powered by battery, the yielded reliability is even more fragile’ (D. Silva, L.B. Poehls, J. Semião, C. Teixeira, J.P. Teixeira, M. Valdés, J. Freijedo, J.J. Rodríguez-Andina, F. Vargas, 2011). Another part of reliability within a Real-Time Operating System is the fail-soft operation. This is the ability to “fail in such a way to preserve as much data and capability as possible” (RTOS, C. Brandolese, W. Fornaciari), for example multiple attempts to improve data consistency.

Design Philosophies and Memory Allocation

The most common design philosophies for Real-Time Operating Systems are, Event Driven, this involves switching tasks “only when an event of higher priority needs servicing; called pre-emptive priority, or priority scheduling”. The other is Time Sharing, this ‘switches tasks on a regular clocked interrupt, and on events; called round robin’ (En.wikipedia.org. (2017). Real-time operating system). K.H. Kim wrote in “Real-Time Simulation Techniques Based on the RT0.k Object Modelling” in 1996 that “an underlying design philosophy of the RT0.k object model is that an RTCS will always take the form of a network of RT0.k objects”. M. Masmano, I. Ripoll, A. Crespo, and J. Real declared in “TLSF: A New Dynamic Memory Allocator for Real-Time Systems” in 2004, that “jointly with other basic computing problems, like searching and sorting, memory management is one of the most studied and analysed problems”. Memory allocation uses standard methods for protection including; block-based, paging and hardware mapping. There is no virtual memory for hard Real-Time tasks, it locks all the pages in the main memory. Many embedded Real-Time Operating Systems do not have memory protection, tasks could be able to access any block, this is to avoid time overheads and to achieve predictable timing. Many of commercial Real-Time Operating Systems provide memory protection as an option. This means that they can run into “fail-safe” mode if an illegal access trap occurs, it is also useful for complex reconfigurable systems.

Comparative Assessment of Commercially Available Real Time Operating Systems

PSOS

I am going to present a comparative assessment of four commercially available Real-Time Operating Systems. The first one I am going to discuss is PSOS, this is a popular Real-Time Operating System that is used primarily in embedded applications. PSOS is being used in several commercial embedded products. An “example application of PSOS is in the base stations of the cellular systems. Both Unix and Windows hosts are supported by PSOS” (Anon, (2017). Some of the important features of PSOS some include, that it consists of 32 priority levels, it “supports priority inheritance and priority ceiling protocols. Also, it supports segmented memory management” (Anon, (2017). It can also allocate tasks to memory regions. “In most of the modern Operating Systems, the control jumps to the kernel when an interrupt occurs. PSOS takes a different approach. The device drivers are outside the kernel and can be loaded and removed at run time”. (Anon, (2017)

Figure 3: PSOS based Development of embedded software

VxWorks

Another Operating System is VxWorks, this is a product from “Wind River Systems, it is a host target system. The host for this operating system can also be a Windows or Unix machine. VxWorks comes with an integrated development environment (IDE) called Tornado” (Anon, (2017). “In addition to the standard support for program development tools such as editor, cross-compiler, cross-debugger, etc. Tornado contains VxSim and WindView. VxSim simulates a VxWorks target for use as a prototyping and testing environment. WindView provides debugging tools for the simulator environment. VxMP is the multiprocessor version of VxWorks. Although VxWorks supports priority inheritance, using the remote debugging tool, it was found to have been disabled in the configuration file. The problem was fixed by enabling it.” (Anon, (2017).

Linux

The third commercially available Real-Time Operating System I am going to discuss is Linux. This is by large a free operating system, it can be described as “robust, feature rich and efficient. The real-time kernel sits between the hardware and the Linux system. The RT kernel intercepts all interrupts generated by the hardware” (Anon, (2017). The figure bellows represents this.

Figure 4: Structure of RT Linux

“In the approach taken by RT Linux, there are effectively two independent kernels: real-time kernel and Linux kernel. Therefore, this approach is also known as the dual kernel approach as the real-time kernel is implemented outside the Linux kernel. Any task that requires deterministic scheduling is run as a real-time task” (Anon, (2017). There are a number of downsides to the dual-kernel approach which are, Duplicated Coding Efforts; Tasks running in the real-time kernel “cannot make full use of the Linux system services. New drivers and system services must be created specifically for the real-time kernel – even when equivalent services already exist for Linux” (Anon, (2017). Programming Difficulties; RT-Linux kernels “support only a limited subset of POSIX APIs. Therefore, application development takes more effort and time” (Anon, (2017). Another is Limited Portability; “In the dual kernel approach, the real-time tasks are not Linux processes at all; but programs written using a small subset of POSIX APIs. Real-Time programs written using one vendor’s RT-Linux version may not run on another’s.”(Anon, (2017).

Windows CE

The final Operating System I am going to discuss is Windows CE. “Windows CE is a stripped down version of Windows, and has a minimum footprint of 400KBytes only. It provides 256 priority levels. To optimize performance, all threads are run in the kernel mode. Windows CE uses a priority inheritance scheme to avoid priority inversion problem present in Windows NT” (Anon, (2017). “When a thread with priority level NORMAL suffers a page fault, the priority of the corresponding kernel thread handling this page fault is raised to the priority of the thread causing the page fault. This ensures that a thread is not blocked by another lower priority thread even when it suffers a page fault.” Anon, (2017)).

And so, to conclude, I feel that I have covered each of the required elements well and to a high degree of accuracy, covering topics beyond what was asked. I am more confident about the overall topic of Real-Time Operating Systems, from the constraints in a Real-Time Operating System to memory allocation and design philosophies. From the research that I carried out to complete this report I feel that I have a better understanding of the different areas and aspects of Real Time Operating Systems.

References

Computerhope.com. (2017). What is RTOS (Real-Time Operating System)?. [online] Available at: http://www.computerhope.com/jargon/r/realsyst.htm

Ni.com. (2017). Do I Need a Real-Time System? – National Instruments. [online] Available at: http://www.ni.com/white-paper/14238/en/

Electronic Circuits and Diagram-Electronics Projects and Design. (2017). Differences between a GPOS (Normal OS) and an RTOS (Real Time OS). [online] Available at: http://www.circuitstoday.com/gpos-versus-rtos-for-an-embedded-system

Requirements Specification of Distributed Hard Real-Time Operating Systems Distributed environment, ManSang Chung and Heonshik Shin Centralized environment Department of Computer Engineering Seoul National University Seoul, 151-742, Korea, 1991

Application of Real Time Operating System in the Internet of Things, Adam Kaliszan, Piotr Zwierzykowski, Poznan University of Technology, Chairs of Communication and Computer Networks, 2016

Foundations and Educational Application of Real Time Operating System Mustafa KÕyar Department of Computer Engineering, Kocaeli University, Yaúar Becerikli1, Department of Computer Engineering, Yalova University, Turkey, 2013

IT Release. (2017). What are advantages and disadvantages of real time operating systems – IT Release. [online] Available at: http://www.itrelease.com/2014/07/advantages-disadvantages-real-time-operating-systems/

Operating Systems: Internal and Design Principles, 8/e, William Stallings, Chapter 1, “Computer System Overview”, 1992

Operating Systems: Internal and Design Principles, 8/e, William Stallings, Chapter 2, “Computer System Overview”, 1992

System-Level Verification of Embedded Operating Systems Components, Mateus Krepsky Ludwich and Antonio Augusto Frohlich, Laboratory for Software and Hardware Integration (LISHA), Federal University of Santa Catarina (UFSC), 2012

Performance Evaluation of Scheduling Policies in Symmetric Multiprocessing Environments, Jens Happe, Henning Groenda, and Ralf H. Reussner, FZI Forschungszentrum Informatik, Germany, 2009

Trusted Real Time Operating System: Identifying its Characteristics, Mohd Anuar Mat Isa1, Jamalul-lail Ab Manan2, Habibah Hashim3, Ramlan Mahmod4, Meor Mohd AzreenMeor Hamzah5, Malaysia, 2012

En.wikipedia.org. (2017). System requirements. [online] Available at: https://en.wikipedia.org/wiki/System_requirements

Critical Issues for the Development of Distributed Real-Time Computing Systems, Gerard Le Lann, France, 1990

Group Communication in Real-Time Computing Systems: Issues and Directions K. H. (Kane) Kim, USA, 1999

Real-Time Computing on Multicore Processors, Lui Sha, Marco Caccamo, Renato Mancuso, Jung-Eun Kim, and Man-Ki Yoon, Rodolfo Pellizzoni, Heechul Yun, Russell B. Kegley and Dennis R. Perlman, Greg Arundale and Richard Bradford, USA, 2016 Volume: 49, Issue: 9

Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications, Giorgio Buttazzo, Italy, 2011

A Communication Protocol for Hard and Soft Real-Time Systems, Christer Eriksson, Henrik Thane and Mikael Gustafsson, Sweden, 1996

Real-Time Systems, Brinkley Sprunt, Lui Sha, John Lehoczky, USA, 1989

Dynamic Integrated Scheduling of Hard Real-Time, Soft Real-Time and Non-Real-Time Processes, Scott A. Brandt, Scott Banachowski, Caixue Lin, Timothy Bisson, USA, 2003

Combining Hard Periodic and Soft Aperiodic Real-Time Task Scheduling on Heterogeneous Compute Resources, Hsiang-Kuo Tang, Parmesh Ramanathan, Katherine Compton, USA, 2011

Real-Time Systems, Kanaka Juvva, USA, 1998

Improving GPOS Real-time Responsiveness using vCPU Migration in an Embedded Multicore Virtualization Platform, Tsung-Han Lin, Hitoshi Mitake, Tatsuo Nakajima, Japa, 2013

RTOS, C. Brandolese, W. Fornaciari

En.wikibooks.org. (2017). Embedded Control Systems Design/Real Time Operating systems – Wikibooks, open books for an open world. [online] Available at: https://en.wikibooks.org/wiki/Embedded_Control_Systems_Design/Real_Time_Operating_systems

En.wikipedia.org. (2017). Real-time operating system. [online] Available at: https://en.wikipedia.org/wiki/Real-time_operating_system

Anon, (2017). [online] Available at: http://www.inf.ed.ac.uk/teaching/courses/es/PDFs/RTOS.pdf

IP Core to Leverage RTOS-Based Embedded Systems Reliability to Electromagnetic Interference, D. Silva, L.B. Poehls, J. Semião, C. Teixeira, J.P. Teixeira, M. Valdés, J. Freijedo, J.J. Rodríguez-Andina, F. Vargas, Brazil, Portugal, Spain, 2011

Real-Time Simulation Techniques Based on the RT0.k Object Modeling, K. H. (Kane) Kim, USA, 1996

TLSF: A New Dynamic Memory Allocator for Real-Time Systems, M. Masmano, I. Ripoll, A. Crespo, J. Real, Spain, 2004

Anon, (2017). [online] Available at: http://www.idc-online.com/technical_references/pdfs/electrical_engineering/Commercial_Real_-_Time_Operating_Systems.pdf