The architecture of RTOS+ 

Context in source publication

Context 1

... accessing the physical machine in order to run applica- tions. A general-purpose operating system may be perceived as an agent between the hardware and resources of a computer and the applica- tions and users. An operating system may be divided into three subsystems known as those of the kernel or system management , the resource management , and the process management (Dijkstra, 1968; Brinch-Hansen, 1971; Liu & Layland, 1973; Peterson & Silberschantz, 1985; Anderson et al., 1989; McDermid, 1991; Deitel & Kogan, 1992; Tanenbaum, 1994; Viscarola & Mason, 2001; Silberschatz et al., 2003; Wang, 2004, 2007). The kernel of an operating system is a set of central components for computing, including CPU scheduling and process manage- ment. The resource management subsystem is a set of supporting functions for various system resources and user interfaces. The process management subsystem is a set of transition manipulation mechanisms for processes and threads interacting with the system kernel and resources. A real-time operating system (RTOS) is an operating system that supports and guarantees timely responses to external and internal events of real-time systems (Laplante, 1977; Sha et al., 1990; ISO/IEC, 1996; Ford, 1997; Bollella et al., 2002; Kreuzinger et al., 2002; Ngolah, Wang, & Tan, 2004). An RTOS monitors, responds to, and controls an external environment, which is con- nected to the computer system through sensors, actuators, or other input-output (I/O) devices. In a real-time system in general and an RTOS in particular, the correctness of system behaviors depends not only on the logical results of com- putation but also on the time point at which the results are obtained. Real-time systems can be divided into hard and soft real-time systems. In the former, a failure to meet timing constraints will be of serious consequences, while in the latter, a timing failure may not significantly affect the functioning of the system. A great variety of RTOS’s have been developed in the last decades (Lewis & Berg, 1998; Labrosse, 1999; Yodaiken, 1999; Rivas & Harbour, 2001; Lamie, 2008; ETTX, 2009). The existing RTOS’s are characterized as target- machine-specific, implementation-dependent, and not formally modeled. Therefore, they are usually not portable as a generic real-time oper- ating system to be seamlessly incorporated into real-time or embedded system implementations. Problems often faced by RTOS’s are CPU and tasks scheduling, time/event management, and resource management. Efficient and precise methodologies and notations for describing solutions to these problems are critical in RTOS design and implementation. Generally, RTOS’s require multitasking, process threads, and a suf- ficient number of interrupt levels to deal with the random interrupt mechanisms in real-time systems. In modern RTOS’s, multitasking is a technique used for enabling multiple tasks to share a single processor. A thread is individual execution of a process in order to handle concur- rent tasks. In addition, an interrupt is a request of an external device or internal process that causes the operating system to suspend the execution of a current low priority task, serve the interrupt, and hand control back to the interrupted process. This paper develops a comprehensive design paradigm of the formal real-time operat- ing system (RTOS+) in a top-down approach on the basis of the RTPA methodology. The conceptual model, architectural model, and the static/dynamic behavioral models of RTOS+ are systematically presented. In the remainder of this paper, the conceptual model of RTOS+ is described as the initial requirements for the system. The architectural model of RTOS+ is created based on the conceptual model using the RTPA architectural modeling methodolo- gies and refined by a set of unified data models (UDMs). Then, the static behaviors of RTOS+ are specified and refined by a set of unified process models (UPMs). The dynamic behaviors of RTOS+ are specified and refined by process priority allocation, process scheduling, and system dispatching models. Due to its exces- sive length and complexity, this paper presents the first part of RTOS+ on its conceptual and architectural models, followed in serial by another paper that presents the second part of this work on the static and dynamic behavioral models of RTOS+ (Wang et al., 2010c). The multi-task and multithread real-time operat- ing system (RTOS+) is a portable and rigorous RTOS with formal architectural models and behavioral processes. As a preparation, this sec- tion presents the conceptual models of RTOS+ from the facets of its architectures, resources, and processes (tasks), as well as their interac- tions. The top-level framework and the process scheduling scheme of RTOS+ are informally introduced. RTOS+ is designed for handling event-, time-, and interrupt-driven processes as a potable real- time system platform. The conceptual architec- ture of RTOS+ is described as shown in Figure 1, where interactions between system resources, components, and internal control models are illustrated. The conceptual architecture of RTOS+ can be divided into three subsystems: a) the processor and the CPU/process/system schedulers, b) the resource/event controllers, and c) the process control structures. The schedulers for CPU, processes, and the entire system are the innermost operating system kernel that directly controls the CPU as well as system tasks, processes, events, and resources. The process scheduling mechanism of RTOS+ is priority-based. A flexible priority scheduling technique is adopted in RTOS+, where the priority of a given process for a task is assigned based on its type and importance when it is created. Processes are categorized into five priority levels known as the high and low periodic interrupts, device I/O interrupt, user application interrupts, and the base levels. A process, when it is created, will be put into a proper queue corresponding to its predefined priority level. The resources of RTOS+ are modeled by the entities of memory, time, devices (ports), interrupt facilities, files, and internal control structures such as dispatching queues, system/ device/event/memory, and process control blocks. The resources in RTOS+ can be classi- fied into three categories known as the system resources (memory, device, and files), event resources (system timing events, interrupts, and I/O events), and resource control structures (running processes and tasks in other states). The process scheduling of RTOS+ is priority- based and event-driven as shown in Figure 2. The process scheduler is responsible for de- termining which process should be executed on the processor at a given time interval of CUP time. The dynamic performance of tasks in RTOS+ is embodied by a series of coherent processes and threads. A task is created by the system (State 1) as a process in the waiting queue with an assigned priority based on its importance and timing requirement. When the required resource is available, the process pending in the waiting queue will be scheduled into a ready queue with the proper priority. The process scheduler dispatches tasks in the high ready queues before scheduling those in the low ready queue in State 2. It continuously checks the ready queues to see if there is any process ready to be run in State 3. If there are ready processes in the queue, it compares the priorities of the currently executing process and that of the first process in the queue. If the first process in the queue has a higher priority, it pre-empts the CPU from the currently run- ning process, assigns the CPU to the higher priority process from the queue, and sends the lower priority process to the delayed queue in State 6. The delayed process is re-dispatched to the appropriate ready queue to be executed when the CPU becomes available. If there are two processes of the same priority, the process scheduler treats them on a first-come-first- serve basis. A scheduled process executes on the CPU until it is either completed (State 4) or is sus- pended due to lack of a resource or pending for an event (State 7). As illustrated in Figure 2, there are three conditions that may cause a running process to be re-scheduled out of run- ning: a) Interrupted by a process or event with higher priority; b) Timed-out for a pre-scheduled time-interval of CPU; and c) Waiting for a specific device or event. An interrupted running process is sent to the interrupted queue (State 5) and later returned to the appropriate ready queue when the interrupt service (State 9) is over. A process that has exhausted its assigned time interval must go to the delayed queue (State 6), while it can be re-scheduled back to one of the ready queues immediately for wait- ing for the next available CPU executing inter- val. However, a process that can no longer be executed due to lack of memory or resource has to be sent to the suspended queue (State 7 ) , which may return to the appropriate ready queue when the pending resource has become avail- able. A process interrupted, delayed, or sus- pended at States 5, 6, or 7, respectively, may be killed (State 8) by the process scheduler in case there is a persistent unavailability on de- manded resources or CPU time. More rigorous description of the system dispatching and process scheduling strategies and algorithms will be elaborated by the entire dynamic behaviors of RTOS+, particularly the CPUScheduler ST (Figure 18), ProcessSchedul- er ST (Figure 31), and SystemDispatcher ST (Fig. 30) from the bottom up. On the basis of the conceptual models of RTOS+ as described in Figs. 1 and 2, the formal design models for RTOS+ can be developed in a rigorous and systematical approach using Real-Time Process Algebra (RTPA) (Wang, 2002, 2008a, 2008c). According to the RTPA methodology for system modeling, specifica- tion, and refinement (Wang, 2007, 2008a), the top-level RTPA specification of RTOS+ is given ...