Asbru is a time-oriented machine readable language developed for implementing skeletal plans in the Asgard project [74, 97]. The idea behind Asbru is to represent the domain knowl- edge as a library of skeletal plans that have various levels of detail and capture the structure of the modelled procedures but that allow parameterisation with different problem-specific el- ements. The created plans are stored in a plan library where each plan consists of a set of sub-plans that are necessary for successfully completing the plan objective. A plan that cannot be decomposed in a more fine-grained plan is then called an action. The plan interpreter when
3ODQ$ 3UHIHUHQFHV ,QWHQWLRQV &RQGLWLRQV (IIHFWV 3ODQ$ 3UHIHUHQFHV ,QWHQWLRQV &RQGLWLRQV (IIHFWV 3ODQ$ 3UHIHUHQFHV ,QWHQWLRQV &RQGLWLRQV (IIHFWV 3ODQV 7LPH $ % & ( ' ) * +
Figure 2.11: A plan structure in the Asbru formalism (Figure adapted from Miksch et al. [97]).
fed with a general plan is then attempting to decompose it into sub-plan until the level of the actions is reached. This plan consisting only of actions is then executed by the agent.
The structure of an Asbru plan can be seen in Fig. 2.11. It consists of a name, a set of arguments, including a time annotation, plan preferences, intentions, conditions, effects, and a plan body which describes the actions to be executed. A sub-plan of a plan then has the same components. It can be seen that the sub-plans are composed of actions (from A to H) which indicates that they cannot be decomposed any further.
2.5.6.1 Applications
Asbru is designed for the project Asgard that aims at supporting clinical guidelines by pro- ducing a library of skeletal plans that can later be applied to specific situations [130]. The project focuses on recognising the caretaker’s intentions from their actions, and providing cri- tique of these actions given the guidelines and the patient’s medical record.
Another application of Asbru was proposed by Azam et al. [7] where they use skeletal plans for inferring user plans based on recognised actions. To achieve that, wireless proximity data is recorded and separated into tasks and subtasks using a task separator algorithm. The detected tasks then are mapped to the high level Asbru plans and together they are fed to an activity recogniser. The recogniser in turn matches the available wireless proximity data to that available in the plan library tasks, and when such are recognised, it attempts to infer the user plan.
2.5.6.2 Requirements fulfilment
Asbru consists of a library of temporally related plans and actions and can thus express many of the requirements with the help of these temporal relations.
Composition: In Asbru a composite action is represented by a plan that either has other plans in its body or consists of actions. Fig. 2.11 shows such plan structure where each plan is considered to be equivalent to a composite action.
Sequence, Parallelism, and Synchronisation: Sequences are modelled by operators in the plan body that indicate whether a plan is executed sequentially, or in parallel. The synchronisa-
tion of two actions is also done with these operators, as the parallel operator expects the actions to start at the same time. Below Plan 1 represents executing two actions sequentially, and Plan 2, the execution of the same actions in parallel that are also synchronised.
Plan 1: (DO-ALL-SEQUENTIALLY (action A) (action B)) Plan 2: (DO-ALL-TOGETHER (action A) (action B))
Suspending and Resuming: Suspending and resuming an action is modelled by defining a suspend or resume point in the plan. It is expressed in the time annotation clause by defining a time range in which the requirement should be executed, and the requirement itself together with a pointer at the action of a plan where this should happen. Time annotation 1 gives an example of a suspended plan, and Time annotation 2 – of such that is resumed.
Time annotation 1: ((<time-range>) SUSPENDED (action A)) Time annotation 2: ((<time-range>) RESTARTED (action A))
Repetition: Repetition of an action or a set of actions can be expressed by defining a cyclical plan. That is done with the every clause that is defined in the plan’s body.
Plan 1: (EVERY (START <start-time>) (END <end-time>) (do action A) END-EVERY)
Choice and Priority: The choice is modelled by an operator in the plan body that allows executing the actions in any order. Priority, on the other hand is not modelled as it is handled by the time constraints and the sequential actions ordering.
Plan 1: (DO-ALL-ANY-ORDER (action A) (action B))
Dependence, Enabling and Disabling: Dependence can be modelled by using the time annotation which allows enabling a given plan or an action. Unless the plan has been already enabled, it is otherwise disabled, so there is no explicit definition of disabling.
Time annotation 1: ((<time-range>) ACTIVATED (action A))
Interleaving: Asbru does not support interleaving actions, as in order to continue from one composite action (or plan) to another, all or part of the actions in the first have to executed, but there is no explicit way of forcing the model to execute the remaining non executed actions, after the second composite action is completed.
Independence: There is no mechanism for modelling independent actions as all specified actions have temporal dependencies.
Application-based requirements: Asbru is not able to model probabilistic durations in terms of probability distribution, but it can express uncertainty in the begin and end times of the action by defining shift periods. It does not support observation model, but Azam et al. [7] have shown that it is possible to map the actions to corresponding sensor readings. The standard Asbru language is used for plans generation, but Azam et al. [7] have shown that it can also be applied to intention recognition.
'RPDLQGHVFULSWLRQ 3UREOHPGHVFULSWLRQ 2EVHUYDWLRQPRGHO QDPH W\SHV SUHGLFDWHV FRQVWDQWV QDPH REMHFWV LQLWLDOVWDWH GXUDWLRQYDOXHV 3 R_V FRPSLOH +003DUWLFOHI OWHU DFWLRQV JRDO
Figure 2.12: A model structure in the CCBM formalism.