Analysis of Candidate PSL Pro cessPlan Represen tations

Analysis of Candidate PSL Process�Plan Representations

Stephen T� Polyak�

Department of Arti�cial IntelligenceThe University of Edinburgh

�� South Bridge� Edinburgh EH� �HNUnited Kingdom

E�mail� Steve Polyakedacuk

Austin Tate

Arti�cial Intelligence Applications InstituteThe University of Edinburgh

�� South Bridge� Edinburgh EH� �HNUnited Kingdom

E�mail� atateedacuk

Abstract

This paper is a summary of analysis work completed during phase � of the National Institute of Standards andTechnology�s �NIST� Process Speci�cation Language �PSL� project� A set of requirements for this languagewas produced in phase �� These requirements were divided into separate categories� The main categories ofinterest for this analysis are the core and outer core requirements� Each set was then further partitioned intoeither representational or functional requirements� In phase � existing candidate process representations wereproposed which were believed to satisfy much of the representational and functional needs� Most of the particularset of candidates reviewed are those representations generated by participants in the DARPARome LaboratoryPlanning Initiative �ARPI� or representations in which participants in the initiative played a part� The resultsof the analyses of a number of the candidate representations with respect to the requirements are reviewed here�

�With contributions from PSL working group members which are speci�cally credited in the paper where provided�

�

Contents

� Introduction �

� Process Speci�cation Language �

�� Mission � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Phase � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Phase � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� Candidate Representations �

�� ACT � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� CPR � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� I�N�OVA� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� OZONE � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� PIF � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� STEP�� TF � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� Results �

� Discussion �

�� Analysis Issues � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Speci�c Representation Results � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

Conclusions ��

A Representation Cross�Comparison Matrix ��

B Detailed PSL Analysis for Each Candidate Representation �

B�� SRI s ACT Formalism Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � ��B�� Core Plan Representation�CPR� Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � ��B�� I�N�OVA� Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��B�� OZONE Scheduling Ontology Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � � � ��B�� PIF �v�� Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��B�� STEP ISO �� Part �� Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � � � ��B� O�Plan TF �v�� Detailed PSL Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

List of Figures

� Overall Analysis Results � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Results of Core Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � Results of Outer Core Analysis � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

�

� Introduction

The National Institute of Standards and Technology s �NIST� Process Speci�cation Language �PSL� project�Schleno� et al� �� grew out of a need for a shared process representation in a manufacturing environment�The project members have summarised their goal as

�� to create a process representation that is common to all manufacturing applications� generic enoughto be decoupled from any given application� and robust enough to be able to represent the necessaryprocess information for any given application� This representation would facilitate communicationbetween the various applications because they would all speak the same language� �Schleno� et al� ��

While the motivation was primarily from a manufacturing perspective� the project also recognised that this�shared representation� should apply to a broad range of systems and uses including� project management�business process reengineering� work�ow management� process planning� and production scheduling� Inaddition to the NIST core project members� a number of individuals from academia� governmental andindustrial organisations were assembled to assist in the e�ort� Steve Polyak and Austin Tate from theO�Plan project at the University of Edinburgh are participants in the NIST PSL project�

The project set out to achieve its goal through a series of phases that structured the work� During phase�� a set of requirements were developed that were expected to be satis�ed by the end�product language�Schleno� et al� �� Gruninger et al� �� In phase �� a variety of existing representations were identi�edthat could address the requirements to some degree� A number of participants performed analyses of vari�ous representations relative to the speci�ed requirements� This paper is a summary of the analysis workcompleted by the authors� during �� for phase � of the project�

Section � takes a look at the PSL project in more detail� A summary of the representations we examinedand some of our reasons for including them are outlined in section �� The result of the analysis is presentedin section � which is then discussed in more depth in section �� Finally� we review some conclusions of thiswork in section ��

� Process Speci�cation Language

�� Mission

NIST s mission is to promote U�S� economic growth by working with industry to develop and apply technologyand standards� One of the working areas involves the development of standards for the manufacturingindustry� There exists an identi�ed need within the manufacturing industry for a standard representationof processes and process information� The NIST Process Speci�cation Language �PSL� is being developedas an interlingua representation that can be used for sharing process knowledge within a manufacturingenvironment�

�� Phase �

In the initial phase of this work� a set of requirements were gathered by inspecting a number of applicationswhich utilise process knowledge �Schleno� et al� �� These requirements were categorised into� core� outercore� plug�in� and application�speci�c groupings� The analysis in this paper is only concerned with the �rsttwo categories� The core re�ects those requirements that the PSL group concluded were either essential�critical� or typically common for all of their identi�ed uses of process knowledge� The outer core containsrequirements which are considered to be �pervasive� but not necessarily essential� The core and outer coreare further sub�divided into either representational or functional requirements�

�With the exception of the OMWG CPR analysis which was completed by Adam Pease at Teknowledge Inc�and the PIF analysis which was jointly produced by the authors and other members of the PIF working group�

�

�� Phase �

The approach for phase � was to identify existing representations that were believed to address these require�ments� Each representation was then assessed by assigning an evaluation of its coverage for each requirementin the core and outer core� The possible values for each requirement were� completely satis�es� partially sat�is�es� cannot satisfy� or uncertain� Analysts were also asked to provide comments and�or describe constructsthat supported their rating for each entry�

� Candidate Representations

As mentioned in the previous section� a number of candidate representations were identi�ed by various PSLmembers based on the phase � requirements� The idea was to provide an overall picture of how existingrepresentations addressed various process�plan requirements in a number of ways� Candidates that were�strong� in certain areas might suggest good representational approaches to consider� With one exception�the representations o�ered and their corresponding analyses shown here were in�uenced strongly by theauthors knowledge and experience with DARPA�Rome Laboratory Planning Initiative �ARPI� or otherDARPA�funded plan� process� and schedule representations� The exception representational analysis wasISO s STEP Part � for which the anlysis was performed as a validation check of another analysis and theoverall approach� These representations are summarised below�

�� ACT

Traditionally� plan generation and reactive execution have been considered as separate activities� with few at�tempts to integrate them within a single system� The ACT formalism �Wilkins � Myers �� is a language forrepresenting the knowledge required to support both the generation of complex plans and reactive executionof those plans in dynamic environments� ACT has been used as the interlingua in an implemented systemthat links a previously implemented planner �SIPE�� with a previously implemented executor �PRS��

ACT is intended to serve as a general�purpose representation language that could be used to share know�ledge between many di�erent execution and planning systems� The representational and computationaladequacy of ACT has been validated by implementing the Cypress system� which uses ACT as an interlin�gua to enable runtime interactions between planning and execution subsystems� ACT focuses on a practical�yet su�ciently expressive representation that can address a variety of needs� Sample domains that ACT hasbeen used in include� controlling an indoor mobile robot� and military operations planning�

The ACT formalism is a domain�independent language for representing the kinds of knowledge aboutactivity used by both plan generation and reactive execution systems� The basic unit of representation isan Act� which can be used to encode both plan fragments and standard operating procedures �SOPs�� AnAct describes a set of actions that can be taken to ful�ll some designated purpose under certain conditions�The purpose could be either to satisfy a goal or to respond to some event in the world� The purposeand applicability criteria for an Act are formulated using a �xed set of environment conditions� Actionspeci�cations are called the plot� and consists of a partially ordered set of actions and subgoals� Theenvironment conditions and plots are speci�ed using goal expressions� each of which consists of one of aprede�ned set of meta�predicates applied to a logical formula� The meta�predicates permit the speci�cationof many di�erent modes of activity� including goals of achievement� maintenance� and testing� ACT canbe used to build a very strong model of the relationships between actions� temporal requirements� andresources� It has been shown to have expressive and computational adequacy in several applications� Speci�cmanufacturing elements would need to be added as extensions to support these domain�speci�c requirements�

ACT has been used as the common representation for SIPE�� and PRS in SRI s Cypress system�Wilkins et al� �� SIPE�� was also used as the core reasoning engine in SRI s SOCAP �System for Oper�

�Cypress � SIPE � PRS

�

ations Crisis Action Planning� �Wilkins � Desimone �� which was part of the second Integrated FeasibilityDemonstration of ARPI �Fowler et al� ��

�� CPR

The DARPA�sponsored Object Model Working Group is currently developing a �core plan representation��CPR� �Pease � Carrico � which is aimed at supporting the representational needs of many types of plan�ning systems� The OMWG s stated goal is

��to leverage common functionality and facilitate the reuse and sharing of information between a varietyof planning and control systems� �Pease � Carrico �

CPR has utilised ARPI work on KRSL� �Lehrer�ed�� the POCG�� the O�Plan project�Currie � Tate �� and the �I�N�OVA� representation �see below�� CPR is composed of a set of basicplan concepts that have been assembled into a re�ned design framework� The initial minimal set of conceptsincluded Action� Resource� Actor� and Objective� This set was then� expanded with more entities �e�g�Plan� TimePoint� etc�� de�ned with individual properties �e�g� an Actor has an Objectives slot� etc�� andstructured with stated relations �e�g� a Plan contains Actions� Actions contain TimePoints� etc��

CPR s intended application might involve the Joint Task Force Advanced Technology Demonstration�JTF�ATD� and Joint Forces Air Component Commander �JFACC� programs which are two DARPA jointforce military planning applications� The OMWG has also identi�ed the possibility of applying CPR tonon�military applications as well�

�� I�N�OVA�

�I�N�OVA� �Tate �c� Tate �b� Tate � is a constraint model of tasks� plans� processes� and activitieswhich adopts the perspective that all of these sources are �constraints on behaviour�� This model can beused as an ontology for shared representations amongst various operations in the planning and executionprocess including� knowledge acquisition� formal analysis� user communication� and system manipulation�

The acronym� �I�N�OVA� stands for� Issues� Nodes� and Ordering� Variable� and Auxiliary constraints�Issues and nodes are also expressed as constraints and can be thought of as implied constraints and activityconstraints� respectively� The inclusion of �issues� in the speci�cation of a plan or process is unique andallows the �state� of the planning process to be captured and communicated throughout the life�cycle of aplan� Tate relates these various constraint types together by stating

�Planning is the taking of planning decisions �I� which selects the activities to perform �N� which creates�modi�es or uses the plan objects or products �V� in the correct time �O� within the authority� resourcesand other constraints speci�ed �A��

�I�N�OVA� is not a representation language like some of the other candidates discussed in this paper�e�g� ACT� O�Plan TF�� Rather� it is a conceptual model which can underly languages which describeactivities� plans and processes� O�Plan s widely used domain description language �TF� can be seen as animplementation that rests upon the more general �I�N�OVA� model� The di�erent types of constraints inthe �I�N�OVA� model re�ect the di�erent types of components in an O�Plan agent �issue controller� issuehandlers� and plug�in constraint managers� �Tate et al� ��

�KRSL Knowledge Representation Source Language�POCG Planning Ontology Construction Group See Appendix in �Tate ��c��See �I N OVA� rationale at http�www�aiai�ed�ac�uk�oplaninova�html

�

�� OZONE

OZONE �Smith � Becker � is a toolkit for con�guring constraint�based scheduling systems �� A centralcomponent of OZONE is its scheduling ontology� which de�nes a reusable and extensible base of conceptsfor describing and representing scheduling problems� domains and constraints�

It had been noticed that there is commonality in scheduling system requirements and design at severallevels across application domains� Many of the concepts in the problems� domain and constraints couldbe considered to be reusable and extensible� The OZONE ontology provides a framework for analysingthe information requirements of a given target domain� and a structural foundation for constructing anappropriate domain model� Through direct association of software component capabilities with conceptsin the ontology� the ontology promotes rapid con�guration of executable systems and allows concentrationof modelling e�ort on those idiosyncratic aspects of the target domain� The OZONE ontology and toolkitrepresent a synthesis of extensive prior work in developing constraint�based scheduling models for a rangeof applications in manufacturing� space and transportation logistics�

OZONE adopts an activity�centred modelling viewpoint� There are �ve basic concepts of the ontology �Demand� Activity� Resource� Product� and Constraint� The ontology also de�nes speci�c inter�relationshipsand properties for these entities�Scheduling is de�ned as a process of feasibly synchronising the use of re�sources by activities to satisfy demands over time� and application problems are described in terms of thisabstract domain model�

OZONE has a powerful architecture that permits a domain modeller to focus on those items that arespecial for a speci�c instance� The use of constraint managers assists in rapid identi�cation of aspects toconsider� While the work on OZONE re�ects years of experience in the scheduling �eld� the ontology is stillrelatively new�

�� PIF

Critical in Business Process Reengineering or Enterprise Integration is the ability to share and interlinkheterogeneous process models� The goal of the PIF �Process Interchange Format� project �Lee et al� �� isto support the exchange of business process models across di�erent formats and schemas� The project pursuesthis goal by developing PIF �a common translation language that serves as a bridge among heterogeneousprocess representations�� translators between PIF and local process representations� and a mechanism forextending PIF to accommodate di�erent expressive needs in a modular way �Partially Shared Views��

At the heart of PIF is a core set of classes� Some of these classes are described in the following excerpt�

In PIF� everything is an ENTITY� that is� every PIF construct is a specialization of ENTITY� Thereare four types of ENTITY� ACTIVITY� OBJECT� TIMEPOINT� and RELATION� These four typesare derived from the de�nition of process in PIF� a process is a set of ACTIVITIES that stand in certainRELATIONS to one another and to OBJECTS over TIMEPOINTS �Lee et al� ��

The PIF project aims to support translations such that process descriptions can be automatically trans�lated back and forth between PIF and other process representations with as little loss of meaning as possible�If translation cannot be done fully automatically� the human e�orts needed to assist the translation shouldbe minimised� If a translator cannot translate part of a PIF process description to its target format� itshould� �� Translate as much of the description as possible �and not� for example� simply issue an errormessage and give up� �� Represent any untranslatable parts so that the translator can add them back to theprocess description when it is translated back into PIF��

�This builds on earlier work with OPIS �Smith ��Most of this PIF summary was written for the PSL group by Jintae Lee University of Hawaii College of Business

Administration

�

�� STEP��

This representation analysis is the only one here that wasn t part of the authors proposed set of represent�ations� This analysis was performed by the authors at the PSL members request as a veri�cation check ofanother analysis performed for STEP�� We include the results here as an additional contibution to thephase � e�ort�

Part � �Process structure and properties� �ISO �� is an Integrated generic resource of STEP �Standardfor the Exchange of Product model data� written in EXPRESS� It speci�es the information necessary tospecify the actions or potential actions to realize a process� This includes the relationships between theactions or potential actions in the process and the relationships between the processes that are used torealize a product� A process plan is the speci�cation of instructions to realize a product� This part doesnot specify any particular process� but de�nes the elements to exchange process information� This part isapplicable to all types of process de�nitions that can be represented in a discrete manner�

The constructs de�ne the structure for specifying� relationships between processes� the e�ectivity of aprocess� the properties of a process� the resources required for the process� the properties of the resource�the representation of process� the representation of the resource� and the relationship of the process to theproduct� Together� these constructs can be combined to create a process plan�

Part � is broken up into three schemas� method de�nition schema� process property schema� and pro�cess property representation schema� The method de�nition schema is the speci�cation of the instructionsrequired to perform a process that augments the product de�nition� de�nes the product� or contributesto the production of a product� The process property schema de�nes the properties of the actions of theprocess� the properties of the action methods of the process� the properties of the resources to be used inthe execution of the process� and the properties of the product that will result from the execution of theprocess� The process properties are the properties of the actions� resources� and products that are partof the process� The process property representation schema represents the properties required by either aresource� an action� or a potential action to e�ect a process� This could include either a resource parametervalue or an action parameter value�

Part � is able to cover many aspect of process representation because of the generality of the con�structs� For example� there is a construct called action method relationship which can either be a con�current action method or a serial action method and may be associated with a relationship with condition�With these constructs� one is able to model alternative tasks� concurrent tasks� parallel tasks� serial tasks�conditional tasks� iterative loops� and abstraction �decomposition�� Although this representation is adequate�the level in which it is written might make it di�cult for a systems developer to understand the meaningand usefulness of the constructs��

�� TF

The O�Plan �Open Planning Architecture� Project �Currie � Tate �� Tate et al� �� is exploring issues ofcoordinated command� planning and control� The objective of the O�Plan Project at the Arti�cial IntelligenceApplications Institute �AIAI� is to develop an architecture within which di�erent agents have command �taskassignment�� planning and execution monitoring roles� �Task Formalism� �TF� is a language that is usedto convey a detailed description of permissible actions or operations within an application area� includinginformation about how constraints imposed on the use of these actions should be satis�ed� and their e�ectson the domain if the actions are used�

O�Plan is a domain independent planning system� The agents in this system require the input of a domainrepresentation in order to complete their respective tasks� Task Formalism is used to provide this detailedknowledge� Task Formalism was originally developed for the NONLIN planner in �� and has been extendedand re�ned for use in O�Plan�

�This STEP �� summary was written for the PSL group by Craig Schleno� National Institute of Standards andTechnology �NIST�

Task Formalism is used to give an overall hierarchical description of an application area by specifyingthe possible activities within the application domain and describing how those activities can be �expanded�into sets of sub�activities with a wide range of contraints imposed� Plans are generated by choosing suitableexpansions for activities in the plan �i�e� re�ning those activities� and including the sets of more detailedsub�activities described by the chosen expansions� Ordering constraints are then satis�ed to ensure thatasserted e�ects of some actions satisfy� and continue to satisfy� conditions on the use of other actions� Othertemporal and resource constraints are also included in the descriptions� These descriptions of actions formthe main structure within TF� the schema� Schemas are also used in a completely uniform manner to describetasks set to the planning system� in the same formalism� Other TF structures hold global information ofvarious sorts and heuristic information about preferences for choices to be made during planning�

TF can be used to represent complex knowledge about a domain� This �rich� knowledge includes actione�ects and conditions� hierarchical relationships� temporal requirements� authority� resource needs� etc� Itsconstraint�based approach provides a strong� extensible approach to domain representation� When examiningO�Plan s Task Formalism with respect to the requirements of NIST s Process Speci�cation Language �PSL� itwas noted that certain aspects that are more closely related to manufacturing were lacking in TF �cost data�milestones� etc�� O�Plan TF is a speci�c language for planning and lacks some of the generality provided bya conceptual model such as �I�N�OVA� on which it is based�

� Results

The data of the analyses is presented in appendices A and B� Appendix A provides a cross�comparisonmatrix to easily see what the rankings were for each representation� Appendix B provides the detailed tablesfor each representation which lists the constructs identi�ed and�or explanations which help to support aspeci�c rating� In some cases where there were multiple contributors� such as the PIF detailed analysis �there are cited comments to show the various inputs�

Figure �� Overall Analysis Results

There were proportionately more outer core �� out of �� total� or �� requirements than there were

The PIF analysis was compiled by a number of the PIF working group members including the authors�

�

core requirements �� out of �� total� or �� No e�ort was made to weight the importance of eitherthe membership of the requirement to a speci�c set nor for its individual importance� The ratings fromthese tables in the appendices have been summarised in three separate �gures� Figure � provides a chartillustrating the overall coverage for each representation� Figures � and � separate the overall results intocore and outer core coverages� respectively�

In �gure �� the candidate representations are shown on the x�axis� These representations are roughly sortedby an ascending coverage rating� Each rating shows the distribution of assesments for the combined coreand outer core requirements� The �complete� data set �in solid black� shows the percentage of requirementsthat were considered to be �completely satis�ed�� So� for example� OZONE and ACT were consideredto �completely� satisfy around �� of all the requirements whereas PIF and STEP�� were around ��Now� if we add the set of �partially satis�ed� requirements to the �completely satis�ed� set we can see thesummation of these percentage below the �partial� series �in grey�� Given this combined set we can see� forexample� that ACT and TF are around �� whereas PIF is around �� The �none� series �in white�shows the percentage of remaining requirements that the representation was considered unable to satisfyat all� The �gure also shows that a small number of uncertain entries which still remained in the OZONEanalysis�

Figure �� Results of Core Analysis

Figure � is expressed in the same format as just described for �gure �� but �gure � only contains the datafrom the core category of the requirements� Rather than resorting this group by its coverage rating as wedid in �gure �� we have left the order alone� This helps to show the di�erence between the overall ratingsvs� the core alone� We can see� for example� that while PIF had a slightly higher overall rating �in �gure ��than STEP�� it had a lower core rating� This somewhat surprising result is discussed more in the followingsection�

The outer core results are re�ected in �gure �� As cited above� �� of the requirements came from thisset so it is not too surprising to see that the relative distribution of the ratings is similiar to the overallrating distribution in �gure �� This data shows a de�nite cut�o� between the ratings assigned to PIF �andthe representations to the left of it� vs� OZONE �and the representations to the right of it�� A result whichwill also be discussed in the next section is the apparently relatively low rating of CPR�

Figure �� Results of Outer Core Analysis

� Discussion

�� Analysis Issues

As we discuss these results� a few points should be made clear relating to certain issues in the analysisprocess� The �rst issue has to do with the �interpretation� of the scale provided for the analysis� This scaleagain was either� completely satisfy� partially satisfy� cannot satisfy� or uncertain� It is obvious that thisis a very large�grained measure and is subject to a number of perspectives on what it �means� to satisfy arequirement� A more �ne�grained scale could have been used but it would be even harder to explain why arepresentation received an � vs� a � for example�

Some members performing the analysis made the judgement that a requirement could only be met ifthere was a speci�c construct that was speci�cally designed to meet a given requirement� So� for example�if a representation used a frame�based syntax and did not have a slot speci�cally designed for �deadlinemanagement� �see requirement �� then it did not �satisfy� the requirement� Another perspective wasto look at the available constructs of a representation and to determine if there was a way in which therequirement could be expressed �e�g� deadlines can be achieved through an association of an activity statusand a speci�c time point�� The latter approach was the one taken by the authors in these analyses �withthe exception of CPR� which was the result of another analyst�� This di�erence lead to a skewing ofcomparsions between analyses performed by separate analysts� Speci�cally� while the CPR analysis wasincluded in this paper to associate its results with the other plan�based representations �e�g� ACT� TF�� itmust be understood that conclusions cannot be directly made on the comparisons between CPR and therest presented here� The other representation analyses are considered to be homogenous�

Another issue that confuses the interpretation of these results is the repeated use of the term �core�� Inrepresentations like PIF and CPR the term� core� is used to mean the set of elements that are central to therepresentation of a process or plan� This generally implies that the concepts which were considered to besuper�ous were moved outside of the core� On the other hand� when we are talking about the PSL �core�requirements� we are referring to those items that were judged by the PSL group to be �important� or

�Speci�cally Adam Pease Teknowledge Inc�

��

�necessary� requirements� These requirements might map to concepts which may not be central to processesknowledge but are more re�ective of PSL s perceived need� This helps to explain why the PIF�Core didn tmatch very well to the core requirements� but something like STEP s Part � did� What was core to PIFwas not necessarily re�ected by the PSL core requirements�

�� Speci�c Representation Results

Before we discuss some of the results of the representations reviewed here� it should be pointed out thatthere were � other representations that were reviewed as part of the phase � e�ort as well� This includedrepresentations like PERT networks� Gantt charts� KIF� Entity�Relationship diagrams� IDEF�� etc� The setin this paper was the authors contribution�� and contains most of the representations that were consistentlyrated very high amongst the complete phase � set� This rating again might be partially skewed due topossibly di�erent perspectives on how to rank the entries�

It is not too surprising that �I�N�OVA� rated the highest in this set due to its intended use� As describedin section �� I�N�OVA� is a conceptual model which can be thought of as a candidate to underly thefuture PSL language� just as it does with O�Plan TF� In fact it was interesting to review the few partsthat �I�N�OVA� didn t address in the PSL requirements �e�g� probablistic uncertainty�� O�Plan TF� SRI sACT� and CMU s OZONE were all relatively equivalent and re�ect their long pedigree in representing planand process knowledge� It is easy to understand that we then take a step down from these more completeand polished representations to review the relatively newer� and spartan PIF�Core and CPR model �againit is possible that the CPR rating might have been higher� possibly more equivalent to PIF�Core� if viewedfrom another perspective�� Possible future extensions to these representations could help them address someof the un�met requirements� It was interesting to note that while part � of STEP addressed a number ofcore items� its overall rating was closer to that of PIF�Core than ACT� OZONE� and O�Plan TF�

� Conclusions

In a way� these results con�rm many of the things one would expect to see when comparing these candidatesagainst a set of rigorous process requirements� �I�N�OVA�� being the most general representation� wasexpected to be able to address almost all of the concepts that were part of the requirements� The notion ofconstraints provided an adequate representation for identfying ways to express the various PSL requirements�ACT� O�Plan TF� and OZONE representations� anchored in prototype AI planning and scheduling systems�were hypothesized to be roughly equivalent in what they could and could not handle� Since the PIF�Coreand CPR model represent a much smaller and more compact set it was consistent to see a slight drop intheir coverage�

The representations developed for AI planning� scheduling and in earlier process�plan interchange lan�guages have been shown to be good �candidates� of ideas and concepts relative to the requirements de�nedin phase �� It is hoped that these ideas and concepts can be used to feed into the future work on NIST sPSL project as it moves forward to phase � work on a proposed language�

��Unless otherwise noted�

��

Acknowledgements

The O�Plan project is sponsored by the Defense Advanced Research Projects Agency �darpa� and RomeLaboratory� Air Force Materiel Command� usaf� under grant number f�� The O�Planproject is monitored by Dr� Northrup Fowler iii at the usaf Rome Laboratory� One author is sponsoredby the Air Force O�ce of Scienti�c Research� Air Force Materiel Command� USAF� under grant numberf�� an AASERT award monitored by Dr� Abe Waksman and associated with the O�Planproject� The u�s� Government is authorised to reproduce and distribute reprints for Governmental purposesnotwithstanding any copyright notation hereon� The views and conclusions contained herein are those ofthe authors and should not be interpreted as necessarily representing o�cial policies or endorsements� eitherexpress or implied� of darpa� Rome Laboratory� afosr or the u�s� Government�

Thanks to Adam Pease for the CPR analysis results and to the members of the PIF and PSL workinggroups for their cited contributions�

References

�Currie � Tate �� K� Currie and A� Tate� O�Plan� the open planning architecture� Arti�cial Intelli�gence� ��

�Fowler et al� �� N� Fowler� S�E� Cross� T�D� Garvey� and M� Ho�man� Overview� ARPA�Romelaboratory knowledge�based planning and scheduling initiative �ARPI�� In Tate�Tate �a�� pages ��

�Gruninger et al� � M� Gruninger� C� Schleno�� A� Knutilla� and S� Ray� Using process requirements asthe basis for the creation and evaluation of process ontologies for enterprise mod�eling� ACM SIGGROUP Bulletin Special Issue on Enterprise Modelling� ��

�ISO �� ISO� Product data representation and exchange� Part �� Integrated generic re�sources� Process structure and properties� Technical Report ISO Standard �� International Standards Organization� ��

�Lee et al� �� J� Lee� M� Gruninger� Y� Jin� T� Malone� A� Tate� and G� Yost� The PIF processinterchange format and framework version �� Technical Report Working PaperNo �� MIT Center for Coordination Science� ��

�Lehrer�ed�� N� Lehrer�ed�� ARPI KRSL reference manual �� Technical Report February�ISX Corporation� ��

�Pease � Carrico � R�A� Pease and T� Carrico� The JTF ATD core plan representation� A progressreport� In Proceedings of the AAAI Spring Symposium on Ontological Engineering�to appear� ��

�Schleno� et al� �� C� Schleno�� A� Knutilla� and S� Ray� Uni�ed process speci�cation language�Requirements for modeling process� Technical Report NISTIR �� NationalInstitute of Standards and Technology� Gaithersburg� MD� ��

�Smith � Becker � S�F� Smith and M� Becker� An ontology for constructing scheduling systems� InWorking Notes of �� AAAI Symposium on Ontological Engineering� Stanford�CA� �� AAAI Press�

�Smith �� S�F� Smith� OPIS� A methodology and architecture for reactive scheduling� InM� Zweben and M� Fox� editors� Intelligent Scheduling� Morgan Kaufmann Pub�lishers� ��

��

�Tate �a� A� Tate� editor� Advanced Planning Technology� Technological Achievements ofthe ARPARome Laboratory Planning Initiative� Menlo Park� CA� �� AAAIPress�

�Tate �b� A� Tate� Representing plans as a set of constraints � the � I�N�OVA � model� InB� Drabble� editor� Proceedings of the Third International Conference on Arti�cialIntelligence Planning Systems AIPS�� pages �� Edinburgh� Scotland�May �� Morgan Kaufmann�

�Tate �c� A� Tate� Towards a plan ontology� AI IA Notiziqe Quarterly Publication of theAssociazione Italiana per l�Intelligenza Arti�ciale�� Special Issue on Aspects ofPlanning Research� �� March ��

�Tate � A� Tate� Mixed initiative interaction in O�Plan� In Proceedings of the AAAI SpringSymposium on Computational Models for Mixed Initiative Interaction� Stanford�California� March ��

�Tate et al� �� A� Tate� B� Drabble� and J� Dalton� O�Plan� a knowledge�based planner and itsapplication to logistics� In Tate �Tate �a�� pages ��

�Wilkins � Desimone �� D�E� Wilkins and R�V� Desimone� Applying an AI planner to military operationsplanning� In M� Fox and M� Zweben� editors� Intelligent Scheduling� pages ��San Mateo� CA� �� Morgan Kaufmann Publisers� Inc�

�Wilkins � Myers �� D�E� Wilkins and K�L� Myers� A common knowledge representation for plan gen�eration and reactive execution� Journal of Logic and Computation� ��

�Wilkins et al� �� D�E� Wilkins� K�L� Myers� J�D� Lowrance� and L�P� Wesley� Planning and reactingin uncertain and dynamic environments� Journal of Experimental and TheoreticalAI� ��

��

A Representation CrossComparison Matrix

Key�p

� Completely satis�es req�� Partially satis�es req�� X � Cannot satisfy req�� Uncertain

PSL Requirement ACT CPR �I�N�OVA� OZONE PIF STEP�� TF

� Core Requirements

�� Representational Req�

�� Ad hoc Notesp p p

�p p

�� Cost Data � Xp

� X � �� Level of E�ort X

p p pX �

p

�� Product Characteristics � �p p

� � �� Resource

p p p p p p p

�� Resource Requirements for aTask

p p p p�

p p

�� Simple Groupingsp p p p p p p

�� Simple Resource Capabil�ity�Characteristics

� �p p

�p p

�� Simple Sequencesp p p p p p p

�� Simple Task Representationand Characteristics

pX

p

p p p

�� Task Durationp p p p p p p

�� Task Executorp p p p p p p

�� Functional Req�

�� Extensibilityp

Xp p p p p

�� Resource Allocation �dealloc�ation for one or many tasks

pX

p p� �

p

�� Simple Precedencep

Xp p p p p

� Outer Core Req

�� Representational Req�

�� Composition �Decompositionp p p

�p

Xp

�� Alternative Taskp

�p p p p p

�� Associated Illustrations andDrawings

p p p �

p p

�� Complex Groups of Tasksp

Xp p

�p p

�� Complex Resource Charac�teristics

� �p p

Xp p

�� Complex Sequencesp

�p p p p p

�� Complex Task Representa�tion and Parameters

pX

p p�

p p

�� Concurrent Tasksp p p p p p p

�� Conditional Tasksp p p

�p p p

�� Con�dence Levels �p

X X X X X�� Constraints

p�

p p p�

p

�� Multiple Duration�s� � �p

� � Xp

�� Implicit�Explicit ResourceAssociation

� �p p p

X X

�� Iterative Loopsp

Xp

Xp

� X

Appendix A � Cross�Comparison Matrix

��

PSL Requirement ACT CPR �I�N�OVA� OZONE PIF STEP�� TF

�� Manual vs� Automated Tasksp

Xp p

X �p

�� Manufacturing ProductQuantity

X �p p

X �p

�� Material Constraints X �p p

X � �� Parallel Tasks

p�

p p p�

p

�� Parameters and Variablesp

Xp p p p p

�� Pre� and Post�processingConstraints

p�

p p p�

p

�� Queues� Stacks� Lists � X � � � X �� Resource Categorization and

Grouping

pX

p p� �

p

�� Resource Locationp p p p

Xp p

�� Resource�Task CombinedCharacteristics

pX

p pX X

p

�� Serial Tasksp

�p p p p p

�� State Existence Constraintsp

Xp p p

Xp

�� State Representationsp

Xp p

� Xp

�� Temporal Constraintsp p p p

� �p

�� Uncertainty�Variability �Tol�erance

�p p

� X Xp

�� Functional Req�

�� Ability to Insert or Attach aHighlight�milestones�

� X � X X X �

�� Complex Precedencep

Xp p p p p

�� Convey the Ancestry or Classof a Task

pX

p p pX

p

�� Deadline Managementp

Xp p

� Xp

�� Dispatchingp

Xp p

X �p

�� Eligible Resourcesp

Xp p

�p p

�� Exception Handling and Re�covery

pX

pX

p� �

�� Information ExchangeBetween Tasks

pX

p p� X

p

�� Mathematical and LogicalOperations

pX

p p p p p

�� Support for Task�ProcessTemplates

pX

p p� X

p

�� Support for SimultaneouslyMaintained Associations ofMult Lev of Abstraction

pX

p p pX

p

�� Synchronization of Multiple�Parallel Task Sequences

pX

p p� X

p

Appendix A � Cross�Comparison Matrix

��

B Detailed PSL Analysis for Each Candidate Representation

B�� SRI s ACT Formalism Detailed PSL Analysis

Key�p


PSL Requirement Rank Description


�� Representational Requirements

�� ad hoc notes and annotations option�ally associated with any component of aplan � on�the��y� o��the�cu� notes anddocumentation� This could be voice�video� as well as text� A person s ob�servation of a process might go here�

pAn individual ACT s environment con�ditions contains a comment slot wheretext can be inserted� This may in�clude a �le reference to drawings� etc�Also� there is a property slot that holdsproperty�value pairs that can be used�de�ned�

�� cost data � the cost associated with aresource or task� This could be a �xedcost� cost rate� or a cost derived fromother attributes such as duration andlevel of e�ort� Costs associated withuncertainty� variability� tolerances� etc

� ACT permits a reusable resource modelthat could be utilized to represent someaspects of cost�

�� level of e�ort � description of theamount of a resource needed� in anygiven unit� to accomplish a task� Someexample levels of e�ort are equipment�hour� labor�hour� and crew size�

X ACT does not support a quanti�cationof resource needs�

�� product �work item� characteristics �information about an intermediate and�nal product which a process will pro�duce�

� This implementation of the ACT form�alism does not support a �produceable�model of resources that could be inter�preted as products�

�� resource � a single resource or a group ofresources� Some types of resources areequipment� people� information� and in�progress goods�

pResources can be logically representedfor use in ACTs�

�� resource requirement�s� for a task �withquantity� � the relationship between oneor more resources and a task�

pA simple association of resources andan ACT is established with the resourceslot�

�� simple groups of tasks � very basic�high�level set of tasks� One exampleis the grouping of tasks and sequencesthat make up a process plan or thatmake up a phase�

pAn ACT s plot consists of a directedgraph of nodes that represents a group�ing of actions

�� simple resource capabil�ity�characteristics � a high�leveldescription of the characteristics of aresource� More detailed descriptionscan be found in the outer core�

� A rough approximation of characterist�ics of a resource can be inferred by thetyped system used in ACT� �i�e� an Air�plane�� has di�erentcharacteristics thana Boat��

B�� SRI s ACT

��


�� simple sequences � linear� time�sequential groups of tasks� Moresophisticated relationships such asparallel and alternative tasks can befound in the outer core�

pAn ACT s plot consists of a directedgraph� The nodes in this graph rep�resent actions and the links represent apartial ordering that can provide simplesequences�

�� simple task representation and charac�teristics � a simple� high�level descrip�tion of the task� More detailed rep�resentations can be found in the outercore�

pAn individual ACT s environment con�ditions contains a comment slot wheretext about the actions can be inserted�Also� there is a property slot for user�de�ned property�value pairing that canalso annotate characteristics�

�� task duration � the time required tocomplete a task or group of tasks� Onlysimple durations are represented here�

pTime�constraints impose any of the ��Allen relations between actions� In ad�dition to these constraints� time win�dows can be setup for start�end� dura�tion� etc�

�� task executor � who is responsible forexecuting a task or group of tasks� Ex�amples include a person� controller� orexternal company if the task is contrac�ted out�

pWhile there isn t an explicit slotfor task executor� this property�valuecould be inserted into the propertiesslot�

�� Functional Requirements

�� extensibility � there must be a mechan�ism in place to allow a user to add ad�ditional information to the pre�de�neddata constructs� One such mechanismcould be the addition of stubs for user�de�ned information�

pThe ACT properties slot provides amechanism to allow additional user�de�ned information to be added to therepresentation�

�� resource allocation�deallocation for oneor many tasks � the assignment and re�lease of one or more resources to a taskof group of tasks�

pAn ACT USE�RESOURCE statementis used to provide a representation forresource allocation�deallocation�

�� simple precedence � a high�level descrip�tion of the precedence constraints of onetask on another� A more detailed de�scription of precedence and constraintscan be found in the outer core�

pVarious constraints can be placed onthe precedence orderings of actions�Temporal constraints can be used tocreate speci�c time windows� precondi�tions can be used to express situationalconstraints that must be satis�ed in or�der to apply the act�

� Outer Core Requirements


�� abstraction � within the scope of thisproject� there are three concepts of ab�straction that must be captured� �hier�archy� incompleteness� ambiguity�

pACTs can be arranged in a hierarchicalfashion that links thru the Cue gatingslot in a plot� In fact� an ACT is an ab�straction of a set of actions and thoseactions may be abstractions of otherACTs�

B�� SRI s ACT

�


�� alternative task � �see complex se�quences�

pACTs support alternative tasks in avariety of ways� A set of ACTsmay share the same cue environmentconditions o�ering alternative choices�Within a plot� conditional arcs can of�fer disjuctive paths�

�� associated illustrations and drawingsp

Property�value slots can be assigned toACTs that contain �lename pointers tographical �les� etc�

�� complex groups of tasks � groups oftasks which have a common tie�

pAn ACT is essentially a complex group�ing of tasks �in a plot�� ACTs arealso connected together via Achieve�Achieve�by� etc�

�� complex resource characteristics � a de�tailed description of the characteristicsof a resource or group of resources�

� Since ACT uses typed variables� re�sources could be grouped as instancesof certain classes� Characteristics of aclass could then be inferred�

�� complex sequences � complex orderingrelationships between tasks

pACTs �and plot nodes� can be orderedin complex relationships that support avariety of conditional� temporal possib�ilities�

�� complex task representation and para�meters � a detailed representation of atask or group of tasks�

pPlots provide a very detailed expressionof how a task �or grouping of actions�may be completed�

�� concurrent tasks � �see complex se�quences�

pConcurrency is possible with parallelnodes in plots that can split�join thenetwork�

�� conditional tasks � a task that onlyneeds to be performed under some pre�de�ned circumstance�

pACTs �and plot nodes� can use testmetapredicates to provide conditionalprocesses�

�� con�dence levels � a measure of cer�tainty that some attribute is true�

� While there isn t direct support for thiswithin ACT itself� there is a subsystemin the implementation �Gister�CL� thatcan reason about uncertain informationabout the world and actions�

�� constraints � implicit or explicit con�straints associated with a task or re�source�

pA variety of constraints can be placedon an ACT that can control things likeapplicability� temporal limits� etc�

�� date�s� and time�s� and�or multipleduration�s� � the association of one ormore dates and times and�or multipledurations with a resource or task

� The temporal elements �windows� dur�ations� etc�� are all relative points toother temporal elements in the repres�entation�

�� implicit�explicit resource association �an implicit or explicit dependency of aresource on another type of resource�

� This can partially be achieved implicity�For instance� whenever we wish to saythat if you use x� you must have y aswell� �USE�RESOURCE �x y��

B�� SRI s ACT

��


�� iterative loops � a situation when a taskor group of tasks repeats until a desiredcondition is met

pLooping is possible by linking a plotnode back to an ancestor node in thegraph� Test metapredicates control thenumber of times�

�� manual vs� automated tasks � charac�teristics of a task can di�er dependingon if a human or a machine is perform�ing that task�

pPrecondition gating slots can �lterwhich ACT is applicable�

�� manufacturing product quantity � theamount of the product that is to man�ufactured�

X This is not part of ACT�

�� material constraints X This is not supported in ACT�� parallel tasks

pParallel tasks can be de�ned using par�allel plot nodes�

�� parameters and variables � place hold�ers that can store a constantly changingvalue�

pACT has a typed variable system thatcan be bound and rebound as needed�

�� pre� and post�processing constraintsp

Preconditions and e�ects provide bothof these�

�� queues� stacks� lists � the representationof an ordered or unordered group�

� ACTs support lists of items�

�� resource categorization and grouping �a logical grouping of resources with acommon tie�

pLogical categorization and groupingcan be done because resource can beconsidered to belong to a class of re�source� �e�g� airplane�� is an airplane�etc��

�� resource location� � identi�cation of thelocation of a resource�

pOn pg� �� of the cited paper� there isan example ACT that tracks resourcelocations�

�� resource�task combined characteristics� qualities of a resource that are depend�ent on a particular task� or qualities of atask that are dependent on a particularresource�

pMultiple ACTs can be de�ned with dif�ferent gating conditions and e�ects thatcan be used to express this requirement�

�� serial tasksp

Serial ordering of tasks is supported�� state existence constraints

pThe test metapredicate can be used toevaluate state existence�

�� state representations � the descriptionof a process in terms of any combina�tion of the states of the process and�orresource�

pState representations are central to theACT representation�

�� temporal constraintsp

A rich set of temporal constraints canbe used to cover all �� relations�

�� uncertainty�variability�tolerance � therepresentation of the deviation from thenominal�

� There are many ways that ACTs canexpress tolerance or variability of val�ues� �For example� you can de�ne anearliest�latest starting time� etc��

B�� SRI s ACT

�



�� ability to insert or attach a highlight�milestones� � the ability for a user tohighlight a section of the process

� This can be roughly approximated byadding property�value entries that areuser�de�ned as milestones�

�� complex precedence � the ability to con�vey a series of tasks ordering require�ments within a given process�

pACT provides a rich set of gating con�ditions�

�� convey the ancestry or class of a task� the ability to describe a task as itrelates to the specialization of another�higher�level task�

pAn ACT s plot is essentially a special�ization of the overall task�

�� deadline management � the abilityto consider a predetermined deadlinewhen making decisions�

pTime windows can express a variety ofdeadlines �e�g� x must happen beforetime�� etc��

�� dispatching � the determination andrepresentation of rules and guidelines todecide when items should be releasedfor production�

pThere isn t an explicit mechanism thatis designed for this purpose� but loop�ing� rebinding of variables� and a testmetapredicate should be su�cient�

�� eligible resources � the ability to de�termine which resources can be chosenfor a task �selection rules�

pThe same mechanism used to describelocation of a resource can be used tocreate custom eligibility needs�

�� exception handling and recovery � theability to specify corrective action whena task fails�

pThis is a central concern for PRS�which uses ACT�� Conditional actionsprovide means to describe recovery pro�cedures�

�� information exchange between tasks �the ability to represent the �ow of in�formation among tasks

pInformation is exchanged via variablebindings�

�� mathematical and logical operations �the language must be able to performmathematical and logical operations�

pACT supports FOL as its representa�tion system�

�� support for task�process templates �the language must allow for templatesof a task or process�

pACTs are essentially a process tem�plates become further detailed by otherACTs�

�� support for simultaneously maintainedassociations of multiple levels of ab�straction � the ability to associate in�formation at multiple levels of abstrac�tion with a task�

pInformation can be associated with anACT that is appropriate for that ACT srelative level in the process representa�tion�

�� synchronization of multiple� paralleltask sequences � the ability to specifya mechanism to coordinate two or moretasks that occur at the same time�

pParallel nodes in ACT plots serve tosynch parallel task sequences where ne�cessary�

B�� SRI s ACT

��

B�� Core Plan Representation�CPR� Detailed PSL Analysis

Key�p






pAnnotation object is contained in Pla�nObject superclass


X No comment


pContained in the CPR specializationobjects of ConsumableResource

�� product �work item� characteristics� in�formation about an intermediate and ��nal product which a process will pro�duce�

� Work products can been given as theunderspeci�ed object DomainObject�


pResource object or its specializations

�� resource requirement�s� for a task � therelationship between one or more re�sources and a task�

pAction objects �tasks� may contain Re�source objects


pActions may contain sub�Actions


� A suggested set of specializationsto Resource is provided includingConsumable� Reusable� Synchronous�lyReusable� ExactCapacity and Non�Sharable�

B�� Core Plan Representation �CPR�

��



pConstraints may be assigned to Actionswhich enfore parallelism or serialism�


X No comment


pActions have start and end times


pActions have associated Actors



X CPR is a representation only� However�any object may be extended through in�heritance�


X No comment


X CPR is only a representation� However�precedence constraints on Actions canbe speci�ed�




pThere is no implied enforcement of com�pleteness� Uncertainty and Imprecision�fuzzy logic� constructs are included�


� Actions can be given aribtrary con�straints but there is no speci�ed con�struct to describe one as an alternativeto another�


Arbitrary Annotations may be linked toany plan object


��



X No comment


� A hierarchy of resource types isprovided


� Arbitary types of constraints may begiven to specify parallelism or serialism


X No comment


pActions may be constrained to run con�currently or may be unconstrained al�lowing concurrent execution if possible�


pActions may have constraints on exe�cution� Assumptions may also be in�cluded which trigger new Actions if theassumptions are violated�


pAll low level data may be tagged withUncertainty or Imprecision measures�High level objects like Entity or Actionmay be encapsulated in an Uncertain�Entity object which has an associateduncertainty or imprecision


� Examples are given for temporal andpre� and post�condition constraints butthe Constraint object is relatively un�derspeci�ed�


� CPR includes TemporalPoint a special�ization of which is the OMG universaltime object which has both time anddate� Action may be specialized to con�tain other durations but the base classonly contains start and end�


� A Resource may contain a Constraintwhich speci�ed dependency on anotherResource�


X No comment


X No comment


� DomainObjects with associated quant�ity may be speci�ed as products of Ac�tions�


��


�� material constraints � Constraints may state ranges about ar�bitrary attibutes of an Entity�

�� parallel tasks � Arbitary types of constraints may begiven to specify parallelism or serialism�


X No comment

�� pre� and post�processing constraints � Examples are given for temporal andpre� and post�condition constraints butthe Constraint object is relatively un�derspeci�ed�


X No comment


X Resources may have subResources butonly hierarchical arrangements are cur�rently allowed


pResources may be constrained to havea particular SpatialPoint


X No comment

�� serial tasks � Arbitary types of constraints may begiven to specify parallelism or serialism�

�� state existence constraints X No comment�� state representations � the description

of a process in terms of any combina�tion of the states of the process and�orresource�

X Cannot�


Actions have associated TimePointswhich constrain their execution


pUncertainty and Imprecision �fuzzy lo�gic� constructs are included and maybe speci�ed for any object includingTimePoints�



X No comment


X No comment


X No comment


��



X No comment


X No comment


X No comment


X No comment


X No comment


X No comment


X No comment


X No comment


X No comment


��

B�� I�N�OVA� Detailed PSL Analysis

Key�p






pA � Misc�Annotation constraint�


pA � Misc constraint � in global �I�N�OVA� model if not speci�c to a givenprocess or plan� or in plan s �I�N�OVA� representation if it is speci�c tothat�


pA � Resource �or A�Resource�Agent�constraint�


pV � entity�variable constraint�


pA � object used in resource constraint�


pA � Resource constraint


pN � include activity constraint�


pV � global �I�N�OVA� entity�variableconstraint for object to be used as a re�source�

B�� I�N�OVA�

��



pO � Ordering constraint on time pointassociated with begin or end of anyactivity�


pN � Name of activity�


pO � Metric temporal constraint betweentime points associated with begin andend of an activity�


pA � Resource�Agent constraint� Thisallows for a speci�c �performer� of anactivity�



pA � Open framework for adding any in�formation in the form of a constraint orannotation�


pA � resource constraints should be ex�pressive enough to support this�


pO � Ordering constraints� For example�O�Plan Task Formalism allows A !� Bimplying time point at end of activity Ais before time point at begin of activityB� O�Plan TF also allows SEQUENCEA� B� C� �� to A!�B� B!�C� C !��




�



pA�N � Constraints of various types �inparticular A�World State constraints�may be modelled at any abstractionlevel� Activity decompositons �Includeactivity constraints in process or activ�ity description library� �N�� Missingconstraints just imply a wider allowedspace of behaviour� The �I�N�OVA�model is speci�cally designed to allowfor incompleteness and uncertainty inprocess and activity descriptions� The�I�N�OVA� model is speci�cally de�signed to allow for incompleteness anduncertainty in process and activity de�scriptions� Speci�c constraints wouldneed to have uncertainty in their for�mulation and expression �I�N�OVA�makes no commitment to this�


pdisjunctive constraints may be includedin the �I�N�OVA� model in any place� and this is not limited to disjunctionswithin any one speci�c constraint typeor sub�type� An other node can alsorepresent conditional activities�


A � Associated information and an�notations may be states as �annotationconstraints� or more generally �Miscel�laneous constraints��


pN � other nodes that contain sub�planscan be used to group a task for a com�mon purpose �I�e� the detailed expres�sion of an activity��


pA � Resource constraints or Agent con�straints can describe these characterist�ics�


pO � ordering constraints can describe avariety of necessary relationships�


pN � Nodes that include activities cantake into account concepts such as ap�plicability� performance limits�resourceusage� number of constraints on its con�ditions� suitable parameter bindings�etc�


pO � activities can be constrained to have�concurrent� execution�


��



pN � other nodes may also represent aconditional �if then else� within theplan�


X �I�N�OVA� does not contain a mech�anism for probablilistic certainty�


p�I�N�OVA� views a plan as a set ofconstraints�


pO � metric temporal constraints can re�late a given time point to an actual timeor calendar reference�


pA�N � Resource constraints can expli�citly be attached to an activity� A nodethat contains sub�plans implicity con�strains resource usage though its sub�constraints�


pN � other nodes can represent an encap�sulation of iteration or for�each�


pA � Misc contraints can be createdto characterize specialized attribute re�quirements�


pA � Resource constraints can be used tocontrol the maximum allowable amountof the resource�

�� material constraintsp

A � resource constraints can be usedto describe specialized characteristics��always� constraints can be used to de�clare unchanging global information�

�� parallel tasksp

O � ordering constraints can describeactivities that occur in parallel�


pV � entity�variable constraints can beused to manage �place holders� thatcan take on a range of values�


O � input and output temporal con�straints are used to describe whatshould hold immediately before or aftera given timepoint�


� �I�N�OVA� does not have an explicitrepresentation for data structures suchas queues or stacks�


pIt is anticipated that a representa�tion language that expresses the �I�N�OVA� model will use a sorted �rst or�der logic�


�



pA� V � A�Resource constraints canadd information such as location� en�tity�variables can be used to update alocation attribute�


pO�N � This requirement can be metby creating alternate �include activity�nodes that utilize the same resources�but may have di�erent input temporalconstraints�


O � ordering constraints are used to de�clare activites in serial�

�� state existence constraintsp

O � input temporal constraints specifythose things that are required to holdbefore a given timepoint �which may beattached to an activity��


pA � World State constraints act on theplan state representation�


O � Temporal modelling is performedby using timepoints and ordering con�straints�


pThe �I�N�OVA� model is speci�callydesigned to allow for incompletenessand uncertainty in process and activitydescriptions� Speci�c constraints wouldneed to have uncertainty in their for�mulation and expression �I�N�OVA�makes no commitment to this�



� A � Misc or Annotation constraintscan be attached to nodes to give them�milestone signi�cance��


pO � Ordering constraints can be gener�ally speci�ed to establish node preced�ence�


pN � other node constraints can be usedto encapsulate specialized sub�plans�


pO � Ordering constraints are used toarrange activities within speci�ed tem�poral constraints�


pO � Input temporal constaints can beplaced on activities that release repres�ent releasing items for production�


��



pA � Resource constraints for an activ�ity describe a sorted requirement for re�source usage�


pO � input and output temporalconstraints can be used to specifywhat should hold before and after atimepoint �therefore an activity��


pV � Information is shared betweennodes thru entity�variable constraints�


pThe expressions in �I�N�OVA� areconsidered to be based in �rst order lo�gic that will allow for logical and math�ematical manipulation�


pN � other nodes and include activitynodes are linked in a �generic processtemplate� that is applicable for use as�suming the constraints are satis�ed�


pA � Constraints can be attached at anylevel of a node hierarchy that would beappropriate for that model�


pO � Temporal constraints can be at�tached to activities that make the hardrequirement that begin�end timepointsare equal�


��

B�� OZONE Scheduling Ontology Detailed PSL Analysis

Key�p






Need more information�


� There is no explicit cost property for re�sources or tasks in OZONE� but someaspects ofcost can be treated as a prop�erty that is a function of the domain�i�e� the same was as LAND or SPEEDare noted in the paper��


pDemands can be de�ned that explicitlyrepresent the quantity required� Activ�ity RESOURCE�REQUIREMENTSimpose resource usage�comsumptionconstraints for the activity to execute�


pOZONE uses a distinct concept de�n�ition for a product� Intermediateproduct information and work itemcharacteristics can be attached directlyto a product�


pA resource is a distinct concept de�n�ition in OZONE� A variety of resourcetypes are supported�


pAn activity can be de�ned with rela�tionships to resources that it requires�


pOZONE supports the grouping of tasksin a variety of ways� Tasks �activities�can be grouped into those that ful�lla demand� produce a product� or areinvolved in a hierarchical ordering�


pA variety of capabilites�characteristicscan be assigned to a resource via prop�erties� �e�g� capacity� amount of set�uptime needed� etc��

B�� OZONE Scheduling Ontology

��



pOZONE contains INTERVAL�RELATIONS that can easily handlesimple linear sequencing�


Need more information�


pOZONE activities contain a �duration�property for this purpose�


pA task executor can be modelled as arequired resource for the activity�



pOZONE puts forward a concept ofmodel specialization� Elements can beadded that specialize the representationfor a target domain�


pResources provide Allocate�Capacityand Deallocate�Capacity capabilitiesand Activities provide reserve�resourcesand free�resources capabilities�


pVarious constraints can be de�ned toregulate precedence relationships ofactivities�




� To a degree� it can be stated thata constraint�based approach permits amodel to be incomplete and vague oneverything� except those items that arenecessary to meet requirements� �e�g�Schedule these tasks in any order youlike� but just make sure C is after B�etc�� What is described in the require�ment though is more of a runtime testcondition�


��



pTwo activities can be de�ned that havethe same e�ects� The scheduler canthen select an alternative that satis�esthe requirement�

�� associated illustrations and drawings Need more information�� complex groups of tasks � groups of

tasks which have a common tie�

pOZONE supports complex grouping oftasks� For example� a set of tasks canbe grouped that meet the requirementsfor a speci�c demand� a set of tasks thatproduce a work item can be attached tothe speci�c product as well�


pOZONE provides a variety of waysto assign characteristics to resources�For example� associating state informa�tion with a resource� physical properties�range� speed�� capacity models� etc�


pComplex ordering relationships can bede�ned via INTERVAL�RELATIONS��e�g� BEFORE� SAME�END� CON�TAINS� etc��


pAn activity can be de�ned with a com�plex set of properties� OZONE activit�ies support an explicit set of pararmet�ers that can in�uence the representa�tion of the task�


pAn activity can contain temporal rela�tionships to other activities� If a rela�tionship of same�start and same�end isde�ned then the two activities are con�strained to be concurrent�


� At a high level� we can say that anactivity is conditional because its exe�cution is dependent on outstanding de�mands� However� there does not seemto be an explicit conditional structure�


X No support for a measure of certainty�


pOZONE presumes an underlyingconstraint�based solution framework�


��



� OZONE uses various date�time re�lationships and assumes the exist�ence of TIME�POINTS� and TIME�INTERVALS� While there is supportfor multiple durations �e�g� duration ofan activity� duration of setup�time for aresource� etc�� a speci�c requirement ofmultiple durations for the overall activ�ity does not seem possible�


pVarious levels of implicit�explicit re�source associations can be made �i�e�sub�resources for aggregation� dynamiccompatibility between � resource as�signments� etc��


X OZONE does not appear to support it�eration or looping constructs�


pOZONE does not make an explicit dis�tininction of this type� but it wouldseem possible to create two activit�ies� one that represented the manualtask and one that represented the auto�matic task and any �di�ering� would bede�ned by each respective activity�


pAn explicit slot for specifying productquantity is part of a demand inOZONE�

�� material constraintsp

OZONE has an explicit slot for materialconstraints as part of a demand �i�e� thetype of material to be used��


Nodes in OZONE s networks of activit�ies can be ordered in parallel�


pThe OZONE ontology has parameters�e�g� an activity accepts a quantityfrom demand� and variables �e�g� re�cording changes in state��


A variety of pre and post processingconstraints apply to activities� �e�g��pre� state existence �post� duration be�fore next activity� etc��


� Lists of elements only�


pOZONE supports a rich set of categor�ies and groupings of resources based ontheir usages� atomicity� capacity� etc�


��



pOZONE has an explicit slot in a de�mand for the ORIGIN and DESTINA�TION for a material�


pCombined activity�resource character�istics are utilized in evaluating staticand dynamic compatibility constraints�


Simple serial assignment falls under a�before� interval�


Activities and resources can be in agiven state and requirements aboutstate existence can be applied�


pActivities and resources can be repres�ented as being in certain states�


A variety of constraints� absolute�time�constraint� relative�time�constraint �interval�relations� duration�constraints�


� Various upper�lower bounded valuessupport variability and tolerance of as�signment values� but probabilistic un�certainty is not supported�



X No support for this�


pDuration�Constraints� interval�relations� state requirements� andaspects of demand management allcombine to provide complex precedencemechanisms�


pClass ancestry in OZONE is expressedthru its extension mechanism of modelspecialization�


pDeadline management is possible viaRELEASE�DATE� DUE�DATE prop�erties of a demand�


pDispatching is encompassed in thedemand�product combined capabilities�Work item generation is linked to expli�cit elements of demand�


��



pOZONE maintains the �eligibility�of resources and also provides otherUSAGE�RESTRICTIONS that canallow a richer model of restrictions �e�g�UNAVAILABILITY�INTERVALS re��ect time periods where a resource isnot eligible� etc��


X No support for this�


pOZONE supports paramaters passingto exchange information between vari�ous elements �e�g� demand informationis passed to an activity� etc��


pConstraint expressions use mathemat�ical and logical constructs in OZONE�


pThe ontological element �activity� is atemplate for what a task should be�The various properties are expected tobe �lled in and new slots can be addedto extend this base concept�


pConstraints can be added at any levelof abstraction to further de�ne the re�quirements on the target space� Inthe example listed� you would require �people �resources�� Next you may adda constraint on those resources �specialability�� Next you may add a very spe�ci�c contraint �who they are�� etc�


pMultiple activities can be synchron�ized when parallel via INTERVAL�RELATIONS�


�

B�� PIF �v�� Detailed PSL Analysis

Key�p






� This requirement is partially �lledthrough the use of the �documentation�slot and the �user�attributes� that canbe attached to PIF entities�

�� cost data � the cost associated with aresource or task� This could be a �xedcost� cost rate� or a cost derived fromother attributes such as duration andlevel of e�ort� Costs associated withuncertainty� variability� tolerances� etc�

X PIF does not address resource or taskcost�


X PIF can say that an activity uses someobject� but does not have a mechanismto quantify the usage�


� While PIF can represent objects thatare created� modi�ed� or used duringan activity� there is no provision for at�taching characteristics to that object��Dec�� As per Lee� should be � �par�tial� because the PIF�CORE provides ameans of specifying such characteristicsvia User�Attributes and PSV s�


pActivities can specify which objects �re�sources� were created� modi�ed or used


� PIF cannot represent quantity of an ob�ject �resource��


pPIF can express grouping of activit�ies through decompositional relation�ships� ��Dec�� Gruninger� satis�ed ifthe grouping is a deterministic activity�but is not satis�ed in general for non�deterministic activities

B�� PIF �v��

��


�� simple resource capability or character�istics � a high�level description of thecharacteristics of a resource� More de�tailed descriptions can be found in theouter core�

� ��Nov�� X to � as per Tate s in�put� PIF Core does not have an explicitmechanism to describe the �capability�of an object �when used in the role of re�source� but it does allow for attributesof such objects to be stated� Capabilitylimited to agents�


pThe use of timepoints and temporalrelationships will provide simple se�quences� ��Dec�� Gruninger� This re�quirement is satis�ed insofar as we canwrite the de�nition of an activity forsimple and complex sequences� How�ever� we cannot express the de�nitionof simple and complex sequences usingPIF�Core�


pPIF can represent a task with its e�ects�conditions� etc� Also� textual high�leveldescriptions can be attached via thedocumentation attribute�


p��Nov�� Change from

pto � as per

Tate s input� An activity can containbegin and end points� but PIF Coreitself does not support quantities forduration� ��Dec�� Changed back top

per Gruninger and Lee� This canbe captured� since the axiomatizationof time points in the situation calculusmeans that time points are isomorphicto the real numbers�


pPIF can describe a �performs� relation�ship between activities and agents�



pPIF has a �user�attributes� slot de�nedat the highest level of the hierarchy thatcan store user�de�ned information�


�



� ��Nov�� Change from � top

as perTate s input that pointed out that spe�cifying individual resource units are notpart of the requirement� PIF can rep�resent objects that are created� modi��ed� or used during an activity� ��Dec�� Changed back to � as per Gruningerand Lee� The feeling is that resourceexclusivity etc� is not explicit�


pPIF can provide a detailed descrip�tion of activities relationships to otheractivities� Temporal� causal� and de�compositional relationships can be usedto impose constraints on the preced�ence�



�� abstraction � within the scope of thisproject� there are three concepts of ab�straction that must be captured�

pPIF supports decompositional relation�ships between activities� Thereforeactivities can be arranged in an ab�stract� incomplete� or ambiguous fash�ion�


pPIF s use of decisions allows for a se�lection of alternative tasks� ��Dec��Gruninger� Although decisions can beused to select an activity based on state�this cannot be used to de�ne arbitrarynondeterministic choices e�g� do A ordo B�

�� associated illustrations and drawings � ��Nov�� Change from X to � as perTate s input� ��a PIF user� can use thedocumentation or user attribute slotsfor this��


� This requirement asks for informationthat goes beyond specifying which sub�activities occur in a group and askswhether there is explicit representa�tion about the overall group �total cost�total resources used in decomposition�etc�� Dec�� Gruninger� satis�ed ifthe grouping is a deterministic activity�but is not satis�ed in general for non�deterministic activities


X See ��


��



pPIF can handle concepts such as� al�ternative� parallel� serial� concurrentactivities� Timepoints and temporal re�lationships provide these requirements��Dec�� Gruninger� This requirementis satis�ed insofar as we can write thede�nition of an activity for simple andcomplex sequences� However� we can�not express the de�nition of simple andcomplex sequences using PIF�Core�


� PIF s highly expressive pif�sentencescan be used to give a detailed represent�ation of what an activity needs and does�hierarchical activities are considered�grouped�� More specialized charac��e�g� uniterruptability� cannot be ex�pressed�


pSee ��


pPIF uses the entity� decision� to repres�ent a conditional activity�


X PIF sentences are boolean�


pActivities and objects �resources� in�herit constraint slots for such purposes�


� Activities can express durationsthrough relative begin and endtimepoints�


pPIF representation of object �resource�component can be interpreted to someextent as a dependency� �e�g� ObjectA has components Object B and C�Therefore using Object A implies usingObject B and C as well�� Dec�� top� Lee� Represent �a� dependency

via Precondition and Postcondition ofan activity� A resource X requires an�other resource Y if the Use activity thatuses X has as a precondition the avail�ability of the resource Y


pThis can be satis�ed using decisionsor preconditions and postconditions ofactivities�


��



X No information is explicitly capturedfor this in the PIF�CORE�


X Not in PIF�CORE� sounds like a PSV�

�� material constraints X PIF contains no support for materialconstraints�


See �� Dec�� Gruninger� This re�quirement is satis�ed insofar as we canwrite the de�nition of an activity forparallel or serial tasks� However� wecannot express the de�nition of paral�lel or serial tasks using PIF�Core�


pPIF activities utilize variables in pif�sentences�


PIF declares what must be true beforean activity is performed and also as�serts what must be true after the activ�ity completes�


� PIF provides a list structure�


� To some extent� PIF can addressthis by explicitly listing whichobjects �resources� each activityuses�creates�modi�es� PIF can alsodescribe which objects are componentsof other objects� but logical grouping�outside of activity� seems to be absent�


X There is no facility in the PIF�COREto address this relationship�


X There is no facility in the PIF�COREto address this relationship�


PIF can order activities in serial� ��Dec�� Gruninger� This requirement issatis�ed insofar as we can write thede�nition of an activity for parallel orserial tasks� However� we cannot ex�press the de�nition of parallel or serialtasks using PIF�Core�


��



PIF can constrain when activities canbe executed using activity precondi�tions�


� PIF can describe state changes foractivities but not for objects �re�sources��

�� temporal constraints � PIF can relate activities through sharedbegin�end points� but a PSV is requiredto appropriately address temporal rela�tionships �other than �before�� Dec�� X to �� Lee� BEFORE is availableand �� some temporal constraints canbe expressed using the begin and endtimepoints�


X PIF does not have a facility for man�aging uncertainty�



X Not in PIF�CORE


pThe use of preconditions and decisionsallows for complex� conditional activityorderings� ��Dec�� Gruninger� Thisrequirement is satis�ed insofar as wecan write the de�nition of an activ�ity for simple and complex sequences�However� we cannot express the de�n�ition of simple and complex sequencesusing PIF�Core�


pPIF s decompositional relationshipsde�ne a hierarchy of specialization�


� PIF s activities utilize an activity�status relation which is linked totimepoints� Therefore PIF can settimepoints for when an activity mustbe at a certain status�


X This level of object detail is not expli�citly represented in PIF�


��



� In terms of agents �as resources� PIFcan explicitly describe their capability�thus making them eligible� PIF doesnot provide the �eligibility� of othernon�agent objects�


p��Nov�� as per Yan Jin s input� PIF sconditional activities can respond to ex�ception handling and recovery� ��Dec�� Gruninger� Depends on interpreta�tion� PIF cannot �a� while the �b� issimply a decision activity� �see below�There are two interpretations of thisconstruct� a� global occurrence con�straint which must be satis�ed regard�less of what activities are occurring atany point in time�b� a conditional activ�ity which occurs at speci�c points dur�ing a complex activity�


� The �ow can be partially mappedout by illustrating which activities cre�ate�modify�use objects�


pPIF has a mechanism to derive booleanresults for conditionals� etc�


� PIF does not provide this explicit formof meta element� but PIF design ele�ments can be reused�


pPIF decomposition allows a designer toattach�modify activity relationships atany level of abstraction�


� PIF does not contain any real�timeevent signalling and noti�cation thatcould manage multiple� parallel� activ�ities� ��Dec�� Gruninger X to ��The de�nition of synchronized activit�ies does not depend on real�time eventsignalling and noti�cation� this onlybecomes an issue when coordinatingagents within an organization�


��

B� STEP ISO �� Part �� Detailed PSL Analysis

Key�p






pThe various description propertiescould be used to capture this informa�tion� Elements such as voice� and videocould be related via textual �lenamesstored in these properties�


� We can partially addressthis by� adding a re�source property representation thatcan describe the cost of the ac�tion resource requirement �e�g� dol�lars�hr for a person� etc��


� An example� We could setup �crews�as action resources� I could add anaction resource requirement that statesthe requirement� �crew with �� mem�bers� or �crew with � members�� Thena requirement for action resource re��ects a satisfying crew�


� Some aspects of the product can bede�ned as product de�nitions in theproduct de�nition process�


pA resource is de�ned as an ac�tion resouce in part ��


pRequirements can be expressed via re�source property representations as thevalue of a resource property that is partof an action resource requirement�


paction method relationships can be es�tablished to group action methods in avery basic� high�level set�


pDescriptions of a resource can be addedas resource properties that are relatedto a resource�

B�� STEP� Part �

��



pA sequential method can be de�nedthat assigns a sequence position to eachaction method in the grouping�


pactions and action methods are used tode�ne basic tasks� These basic taskscan be further de�ned by relating themto a speci�c product or service thatthey provide in the manufacturing pro�cess�


pPage � of ISO DIS �� describesthe use of the action property to de�nethe time it takes to perform the task �orany other characteristic�� Also see page�� for action property representation�


pThere are a couple of ways to addressthis requirement in part �� You cantreat the executor in the same wayas duration �listed above� or you cande�ne a resource that represents the ex�ecutor and associate it to the task�



paction properties can be assigned to ac�tion methods and actions to captureuser�de�ned information intended toextend the information about a task�


� The support for resource alloca�tion�deallocation is possible� but onlyat a very high grain� For example�a milling machine can be thought ofas being allocated to a task and itwill be deallocated once the task hascompleted� etc� Needs a lower level ofsupport�


��



pThere is the support for ordering con�straints �see simple sequences� as wellas informational constraints on the per�formance of tasks� For example� giventhe example on page �� we can de�neexactly when �maintain speed� shouldfollow �drive down street� based on thecondition of the light being green� Con�text dependent relationship conditionscan be strung together to de�ne theprecedence of tasks based on theinformation in condition descriptions�




X The constructs are very de�nite andhighly structured� They do not permitsuch things as ranges� abstract levels�etc�


pIn part �� it is possible to relateactions in a �replacement relationship�that means that the related actioncould be used as an alternate im�plementation of the task� The con�text dependent relationship conditionscan also be used to determine whichtasks can be alternatively performed�based on some criteria�


Part � has a unique implement�ation that explicitly incorporatesdocumentation via entities like� ac�tion method with speci�cation referenceand action method with speci�ca�tion reference constrained�


pComplex groupings canbe made via the con�text dependent relationship conditionsand action method to select fromentities�


presource properties and re�source property relationships canbe de�ned to describe complex charac�teristics�


�



pA variety of entities support the de�ni�tion of complex sequences� sequential�serial� concurrent� context�dependent�The key entity here is the con�text dependent relationship conditionwhich permits the expression ofpreconditions of a task�


pAction properties and ac�tion property relationships can beused to express detailed aspects of atask�


pconcurrent action methods can be usedfor this requirement�


pcontext depednent relationship conditionscan be de�ned to model prede�nedcircumstances�


X No support for ranges� or measures ofcertainty�


� While it could probably be said the con�text dependent relationship conditionsrepresent a type of constraint� as wellas the ordering� etc� the support forconstraint expression is certainly notenough to say that it completely coversthis requirement�


X No support for timepoints� or time in�tervals� etc� This could be listed as anaction property but this temporal sup�port should have stronger core support�


X Cannot �nd a construct that relatesa dependency between two resources�only a resource dependency to an ac�tion or task�


� This may even be a completely� butthere is at least a partially based on theability to characterize what an action oraction method does� providing precon�ditions via context dependent actionmethod relationships� and orderingthese tasks to cycle based on somecondition �or context��


� This could be considered a property ofthe action �action property��


��



� This could again be a property� butit is not well�positioned for use in anapplication that needs to reason aboutproduct quantity�

�� material constraints � If materials are manipulated as re�sources to be used in a manufactur�ing process� it would seem possibleto express material constraints via ac�tion resource requirements�

�� parallel tasks � Unordered� non�related tasks can bethought of as parallel� but greater sup�port is needed to make it completely�


pSupported via the Express language�

�� pre� and post�processing constraints � Since we have conditional tasks� we canexpress the pre�processing constraintsby stating what must be true to executethis task�


X While there are sets� there is no supportfor these types of data structures�


� Resources with identical �require�ment for action resource� can bethought of as �grouped� by capability�


pThis could be treated as aresource property or require�ment for action resource depending onits intended use�


X I don t think this is supported�


Part � has a serial action method en�tity to describe this relationship�

�� state existence constraints X Need smaller grained conditionals toexpress state representations�


X

�� temporal constraints � High�level constraints for temporal re�lationships� �serial� complex� etc��


X No support�



�



X No support for highlighting a section�


pThe key here again is the con�text dependent relationship conditionswhich permit the use of specializedinformational requirements�


X No hierarchical�decompositional sup�port�


X If we take deadline a deadline to besomehow connected to a date�time rep�resentation than there is no support�


� This would have to be partial againsince there is a method for condition�ally controlling the applicability of taskfor a given representation�


pResources contain require�ments for action resource entriesthat determine this�


� This partly depends on interpretation�but you could imagine adding a condi�tional task after an operative task thatwould do something in the event thatthe condition following the operativetask fails�


X No support�


pEXPRESS contains math�logic sup�port�


X No support�


X No support�


X No support�


��

B�� O�Plan TF �v�� Detailed PSL Analysis

Key�p






pNotes via comments and �tf info�items� Individual plan items can con�tain �annotation�constraints�� Exten�ded documentation for schemas canbe achieved by linking �info� attrib�ute�value pairs with �lenames of asso�ciated drawings� etc�


� O�Plan TF can be used to describe anaction that consumes a resource �e�g�money� in the case of cost�� Uncertaintycosts� variability� etc� is incorporatedby the use of upper�lower bounds onnumerical values�


pO�Plan TF has a rich set of resourceelements that can describe the units�types� and number of resource itemsthat are required by an action�


� O�Plan TF can be used to model a classof resources that are �producible� whenan action is applied� This �produced�item can be an intermediate productthat is used to supply a condition foranother action�


pO�Plan TF can be used to describe re�sources and resource types�


pO�Plan TF resource statements canquantify an action s usage of a resource�


pAction schemas can de�ne partiallyordered sub�actions and action schemascan be arranged hierarchically throughthe use of �expands� action patterns�


pO�Plan TF can give resource charac�teristics that can be used to select theappropriate resource for a task� �e�g�attributing �wolf�proof� characteristicsto �bricks� in a sample domain��

B� � O�Plan TF �v��

��



pO�Plan TF has a number of ways toexpress temporal relationships� �At�links actions to a speci�c timepoint��Duration� specifys a range� TFcan also express �delay between� asa means to specify a latency periodbetween the end and begin of two ac�tions�


pSimple high�level descriptions can beattached via the schema annotationsthat were described in ��


pAs per Tate ��Nov�� In O�Plan auser can express duration in metric timepoints against a reference basis of zerotime� �e�g� day �� for examplefor noon on day �� of a project��


pO�Plan TF can select modeled re�sources to be associated with an instan�tiated action� �e�g� selecting vehicles inpaci�ca sample domain�� TF can alsobe used to directly model the �contract�ing� relationship using �un�supervisedconditions�



pO�Plan �other�constraints� can be usedto record additional information�


pO�Plan TF can be used to model as�signment and release of resources�


pO�Plan TF conditions� e�ects� and ex�pands can be used to form interschemarelationships while orderings are usedto de�ne intraschema sub�action rela�tionships�




��



pSchemas arranged in a hierarchicalfashion can abstract the details of vari�ous plan expansions� TF can be ar�ranged into plan levels�phases that al�lows O�Plan to control how far to plan�incompleteness�� More than � schemacan be appropriate �ambiguity��


pMore than one TF schema may be ap�propriate for a plan node expansion�


Textual items �comments� can be at�tached to O�Plan TF items and exten�ded documentation for the domain canbe achieved by linking tf info attrib�ute�value pairs with �lenames of asso�ciated drawings� etc�


pO�Plan TF can describe an explicitgrouping of actions �e�g� install ser�vices�� TF can also address constraintsrelated to the overall group� �e�g� de�scribing how much resource an actionand its expansions can consume��


pResources can have a �speci�c� typethat a�ects how the planning systemmay use the resource� �movable objectsvs� objects� etc��


pO�Plan TF schemas can explicity rep�resent complex sequences as well as ex�press the elements necessary to createmore ordering relationships during gen�erative planning�


pAction schemas can take into ac�count concepts such as applicability�only use if�� performance limits �timewindows� resource consumption�� and anumber of constraints on its conditions�suitable parameter bindings� etc�


p��Nov�� via Tate� �Two actions canbe constrained to have the same beginand end times by giving a zero durationlink between their begin points and thesame zero duration link between theirend points��


pTF schema �lters �only use if� controlthe applicability of a speci�c schema�


X O�Plan TF does not have a means toexpress certainty degrees�


��



pO�Plan has a rich set of constraint typesto limit the plan behavior �this includesactions and resource usage��


pO�Plan TF can be used to express relat�ive temporal relationships that are tiedto an initial zero date�time�


X There are no dependency relationshipsbetween resource types in O�Plan TF�


X While the use of an �iterate� or�foreach� node type is planned� TF ver�sion �� does not contain this function�ality� �Now in O�Plan version � January��


pSeparate action schemas can be de�signed with constraints on agent bind�ing types� If a schema is instanit�ated with an agent binding of type�machine� there will be a certain seq�whereas the type �human� schemawould be di�erent�


pThe amount of product to be producedcan be expressed as an achieve condi�tion in a task schema and the actionschemas can be designed to �produce�the resource based on constraints�

�� material constraints � Materials can be quali�ed through theuse of resource types and �always� as�sertions� �e�g� bricks are wolf�proof�etc��


O�Plan actions are arranged in a par�tially ordered fashion that can repres�ent parallel tasks�


pO�Plan plan state variables can be usedto bind values to various aspects of theplan�


This is achieved through the use of O�Plan conditions �pre� and e�ects �post��


� O�Plan TF utilizes �sets� but does nothave speci�c data structures such asqueues or stacks�


pLogical resource grouping is created byusing speci�c resource types�


��



pThe �paci�ca� TF sample shows howresource location can be represented us�ing an �at OBJ " LOC��


pThe simplest way to address this re�quirement is to create alternate actionschemas that utilize di�erent resourcesand can also thereby have di�erent timeconstraints�


O�Plan TF can be used to impose atotal ordering between actions wherenecessary�


This requirement can be expressed indetail by selecting an appropriate con�dition type in O�Plan TF�


pO�Plan uses a state�based approach forplan domain representations �I�e� con�ditions and e�ects relative to a worldstate�


Time �windows� can be expressed foractions in O�Plan TF�


pNumerical variables can be representedvia Min�Max pairs and a �computed�value that must lie within this range�This allows for tolerance and variabilityof a value�



� As per Tate� O�Plan can support theattachment of milestones or statements�e�ects� about some point in the plan�But the ability to �highlight� or annot�ate some area of the plan is outside ofwhat TF is trying to do�


pO�Plan action orderings can be spe�ci�ed within an action schema or im�plied through the conditions and ef�fects�


pThe �expands� entry in an actionschema denotes how it extends a higherlevel action�


pO�Plan can handle tasks with relativetime constraints� durations� etc�


pThe preconditions of an action can beutilized as a mechanism for stating dis�patching rules�


��



pIn O�Plan TF� conditions on using re�sources can be de�ned that meet thisrequirement�


� Alternative schemas �and orderings�can be chosen to satisfy a task whena suggested course of action fails�


pInformation is �passed� between ac�tions via plan state variables�


pO�Plan TF can be used to express thenecessary mathematical and logical op�erations for this requirement�


pvia Tate ��Nov�� All Task Formal�ism schemas are �generic processes� or�task descriptions� that meet this re�quirement�


pConstraints can be attached at any levelof an action hierarchy that would be ap�propriate for that schema�


pSee ��


��

Analysis of Candidate PSL Pro cessPlan Represen tations

Documents

Transcript of Analysis of Candidate PSL Pro cessPlan Represen tations