Real-Time Reasoning using Procedural Reasoning Francois Felix Ingrand Vianney Coutance LAAS/CNRS ACS Technologies 7, Avenue du Colonel Roche 5, Place du Village d'Entreprises, 31077 Toulouse Cedex, France 31674 Labege Cedex, France E-mail:
[email protected] E-mail:
[email protected] January 8, 2001 Keywords: Architectures and languages for AI, real-time AI.
Abstract
In the last years we have witnessed an increasing interest in AI systems able to perform reasoning and actions in real-time environments. However, the issue of combining advanced reasoning under real-time constraint remains a challenge. On one side, we have \pre-compiled knowledge" systems, with guaranteed response time, and on the other side, high level architectures which, even if they satisfy a number of desired functionalities required for real-time systems, fall short of being able to prove any temporal property. In this paper, we rst dene and characterize various temporal properties of a reasoning system, such as reaction time and response time. We argue that, although minimal, an upper bound on reaction time is a requirement to build any Real Time Reasoning System (RTRS). Moreover, independently of any particular application, it appears to be the only easy to prove real time property for a RTRS. However, a bound on response time is in most cases impossible to obtain. Nevertheless, there are still some temporal properties which, although less important than the response time, are required by some applications and can be proven for some systems. We then present the PRS system, which provides an upper bound on its reaction time, under some well dened assumptions, and gives great exibility to the user to implement meta level reasoning which allows him to add new temporal properties to the system, such as priority mechanisms or the capability to take deadlines into account. We conclude with a short survey of the current RTRS, we also show that the number of temporal properties we can prove about a system decreases as its exibility increases. The more open systems are, the less we can prove about their temporal properties.
1 Introduction In the last years we have witnessed an increasing interest in AI systems able to perform reasoning and actions in real-time environments. However, it appears that few systems simultaneously provide provable temporal properties, 1
while allowing advanced reasoning. In this paper, we provide an account of the temporal properties one can expect from a RTRS. In Section 2, we will dene what a RTRS is. For this denition, we will take the point of view of an event, and we shall study the journey of this event in the RTRS. Section 3 will present PRS, a general architecture for representing and reasoning about procedures in dynamic domains. We will show that by design, and under some well dened assumptions, the PRS main loop satises one important temporal property: an upper bound on the reaction time. Moreover, we will show in Section 4 that by extension, i.e. by writing meta level procedures, PRS can implement other temporal properties. Section 5 will present other systems and architectures which address the issue of RTRS. This short survey ranges from \Compilation Techniques" to \High Level Architecture".
2 What is a Real Time Reasoning System? Creation Date
TIA Date Reception Date
Done Date Parsed Date Time
Transmission Time Reaction Time Parsed Time Response Time An event occurs.
It is received by the The system reads system the event from its The event has input buffer been parsed by the system The last action applicable because of this event completed
Figure 1: Important dates in the life of an event The denition of a real-time reasoning system (RTRS) has been the subject of many publications, and is still a controversy in the AI community. Before entering the arena, we shall intuitively dene some temporal properties from an event point of view.1
2.1 Time intervals
As shown on Figure 1, we can dene the following time intervals for a given event: 1
We shall de ne them more accurately in Section 2.3.
2
Transmission time is the elapsed time between the date of creation of the
event and the date at which the event arrives in the system input buers, which is asynchronously accessible by the external modules. In other words, we recognize the existence of a buer, where external modules can put events for the RTRS when desired. From time to time, the RTRS picks up all the events in this buer to parse them. Reaction time is the elapsed time between the date of arrival of the event in the input buer and the date at which the event is taken into account by the system (or picked up from the input buer). In other words, for each event, it is the time spent waiting in the input buer. Parsed time is the elapsed time between the date at which the event is taken into account by the system and the date at which the event has been parsed by the triggering mechanism of the RTRS. Response time is somewhat more complex to dene. It basically depends of what we consider to be a response to an event, i.e. what type of solution we want to use in response to an event. The solution to arbitrary problems can be arbitrary complex... By using internal states, most systems \build up" the response over more than one cycle (except for \reex" or 0(1) computation). Thus it is certainly not reasonable to dene the response time as the time elapsed between the date of creation and the date at which the rst action to be performed, because of this event, has completed. We dene it at as the elapsed time between the date of creation of the event and the date at which the last action to be performed, because of this event, has completed. Note that for a given event, reaction time is always inferior or equal to the response time, which means that an upper bound must be found on the former if the latter is to be bounded. Now that we have dened these time intervals, we shall dene RTRS.
2.2 RTRS
To some people, it is not reasonable to \view real-time performance as a provable, guaranteed, universal property of the agent" 12]. Other think that an upper bound on the response time is always required 17], even if the price to pay is an almost complete loss of exibility at run-time. We believe that a so called RTRS must guarantee some temporal properties. In fact, the very essence of this domain, real-time system, is that one can prove some temporal properties before hand. People will only nd interest in RTRS, and will trust them if, and only if, for a given application, one can prove given properties about them. Which patient would accept to be under the control of an automatic respirator system which cannot guarantee a bound on reaction time? Which pilot will accept to y a plane if his assistant may fail whenever he needs it the most. One cannot trust a system if we can only guarantee that it works 3
in most situations, or average situations, but may loose events or exceed a given reaction time from time to time.2 At some point we need to be able to prove some properties of the reasoning system. The problem remains to decide which temporal properties do we need? what do we want to prove? and what is the trade o we are willing to make to guarantee these required property? For example, in some applications, one needs to prove that there exists an upper bound on the response time, and indeed, there is plenty of \traditional computer science" literature on systems which can guarantee such a thing 1]. However few reasoning systems are able to guarantee this property. The cause is not lost, we can in some situations use a more exible mechanism while still guaranteeing some basic temporal properties. Coming back to the RTRS denition, most people commonly expect a realtime system to give an appropriate response in a bounded, known in advance amount of time. Although this is desirable, it is not possible for most AI reasoning systems. Among the various underlying reasons, the most obvious one is that, contrary to standard programming systems, the control is not dened as imperative and therefore, it is very tedious, if not impossible, to predict exactly which execution path will be taken. Intuitively, the automata which would implement such a system would be very dicult, if not impossible, to produce, and probably too large to be used. As a result, it is quite dicult to predict the amount of time which will be spent to react to some particular event or combination of events. In fact, we will see in Section 5.1 that some languages and systems do allow the user to build a system with predictable response time. However, the trade o is usually very high and, considering that everything is hardwired before hand in some type of structure (an automata, a decision tree or an universal plan), we can hardly talk about reasoning systems.
2.3 Time Line for Events, or the Journey of an Event in a RTRS
Before going any further, we need to dene accurately what makes a RTRS. Which characteristics must be present and provable to guarantee such a quality? Which properties can one expect from such a system? First, considering that most people do not agree on what is a RTRS, we will assume that there are no such thing as RTRS, there are only reasoning systems with provable temporal properties. Various papers describe the expected functionalities of a RTRS 15, 12, 18, 22], but these functionalities are usually empiric and can hardly be considered as provable properties. For example, one usually nds the following: asynchronous event handling, non monotonicity, temporal reasoning, handling of multiple problems, reactive and goal-directed behavior, focus of attention, continuous embedded operation, and so on... Indeed, most of these characteristics are desired and they do help in designing a RTRS, but none of them yields enough 2 Note that this type of situation tends to appear exactly when you are in a critical phase, where many events occur at the same time and the risks of exceeding the capabilities of the RTRS are high.
4
provable information to guarantee any temporal property, they just participate in the overall design of a RTRS. We shall therefore take another approach. We will dene temporal properties not from the system point of view, or the system designer point of view, but from the event point of view. Instead of trying to dene what a system does or what its functionalities are, we shall present what happens to an event which occurs in, or is passed to, a so called RTRS. This description makes little assumption about the system architecture. Suce to say that we consider the system to respond to external events received from time to time in its input buer. The system runs a main loop which reacts to events and produces responses. These responses are usually a sequence of actions. Between the reception of the event and the action produced, dierent things happen and various steps are taken. By event, we mean any type of stimuli the system monitors or notices. An event can either be external, coming from other systems or the environment, or internal as it is produced by the system itself (such as posting goals or concluding new beliefs). In most cases, a system reacts to a conjunction of such events or conditions. However, for the purpose of this presentation, we consider only the event that triggers the reasoning to be meaningful, which is most likely the last one to appear. In other words, if a system reacts to A ^ B to do C , and A arrives in the system while B is not true, and then B arrives, we will consider B , which, in this case, causes the condition A ^ B to arise, as the important event. We dene c1 ::: ci ci+1 ::: the sequence of cycles of the main loop. We dene ei 1 :: ei j ei j +1 ::: the sequence of events arriving (note we use \arriving" and not \occurring") during the cycle ci . When the event arrives in the system, it is submitted to various treatments which lead the system to take a number of actions in response. Without dening any particular architecture, we shall dene various critical dates.
Creation Date is the date at which the event occurs and is created. This
date is probably not under the control of the system itself, but it should certainly be considered as the starting point of any temporal consideration with respect to this event. For an event e, we shall note this date DCre (e) . Reception Date is the date at which the event ends up in the system input buer. This happens during the cycle ci , and e is the j th event to appear in this cycle. For an event ei j , we will note this date: DRec (ei j ). Starting Cycle Date is the date at which the cycle ci starts, i.e. the date at which the system starts parsing its input buer. This buer contains all the events which arrived during ci;1 . For a cycle ci , we note this date DSC (ci). Taken into Account Date is the date at which each event is taken into account by the system. For an event ei j , we note it:DTIA(ei j ). This date 5
really corresponds to the time at which the system parses its input buer and transfers the event in its internal structure. Parsed Date is the date at which the event has been parsed. For an event ei j , we note this date: DPars(ei j ). This date really corresponds to the time at which the system decides which rules, procedures, ksar or actions are applicable regarding this event (and probably other events previously received and stored in the database). Done Date is the date at which an action to be done, because of an event, has completed. If we dene the sequence (ai j 1 :: ai j k :: ai j m) of the m rules, procedures, ksar, actions applicable, directly or not, because of the event ei j . We then consider the date DDone (ai j k ) as the date at which Min (ei j ) as the earliest action taken ai j k has nished. We then dene DDone Max (ei j ) as the latest by the system in response to the event ei j and DDone action of the system in response to the same event. From these dierent dates, we can establish a number of interesting time intervals on events and cycles.
2.3.1 Transmission Time
Transmission time of ei j is: TTran(ei j ) = DRec(ei j ) ; DCre(ei j )
This time is not really under the RTRS control, and although it is desirable to bound, this issue is not in the scope of our discussion. This time interval is very much dependent on the operating system and the type of communication mechanism (shared memory, sockets, and son on) used. Note, however, that this time can be of interest to systems performing temporal plan execution control 5].
2.3.2 Reaction Time
We dene Reaction Time for an event ei j as: TRea(ei j ) = DTIA(ei j ) ; DRec(ei j ) For a given cycle ci , we know by denition that: DSC (ci) DRec (ei j ) < DSC (ci+1) and DSC (ci) < DTIA (ei j ) < DSC (ci+1 ) thus the reaction time is inferior or equal to the time elapsed between two successive start cycle dates: TRea(ei j )
