c2@3 -- -- E/J

ELSEVIER Journal of Systems Architecture 42 (1996) 391-407

;WfMi; OF

ARCHITECTURE

Strategies for scheduling optional tasks in intelligent real-time environments

Ana Garcia-Fornes * , Houcine Hassan, Alfons Crespo Departamento de lngenieria de Sistemas Computadores y Automritica, Uniuersidad Politkcnica de Valencia, Valencia, Spain E-46071

Abstract

Control systems have been the main application field of real-time system programming. While the complexity of the control system has been solved using classical theory, the theory to design the real-time system has follow some well known practices. However, when the complexity of the applications requires the combination of the control theory and techniques coming from the artificial intelligence field, the real-time design and implementation requires some new features. One of the main aspects to be considered is the non predictable behaviour of most of these techniques and, as consequence, their application to systems where the predictability plays a critical role. In this paper, a global organisation of a real time artificial intelligence system is presented. The proposal includes a task model to define real time tasks with components where the execution time is unbounded. To handle these tasks, a system organisation is proposed. The system includes an intelligent server that manages the execution of all unbounded parts. The proposal uses two scheduling levels, a static first level which is supported directly by the operating system, and a dynamic second level which handles the optional parts. Several scheduling algorithms are presented and evaluated.

Keywords: Control systems; Predictability; System organisation; Scheduling algorithm

1. Introduction

Classical control theory has been the basis for the development of simple real-time control systems. Due to the complexity of new systems to be con- trolled and the necessity of adapting to changes in the environment, classical control is insufficient. The idea of the application of artificial intelligence (AI)

* Corresponding author. Email: agarcia@dsic.upv.es

techniques appeared in order to overcome such prob- lems. In the last decade, techniques such as knowl- edge based systems (neural nets, fuzzy logic, genetic algorithms, etc.) have been considered with a re- newed interest, since they appear as a promising approach to cope with the non-linearities and com- plexity of systems to be controlled.

In the domain of real-time control systems (pro- cess control, avionics, robotics, etc.) these techniques have inspired new resources for implementation of better and more efficient control. Therefore, several

1383-7621/0165-6074/%/$1.5.00 Copyright 0 1996 Elsevier Science B.V. All rights reserved. PII Sl383-7621(96)00030-6

392 A. Garcia-Fornes et al./Journal of Systems Architecture 42 (1996) 391-407

approaches have recently been proposed to adapt AI techniques to the real-time requirements [13,17]. For the most part, they propose a modification of tradi- tional AI techniques to improve their predictability and to take time into account [3,8,12]. With respect to the global software organisation the approaches are influenced by the initial field of the research groups. AI groups organise the system around soft- ware architectures adapted to real-time environments managing activities with deadlines [ 141. Real-time control groups see the problem as a traditional real- time system where the introduction of activities with low predictability has to be managed by a more adequate scheduling policy [ 161.

One of the most important modules in a real-time system CRTS) is the scheduler. This module is in charge of providing suitable computational resources to the system task set. The main topics to be consid- ered by the scheduler are: scheduling policy, mono/multi-processor environment, interruptability and re-scheduling of tasks, etc. From a real-time artificial intelligence system (RTAIS) point of view, this is more difficult than in conventional systems, because it is difficult to predict the response time in such systems. The solution to the problem comes from a heuristic process whose computation time is unbounded. For these reasons, it is interesting to study how to model such unbounded intelligent tasks and develop scheduling algorithms that guarantee the system response time. Specifically, it seems very interesting to adapt the existing scheduling tech- niques for hard RTS to hard RTAIS with unbounded computation time. The term “unbounded” is adopted from Audsley et al. [l], which implies that the timing behaviour of a task is unpredictable or is so pes- simistic (it cannot be analyzed to produce realistic worst case execution times) that no scheduling scheme will guarantee it.

The ARTIS (An Architecture for Real Time Intel- ligent Systems) project [ 11 I develops an architecture and a task model, combining concepts from both fields, in order to achieve the necessary predictability

for the system. Furthermore, it allows us to guaran- tee a minimum level of quality in the system and to control the way that this quality can be improved as free time becomes available. The approach takes the form of a layered architecture which uses a hard real-time scheduler at the base and AI techniques at higher levels. The work reported in this paper fo- cuses on both schedulers, defining and comparing several existing and new strategies.

The paper is organised as follows, after a short introduction to work in the field (Section 21, a model task and the system architecture is presented and described (Section 3 and Section 4). Section 5 and Section 6 describe the two scheduling levels pro- posed in detail. For each level, a description and evaluation of several alternatives are presented. Re- sults are compared with those obtained with other approaches with respect to relevant parameters such as idle CPU time. For the second level, three differ- ent strategies are presented, evaluated and compared in order to conclude which give better performance depending on the characteristics of the application. Finally, Section 7 elaborates some conclusions.

2. Previous work

In 1201 Stankovic and Ramamritham state: “One common denominator of all real-time systems is the need for predictability”. Predictability with respect to the timing requirements is difficult to achieve in artificial intelligence systems, since AI methods may include heuristic searching in exponential solution spaces. The ARTIS project presents a two-level task model approach for achieving predictability in artifi- cial intelligence systems. In the high-level task model the user can specify a Real-Time Artificial Intelli- gence System behaviour by means of activities and agents [ 101.

An activity is a set of agents that cooperate to solve a subproblem from the global control problem. Each activity is composed by perception, cognition

A. Garcia-Fornes et al./Joumd of Systems Architecture 42 (1996) 391-407 393

and actuator agents, and has two time attributes (a deadline and a period). The perception agents pro- vide the communication interface between the exter- nal world and the intelligent system. The intelligent or cognitive agents include the reasoning and prob- lem solving capabilities. The effector or actuator agents transmit the solutions computed by the intelli- gent component to the external world in order to control the execution of physical actions.

An agent is the minimum intelligent entity which finds the solution for a particular problem. Each agent is structured as a list of deepening levels, each of which is defined by a knowledge source which holds knowledge to solve a problem in a different manner or to refine the solution reached by a previ- ous level. In critical agents, their lowest level must have a predictable and realistic computation time.

In general, when performing an agent, its lowest level (with presumably the lowest solution quality) is executed first, followed by more and more complex (and time-consuming) optional levels. When the allo- cated time for the agent expires, the currently execut- ing level is stopped, and the results obtained’by the more recent level are used as the agent solution.

This model adequately fits the requirements to be applied in the real-time control of complex pro- cesses, where some artificial techniques must be used in order to control the process in the proper way. The lowest level could be filled with traditional techniques and allows us to provide a predictable result from an inexact model of the system. The optional levels allow us to define alternative un- bounded algorithms or techniques (knowledge-based systems, neural networks, predictive control, etc.) with unpredictable computation time. The optional levels could be handled by means of approximate algorithms [13]. These methods have been used in real-time AI research. Among them, you can find: approximate processing and design-to-time schedul- ing [8,12], anytime algorithms 13,191 and progressive reasoning [6].

Working with activities and agents the user fo-

cuses his attention on the functional aspects of the control system being designed rather than the under- lying methods for implementing and scheduling the system. The low-level task model defines the entities to be scheduled and executed in the system. The low-level task model is obtained by making an auto- matic translation of the former. This model is in fact suitable for implementing and scheduling the system as a hard real-time system, which allows the user to achieve the required guarantee.

As this paper is concerned with scheduling pur- poses, a detailed description of the low-level task model is now presented.

3. Task model

Each task in the system can be composed of three sequential parts: ri = (T,,T,,T~], where T,,, is the mandatory part which has to be executed and is able to provide a minimum quality answer. rO is the optional part and can be composed of several meth- ods each one refining the previous answer; this part may not be executed or may be only partially exe- cuted. rf is the final or action part and is in charge of sending the result to the external actuators.

So, each task is defined as a predictable code which provides a minimum quality response and a set of optional methods, organised in levels, which improve the answer of the previous one. All the optional levels can be unpredictable. Depending on the time available, the system should execute as many levels as it can to provide the best response.

Each task has the following attributes:

ri = (T.,Di,@i,Imi,Cmi,Cfi,Li,j),

where Ti is the period, Di the deadline Qi, the offset, Im, the importance, Cm, the worst case exe- cution time for the mandatory part, Cfi the worst case execution time for the final part, and Li,j is the estimated computation time for the j-th level.

394 A. Garcia-Forms et al./ Journal of Systems Architecture 42 (1996) 391-407

Fig. 1. Task example.

Some premises should be accomplished in this model: * the mandatory part has to be executed before its

optional and final parts; . the final part has to be executed after the manda-

tory Pat-C * the optional parts should executed after the

mandatory and before the final part, and as many levels as a second scheduling level decides have to be executed. Fig. 1 shows a graphical representation of this

model. On the left part of Fig. 1 a definition of a task ri is shown with a mandatory part, four optional parts and a final part. On the right, a possible execution during a period of this activity is shown. It is assumed that no other tasks are ready to be executed and as a consequence only this 7i is exe- cuted. After the mandatory part is executed, because there is available time, optional parts are executed until the third one (at t,), cannot be allocated in the available slack (t2 - r, < Li,3) and, consequently, it is not executed. The final part is then executed.

4. Overview of the software architecture

In this section, a general description of the RTAIS software architecture is given. The proposed RTAIS is a multiagent system based on the blackboard model [18]. It is formulated as a result of the one designed for the REAKT ESPRIT Project [21].

The proposed system architecture is shown in Fig. 2. This architecture is the result of the blackboard model in which some modifications have been made in order to adapt the model for handling real-time constraints. All of the unbounded parts of the system are embodied in a task which is called the intelligent server. This task is only executed in slack time. The main components in the architecture are: * RTOS: this module provides system calls to cre-

ate internal processes, communicates and syn- chronises them. But this RTOS has to be ex- tended with some functions that allow us to schedule internal processes using user-defined policies by means of a real-time scheduler (First Level Scheduler) based on pre-emptive priorities. This scheduler is in charge of scheduling all the application tasks composed of mandatory parts and final parts, as well as the intelligent server.

* The blackboard is a global-structured memory containing objects of the solution space. These objects also store information about time in order to permit temporal reasoning [4]. Temporal data are managed by means of a Time-Map Manager module that is in charge of maintaining temporal relations between temporal information. These temporal constraints are kept in a temporal graph. Tasks communicate with each other by reading and writing on the blackboard, where the solution is incrementally built up.

* Intelligent Server: this module is in charge of handling all the optional levels of agents and the

A. Garcia-Fornes et al./Jourd of Systems Architecture 42 (1996) 391-407 395

agents that are fired by sporadic events. At each point in time, each optional part of an agent must compute its “best available” solution in order to achieve its partial goals. These solutions are com- municated to the external environment by the actuator tasks. The intelligent server has a compo- nent (the control component) that is in charge of co-ordinating several optional parts in order to obtain the “best available” global solution. The control component receives significant events in the system, and, consequently, fires aperiodic non critical agents and activities to solve the situation. Furthermore, by means of the second level sched- uler, the control is in charge of computing the level depth (i.e., the number of levels to be performed) of each active agent, depending on the available CPU time. To operate under hard real-time constraints, a

number of restrictions have to be made. Access to the blackboard must be restricted in time and must use protocols which guarantee mutual exclusion and which limit blocking times. The unpredictable agents

(i.e., the optional components) must work with their own local memory, run-time entities associated to optional components are split into a read, a computa- tion and a commit phase [4]. Before writing the intermediate solution from the local memory to the global blackboard (commit phase), the existence of sufficient slack to complete the phase must be con- firmed. All the system components whose computa- tion time is unpredictable (for example, the updating of the graphs that maintain the temporal dependen- cies in the blackboard [2] whose computation time depends on the number of relations to update) will be executed in slack time.

One of the more important aspects in the control of the task execution is to know in advance wether the system is schedulable with the mandatory and final parts of the tasks. If this set of tasks is schedu- lable, an important piece of information is the slack time available to execute optional times and the instants it can be used. Several methods have been recently developed to determine the available slack time [7,9,151.

I I I I I i

Real-Time Operating System

- Task Auiiatiin 0 Task

-- Data Transfer 0 Data Structure

Fig. 2. Global architecture.

396 A. Garcia-Fornes et al./Journal of Systems Architecture 42 (1996) 391-407

The next step is to organise the priority of the tasks (mandatory, optional and final) in order to be able to make a schedulability analysis, so that a method of slack extraction can be applied and a policy can be established to use the slack time in optional parts. Two different scheduling levels can be clearly identified: * A first level corresponds to the global organisa-

tion of tasks: priority of the mandatory and final parts, priority of the intelligent server, mecha- nisms to control the execution of the intelligent server, interactions with the real time operating system.

. A second level determines which of the optional parts is executed, and how many levels of them. While the first level needs to be static to guaran- tee the temporal constraints, this second level is dynamic and several criteria can be applied.

5. First level organisation

In this section, the problem of assigning priorities to all the tasks in the system is addressed. Several approaches in the same direction can be found in the literature. From one of the first works in this line [16] a task model to incorporate imprecise computa- tion was defined. A refinement of this model was developed by Audsley et al. [ 11 who decomposed the process model into three tasks: a mandatory, a final and an optional task. From the scheduling point of view, each task has a fixed priority assigned. The approach consists of calculating the temporal at- tributes for the task set to be guaranteed, from the original process attributes. After that, the priority is assigned with a deadline monotonic approach [5], and a schedulability test allows us to know if the task set is schedulable. For these purposes only the mandatory and final tasks are considered. The ap- proach assigns an offset to the first activation of each final task, and modifies the deadlines associated with the mandatory and final tasks.

Some of the drawbacks of this proposal is the high number of priority levels required (3 * process numbers), the low utilisation that can take place in the new set of tasks, or worse, there is no proposal to recalculate the new set of temporal attributes to the tasks when the resulting approach is not schedulable. The static consideration of optional tasks that do not allow us to concentrate all the efforts (in terms of CPU time) on different optional parts each time, can be relaxed by taking into account the same ideas proposed in the above architecture. This approach is named the Audsley approach in Fig. 6 and Fig. 7.

Alternatively, under the same idea of changing the temporal attributes of the tasks, one can assign an offset at each activation of each final part. Based on the work of Garcia-Fomes [9], final parts of tasks are delayed as late as possible. So, these final parts are considered as a task with the same period and dead- line of the mandatory part but with an offset ob- tained from the function 0 * . This function provides the amount of processor time that can be used for optional processing at the highest level of priority in the system, in preference to mandatory and final periodic parts. This amount is defined for determined subintervals. The proposal develops a method to calculate the offset of each activation for all final tasks (assuming that all the time indicated for 0 * is consumed in optional processing) and assigns the same level of priority to mandatory and final tasks. The priority of the optional tasks is lower than the other tasks (mandatory and final) and the value is n + i, n being the number of initial global tasks and i the priority level of their mandatory and final part. This approach is named the OffStat approach in Fig. 6 and Fig. 7. As in the above approach, when there are no mandatory or final tasks active, the second scheduling policy in the control component will se- lect the most appropriate optional task to be exe- cuted.

The OffStat approach obtains better performance than the Audsley approach as can be observed in Fig. 7. Drawbacks of this proposal are the lack of flexibil-

A. Garcia-Fornes et al./Journal of Systems Architecture 42 (1996) 391-407 397

ity in the use of the 0* function, when tasks are not independent, and share common resources.

The most flexible approaches are those based on strategies which are able to calculate the slack avail- able in the system for a wide range of situations [7]. For the next three strategies it is assumed that the kernel is responsible for maintaining spare capacity, and at any time t, for each priority level i, the function Si(t) gives the amount of slack available. As the exact method is not practical, in order to implement a method for calculating the slack, the approximate dynamic algorithm has been chosen, without calculating the effective deadline.

The demand for spare capacity is application pro- cess driven. When the global system is built, the compiler inserts some kernel calls to inform the kernel that relevant events in the system have oc- curred (termination of a mandatory part). The control component of the system will decide, at run-time, to which optional part or to which aperiodic task, avail- able spare capacity will be assigned, by means of the second level scheduler policy.

The system is analyzed using the results of the feasibility theory for fixed priority scheduling [5] for the proposed low-level task model (mandatory and final parts). Each task has a priority assigned accord- ing to its deadline by applying the Deadline Mono- tonic theory. To apply the schedulability test only the worst case execution time (WCET) of the task pre- dictable parts (i.e., the mandatory WCET (Cmi> and the final WCET (Cf,)) are taken into account. As the mandatory and final parts are members of the same task, separated by a system call that allows for executing the optional part, the precedence between them is guaranteed. So, it is also a priori guaranteed that the predictable parts of a task will be executed before their deadline and in the appropriate order, resulting in a safe system.

All optional components are included at run-time through a server process (the intelligent server). Ini- tially, the intelligent server component does not af- fect this off-line feasibility, as it always executes in

slack time. However, at run-time some action must be taken if we do not want the guaranteed deadlines to be affected: * the kernel must stop the intelligent server execu-

tion once it has exhausted its assigned computa- tion time (server capacity);

. if guaranteed parts and optional parts from differ- ent tasks share resources, the kernel has to take this into account when calculating the slack avail- able. It also has to check for enough slack avail- able when an optional part begins its commit phase. Several strategies for priority assignation to the

server have been studied and their influence on the flexibility of the scheduling strategy of the second level compared. In all of them, the intelligent server will be executed: * at the priority level of the optional part selected,

preventing the execution of its corresponding fi- nal part, or

. at the priority level of the highest priority active task (in preference to this task), when the server capacity is used to execute aperiodic tasks.

5.1. Strategy 1

The simplest strategy (strategy 1) is the following: when the application task, i, requires the intelligent server execution, the maximum slack, S, that can be used at the priority level of such task is computed (as the minimum amount registered at this priority level and all lower levels):

S= min Sj( t). VjE [p(i)

If this amount S is larger than a threshold (i.e., large enough to justify the context switches and the execution of a second level scheduler module in the control) the kernel activates the intelligent server and assigns priority i to it, with S as its maximum execution time. Then the slack available at this

398 A. Garcia-Forms et al./ Journal of Systems Architecture 42 (1996) 391-407

Table 1 Task set

Task Cm Cf Period Deadline

T, 1 1 21 9

T2 1 1 35 15

T3 1 1 70 70

priority level and at all lower priority levels is reduced by this amount:

vjEIp(i):Sj(r)=sj(t)-s.

Fig. 3 shows an example of this strategy for the task set in Table 1.

In this execution example the second scheduling level has not been considered, so all the time avail- able to execute optional parts have been accumulated and represented as “OPT” in the figure. Indeed, “OPT” represents the intelligent server availability. Using this execution time the second execution level will determine which optional tasks have to be exe- cuted.

The main drawback in using this strategy is that, once assigned to the server all the slack available at a low priority level, there is no more slack available at higher priority levels until the current server exe-

cution finishes. As a consequence, this strategy pre- vents the selection of optional parts of higher priority tasks, while the server has capacity assigned, in spite of the former pre-empting the latter. This is what happens at t,. Once the server has been assigned at I, the priority level 3 and the capacity of 45 time units, when task T, asks for slack time at t,, the answer is that no slack time is available for execut- ing its optional part. This first level integration strat- egy leads to a less flexible scheduling policy at the second level.

5.2. Strategy 2

One solution to the above problem consists of using a different method in order to maintain the slack available at each priority level updated. When the application requests a possible execution of its optional part if there is slack available, the system assigns the correct priority and capacity to the server, but the counters that maintain the slack available at each priority level are not decreased in the amount assigned to the server as its execution time. Instead, the system updates the slack available at all priority levels each time the server executes, decreasing the counters in the amount equal to the capacity con-

.O 20 90 .60 80 I

“T 2”

“T 3”

Fig. 3. Execution example for Strategy 1.

A. Garcia-Fornes ef al./Jourd of Systems Architecture 42 (1996) 391-407

Fig. 4. execution example for Strategy 2.

sumed by the server. If the processor serviced the optional part at priority level 1. Unfortunately, this intelligent server from t to t’, then slack is con- strategy leads to an increase in the amount of idle sumed at all priority levels in this interval, time in the system.

5.3. Strategy 3 Moreover the capacity of the server must be

updated each time the server priority changes. Fig. 4 shows this strategy for the above task-set example.

In this case, at r2 when task T, finishes its mandatory part and requests available slack, the system finds 7 units of free time for executing its

This problem can be easily solved if we increase the number of calls for requesting optional process- ing, and extend them to the kernel. Strategy 3: each time the server capacity becomes exhausted, the kernel has to compute the slack available at the

.O 20 40 .60 80

Fig. 5. Execution example for Strategy 3.

400 A. Garcia-Forms et al./Journd of Systems Architecture 42 (1996) 391-407

:.:, 1;’ :::. ..:.:..: y::: : :, :::j : :; ::,:.::: : .: : yDLE.: : 0 .:j..:... : j.:. . ” : :: ‘IDLE’ 0 ..: :

“‘. : ” : .’ : :: : .: .:.::. .: : :.:::...:. :,,.

I I I

Fig. 6. Audsley and OffStat example comparison.

I

priority level i, using the next equation, where i is the priority level such that the level i - 1 is the lowest level that has no slack, i.e.,

q-,(f) =o If such a priority level i exists, the kernel returns

the processor to the server with priority i and capac- ity S. Fig. 5 shows the same example with Strategy 3. In this case, at time rs when the server exhausts its capacity, the kernel programmes an execution of the server at priority level 2.

The proposed organisation of the first level allows us to obtain better performances than the other mod- els referenced in the introduction. To compare the performance of the system organisation proposed a comparison of the same set of tasks is presented. These strategies have been compared with the Auds- ley and the OffStat approaches. First, Fig. 6 shows the execution obtained when these models are used.

A parameter that can determine a better perfor- mance of the model is the idle time parameter. Fig. 7 compares the idle time obtained in different periodic load conditions. As can be seen in the chart, strate- gies proposed in this paper obtain better perfor- mances than the other models except when the load conditions are very high and the results are more or less the same.

6. Second scheduling level

The model described covers the first level of scheduling. The following question is how to assign

the optional time to concrete optional parts of tasks and, as a consequence, which are the most appropri- ate criteria to handle these optional parts?

It is difficult to determine which is the best strategy to assign the time available to optional parts. In most of the cases, it depends on the application, so it is convenient to develop several strategies and compare them. To implement and compare results the following work has been developed: * Definition of three heuristic criteria to assign the

available time to optional parts when the server is invoked.

* A task to summarise the system inactivity. * A user interface to study and show the results.

6.1. Second level criteria

In order to evaluate the second level scheduling three different and complementary criteria have been

7

6

5

E4 .- a,3

5 2

1

0

30 40 50 60 70 80 Load condition (%)

Fig. 7. Models comparison.

A. Garcia-Forms et al./Journal of Systems Architecture 42 (1996) 391-407 401

Fig. 8. Execution example for Criterion 1.

defined. For each criterion, a basic description, a snapshot of an execution with the same set of tasks used in all the paper, and a chart with the results obtained in the execution of a large number of set of tasks. To obtain these results, each task set is ran- domly generated: period, deadline, worst execution time of all parts, number of optional parts, average of execution of each optional part, and the impor- tance of each task. Each task set requires a number of CPU ticks to execute its mandatory and final parts. So, when a load of 30% is specified, it means that the mandatory and final parts use 30% of the CPU, or, the system has a 70% of CPU cycles to execute optional parts. In these charts, the upper-right comer shows the total amount of CPU cycles dedi- cated to execute optional parts.

. Criterion 1: The available time is invested in scheduling optional parts of the most important

Table 2 Task set example

task. When the remaining time is less than the required by the next optional level, the control is transferred to the optional part of the next most important task. Finally, if no task is able to use the available time, it is computed as idle time to measure the system inactivity.

Fig. 8 shows an example of this criterion for the above tasks set with the importance and depth levels of optional parts given in Table 2.

In this case, T3 has the higher importance. So, the algorithm executes optional parts of T3 (Ao31, and when it is not possible, it executes the optional parts of the next most important task T-1 and then T-2. It could be noted that initially 0-l and O-2 are exe- cuted before O-3 because T-3 is still inactive. As imposed by the algorithm, only in the cases where more a important task is not able to process more time, it is permitted to the next more important one

Task

T,

Cm

1

Cf

1

Period

21

Deadline

9

Importance

1

Lid

3 5 7 8 10 12

.T, 1 1 3.5 1.5 0 3 6 8 11 13 15

T3 1 1 70 70 2 7 9 13 15 17 19

402 A. Garcia-Forms et d/Journal of Systems Architecture 42 (1996) 391-407

to be scheduled. At instant 69, the server schedules O-2 because T-3 is still in an inactive state. As can be observed, O-3, the more important task, reaches it’s maximum levels depth of optional computation: 6’e’h level.

Fig. 9 shows that more important tasks execute the great part of available optional time. The results obtained are the same for different kind of loads, taking into account that for less critical load more optional time is available, and, hence, more time is scheduled by more important parts. Inactivity of the

system during the hyperperiod is collected by idle task. Idle task process more time than other tasks as Imp-10 because levels of optional part 10 are greater than the available time proposed by the server.

* Criterion 2: Initially the available time is spent on the most important task. Unlike Criterion 1, Crite- rion 2 rotates tasks’ importance each time the slack server assigns a new time interval. It allows the fairness of the system between optional tasks.

Fig. IO. Simulation example of Criterion 2.

A. Garcia-Fames et al./Journal of Systems Architecture 42 (1996) 391-407 403

Fig. 10 represents the evolution of the system using Criterion 2. Optional load is better distributed than the previous case. This is possible by rotating task’s importance after processing optional parts. As a consequence the optional time dedicated to O-3 decreases producing the execution at most of the Simth level of refinement. Instead, the dedicated time for the other optional tasks increases. The effect of this

criterion could be seen in instant 35. O-2 becomes the more important task and consequently executes the optional time. In the next invocation of the server O-3 is scheduled because of the priority rotation.

To perform an equilibrium between optional util- ity of tasks Criterion 2 is used. Results of simula- tions are shown in Fig. 11 for different critical loads. The effect of previous algorithm decrease and op-

9 30 .60 90 .120 .150 360

~~~~‘~~~~i~~~.~~~.~~~.

:::,:::::::::::::::::::::::::::::::::

Fig. 12. Execution example for Criterion 3.

404 A. Garcia-Fornes et al./Jourd of Systems Architecture 42 (1996) S-407

tional load is shared by all tasks in a better way. For a 70% load, there remains 30% of time schedulable by the rotating algorithm. It can be seen that first eight tasks are consuming time in the environments of 4%.

- Criterion 3: It starts with the assignation of all the available time to the most important task. To reach fair sharing between optional tasks, this criterion tries to grant available time to the least

time consuming optional task. Like the previous criteria, whenever a task is unable to use the time, it is relegated to the next most important one.

To gain more fairness between optional parts, Criterion 3 is developed and illustrated in Fig. 12. It can be seen that optional load is balanced better than previous algorithms. Optional time is used by the task that has the least consuming time. As fairness is the objective, processing maximum depth levels is

Assignement strategies of slack time for 30% critical load

Fig. 14. Criteria comparison at 30% of critical load.

A. Garcia-Fornes et d. / Journal of Systems Architecture 42 f 1996) 391-407

12

10 29.99 29.04 29.W 29.00 29.00 29.00 29.01 29.01

6

405

Optionel parts of sctlvltlcs

Fig. 15. Criteria comparison at 70% of critical load.

difficult to reach between all tasks. In Fig. 12 O-3 reaches the 3rd level when O-2 maintains it’s 4-th level. For more precision, in instant 50 O-3 is scheduled by the server because it is the only task in active state. The next snap at time 64, as the less consuming optional time is O-l, it grants the highest importance and hence consumes the optional service.

Criterion 3 aims to obtain fairness between all optional tasks. Fig. 13 shows that more tasks are intervening in execution of slack time available. As it can be seen, more optional time is available at 30% and then more time is processed by optional parts. Optional tasks that use less time are task 9 and task 10 at the 70% of critical load. This happened because their optional levels need more time than the available time proposed by the server.

It is difficult to assume a better performance or results of any of the above criteria. It seems reason- able to assume that in real applications not all tasks have optional parts, perhaps only few of them. The use of a criterion is closer to the application than a general purpose algorithm. As a consequence, it is difficult to extract conclusions, and it seems more appropriated to show the behaviour of the criteria and give the possibility to the user to choose the strategy most appropriate to the problem.

The next two figures compare the behaviour of three proposed criteria. In Fig. 14 the amount of slack time used by optional tasks for three criteria at 30% of critical load is summarised. Fig. 15 shows at 70% of the load, the distribution of slack time be- tween optional parts.

For applications that need to assign optional avail- able time to more important tasks it can be seen that Criterion 1 is more suitable. In order to cope with applications that need to perform more fairness in the system Criterion 3 is the better one because it performs assignment of available time to optional parts in a more equitable way.

7. Conclusions

In this paper, a task model suitable for providing predictability to artificial intelligence tasks has been presented. It allows us to incorporate AI techniques in real-time systems guaranteeing their response time. Furthermore, a RTAIS architecture based on a black- board with the previous task model has been de- scribed.

The feasibility theory for fixed priority scheduling 151 in order to guarantee the minimum system quality

406 A. Garcia-Fornes er al./ Journal of Systems Architecture 42 (1996) 391-407

has been applied to the set of mandatory and final parts of tasks. If this set is schedulable, the first level of scheduling can guarantee it, and it uses the slack time to execute optional parts.

All of the unpredictable parts of the system are embodied in a task which is called the intelligent server, which is in charge of handling slack time. Different integration strategies for executing the server in slack time have been analyzed and com- pared with other strategies showing better perfor- mance. From the above analysis, it can be concluded that the following parameters have to be taken into account to select the appropriate strategy to integrate the intelligent server in a fixed priority system and to obtain the maximum flexibility and utility: * the way the kernel maintains and updates the

slack available at each priority level; * the places where we request optional processing; * the way the kernel assigns and replenishes the

server capacity. This work has been completed with the descrip-

tion of different strategies for the second level. A description and evaluation of three different criteria allow us to conclude that in many cases the best criteria to be applied is application dependent. Tak- ing into account the behaviour of these criteria, a user can select the most appropriate criterion for their application. So, it is convenient that in a high level environment these, and perhaps other criteria, can be chosen by the user.

Acknowledgements

This work has been partially supported by the Comisi6n Interministerial de Ciencia y Tecnologia of the Spanish Government: Project Tap-051 l-~02.

References

[l] N.C. Audsley, A. Bums, M.F. Richardson and A.J. Wellings, Incorporating unbounded algorithms into predictable real-

El

[31

141

[51

b1

[71

[81

[91

[lOI

[ill

[I21

1131

1141

[151

Time systems, Technical Report, Real-Time Systems Re- search Group, Department of Computer Science, University of York, UK, Report number RTRG/91/102, 1991. F. Barber, V. Botti, E. Onaindia and A. Crespo, Temporal

reasoning in REAKT: An environment for real-time knowl- edge-based systems, AICOMM 7(3) (1994) 175-202.

M. Boddy and T. Dean, An analysis of time dependent planning, Proceedings of rhe 7th AAAI, Saint-Paul, Min-

nesota, 49-54, 1988. V. Botti, F. Barber, A. Crespo, E. Onaindia, A. Garcia-For-

nes, I. Ripoll, D. Gallardo, and L. Hemandez, A temporal blackboard for a multi-agent environment, Data and Ktwwl-

edge Engineering 15(3) ( 1995). A. Bums, Pre-emptive priority based scheduling: An appro-

priate engineering approach, Technical Report, Real-Time Systems Research Group, Department of Computer Science, University of York, UK, Report number YCS214, 1993.

F. Charpillet, A. Boyer and J.P. Haton, Progressive reasoning in REAKT, Workshop on Integration Technology for Real-

Time Intelligent Control Systems, Madrid, October 1993. R.I. Davis, K.W. Tindell and A. Bums, Scheduling slack

time in fixed priority pre-emptive systems, Proceedings of the Real-Time Systems Symposium, Raleigh-Durham, North

Carolina, December 1-3, IEEE Computer Society Press, 1993, 222-231. K. Decker, V. Lesser and R. Whitehair, Extending a black-

board architecture for approximate processing, The Journal of Real-Time Systems 2 (1990) 47-79.

A. Garcia-Fomes Scheduling tasks with optional parts in artificial intelligence environments, Technical Report DSIC- II/ 1 l-94, Universidad Polidcnica de Valencia, 1994. A. Garcia-Fomes, A. Crespo and V. Botti, Adding hard real time tasks to artificial intelligence environments, Workshop

on Real Time Programming, Fort Lauderdale, Florida, 1995a. A. Garcia-Fomes and V. Botti, ARTIS: Una arquitectura para sistemas de tiempo real inteligentes, VI Conferencia de la

Asociaci6n Espaola para la Inteligencia Artificial, Alicante, Espaiia, 1995b. 161-174. A. Garvey and V. Lesser, Design-to-time scheduling, Techni-

cal Report, University of Massachusetts, 1992. A. Garvey and V. Lesser, A survey of research in delibera- tive real-time artificial intelligence, Journal of Real-Time

Systems 6 (1994) 317-347. B. Hayes-Roth, Architectural foundations for real-time per- formance in intelligent agents, The Journal of Real-Time Systems 2 ( 1990) 99- 125.

J. Lehoczky and S. Ramos-Thuel, An optimal algorithm for scheduling soft-aperiodic tasks in fixed-priority preemptive systems, Proceedings of rhe Real-Time Systems Symposium,

Phoenix, Arizona, December 2-4, IEEE Computer Society Press, 1992, 110-123.

A. Garcia-Fornes et al./ Journal of Systems Architecture 42 (1996) 391-407 407

[16] J.W.S. Liu, K.J.L. Lin, W.K. Shih. A.C. Yu, J.Y. Chung and W. Zhao, Algorithms for scheduling imprecise computations, IEEE Cornpurer (1991) 58-68.

[I71 D. Musliner, J. Hendler, A. Agrawala, E. Durfee, J. Stros- nider and C.J. Paul, The challenges of real-time AI, IEEE Computer (1995) 58-66.

[18] H.P. Nii, Blackboard systems: The blackboard model of problem solving and the evolution of blackboard architec- tures, The AI Magazine (1986) 38-53.

[19] S.J. Russell and S. Zilberstein, Composing real time systems,

Proceedings of the 12th IJCAI, Sydney, Autralia, 1991. [20] J.A. Stankovic and K. Ramamritham, Editorial: What is

predictability for real-time systems?, Technical Report 1990- 62, Department of Computer and Information Science, Uni-

versity of Massachusetts, Amherst, MA, July 1993. [21] Syseca Thomson, Grin, GMV, UPV, Marconi, Etnoteam,

REAKT Environment and methodology for real-time knowl- edge based systems, Esprif 2 (1990) 465 1.

Alfons Crespo received the B.S. and the Ph.D. degree in Electrical Bngineer- ing from the Polytechnic University, Va- lencia, Spain in 1979 and 1984 respec- tively. He is currently a Professor of Computer Engineering an Science at the Polytechnic University, Valencia, Spain. Since 1988, he has been the head of the Knowledge Technology group, leading several national and European research projects. His areas of interests are real- time systems, automation process con- trol and real-time operating systems.

Ana Garcia-Fornes recieved the B.S. degree in Computer Science from the Polytechnic University of Cataluiia, Spain in 1986. She is currently pursuing the Ph.D. degree in Computer Science at the Polytechnic University, Valencia, Spain, where she is a T.E.U. Professor with the Department of Computer Sci- ence. Her research interests focus on real-time scheduling, real-time operating systems, and real-time knowledge-based systems.

Houcine Hassan received the B.S. de- gree in Computer Science from the Polytechnic University of Valencia, Spain in 1993. He is currently pursuing the Ph.D. degree in Computer Science at the Polytechnic University of Valencia, Spain, where he is an Assistant Profes- sor with the Department of Computer Engineering and Science. His main re- search interests are focused in real-time systems scheduling and real-time archi- tectures for planning and process con- trol.