REFLECTIVE ONLINE RECONFIGURATION OF REAL-TIME APPLICATIONS HAVING TASKS WITH STATIC PRIORITIES

Transcription

1 BULETINUL INSTITUTULUI POLITEHNIC DIN IAŞI Publicat de Universitatea Tehnică Gheorghe Asachi din Iaşi Tomul LVIII (LXII), Fasc. 1, 2012 SecŃia AUTOMATICĂ şi CALCULATOARE REFLECTIVE ONLINE RECONFIGURATION OF REAL-TIME APPLICATIONS HAVING TASKS WITH STATIC PRIORITIES BY CORINA AGRIGOROAIE, LAVINIA FERARIU and CĂTĂLIN BRĂESCU Gheorghe Asachi Technical University of Iaşi, Faculty of Automatic Control and Computer Engineering Received: September 2, 2011 Accepted for publication: November 7, 2011 Abstract. This paper addresses to online reflective reconfiguration of real time applications. Both periodic and aperiodic processes compliant with precedence constraints and real time constraints are accepted. The suggested approach is targeted at providing increased runtime predictability for the real time systems working with static priorities. Concerning this purpose, the reconfiguration algorithm performs online feasibility tests and lack/utilisation s evaluations, and triggers the commutation between predefined running scenarios, whenever excessive under-loading or unfeasible over-loading is detected. A specific formalism is introduced to describe the allowed reconfigurations. This formalism is also exploited within a software tool which permits a simple definition of all necessary data inputs and their automatic export to the real time system. The suggested reconfiguration is compatible with a very large range of applications. The design idea is illustrated for OSEK/VDX, by making use of the available tracing functions for time monitoring an on-line reconfiguration. Key words: real time systems, embedded systems, static priorities, scheduling Mathematics Subject Classification: 68M20, 68N25, 68W27, 93C95. Corresponding author; cagrigoroaie@tuiasi.ro

2 10 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu 1. Introduction Real-time applications are widely employed in various engineering fields, as usually the desired functionalities have to be related to specific timelines and time constraints (Gansle, 2007). A real-time application is modularly built as a set of processes Tasks and Interrupt Service Routines (ISRs), which have to share the available active resources in order to provide the targeted behavior. Within this framework, the Real Time Operating System (RTOS) plays a major role. It is responsible with a safe context switching and tasks arbitration. Additionally, most real time operating systems provide facilities for reliable inter-process communication and flexible sharing of passive resources, thus making the development of multitasking applications easier and suppler (Zurawski, 2006; White, 2011). For mono-processor applications, no allocation mechanisms are necessary. Hence, the runtime behavior is decided by the scheduler, which supervises the execution of the tasks subject to the imposed real-time constraints and precedence constraints. Please note that the execution of ISRs result from the interrupt handling mechanisms specific to the employed processor and to the external interrupt controllers, which usually ensure that the ISR priorities are higher than the maximum priority of a task. However, although not supervised by the scheduler, the ISRs execution is decisive in achieving a feasible task schedule on a shared processor (Gansle, 2007; Zurawski, 2006). In preemptive mode, the scheduler is implicitly activated periodically or event driven. The further case gives increased responsiveness, as it reshapes the execution sequence whenever the configuration of the ready tasks is changed. Almost all of the real time operating systems work with dynamic scheduling and static priorities. This means that, whenever called, the scheduler gives the control to one of the highest priority tasks which are ready at that instant time, without making the scheduler responsible for any task priority changing. This offers increased safety and simplicity which is crucial in critical industrial real-time applications, although it translates to the need of performing extensive offline feasibility analysis. Basically, one has to determine the worst running scenario in terms of the imposed constraints and to design the application subject to the accomplishment of all critical deadlines in this most unfavorable case (Buttazo, 2006). The common solution recommends reserving an amount of processor s execution time for unpredictable, non-periodic requests and unexpected delays, at the payoff of obtaining a reduced utilization, corresponding to the feasible schedule built for the worst running scenario (Yao et al., 2010; Yao et al., 2011). Hence, the capabilities of the available hardware resources are not fully exploited in other running conditions, and one assumes decreased overall application performances (e.g. reduced set of functionalities, smaller precision in certain numerical computations, etc.) (White, 2011).

3 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, Commonly, the critical functionalities are implemented by periodic or quasi-periodic tasks, assigned with hard deadlines. In the absence of aperiodic processes, the feasibility analysis can be limited to a hyper-period. However, this configuration cannot ensure proper responsiveness to external events and, unfortunately, finding the worst running scenario becomes a very difficult assignment whenever the application comprises aperiodic, dependent processes featuring multiple execution branches with different execution times (Buttazo, 2006; Gansle, 2007). Some theorems state the optimality of several scheduling algorithms with static priorities for the simplified case of multitasking, mono-processor applications with preemptive, independent, periodic tasks. One can mention here the Rate Monotonic (RM) and the Deadline Monotonic (DM) policies, which sort the tasks according to their periods or relative deadlines, respectively. However, as practical applications usually violate at least one of the former premises, the runtime optimality is no longer guaranteed. It is worth mentioning that similar mathematical results are also available for some dynamic scheduling policies, for the same restrictive configurations of the realtime applications, only (Buttazo, 2006). Considering the former, it is of great interest to endow the scheduling algorithm with the capability of triggering certain application s reconfigurations, whenever unexpected running conditions can induce constraints violation. No matter if the ROTS work with static or dynamic priorities, this translates to the need of performing additional online feasibility verifications and predictions in order to enable various reflective reconfigurations (Buttazo, 2006) e.g. the use of different frequencies for the periodic tasks and/or the avoidance of optional sequences inside tasks and ISRs. These reconfigurations can give increased efficiency when dealing with realtime applications in a variable execution environment. In fact, they exceed the capabilities of any classic dynamic scheduling algorithms, which are limited to adjusting a single task parameter, namely the priority (Zurawski, 2006). Concerning this purpose, the paper suggests an on-line reconfiguration of the real-time applications which involve scheduling algorithm with static priorities and dependent tasks related by precedence constraints. Using a PC friendly interface, the designer can simply describe the accepted running scenarios and the imposed constraints. These configurations are encrypted in appropriate data structures which are accessible for the embedded system via several files (automatically generated according to predefined templates). During the runtime exploitation, the proposed algorithm monitors the execution time of each running process in order to predict the feasibility of the active execution scenario, as well as the corresponding utilization. Whenever overloading or under-loading conditions are detected, the algorithm automatically triggers the switch to another execution scenario, better tailored to the current running environment.

4 12 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu Compared to other similar work, the main benefits of this approach result from the fact that it supports improved robustness (via the on-line feasibility verification test), as well as higher average utilization and increased flexibility (via the on-line reconfiguration of the processes). Please note that unlike the previous versions presented in (Brăescu & Ferariu, 2010) and (Brăescu & Ferariu, 2011), this release provides extended capabilities for configuring various running scenarios and commutation conditions, as detailed in section 4. The algorithm was implemented for OSEK/VDX, which is one of the most popular real time operating systems in automotive industry. However, the idea can be easily applied to any other operating system with static priorities, as the runtime monitoring is performed using services available in almost of them. The rest of the paper is organized as follows. Section 2 outlines the most important issues related to real time scheduling algorithms and Section 3 revises the basic facilities of the adopted RTOS, namely OSEK/VDX. The goals of the suggested online reconfiguration application are presented in Section 4, followed, in Section 5, by a detailed description of the main algorithm s components. The usability of the approach is illustrated in Section 6 and final remarks are summarized in Section Overview on Static Priority Scheduling Algorithms The theory of static priorities based scheduling was introduced by Liu and Layland (1973). They firstly proved that, in particular working conditions formerly enumerated RM is an optimal assignment with static priorities, meaning that, if a task set can be feasibly scheduled with any other static priority based policy, then RM leads to a feasible sequence, too (Sha et al., 2004). Moreover, Liu and Layland showed that RM guarantees a feasible schedule for any large set of tasks as long as the processor utilization is below 70%. Current research trends in this field are mainly configured as extension of this preliminary analysis, being meant to deal with the cases when the assumptions made by Liu and Layland are not satisfied: exact feasibility analysis, task interaction analysis, execution of aperiodic and sporadic tasks, overload management, management of simplifications and scheduling in multiprocessor distributed systems (Liu & Layland, 1973). The feasibility analysis thread tries to find necessary and sufficient tests that permit to guarantee higher utilization levels. Lehoczky states that a real average utilization less than 88% is a sufficient condition for the optimality of RM applied to large, randomly chosen task sets (Lehoczky et al., 1989). If the periods are nearly harmonically, then the utilization can even reach a level of 100% (Sha & Goodenough, 1990). A new sufficient test known as the Hyperbolic Bound was determined by Bini and Buttazzo (Bini et al., 2003). It

5 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, illustrates that the feasibility bound improves if the periods have harmonic relations. The feasibility analysis under fixed priority scheduling with limited preemption addresses the problem of scheduling a set of real-time tasks having fixed priorities and fixed preemption points (Yao et al., 2010; Yao et al., 2011). Under specific, but not restrictive assumptions, the feasibility analysis is simplified. Efficient feasibility tests can be used leading to advantages like reduced context switch costs, easy access to shared resources and more predictable estimations of worst-case execution times. Another important research direction focuses on overload management. Usually the workload is estimated by taking into account the worst-case execution times and the minimum inter-release time of each task, which are very difficult to determine. There are two main approaches trying to deal with this problem: prevent the overload situations or tolerate the overloads. The former is based on considering safer assumptions about workload, leading most of the times to a low degree of processor utilization. A better way to deal with overload situations is based on application reconfiguration and is done by providing a reduced, yet acceptable level of service. Server tasks can be used to isolate the effect of overloading (Ramos-Thuel & Stosnider, 1991) or tasks can be divided in mandatory and optional subtasks (Shih et al., 1989). Run-time feasibility verification and real-time constraints monitoring can be employed within event-driven operating systems with static priorities in order to assure the application s dynamic reconfiguration whilst preserving high average resource utilization (Brăescu & Ferariu, 2010; Brăescu & Ferariu, 2011; Brăescu et al., 2010). 3. OSEK/VDX Basic Facilities The proposed approach exploits the characteristics of OSEK/VDX, however the solution is applicable to any other RTOS with static priorities based scheduling mechanism. It should be noticed that OSEK/VDX is event driven and requires the static configuration of all necessary standard objects (including the static configuration of tasks priorities) (Lemieux, 2001). OSEK/VDX accepts basic and extended tasks. The basic tasks can be either in ready, running or suspended state. On the other hand, the extended tasks are the owners of one or multiple events and, for synchronization purposes, can switch to the waiting state since the waited owned events are set. Also note that OSEK/VDX offers API services which simplify the implementation of the preceding constraints and allows an easy design of periodic task, via alarms and counters management (Lemieux, 2001). In most applications running on embedded systems, ISRs represent the critical interface for/with the external asynchronous devices (Zurawski, 2006). In this attempt, OSEK/VDX provides a subset of API services compatible with ISRs, which mainly facilitate inter-process communication, resource sharing,

6 14 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu synchronization with extended tasks via events and protection of critical sections (Lemieux, 2001). Resource sharing is solved by means of the ceiling protocol which implements the priority inference mechanism in order to speed up resource liberation in lower priority tasks. Also, OSEK/VDX gives the possibility to asynchronously pass information between the application s processes by means of postal boxes or queues of messages, with reduced risk of data corruption, whilst benefiting of diverse types of transmission notifications. As support for application monitoring and debug, OSEK/VDX allows customization of predefined hooks and provides some tracing functions, which, for instance, could be tailored for updating the execution times of running processes and consequently, for determining the lacks in different running scenarios (Lemieux, 2001). 4. Problem Statement Let us consider a real time application developed for a RTOS based on dynamic scheduling with static priorities. Let us also consider a real time application defined for k distinct running scenarios, S i, i = 1,,k, each one supported by means of a set of processes (ISRs and periodic/sporadic tasks), denoted P. A process may be used in multiple running scenarios, possibly Si with different running options (e.g. different periods, different sequences of instructions), yet with the same static priority. If the whole set of processes used in all predefined scenarios is noted with P, it results that P S P, i=1,..., k and P = P k Si i=1, with accepted non-disjoint P Si i. Within a certain running scenario S i, the processes must met the preceding constraints ( RP i ) and the real-time constraints ( RT ). RP are embedded in the precedence graph associated with S i, whilst i i RT i are specified by the release time ( j r ) and the relative deadline ( D j ) associated to any process P j belonging to P. Please Si note that any S i implicitly satisfies all RP i, but it can violate RT i in certain running conditions, corresponding to unexpected delays/loading which are not portrayed by the predefined precedence graph (e.g. additional interrupt requests, additional execution of tasks, etc.). The application is allowed to switch in some conditions from S i to S j without altering data consistency. More precisely, one considers that C ij = 1 enables a switch from S i to S j (the next process in S j being obtained in relation to the current task in S i ). At any time instant t with C ij =1, S j is defined as a valid scenario for S i. Obviously C ii = 1, i= 1,..., k, as

7 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, any scenario is valid for itself. For instance, the running scenarios can be drawn for the same time interval (e. g. the hyper-period of the periodic tasks) and the commutations from S i to S j can be allowed at the end of S i to the beginning of S j only. However, these customizations are not compulsory. Given the set P of processes and the set of running scenarios S i, described by the constraints RP i, RT i, i = 1,, k and the commutation conditions C, i, j = 1,, k, the aim of the suggested online reconfiguration ij algorithm is to determine, at each reconfiguration instant, what valid scenario S i ensures: (1) minimum tardiness computed subject to RT i ; (2) maximal processor s utilization. Please note that the problem above is not solved in multi-objective sense, the objective (2) being addressed merely if the objective (1) leads to multiple optimal scenarios, between which the algorithm has to discriminate. Whenever the current running scenario is not optimal, the reconfiguration algorithm has to trigger the commutation to the valid optimal, one. All feasible schedules are globally optimal in terms of the objective (1). Hence, if at least one of the valid alternative scenarios is feasible in any reconfiguration point, then the reconfiguration algorithm guarantees the feasibility of the whole schedule. Besides, if in a certain reconfiguration point more than one valid alternative scenario is feasible, then the one leading to higher processor loading is preferred, as this scenario is expected to provide better overall performances in terms of application usability (e.g. higher precision, more errors verifications, more facilities, etc.). If in some reconfiguration points no alternative scenario is valid, the reconfiguration cannot take place. Therefore, in these cases the runtime tests could be useful for a consistent global tardiness/utilization evaluation, only. For OSEK/VDX, all the objects corresponding to the elements of P must be configured beforehand. Hence, they are available when the set of accepted running scenarios is defined, but no running scenario can change the static attributes specified in *.oil files. Moreover, given the available tracing facilities (Lemieux, 2001), all context switches can easily stand as reconfiguration points, too. Although the reconfiguration algorithm may use only a subset of them for on-line feasibility tests and scenario switches. Considering this, the reconfiguration algorithm (Fig. 1) compliant with (1) and (2) should provide facilities to: define the running scenarios S i, define the constraints RP i and RT i, as well as the commutation conditions C ij, i, j = 1,, k; update the execution times of running process; update necessary information (tardiness/lacks, utilizations, etc.) related to objectives (1) and (2) for all available valid scenarios and determine the optimal valid scenario;

8 16 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu reconfigure the application in compliance with another recommended running scenario. OSEK/VDK application Reconfiguration tool *. oil *.C, *.h files Tasks with multiple running options script.h init.h Configuration Manager (C# - GUI) - configuration of running scenarios & constraints Time monitor Off-line initialization new running scenario execution times Runtime reconfiguration - find optimal valid scenario & command reconfiguration On-line Fig. 1 Main components of the reconfiguration algorithm. A software solution compliant with the above mentioned specifications is described in Section 5. It allows a simpler configuration of various categories of running scenarios/constraints. This lies in an easy customized version of the reconfiguration algorithm for a wider range of real time applications, with few required additional interventions over the source code. 5. Online Reconfiguration of OSEK/VDX Applications The reconfiguration algorithm design is carried out assuming that all running scenarios are drawn for the same time interval, denoted in the following as the hyper-period of the application. Within each running scenario, the aperiodic/sporadic processes may have different predefined number of activations. During runtime exploitation, a higher number of activations is interpreted as an unexpected overloading. The proposed online reflective reconfiguration is described in compliance with the formalism introduced in Section The Off-line Configuration Manager All necessary initial settings concerning running scenarios/constraints allowed within the OSEK application have to be made offline, by means of a specialized Configuration Manager developed in C#. Its GUI provides an intuitive and simple way for configuring the precedence graph describing the

9 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, available scenarios, for setting the options of their tasks and for selecting the starting scenario (Fig. 1) and valid inter-scenarios commutations. The information regarding the TASK objects available in *.oil file is imported beforehand within the Configuration Manager s workspace (Fig. 1). Therefore, the precedence graph configuration can be done by selecting the nodes of the graph from the available imported set of tasks and by drawing the directed edges between the existing vertices. Typical editing facilities are provided, including vertices drag & drop, edge deletions, etc. The Configuration Manager also asks for additional information concerning the tasks used in the each running scenario, namely the initial estimations of their execution times, the deadlines and the running options used within each scenario. For each task, the later parameter defines the sequence of instructions which has to be executed, e.g. the number of iterations for all inner loops, the Boolean values controlling certain conditional instructions, etc. The initial estimation execution time is used for proper initialization, being afterwards updated during runtime monitoring. A distinct GUI tab indicates the starting running scenario and the interscenarios valid commutations. For the sake of simplicity, only the commutations available for any runtime instant are drawn. The commutation graph uses the available running scenarios within its nodes. Any directed arch linking two nodes indicates a valid commutation. The configuration tool passes all related data to the OSEK/VDX application via two automatically generated files, namely init.h and scripts.h. Once a running scenario is saved, the Roy-Warshall matrix corresponding to its graph, together with additional information concerning its tasks (priorities, deadlines and initial estimations of the execution times) are concatenated to init.h. The file scripts.h is generated via Configure Script GUI command. It holds the hyper-period of the application, the number of predefined running scenarios, as well as the pairs ( i, j) corresponding to any allowed transitions from S i to S j. For the sake of simplicity, these pairs could be sorted for each scenario i, in terms of the expected utilization/lack provided by the target scenario j The Time Monitor The execution times of the running processes are measured using an onchip timer working with automatic constant reloading. Context switches occurred during runtime exploitation are detected via OSEK/VDX tracing facilities. In this attempt, Tracer_Init(), which is automatically called at OSEK/VDX initialization, initializes specific data structures. The data structure associated to a task stores general information (the number of available running

10 18 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu options, the period, the deadline), information updated by the time monitor which is useful for future configurations (execution time obtained at the most recent previous execution, maximum and minimum execution times resulted during application s monitoring), as well as information necessary for determining the execution time of the current active instance. Knowing that Tracer_TaskChange() is called at every context commutation, the algorithm identifies the switches to and from the running state and measures the lengths of all disjoint time intervals in which the task stays in running state (Fig. 2). Fig. 2 Measuring a task s continuous RUNNING state time span. Here, t1 and t2 designate the extremities of such an interval, detected with Tracer_TaskChange(). To accomplish this, the timer s overflows are detected, by using the number of timer automatic re-loadings (var) which is updated by an ISR process, the current value of the timer (PITCNT) and the maximum constant loaded in the timer (MAXPIT). Afterwards, the total execution time results by summation (Fig. 3), final result being validated only when the task commutates to the suspended state. This strategy permits a correct evaluation of the execution time, even for the tasks which are preempted or switch to waiting states during their execution.

11 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, Fig. 3 The computation of the execution time within Tracer_TaskChange() Runtime Reconfiguration Basically, the runtime feasibility test requires checking the current task and its successors deadlines, as specified within the precedence graph of the running scenario. If not explicitly set, the default relative deadline of a periodic task is its period. The test is performed using the most recent execution times for the predecessors of the running process and the maximum execution time of its successors. For each running scenario, the feasibility tests results are stored within an array with k elements ( k = P ), Ver[k]; value 1/0 of Ver[j-1] means that P j violates/satisfies its real time constraints. During the feasibility test, the algorithm can also compute the corresponding running scenario s tardiness or lack/utilization. This information is necessary for future decisions. Assuming the current running scenario S i, at every verification point, the algorithm is carried out as described in the following: using the most current updates performed by the time monitor, verify the feasibility of S i ; if S i is feasible, under-loading is checked: the algorithm finds all the valid running scenarios and tests their feasibility; the algorithm marks the winner scenario to be configured in the next reconfiguration point, looking to all the feasible valid scenarios and the current scenario; if S i is non-feasible, overloading is solved: the algorithm finds all the valid running scenarios and tests their feasibility; if at least one valid scenario is

12 20 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu valid, the winner scenario is the feasible valid one with best lack/utilization; if no valid scenario is feasible, the winner scenario is the one with minimum tardiness, selected from all the valid scenarios and the current scenario. The feasibility test and the related reconfiguration procedure can be included in Tracer_TaskChange(), if runtime verification is allowed at context switching instants. Any decimation can be also considered, e.g. verifications can be enabled solely if the task commutates to SUSPENDED state. The reconfiguration points can be selected from the verification points (the whole set or a subset). For the exemplification given in Section 6, the set of runtime verification points is identical with the set of the reconfiguration points and includes the time instants corresponding to all the commutations performed from SUSPENDED state to RUNNING state by the tasks employed in the predefined scenarios. 6. Study Case The usability of suggested algorithm is illustrated on a particular OSEK/VDX application developed for a MC9S12XDP512 based architecture. The main goal of the experimental trials is to provide more intuitive explanations concerning the reconfiguration algorithm s design and behavior. The real time application comprises ISR processes, as well as 9 tasks (periodic and aperiodic). These processes define the P set. Four tasks (denoted with T1 T4) are implemented according to the template presented in Fig. 4, hence are compliant with multiple running options. Only these processes are used to define the running scenarios, namely P = T,...,T }, i =1,.., 5. A Si { 1 4 particular running option specifies the values of Init1, Init2, VAL1, VAL2, step1, step2, and obviously, leads to a distinct execution time and utilization. Within the running scenarios, the rest of processes are interpreted as unexpected overloading. T1 and T4 are periodic T1 (period 5s), T4 (period 2s), whilst T2, T3 are aperiodic. The periods of T1 and T4 stand also as relative deadlines, respectively. The precedence constraints force T1 to be a mandatory predecessor of T2 and T3. TASK(Ti) { for(i = Init1; i < VAL1; i += step1) for(j = Init2; j < VAL2; j += step2) { ; } //Li: processing data[i][j];..} Fig. 4 The template accepted for T1, T2, T3 and T4. All running scenarios S 1,.., S5, follow the same precedence graph (Fig. 5 left image), but employ different running options for T1, as detailed in Table 1.

13 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, In any reconfiguration point, the commutation from S 5 to any other scenario is valid, namely C 5 j = 1, for any j = 1,.., 5 (Fig 5 right image). S 5 is set as the initial running scenario. Time monitoring is performed at every task context switching, yet the runtime verifications/reconfigurations are done whenever an instance of T1 T4 begins its execution, due to the commutation from SUSPENDED state. Fig. 5 Initial profile of the running scenarios. Table 1 Available Running Scenarios Scenario VAL1 VAL2 S1 3 2 S S S S The application is traced over a hyper-period of 10 s, by making use of PIT2 for time monitoring. The execution times resulted during runtime are listed in Table 2, considering the experimental trials with and without runtime verifications.

14 22 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu Table 2 The Execution Times [µs] Obtained Experimentally for the Running Scenarios S1 to S5 Without (1) or with (2) Runtime Verifications Scr. no. 1 Scr. no. 2 Scr. no. 3 Scr. no. 4 Scr. no. 5 T Id Task Name Minimum Maxim Last registered (1) (2) (1) (2) (1) (2) 0 Task_Cyclic Task_Cyclic Task_Wdm MAX Bgnd_task Task_1s T T T T Task_Cyclic Task_Cyclic Task_Wdm MAX Bgnd_task Task_1s T T T T Task_Cyclic MAX Task_Cyclic Task_Wdm MAX MAX Bgnd_task Task_1s T T T T Task_Cyclic Task_Cyclic Task_Wdm MAX Bgnd_task Task_1s T T T T Task_Cyclic MAX Task_Cyclic Task_Wdm Bgnd_task Task_1s T T T T

15 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, S5 is the starting scenario. Because it offers much higher utilization than any other running scenario, S5 is declared the optimal one, while the reconfiguration algorithm detects it as feasible. However, as listed in Table 2 and 3, within S 5, T1 together with its successors T2 and T3 violate deadlines. So the reconfiguration algorithm has to search for a feasible solution within the set of valid scenarios { S 1,.., S4}. According to Table 2, the optimal scenario is S 4. This commutation is also revealed in Table 3. Table 3 Runtime Execution with Online Reconfiguration Results on LCD display Explanations 1 At t = ms, T4 starts its execution. T4 task ends in rtl = ms, without violating its deadline. 2 At t = ms, whilst T1 is running, a deadline violation is detected for T1, T2, T3; this triggers the switching from S5 to S4. 3 At t = s, T3 starts its execution. T3 terminates without violating its deadline. 4 At t = s, T2 starts its execution. T2 terminates without violating its deadline. 5 At t = s, T4 starts its execution. T4 ends in rtl = ms, without violating its deadline. 6 At t = s, T4 starts its execution. T4 ends in rtl = ms, without violating its deadline. 7 At t = s, T1 starts its execution. T1 ends without violating its deadline in rtl = ms.

16 24 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu As S 4 remains feasible and optimal in the rest of the verification points, no other commutation to alternate running scenario is forced, till the end of an application hyper-period. S 5 to S 4 reconfiguration is staged by modifying the running option of T1, via a global variable. 7. Conclusions This paper suggests a reconfiguration algorithm suitable for real time applications developed for RTOS with static priorities. The approach inherits advantages brought by the employed scheduling algorithms, although gives increased flexibility and robustness via feasibility tests and evaluations made during runtime exploitation. The designer has to define alternative the running scenarios, the cases when the commutations from a running scenario to another are valid, as well as the precedence and the real-time constraints imposed to the application s processes. However, by means of a friendly Configuration Manager, all these input data can be introduced in a simple and intuitive manner, being automatically converted to data structures compliant with the real time application. The online switches enabled between the running scenarios are aimed to provide minimum tardiness and maximum utilization, being therefore devoted to solve both overloading and under-loading cases. The idea is exemplified for OSEK/VDX. The reconfigurations are triggered within a tracing function which detects context switching time instants. As such facility is available in most real time operating systems, the presented solution can be easily extended to other real time systems. REFERENCES * * * OSEK/VDX, OSEK/VDX Operating System Specifications. Version 2.2.3, 2005, Bini E., Buttazzo G.C., Giuseppe M., Rate Monotonic Scheduling: the Hyperbolic Bound. IEEE Transactions on Computers, 52, 7, , Brăescu C., Ferariu L., Real Time Constraints Monitoring for OSEK Applications. Bul. Inst. Polit. Iaşi, s. Automatică şi Calculatoare, LVII (LXI), 1, Brăescu C., Ferariu L., Run-Time Feasibility Verification in Event Driven Operating Systems with Static Priorities. Proc. of the 14th International Conference on System Theory and Control, Sinaia, România, October 2010, Brăescu F.C., Ferariu L., Lazăr C., OSEK-Based Multiple Controllers with Schedule Feasibility Self-testing. Proc. of the International Symposium on Power Electronics, Electrical Drives, Automation and Motion, Pisa, Italy, June Buttazo G.C., Research Trends in Real-Time Computing for Embedded Systems, ACM SIGBED Review, 3, 3, 2006.

17 Bul. Inst. Polit. Iaşi, t. LVIII (LXII), f. 1, Fohler G., Lennvall T., Buttazzo G., Improved Handling of Soft Aperiodic Tasks in Offline Scheduled Real-Time Systems Using Total Bandwidth Server. In Proceedings of the 8th IEEE International Conference on Emerging Technologies and Factory Automation, Nice, France, October, Gansle J., Embedded System: World Class Designs, Newnes, Lehoczky J., Sha L., Ding Y., The Rate Monotonic Scheduling Algorithm: Exact Characterization and Average Case Behavior. Proceedings of the 10th IEEE Real-Time Systems Symposium, 1989, Lemieux J., Programming in the OSEK/VDX Environment. Elsevier, Liu C.L., Layland J.W., Scheduling Algorithms for Multiprogramming in a Hard Real- Time Environment. Journal of the ACM, 20, 1, 46 61, Ramos-Thuel S., Stosnider J.K., The Transient Server Approach to Scheduling Time- Critical Recovery Operations. Proceedings of the 12th IEEE Real-Time Systems Symposium, , Sha L., Abdelzaher T., Arzen K.E., Cervin A., Baker T., Burns A., Buttazzo G., Caccamo M., Lehoczky J., Mok A.K., Real Time Scheduling Theory: A Historical Perspective. Journal of Real-time Systems, December, Sha L., Goodenough J., Real-Time Scheduling Theory and Ada. IEEE Computer, 23, 4, 53 62, Shih W., Liu W.S., Chung J., Gillies D.W., Scheduling Tasks with Ready Times and Deadlines to Minimize Average Error. Operating Systems Review, 23, 3, 14 28, White E., Making Embedded Systems: Design Patterns for Great Software. O Reilly Media, Yao G., Buttazzo G., Bertogna M., Feasibility Analysis under Fixed Priority Scheduling with Limited Preemptions, Real-Time Systems, Vol. 47, 3, , Yao G., Buttazzo G., Bertogna M., Feasibility Analysis under Fixed Priority Scheduling with Fixed Preemption Points. Proceedings of the 16th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA 2010), Macau, China, August 23-25, Zurawski R., Embedded Systems Handbook. CRC Press, RECONFIGURAREA APLICAłIILOR DE TIMP REAL CU PRIORITĂłI STATICE PRIN MONITORIZAREA ON-LINE A RESTRICłIILOR (Rezumat) Lucrarea tratează reconfigurarea on-line a aplicańiilor de timp real. Se acceptă atât procese periodice, cât şi aperiodice, având definite restricńii de precedenńă. Abordarea propusă urmăreşte asigurarea predictabilităńii execuńiei pentru sistemele de timp real cu priorităńi statice. În raport cu scopul stabilit, algoritmul de reconfigurare execută teste de fezabilitate şi evaluează online gradul de utilizare a procesorului, declanşând comutarea între o serie de scenarii de execuńie predefinite, ori de câte ori se detectează o supraîncărcare sau o subîncărcare. Lucrarea stabileşte un fomalism de

18 26 Corina Agrigoroaie, Lavinia Ferariu and Cătălin Brăescu descriere a reconfigurărilor permise, acesta fiind fructificat prin intermediul unui software ce permite definirea simplă a datelor de intrare şi exportarea automată a acestora către sistemul de timp real. Reconfigurarea propusă este compatibilă cu o gamă largă de aplicańii de timp real. Metoda de proiectare este exemplificată pentru OSEK/VDX, beneficiind astfel pentru monitorizarea execuńiei şi reconfigurarea on-line de funcńiile de urmărire oferite de acest sistem de operare.