7th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS S u c e a v a, R o m a n i a, M a y 27 – 29, 2 0 0 4

HARETICK: A REAL-TIME COMPACT KERNEL FOR CRITICAL APPLICATIONS ON EMBEDDED PLATFORMS1

Mihai V. MICEA Department of Computer Science and Engineering POLITEHNICA University of Timisoara 2, Vasile Parvan Bv., 300223 – Timisoara, Romania Tel: +40 256 403271, Fax: +40 256 403214 [email protected]

Abstract. This paper discusses the problem of designing and implementing a real-time compact kernel for embedded and DSP-based platforms, able to provide a fully predictable execution environment for critical applications. Based on a sound and uniform set of models defined for time, signals and tasks, we describe the architecture and operating principles of a particular real-time kernel – "HARETICK". Its modular and compact architecture is designed around the key idea of enabling concurrent execution of hard real-time (HRT) and soft real-time (SRT) tasks in two separate contexts. The HRT execution context is based on non-preemptive scheduling algorithms and has precedence over the SRT context, which uses traditional, preemptive, priority- based scheduling techniques. Key words: real-time, embedded, operating kernel, non-preemptive, scheduling, temporal parameters

Introduction Although a very large number of projects have been lately developed in the field of real- Embedded systems and digital signal processing time and embedded systems, both in the industry (DSP) systems [1], [2], are widely used in and the academic communities, there still are today's digital control applications, requiring in many important issues to be addressed. most cases real-time behavior of the hardware- A large number of real-time systems are still components. Many applications have a being developed as ad-hoc implementations and critical impact on the environment and/or on the oriented mainly towards particular applications human factor with which they interact. – especially if they have critical impact on the Examples of such applications include: modern environment. Many other real-time systems flight control systems, fly-by-wire, auto-pilot, derive from traditional, time-sharing navigation equipment, rocket control and architectures, further adapted to real-time guiding, military communication equipment, applications and optimized in order to increase automotive control, industrial mechatronics, and their speed of reacting to events. Their main nuclear plant surveillance and control systems. disadvantage resides on the lack of compatibility There are two essential characteristics a between their hardware/software architecture, hardware-software platform has to meet in order designed to provide a good average case to provide correct operation results for critical behavior, and the requirements of real-time applications [3], [4], [5], [6] and [7]: applications that specify a correct behavior of the system even in worst case operating (a) The entire process of system/application conditions. development should include the time Another important issue regarding the coordinate, predictability of hard real-time systems is related (b) The system must provide maximum of to the unrestricted use of interrupts [7] and the predictability for the hard real-time tasks. associated asynchronous mechanisms and tasks.

1 This work is supported in parts by a grant from Motorola, Incorporated, through the PhD Collaboration Program "DALT- PhD/2001", with the Department of Computer Science and Engineering (DCSE) Timisoara. 16 Our current research focuses on developing function calls, unbounded program loops, suitable methodologies and architectures that dynamic resource allocation, must be avoided enable hard real-time systems to meet the two [3], [4], [5]. basic requirements previously stated in this Figure 1 depicts the OPEN-HARTS system section. The approach is based on studying and (Operating Environment for Hard Real-Time integrating proper models of time, signals and Systems), composed of two main subsystems. tasks, emphasizing on non-preemptive INVERTA (Integrated Visual Environment scheduling techniques. for Real-Time Application Analysis and This paper discusses the problem of Development), provides the with designing and implementing a real-time compact the necessary tools for designing, specifying, kernel for embedded and DSP-based platforms, programming, validating and analyzing the able to provide a fully predictable execution applications on a host (mobile) computer. environment for critical applications. HARETICK (Hard Real-Time Compact Kernel), which runs on the target platform and An Operating Environment for Real-Time provides two distinct execution contexts, Applications operating concurrently: a non-preemptive context for HRT tasks, along with a traditional, Our approach on designing and implementing preemptive context for SRT tasks. real-time systems for critical applications is based on the following key ideas: HARETICK (i) Based on the general acceptance that even the critical applications contain both types of INVERTA tasks – soft real-time (SRT) and hard real-

n time (HRT) tasks, the host platform must tio Embedded platform ica un accommodate properly the concurrent m k om lin execution of the two types of tasks. C Host (mobile) platform (ii) The use of interrupts and asynchronous mechanisms in the system generates Figure 1. General architecture of the OPEN- predictability problems, affecting its HARTS system capability to guarantee that the temporal After some real-time application has been specifications of hard real-time tasks can be successfully developed and analyzed within the met, in any operating conditions [3], [5], [7]. INVERTA, it is loaded on the target platform to (iii) In order to provide maximum be executed with the necessary predictability predictability for HRT tasks, non-preemptive under the HARETICK kernel. models and techniques are been studied and used for scheduling and executing hard real- The HARETICK Kernel: Characteristics and time and critical tasks [8], [9]. Components (iv) The entire process of system/application development should integrate the time HARETICK is a single-user, multitasking, coordinate within homogenous methods and hybrid real-time operating kernel for embedded models for each of its phases [5], [6]. and DSP-based platforms, designed to provide (v) For HRT systems design and maximum predictability to critical or hard real- implementation, the offline analysis of HRT time applications. "Hybrid real-time" refers to and critical tasks, prior to their execution on the fact that the kernel provides support for two the system, is an imperative requirement [6]. concurrent task execution environments: the (vi) Structures and mechanisms that generate HRT context, for the execution of hard real-time unpredictability in the system operation, such tasks in a non-preemptive manner, and the SRT as: interrupts, cache and virtual memories, context, for the execution of soft real-time (or pipelining, cycle stealing DMA, recursive regular) tasks in a classical, preemptive and 17 priority-based manner. Therefore, HARETICK DATALINK is a hybrid task (it contains both is able to guarantee that all the tasks scheduled SRT and HRT components) for managing the and executed within the HRT context will meet communications link of the HARETICK to a all their temporal specifications, even in the host computer. After being successfully worst case operating conditions. designed, programmed and analyzed within the As a consequence of the features mentioned INVERTA environment, a new application can above, HARETICK currently allows only one be loaded on the target platform to be executed. interrupt source: the Real Time Clock (RTC). The LOADER task is responsible for creating Figure 2 presents the main components of the the structures needed to represent the application kernel and their relationship. into the kernel. It can also be viewed as the

RESET application memory manager. The kernel user interface is implemented by the task BOOT MONITOR. SRT Context The kernel can provide various status and HRT Context SYSINIT execution reports upon request. STATREPO is SSCD HDIS TiLT responsible for gathering the necessary data from the system and for generating the reports. HSCD TiLT (Time Log Tool) is a subroutine DATALINK attached to the system executive HDIS, which

MONITOR stores in a dedicated memory buffer information regarding each execution of HRT tasks. LOADER

Execution Loops Execution STATREPO Execution Loop Execution Time Management and Representation User Application Time is a key operating dimension for real-time systems and it must be considered in all the Figure 2. Main HARETICK components development stages of such systems: formal At system startup (after RESET), the BOOT specification and verification, programming, sequence is launched, thus loading the other analysis, scheduling and execution [10], [11]. kernel components into memory. Then, system A model of time, suitable for embedded and initialization is performed. As seen from Figure DSP-based platforms, can be defined based on 2, the SYSINIT task belongs to the SRT context the characteristics of system clock generating (in fact, it is the first SRT task of the system). devices (here, the Real Time Clock, RTC). Thus, SYSINIT also starts the HRT execution context, the system temporal domain has a linear and by activating the RTC interrupts. Before discrete structure, and is limited to the left (i.e. termination, SYSINIT calls the SRT context there exists the initial time instant, t0 = 0, scheduler (SSCD) which will take over the corresponding to the system startup moment in scheduling and execution of the SRT tasks in the the absolute time domain). The time unit system. corresponds to an interval ΔtRTC from the The execution within the HRT context starts absolute time domain (Figure 3). with the system dispatcher/executive (HDIS), System startup which is activated by each of the RTC interrupt instance Absolute events. The first hard real-time task HDIS time τ0 τm τ launches is the HRT scheduler (HSCD). It uses System time t non-preemptive algorithms optimized for t0 = 0 t1 t2 tk Δt (system time unit) embedded platforms (a modified version of the RTC

EDF – Earliest Deadline First approach [8], [9]), T (temporal interval) k to fill in a Dispatch Table with HRT tasks and their calculated start times, in a cyclic manner. Figure 3. Absolute time and system time 18 The system time model has a metric, thus The "Scheduling Time" is used by the HRT allowing one to express quantitative scheduler (HSCD) to compute the execution relationships between time instances or schedule of the HRT context in a cycling intervals, and to calculate the length (duration) manner. At each execution of the HSCD of the time intervals, as in (1). (corresponding to the start of a new scheduling cycle), it also updates the system "Absolute ⎧T mk ττ 0 Δ⋅=−= tk RTC absolute time ⎨ (1) Time" with the duration of the previous cycle. ⎩ kk 0 =−= kttT timesystem Hard Real-Time Task Representation: the A correspondence between the absolute and ModX the system time domains can be stated as in (2). τ i τ ()i 00 Δ⋅−+= ttt RTC (2) Assuming the non-preemptive operation, we introduce a particular model for HRT tasks, The real-time applications designed to run on which can be used in real-time system the HARETICK kernel use the time model specification, analysis and execution. described above. The importance of time is A ModX (executable module) is defined as a emphasized on the kernel by the fact it periodic, modular, HRT task, with complete and implements three distinct structures for time strict temporal specifications, scheduled and management: the "Absolute Time" variable executed in non-preemptive context: (Sys_AbsTime), the "Scheduling Time" variable (HScd_TSched) and the Real Time Clock device M i ≡ ,,, FSPT (3) (RTC), composed of two cascaded timers. where: P = {P , P , P } is the set of input, Figure 4 presents the time management IN OUT GLB output and global parameters of M , respectively; structures in HARETICK for an implementation i S = {S , S } is the set of input and output with the Motorola DSP56307, a 24-bit digital IN OUT signals which M interacts with; F is the task's signal processor [12], [13]. i instruction set (its functional specification); and:

System memory ⎧ M M ii M M ii S j ⎫ 23 0 T = ⎨ pr ex ,,,, NTTTT ⎬ (4) ⎩ dl dy ⎭ RTC represents the set of temporal parameters of Mi, HScd_TSched_Hi 23 0 HScd_TSched_Md Timer1 in their respective order: period, execution time, Data Memory HScd_TSched_Lo Timer0 deadline, delay of execution during each period,

HSCD and execution count (see also Figure 5).

Sys_AbsTime_Hi Tdl Tdl

Sys_AbsTime_Md Tdy T Tdy T Interrupt ex ex Sys_AbsTime_Lo Sys_AbsTime Mi t

T (Period k) T (Period k+1) Figure 4. Time management structures and pr pr mechanisms in the HARETICK kernel Figure 5. Temporal parameters of ModX Mi The RTC measures the system real time and, The non-preemptive approach of modeling once started (by the SYSINIT task), it runs in a each HRT task of an application as a ModX, continuous and independent manner. The RTC requires actual values (in system time units, see timers are programmed by the system executive (1) and (2)) for a minimum of temporal (HDIS) to generate compare interrupts at parameters, such as the period, execution time particular time instants, corresponding to the and execution count. These values are set or start moments of scheduled HRT tasks. calculated during the application specification

19 and analysis phases, and will be verified during M i y N = 0 , specifies that Mi will not be the validation phase. These phases must be executed, although currently scheduled. performed prior to the actual scheduling and This type of ModX is called a Ghost execution of the application [6], in order to ModX; ensure maximum predictability. Two basic M i relationships between the temporal parameters y 0 N ∞<< , specifies that Mi will be of any ModX that must be verified are given in executed at the time instance (5) and (6): corresponding to the schedule. Before execution though, the kernel executive M i M i M i task decrements the execution count of M . 0 ex dl ≤≤< TTT pr (5) i An interesting feature of the ModX model is M M ii M i M i M i 0 dy dl ex dl ≤<−≤≤ TTTTT pr (6) that its execution count (and, therefore, its effective execution) can be controlled (changed) The formulas basically state that the execution at runtime by other ModXs or even by itself. time is a positive, non-zero value and it must be less than the deadline and the period of the Basic Kernel Operation ModX. The execution time is considered to be a Our discussion in this paper focuses on the constant value during the entire task operation, particularities of operation of the HRT tasks (the and to be equal to the task's WCET (Worst Case ModXs) within the HARETICK kernel. Execution Time) that results from the program INVERTA HARETICK timing analysis [5]. The modular approach of "load" "schedule" "dispatch" defining the HRT task model – the ModX, DATALINK LOADER HSCD HDIS enables automatic techniques of WCET System "unload" "terminate" estimation during application analysis. Tasks L1 Data From the structural and from the functional PDAGT PDT M1 M2 Memory Dispatch ... points of view, the ModX is a standalone ... Table Processor M4 Global ... software module, similar to the "basic block" L3 M4 App. M3 Graph Variables M4 M2 M3 element used in the compilers theory, and which M2 L2 M3 M1 is executed in non-preemptive context. M1 M4.DOut Program M3 Therefore, the ModX implements atomic L4 Memory M4.DOut M1 Data Memory operations, eliminating the need of System HSCD Application Graph Resources M4.DOut synchronization of concurrent access to shared M4.CODE M4.DOut Heap resources of the system or the application. M3.CODE Local Information exchange between ModXs is M2.CODE Variables Symbol M3 performed through the input, output and global M1.CODE Table parameters. As asynchronous mechanisms have been ModX NOP RDY SCD RUN GST eliminated from the model, input signals are States processed by their corresponding ModXs by periodic polling techniques. Figure 6. The ModX states and the general operation of the kernel While a ModX Mi, once loaded on the target platform, is scheduled for as long the application Figure 6 depicts the states of ModXs is running, its execution count parameter, N M i , belonging to an application during its operation specifies three possibilities for the effective within the kernel. The application is developed and analyzed on execution of Mi: a host (mobile) computer within the INVERTA M y N i ∞= , states continuous execution of environment. Its ModXs are unknown to the Mi (i.e. the ModX will be executed each HARETICK kernel and their status is defined as time it is scheduled); "NOP" (No Operation). 20 Loading of the application onto the target (λ + 1) ⋅ record_size (7) platform is performed by the LOADER task, and containing 1 special record (the first one) through the communication interface provided by the DATALINK task. The LOADER defines and λ normal records. The special record the following structures for representing the identifies the execution of HSCD itself, which application and its ModXs: will start the next scheduling cycle. The other records describe the schedule of ModXs to be y The Program Directed Acyclic Graph run during the current cycle. Table (PDAGT) describes the control and At a given moment, in the Dispatch Table, data dependences of each ModX; there can be several records referring to the y The Process Descriptor Table identifies execution of a particular ModX during the each ModX along with its parameters current scheduling cycle, if the ModX period is (including the temporal behavior, see (4)); short enough. Obviously, the start times will be y The compiled code area (Mi.CODE); different. y The output parameter area (Mi.DOut); As a result of the non-preemptive approach y The application's global parameter area; regarding task scheduling within the HRT y The symbol table. context, the start time of a particular ModX in After all the ModXs have been successfully the Dispatch Table complies with the relation: loaded into the system, they are in the "RDY" state, meaning they are Ready for Scheduling. M M ki M k M k The HRT scheduler (HSCD) applies st st ex tttt st +=+≥ Mk.WCET (8) particular non-preemptive scheduling algorithms to fill the Dispatch Table with ModX identifiers M i and their corresponding starting times, thus where: tst is the start time of the current defining a scheduling cycle, each time it is M k M k executed. ModX (Mi), and st and tt ex are the start time and the execution time, respectively, of the Dispatch Table ModX previously scheduled in the table (see Figure 7). λ All the ModXs referred in the Dispatch Table Circular . are in the "SCD" state (Scheduled). Buffer The HARETICK executive (HDIS) is M Mj t j activated each time an RTC interrupt occurs. p+1 st HDIS reads the current record in the Dispatch M λ Normal p Mi i Table (i.e. the ModX scheduled for execution at HDis_Tab_Ptr tst Records p−1 M (ModXs) the current time instance: Mi in Figure 7). HDIS Mk k (current position) tst also reads from the table the start time of the . next ModX (Mj) and programs the RTC timers to generate an interrupt when that ModX is 1 M j scheduled (i.e. at tst ). 0 HSCD HSCD Sys_HDis_Table tst Special Record: HDIS also reads the execution count of the HSCD (base address) current ModX, and if it has a finite, non-zero Offset PID Start Times value, the ModX will be launched in execution (after decrementing the count). In this case, it Figure 7. Structure of the Dispatch Table enters the "RUN" state. On the other hand, if the execution count is zero, it defines a Ghost ModX, equivalent to the The Dispatch Table (see Figure 7) is a special "GST" state. Ghost ModXs are not executed by circular buffer of length the kernel. 21 suffix (SD), which decides whether to restore Sched. Sched. Exec. Exec. HRT HRT HRT SRT SRT the SRT context and hand over the control (t3), if System

Start there is enough time remaining until the next

BOOT BOOT execution of a scheduled ModX. If not, SD waits to be interrupted by the RTC (the RUNIDLE SYSINIT SYSINIT state, started at instance t1 and interrupted at t2). The SRT tasks (L , etc) are scheduled and

t i 0 = 0 PD PD executed in a traditional, time-sharing and

HSCD priority-based manner, by the SRT scheduler HSCD (SS). RUNIDLE

SD Figure 8 also depicts the behavior of the t 1

SD kernel in the case of a Ghost ModX (Mj, t

PD scheduled a t3): PD calls directly the PD PD 2 Offline WCET Mi Runtime WCET Mi

HSCD SchedulingCycle component of the HRT executive. Mi

Mi SD Conclusion t 3 SD t SS 4 This paper discusses the problem of designing SSRT SS and implementing a real-time compact kernel for Li embedded and DSP-based platforms, able to t 5 PD PD Mj: Ghost ModX provide a fully predictable execution

SD environment for critical applications. Based on a Mj t 6 sound and uniform set of models defined for

SD time, signals and tasks, we describe the t Li 7 architecture and operating principles of a SRT particular real-time kernel – "HARETICK", t

PD which is designed around the key idea of 8 PD enabling concurrent execution of HRT and SRT HSCD HSCD tasks in two separate contexts. The HRT execution context is based on non-preemptive scheduling algorithms and has precedence over the SRT context, which uses traditional, preemptive, priority-based scheduling

techniques. Figure 8. Task scheduling and execution within the HARETICK kernel Considering our approach from another perspective, the entire concept, mechanisms and Figure 8 depicts an example of application structures used to support the HRT context in scheduling and execution on the HARETICK the HARETICK kernel, can be used as an kernel, within its two operating contexts: HRT extension to classical operating systems, which (for ModXs) and SRT. are based on time-sharing, preemptive task The HRT context is launched after system execution (equivalent to the SRT context), thus startup and initialization (t0), using the only providing them with the capability of interrupt allowed, the RTC interrupt. First, the guaranteeing the temporal behavior needed by prefix component of the HRT executive (PD) the HRT tasks of a particular application. The saves the SRT context and prepares the operations required to adapt a traditional system scheduler (HSCD) for execution, which, in turn, to the HRT context extension include setting the creates the list of ModXs (Mi, Mj) to be run highest priority to the RTC interrupt and during the current scheduling cycle. At blocking all other interrupts during HRT termination, every ModX calls the executive executions. 22 On the other hand, the SRT context helps also Engineers of Japan, Vol. 31, No. 7, pp. (726- to overcome the system's drastic lack of 736). efficiency when running the HRT context. The [5] R. Chapman, (1994) Program Timing scheduling and execution mechanisms for the Analysis, Technical Report, Dependable HRT tasks rely on pessimistic assumptions and Computing Systems Centre, University of York. evaluations of execution time and signal [6] K. Ramamritham, J. A. Stankovic, (1994) interaction (periodic polling). In the actual Scheduling Algortihms and Operating Systems operating conditions of the system, these Support for Real-Time Systems, in Proceedings conditions have a small probability of of the IEEE, Vol. 82, No. 1, pp. (55-67), occurrence, thus leading to many time intervals January. in which the system is idle. SRT tasks will then [7] . B. Stewart, (2001) Twenty-five Most be executed. Common Mistakes with Real-time Software Currently, the HARETICK kernel is partially Development, in 2001 Embedded Systems developed and tested with good results on a Conference, Class 270, San Francisco, April. Motorola DSP56307 platform. The HRT executive (HDIS) has been fully implemented [8] K. Jeffay, D. Stanat, C. Martel, (1991) On Non-Preemptive Scheduling of Periodic and and a preliminary version of scheduler (HSCD) th has been used to test the system with simple sets Sporadic Tasks, in Proceedings of the 12 IEEE of ModXs. All the tests proved a correct Real-Time Systems Symposium, San Antonio, behavior of the HRT applications with respect to Texas, IEEE Computer Society Press, pp. (129- their temporal specifications. 139), December. [9] L. George, N. Rivierre, M. Spuri, (1996) References Preemptive and Non-Preemptive Real-Time Uni- Processor Scheduling, Rapport de recherche, Nr. [1] V. Cretu., T. Jurca, M. V. Micea, I. Sora, 2966, Institut National de Recherche en (2003) Instrumentation and Measurement in Informatique et en Automatique, INRIA, Romania: Technical Developments at Rocquencourt, France, September. 'Politehnica' University of Timisoara, in IEEE [10] D. Chen, A. Mok, S. Baruah, (1998) On Instrumentation & Measurement Magazine, Vol. Modeling Real-time Task Systems, Lecture 6, No. 3, pp. (41-47), September. Notes in Computer Science, No. 1494, Springer- [2] M. V. Micea, M. Stratulat, D. Ardelean, D. Verlag, pp. (153-169), October. Aioanei, (2001) Implementing Professional [11] P. Bellini, R. Mattolini, P. Nesi, (2000) Audio Effects with DSPs, in Transactions on Temporal Logics for Real-time System Automatic Control and Computer Science, Vol. Specification, ACM Computing Surveys, Vol 46 (60), Periodica Politehnica, Timisoara, pp. 32, No. 1. (55-60). [12] Motorola, Inc., (2000) DSP56300: 24-Bit [3] J. A. Stankovic, (1992) Real-Time Digital Signal Processor: Family Manual, Rev. Computing, Invited paper, BYTE, pp. (155-160), 3, DSP56300FM/AD, Semiconductor Products August. Sector, DSP Division, Austin, USA, November. [4] J. A. Stankovic, (1992) Distributed Real- [13] Motorola, Inc., (1998) DSP56307: 24-Bit Time Computing: The Next Generation, Invited Digital Signal Processor: User's Manual, keynote paper, Special issue of Journal of the DSP56307UM/D, Revision 0, 08/10/98, SPS, Society of Instrumentation and Control DSP Division, Austin, USA, August.

23