Core Plan Representation - Semantic Scholar

Object Model Focus Group

Core Plan Representation

version 4 released

November 6, 1998

comment deadline December 31, 1998

R. Adam Pease

sponsored by

DARPA Defense Advanced Research Projects Agency

Core Plan Representation Request For Comment

Table of Contents 1.

INTRODUCTION.........................................................................................................................................3

2.

BACKGROUND...........................................................................................................................................5 2.1. 2.2. 2.3. 2.4. 2.5.

3.

CPR DESIGN.............................................................................................................................................. 11 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12.

4.

FOUNDATION CONCEPTS......................................................................................................................... 11 FROM CONCEPTS TO CLASSES ................................................................................................................. 11 ATTRIBUTES .......................................................................................................................................... 13 METHODS .............................................................................................................................................. 14 EXECUTION MODELING ........................................................................................................................... 16 DESIGN TRADEOFFS AND ISSUES ............................................................................................................. 18 DETAILED DESIGN - CLASS DESCRIPTIONS (ALPHABETICAL LIST).............................................................. 21 ALPHABETICAL LIST OF ATTRIBUTE TYPES.............................................................................................. 24 CPR SENTENCES .................................................................................................................................... 24 PREDICATE LOGIC PRESENTATION ....................................................................................................... 26 ONTOLOGY PRESENTATION................................................................................................................. 31 CPR LANGUAGE................................................................................................................................. 33

SPECIALIZATIONS OF CPR OBJECTS................................................................................................. 35 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7.

5.

MOTIVATION ...........................................................................................................................................5 DESIGN OBJECTIVES .................................................................................................................................6 RELATED RESEARCH .................................................................................................................................8 MULTIPLE PRESENTATIONS AND SPAR .....................................................................................................9 PROCESS AND SCHEDULE ........................................................................................................................ 10

RESOURCE SPECIALIZATIONS .................................................................................................................. 35 TIMEPOINT SPECIALIZATIONS ................................................................................................................. 37 SPATIAL POINT SPECIALIZATIONS............................................................................................................ 37 ANNOTATION SPECIALIZATIONS.............................................................................................................. 37 ACTION SPECIALIZATIONS ...................................................................................................................... 38 AN OBJECTIVE SPECIALIZATION .............................................................................................................. 38 CONSTRAINT SPECIALIZATION ................................................................................................................ 38

EXAMPLE PLAN REPRESENTATIONS USING CPR........................................................................... 39 5.1. 5.2.

JFACC.................................................................................................................................................. 39 EDAPS ................................................................................................................................................. 40

6.

COMMON QUESTIONS........................................................................................................................... 41

7.

CONCLUSION ........................................................................................................................................... 42 7.1.

ACKNOWLEDGMENTS ............................................................................................................................. 42

8.

REFERENCES ........................................................................................................................................... 43

9.

ABBREVIATIONS AND ACRONYMS .................................................................................................... 46

CPR Version 4

2


1. Introduction The Core Plan Representation (CPR) is a model that expresses information common to many plan, process, and activity models. The goal of this effort is to leverage common functionality and facilitate the reuse and sharing of information between a variety of planning and control systems. The CPR embodies a standard that is general enough to cover a spectrum of domains from planning and process management to workflow and activity models. The representation is powerful enough to support complex, hierarchical plan structures. The initial application of the CPR is in addressing plan interchange requirements of several military planning systems, but the model goes beyond military planning and presents a more general plan representation. This document is issued as a request for comments. The first draft of this document was issued in September of 1996. Comments were received and incorporated and a second version was prepared and released. The second version was reviewed by the community and suggested changes were limited indicating that the design might be considered “mature”. The third version presented a slightly simplified core and suggested a series of specializations that are usable in actual applications. This fourth version adds information to support plan and process execution and also shows how to formulate CPR in a variety of languages including formal logic. Continued feedback from the planning community is encouraged in order to help refine this design and broaden its acceptance. In order to gain a full appreciation of the proposed CPR, it is important to understand the design process associated with it. Section 2 of this document provides information about the history, processes, and plans for the CPR. It also includes reference to some of the research and development efforts that contributed to the current design. Section 3 provides an overview and then explains the design, incrementally adding pieces of plan information. This section also provides a detailed description of the complete design, including class designs with descriptions, a predicate logic version, and a linearization of CPR. Section 4 presents candidate specializations of some of the CPR classes. Section 5 contains some brief examples and section 6 contains a few common questions on CPR.

CPR Version 4

3


Comments, questions, or pointers to additional relevant information would be greatly appreciated. All responses should be directed to Adam Pease at [email protected].

CPR Version 4

4


2. Background This design attempts to unify the major concepts and advancements in plan and process representation into one comprehensive model. This section first provides some motivation for the CPR effort. Next, significant design considerations are explained. A very large body of work has had an impact on the CPR. The design of the CPR would not have been possible without the contributions of many different researchers. References are given for research efforts that had particular influence in the design process. Finally, the process of the CPR design that has followed is given. 2.1.

Motivation

There are two significant benefits to the CPR effort. The first is that creation of a base plan representation will facilitate information sharing among different planning systems. When we speak of “information sharing” in this paper, we mean information that can be processed and interpreted by machines as well as people. In current C4I systems, information is exchanged in natural language, graphics, and databases. These information types rely upon extensive implicit knowledge either in the heads of the recipient or in the mind of the programmer who created the access and manipulation procedures. In contrast, we are looking for a representation that can distinguish different types of plan information so that programs can be written easily to access, modify, or analyze the quality of the associated plan decisions. Imagine a generic military planning situation. A crisis develops and a joint task force is formed. The leadership and staff use a planning application to develop guidance for their subordinate commands. This guidance includes background on the situation, objectives that must be met to contain the crisis, constraints on the actions of the task force and high level specification of the schedule of operation. This information is passed to individual commands that have specific requirements and methods of planning. A standard plan framework enables improved information transfer among the specialized planning applications of different commands. The commander of the air component of the task force and his staff use their superiors’ objectives to develop more detailed objectives, lists of targets which support those objectives, and then repeatedly create a schedule of aircraft sorties to destroy those targets. Information from the plan is transferred to CPR Version 4

5


simulation entities allowing a single pilot to fly sorties along side computer generated forces simulating the other pilots in his flight. While information transfers of this sort will rarely be complete and will often require further augmentation and elaboration for the new application, the CPR will permit sharing of the essence of the plan and reduce the amount of manual reformulation of existing data. The second benefit is in the creation of common services based on the CPR. There are several broad areas of services with immediate utility. One area is visualization. Manufacturing, business planning and construction management all employ similar views of plan information such as Gantt and PERT charts. The CPR enables creation of these common views and will dramatically reduce implementation time for specific systems. Well-designed common viewers can then be specialized for particular planning applications instead of written from scratch. Another area presenting significant reuse and specialization opportunities is scheduling. Many important advances have occurred in the operations research and artificial intelligence communities that allow software systems to provide significant aid in solving complex scheduling problems. Although a full scheduling system for any particular problem would generally require some specialization, many systems can reuse common classes and methods as a foundation. The CPR provides just those reusable ingredients needs to accelerate the development of such specialized schedulers 2.2.

Design Objectives

The “Basic” Level One design objective for the CPR is that it attempts to model the “basic level” [Rosch,, et al., 1976] of plan representation for the given domain or perspective of planning. The basic psychological level is a simple yet elegant concept. In an ontology of several levels describing a given domain, there is one level at which humans associate the largest amount of information. For example,

CPR Version 4

6


SUPERORDINATE

ANIMAL

FURNITURE

BASIC

DOG

CHAIR

SUBORDINATE

RETRIEVER

ROCKER

Table 1 : Example from [Rosch, 1976]

There are several attributes of the basic level. One is that this is the level at which terms are used in neutral contexts. For example [again after Rosch] There is a dog on the porch as opposed to There’s a mammal on the porch or There’s a retriever on the porch. The latter two sentences are unusual and require further explanation. For plan information, simply specifying generic objects like Entity and Relationship is not enough. Nor would defining Plan as an object without attributes be sufficient. The CPR specifies plan information at the lowest level common to all planning systems of interest. It should be noted that the basic level is specific to the domain being covered. If the context of interest is air campaign planning then a weather forecast object is useful and the CPR must be specialized for that context. The CPR may be specialized to cover more restricted domains in greater detail. The basic level of plan information for air campaign planning will contain a much richer set of information than is common to planning in general. The basic level provides initial guidance for the inclusion of concepts into the CPR. All basic level objects need not be included nor must all objects meet the basic level criterion. Practicality and relevance are important and may outweigh the basic level criterion in some cases. Idiomatic Expression The design of the CPR is intended to be idiomatic (or proper or stylistically appropriate) for the languages that it is represented in. Each language, whether formal or informal, has a set of stylistic or aesthetic considerations. Some such considerations may be given as general rules. Others no doubt remain to be formalized but violations may be clearly evident to the "native” user of a language as something which “feels” wrong. Rules for English usage (all of which having exceptions) might be as simple as a general prohibition against double negatives or split infinitives, more complex ones suggesting not to use a large number of dependent clauses or the diabolical fused participle. Simple rules for object oriented expressions (again with numerous exceptions) might be only creating classes that have CPR Version 4

7


both state and behavior, creating relation objects when complex relations with qualifiers exist or preference for designs with strictly a hierarchical aggregation structure. These considerations are detailed further in later sections and it is hoped that this modest effort begins to contrast the different design considerations of several important formalisms. Requirements There are a number of requirements for a planning system that CPR should support (adapted from [Gruninger & Fox, 1994]). •

Planning and scheduling–what sequence of activities must be completed to achieve some goal?

•

Temporal projection––given a set of actions that occur at different points in the future, what are the properties of resources and activities at other points in time?

•

Execution monitoring––what are the effects on the schedule after the occurrence of external events?

•

Also, what are the effects on the plan or schedule due to success or failure of part of the plan (e.g., an action), or satisfaction of a constraint (which could of course be an event)?)

•

Hypothetical reasoning––what will happen if we move one task ahead of schedule or another behind schedule? Note that this could also be referred to as dependency analysis.

2.3.

Related research

Planning is a fundamental component of intelligent behavior. The discipline of planning has been studied for generations in an attempt to produce more effective plans. Modern developments and techniques from the fields of artificial intelligence, operations research, management, decision theory and philosophy have all been applied to planning problems. Planning is a significant area of research within artificial intelligence. A review of this broad field is outside the scope of this document. The interested reader is referred to [Tate,, et al., 1990] and [Allen, et al., 1990]. Planning may also be seen to include that which AI researchers have separately termed scheduling. Scheduling has a significant body of literature as well. For this, the reader is referred to [Zweben and Fox, 1994]. While the CPR is targeted to address the

CPR Version 4

8


representation needs of both planning and scheduling, the two areas are given the following definitions in AI Planning–Specifying a set of actions in order to meet a set of goals or objectives Scheduling–Resolving the dependencies among actions and resources in a plan to specify amounts of resources used over time and times at which actions will take place. Several efforts in particular have influenced the CPR. KRSL-Plans [Lehrer, 1993], [Tate, 1996:2] bears many similarities to CPR. In fact, some of the same people working on KRSL-Plans have contributed significantly to the CPR design. It should be noted that KRSL-Plans, like CPR, is also an ongoing effort although it began much earlier. PIF [Lee, et al., 1996] and [Tate, 1996] are other relevant efforts which bear some similarity to CPR due to the significant contribution of Austin Tate to the CPR effort. Foundational work that has impacted CPR also includes the Situation Calculus [McCarthy & Hayes, 1969] and Cyc [Lenat, 1995]. CPR has also been an input to the design of the NIST Process Specification Language [Schlenoff, et al., 1996]. 2.4.

Multiple Presentations and SPAR

Computer science is a very broad field and researchers and practitioners have developed a host of ways to express their designs that are targeted to their specific needs. Frequency of use develops comfort with particular means of expression. We need several different forms of expression in order to capture fully the meaning of a model of aspects of the world. Regardless of the expressive power of a formal or semi-formal language, because people have to create expressions in the language, it's likely that the expression won't be “complete.” Complete is meant in a possibly informal sense of having the ability to conclude everything intended by the author from the expressions. Even though expressive logical languages might have the theoretical capacity to express whatever model an author intends, they are unlikely to do so in practice. Thus, any time when an author has a really complex or difficult model, such as that attempted in CPR, it makes sense to have several alternate expressions of the intended model. Each expression should be on an equal CPR Version 4

9


footing and is an attempt to communicate a model held in the mind of the author. The more expressions, the better the chance that the author will communicate what he intended. This may be viewed as being just a variant of human to human communication. People are still engaging in incomplete and ambiguous communication acts while using predicate calculus. Changing the form of communication from English to KIF doesn’t solve the problem. Our best bet is to use multiple presentations: logic, Unified Modeling Language (UML) [Booch et al., 1997], and our most precise English. The Shared Planning and Activity Representation (SPAR) [Tate, 1998] is a general plan representation which has been developed by a group of people and has an orientation toward English and ontology presentations of the model. It has been developed in partnership with CPR and is consistent with it. SPAR includes a number of presentations and the object model of CPR is one of those presentations. In section 3.9 below, an English description of CPR is given in the same format as the SPAR sentences. The section also details any differences with the SPAR model at the time of publication of this document. 2.5.

Process and Schedule

The CPR design effort began in May of 1996. Background was collected and a “strawman” design was created. This information served as inputs to a Core Plan Representation meeting held July 15-16 at Teknowledge and sponsored by DARPA,. Members of the meeting included DARPA researchers investigating planning and ontology issues and creating. major planning systems. Included were software developers for the JTF-ATD [Hayes-Roth and Erman, 1994] [Hayes-Roth, 1995] [Carrico, 1996] and Air Campaign Planning Tool who are creating planning systems as part of those efforts. This meeting yielded progress on many ontological issues related to the CPR and on improvements to the design. A second group meeting was held on August 6 with ARPI researchers some of whom were present at the July meeting. This second meeting yielded additional progress principally on ontological issues but also on the design. Design discussions with members of these groups are ongoing.

CPR Version 4

10


The results of the two meetings and discussions were integrated into the first version of this document which was released on September 17, 1996 and presented at the ARPI quarterly meeting on September 24. Comments were received on the first version and were incorporated in a subsequent version which was released on January 27, 1997. Version 3 was released on September 30th of that year

3. CPR Design To develop an appreciation for the proposed CPR design, some of the component objects will first be presented. The plan representation will constructed piece by piece in order to capture the design motivations, considerations, and open design issues. Finally, all the components will be brought together to form the complete CPR.. 3.1.

Foundation Concepts

The first step is to identify the minimal concepts necessary to represent any plan. This draws on the work KRSL, the POCG, and O-Plan [Tate, 1996]. The initial concepts are Action, Actor, Objective, and Resource. An Action is performed by an Actor. The motivation behind performing the Action is to accomplish some Objective. In performing the Action, the Actor may utilize a Resource. An Actor in one Action could be a Resource in another. The minimal set is shown in figure 1. This is the set of core conceptual pieces from which the CPR representation will be constructed.

Actor

Objective

Resource

Action

Figure 1 - Basic Concepts

3.2.

From Concepts to Classes

The basic design can be created from the above concepts. A Plan consists of one or more Actions performed in pursuit of some Objective. As noted above, Actors may use Resources in

CPR Version 4

11


performing an Action. Actor and Resource are not directly elements of the Plan, but rather of the Action itself. TimeSpec represents some association of the Action with time. Though a number of TimeSpec may provide information about an Action, every Action has at least a beginning and end, even though it may be infinite or periodic. In considering the temporal reference of the Action, it is only natural to then consider the relevance of the spatial references. A SpatialSpec is added to the minimal set. It may ground the objects both in absolute and relative terms. For example, to ground an Action in absolute terms a SpatialSpec might give a latitude and longitude. To ground in relative terms it might specify a distance and direction with respect to another location and in terms of a particular coordinate system such as "2mi north of objective SLAM". SpatialSpecs are also associated with Actions. Every Action takes place in some space whether the space is real or virtual. Constraints need to be added our initial set of classes. Constraints are restrictions on other elements of the plan. For example, we might need to specify that one Action must take place in a certain proximity to another Action, or that the end TimeSpec of one Action occurs before the begin TimeSpec of another. Constraints have no single place in the CPR where they would be most appropriate. As such, Constraint is left as an object that can be contained in any object of the plan. From this basic framework, a host of other required elements could be identified and added. Because the CPR was meant to be a general purpose, flexible representation, an extremely complex or constraining design is inappropriate. To that end, elements are carefully considered for both relevance and generality before being added. Due to the hierarchical nature of Plans, it is appropriate to allow a Plan to be associated with another Plan, where one would be the parent plan and the other a sub-plan. A similar argument is made for both Objectives and Actions, representing sub-objectives and sub-actions respectively. During execution of the Plan, Objectives are reviewed in order to gauge the effectiveness of the Plan and identify when Plan execution is complete. This review is performed against a set

CPR Version 4

12


of evaluation criteria relevant to the Objective. The entity EvaluationCriterion is included in Objective to meet this need. This design at this point is shown in figure 2.

Key:

Plan

A

B Action

A hasA B

Actor

Resource

Objective

TimeSpec

Evaluation Criterion

Constraints may be contained in any of the above objects

Constraint

Figure 2 -The Revised CPR Framework

3.3.

Attributes This section continues explaining the design by introducing attributes to the classes and

identifying additional classes. Refer to Figure 3 for a graphic illustration of the concepts as they are introduced. Attributes that are plural may be understood as containing a list of objects. There are several common attributes that are needed by most of the elements within a plan. Most objects within a plan will require a name for explicit reference. In addition, it is valuable to be able to add Annotations to any element of the plan. As mentioned in section 3.2 above,

CPR Version 4

13


Constraints may also apply to any object within a plan. For this reason, the common superclass of PlanObject is created containing the attributes of constraints and annotations. Action already includes subActions, actors, resources, and begin and end TimeSpecs. DomainObjects are defined to represent entities referred to in an Action which are not the Actor or a Resource. For example, the recipient of a mail message would be recorded as an instance of DomainObject. Instances of this class are contained in the attribute otherRoles. Actions also include the attribute effects, which indicate changes in the WorldState (see section 3.5) that the Action is intended to bring about. Actors may have objectives of their own and so a reference to the plan objectives is added and called objectives. Since the Actor may not be a single person, but represent an aggregate of some kind, the attribute subActors was added. Objective contains subObjectives, and evaluationCriteria. To Objective, value is added to hold the instance of Objective. Objective also references the list of Actions in the Plan which are meant to satisfy it. This information is held in the attribute action. In order to complete Constraint, additional fields are included to hold the terms of the constraint expression. Those terms may themselves be sub-Constraints..These are represented as attributes of type Term and Constraint. Annotations consist of a name and the body of the annotation. In addition, the annotations could be constructed hierarchically to form linked documentation, and thus a list of subAnnotations is required. An implementation of CPR would add an attribute to contain the body of the annotation and define it as a string, bitmap or other appropriate form. 3.4.

Methods

A few generic methods are included in CPR to ensure that specializations can function effectively with tools that only assume the presence of the core. One group of methods are those that simply return a set of objects. returnConstraints

returnAction, returnObjective

(on Plan) and

(on PlanObject) provide a common way to return objects in the plan without

regards to the structure of the objects which may contain them. They also provide for a mechanism by which “virtual” objects may be returned. For example, it is quite common in plans CPR Version 4

14


for a series of Actions to be executed sequentially. To express sequential actions, a CPR instance would require Constraints between the TimeSpecs of each Action, enforcing sequentiality in the desired sequence. However, Action could be specialized into a SequentialAction which simply knew to generate the implied sequentiality Constraints in response to a returnConstraints message. resolveConstraints

functions [Kumar, 1992].

(on PlanObject) provides an interface to constraint resolution

webPublish

into an HTML file for viewing.

(on Plan) suggests a method which streams the entire plan

search

(on Plan) ensures that all specializations provide at least

one way of searching for objects in the plan structure.

displayMe

(on PlanObject) provides a way

to activate a window which is a view on the information contained in the object sent this command.

translateToCore

(on Plan) ensures that all specializations provide a mechanism to

convert themselves to use only those objects specified in the CPR. For example, specialized Actions with implied Constraints would have to return a structure that made those Constraints explicit. The design at this stage is shown in figure 3.

CPR Version 4

15


Plan

Key: A

subPlans objectives actions

A

returnAction returnObjective webPublish search

0..N A

A B isA A

A hasA B

0..N

0..N Action

Objective

subActions actors resources otherRoles location begin end effects

0..N

actions 0..N evaluationCriteria subObjectives returnActions

returnObjectives

0..1

0..N

0..N

0..N Actor

Resource

Role

Spatial Spec

0..N objectives subActors

0..1

0..N

0..2 Time Spec

World Model


0..1

0..1 Entity

PlanObject name annotations constraints viewer translateToCore displayMe returnConstraints resolveConstraints

0..N Annotation 0..N name subAnnotations

0..N Constraint name terms

Role

View 0..N Update

Actor

Resource

Process Product

Figure 3 - CPR with attributes and methods

3.5.

Execution modeling

The preceding design addresses information about a plan that is intended to be executed. It does not however address how to record evidence of a plan’s actual execution. For this, we need to add the concept of a WorldModel that contains plan execution records. The plan CPR Version 4

16


execution record has much the same form as a plan. The key difference is in the semantics of information even though the form is the same. The effects of an Action may have some uncertainty in a plan reflecting that the outcome is uncertain. The effects of an Action may also have uncertainty in a plan execution record, however, the uncertainty is due to the fact that the sensing process is not foolproof. While a resource specification in a plan is an expectation of how much of a certain resource is needed, the resource specification in a plan execution record shows how much of the resource was actually used. Each plan execution record must be tied back to the original Plan. In that way, Actions can be assessed for their completion, Objectives can be assessed as to whether they have been met, and replanning can be triggered if a plan is not succeeding. Note that the same class Plan is used in two different ways, once as a record of the plan that is intended, and another as a record of the plan as it is actually executed. In order to evaluate a Plan, we look at Objectives to see how well they have been met. EvaluationCriteria provide a metric for this. By applyingEvaluationCriteria to the current WorldModel, an Evaluation can be derived. To round out our description of the real world we must also describe relevant parts of the environment outside the plan. This includes Events not triggered directly by Actions and Inventory that describes the current state of Resources that a plan may draw from. The state of the world must also be given in regards to a particular time. It is left up to implementers of CPR to trade off storage space and information loss issues. A record of the state of the plan (and the environment outside it) at every point during its execution would quickly overwhelm available storage for most systems in real world domains. However, the choice of which record to discard is a challenging one that will not be solved in this document. The design of the execution components is shown in Figure 4. The next section presents the complete design, including details about each component.

CPR Version 4

17


World

WorldModel

Plan

Action

Objective

Plan

Action


Inventory

Objective

Event

Time Spec

Resource


Evaluation

Figure 4 - Execution monitoring objects

3.6.

Design Tradeoffs and Issues

Unfortunately, in many design efforts, decisions and tradeoffs are made and not recorded. Subsequent design efforts do not have the advantage of reusing or being influenced by the alternate design elements that were not chosen. To avoid this error, the CPR effort has taken a pro-active approach to recording open issues and reasonable alternative choices whenever possible. The rationale for the design was integrated into the description of the CPR model in section 3, with a limited discussion of tradeoffs and issues. They have been reflected in this section for completeness CPR Version 4

18


1)

Uncertainty and Imprecision. Plans must be able to represent incomplete information about the world. The classes Uncertainty and Imprecision represent two kinds of incomplete information. Uncertainty captures the degree of confidence in information. Imprecision captures the degree to which an exact value cannot be specified. Uncertainty and Imprecision are both required but different plans may have very different requirements for handling them. Both Uncertainty and Imprecision are meaningful when attached to values rather than the classes that are described in CPR. It remains a subject of further study to integrate this information into the CPR model in a way that is both efficient and aesthetically pleasing. Associated with this construct is InfluenceNetwork. This construct keeps track of how uncertainties influence each other. It would most commonly be specialized to be a Bayesian network [Pearl, 1988]. The Uncertainty object holds a measure of the uncertainty associated with a piece of information. There are many possibilities for an Uncertainty measurement. A Bayesian scheme [Feller, 1957] might have a single real number, a Dempster-Shafer scheme [Shafer, 1976] two numbers, a simple certainty factor method might have a single integer, an endorsement scheme [Cohen, 1985] might have an enumerated type. Drawing on endorsement research, we might add an attribute for the source of the uncertainty. There might be uncertainty due to unreliability of the source, or of prediction of a future event for example

2)

Location of Execution Record. It may be possible to attach execution information directly to the Actions in the plan rather than duplicating the plan structure under the WorldModel.

3)

Activity-Specification. In SPAR there is a construct called ACTIVITY-SPECIFICATION. It holds both a set of activities and the constraints among them. One of the Constraints may be to avoid doing X. Having this item created explicitly might be better than including avoidance Constraints just like any other Constraint. This consideration is related to item 12) below.

4)

Action linking. Action could have a slot that would be a relation to another action. This would be very useful in plans that have partially ordered sequences of actions. However, an ordering constraint is just one type of constraint, so a scheme where ordering constraints are represented like any other constraint can be considered more general. That is the current solution. A possible specialization to cover this convenience is listed in section 4.5

5)

Action begin and end times. These times could be viewed as constraints since they are often not absolute times. There may be justification not to specify how Action will use begin and end times. For example, some Actions are continuous, periodic, or intermittent and don’t clearly have a beginning or ending. Currently, however, Actions have slots begin and end.

6)

Actions could also have priority and sequence items like the Air Campaign Planning Tool developed by ISX. Priority refers to the relative importance of an Action. Sequence indicates the order in which Actions should be executed. These are constraints so currently they are not explicit attributes of Action but would be modeled as instances of Constraint. Further discussion on this topic is given in section 4.7

CPR Version 4

19


7)

Actor types. One alternate approach would be to have different types of Actors. We could have Actors who carry out Actions, Actors who are influenced by Actions, or Actors who are responsible for a Plan. Currently, the CPR models the first case only as Actors. In the second case, the entity may be specified as a Constraint on an Action or as simply a Annotation. In the third case a planner would be an Actor in a workflow Plan which specifies the creation process for a Plan. Currently, Actors which are not carrying out Actions are DomainObjects (see item 9) below).

8)

Action and Plan status. Representing status is potentially a very complex problem. There is a need to represent the status of individual Actions, the aggregate status of a Plan and the status of the context in which the Plan exists. Previous versions of CPR did not address this issue. The current solution is to model the execution of a plan via a WorldModel that contains plan execution records, as described in section 3.5.

9)

Do Actors need to have roles? Is role an attribute or a class? Is there a need to place Actors into groups? Is the current hierarchical structure of Actors and sub-Actors sufficient? An implementation of CPR would likely have a specialized set of Actors. Currently, Actors are one type of Role..

10)

Plan and subPlan. subPlan is an attribute that may not deserve a place in an ontology. Here is another issue that straddles the fence of philosophical purity vs implementation effectiveness. While a really huge plan could be encoded all as one plan, there is value to the user in splitting it up into manageable sections. Microsoft Project for example allows the user to have multiple projects that are linked together. Each one is self-contained yet can link to the others. The same concept is in the CPR and currently subPlan is included as an attribute of Plan.

11)

Constraints vs. Facts. Constraints are envisioned as allowing variables in the terms. Facts would not allow variables. However, a completely specified Constraint is just a fact, and there’s no reason why a Fact can’t specify incomplete information. A Constraint could be viewed as an object with a dynamic function in automation. That is to say Constraints would be updated by a constraint resolver whereas Facts are intended to hold information entered by the user and not modified by the system. This is probably a poor distinction however, and as a result the CPR currently has dropped Facts.

12)

Location of Constraints. One possibility would be to place all Constraints under Plan and simply have them refer to objects they constrain by a key or object reference. This is however, an implementation concern. Currently, Constraints are included in PlanObject and its subclasses.

13)

Resources. It may be reasonable to include a numberOfUnits attribute. Most, although not all, Resources have some measure of how much of it there is and how much of that is being used or consumed. Knowledge is a notable exception. Some reasonable specializations are found in section 4.1. Currently, no attributes are given for Resource.

14)

Plan decompositions and Objectives. SubPlans and Actions are alternatives for decomposing plans and the conjunction of both is the complete decomposition of a Plan. There are several alternatives for how to relate Objectives in a subPlan with its parent Plan.

CPR Version 4

20


a) The objectives in a subPlan must be specializations of Objectives in the parent Plan. b) The Objectives in a subPlan must be specializations or orthogonal to the Objectives in the parent Plan. c) The Objectives in a subPlan may override the Objectives of the parent Plan much like subclassing in an object-oriented language. The Objectives in the subPlan are true for the subPlan and the Objective in the parent Plan are true for the parent Plan. When Objectives in the subPlan and parent Plan are in conflict, the resolution is undefined. The anomalies are flagged for user or system resolution on a case by case basis. No commitment has currently been made to any one of these options. 15)

Action vs. Plan vs. Objective. An Action in one context could be seen as a Plan in another or an Objective in yet another. All can be decomposed. Possibly they should be the same class or derived from a common superclass. Currently they are distinct objects in the CPR.

16)

LevelOfHardness for Constraints. One possible specialization would be to include a LevelOfHardness describing how strict the Constraint is. Is the Constraint an absolute, or is it simply guidance that may be overridden if necessary? What would most likely be needed would be a partial order on an ontology of Constraints indicating which Constraint would take precedence over another. Currently this attribute is not included in Constraint but it is discussed as a specialization in section 4.7. 3.7.

Detailed Design - Class Descriptions (alphabetical list)

Note that Lists in this section denotes a data structure that is both ordered and does not contain duplicates. Action subActions actors resources otherRoles location begin end

: : : : : : :

List of Action List of Actor List of Resource List of DomainObject SpatialPoint TimeSpec TimeSpec

Action contains a set of decompositions, the Resources used in carrying out the Action, the Actors and any DomainObjects may be involved or the object of the Action and the time and location at which the Action takes place. Actor objectives subActors

: List of ObjectivePointer : List of Actor

An Actor is the subject of an Action. The Actor may have Objectives that drive the Actions it takes. This is a pointer to an Objective in the Plan. There might be utility in having an Actor contain its own Objectives that are not directly Objectives of the Plan. SubActors is designed to hold aggregates of Actors like an organizational division in which the division CPR Version 4

21


acts together but where there is still a need to record information about the individuals who may act by themselves for other Actions. Annotation name subAnnotations

: Name : List of Annotation

An Annotation is designed to hold any type of unstructured data, paragraphs of text, pictures, video etc. It exists to hold any information that supports understanding or maintenance of the plan but it not strictly part of the plan itself. Note: This was previously called PlanDataElement. Constraint name terms subConstraints

: Name (a predicate name) : List of Term (terms for the predicate) : List of Constraint

This object holds any formal restrictions on an entity in the plan. Name and terms hold the expression of the Constraint, for example before(action1.begin,action2.begin) or greaterThan(numberOfTanks,100). A set of standard constraints are given in section 4.7 below Entity An Entity is an object which allows a correspondence among Actors, Resources, and ProcessProducts when those objects describe different roles which are filled by the same real world entity. Entity currently has no attributes. Evaluation An Evaluation is the product of applying an EvaluationCriterion to a WorldState. It described how well a Plan has met its Objectives. EvaluationCriterion currently has no attributes. EvaluationCriterion This object currently has no attributes. While there is a general need for Objectives to have evaluation criteria, it is believed than any further specification is too specific for the CPR. Specializations of the CPR however, will subclass useful specific versions of EvaluationCriterion. For example, if we have an Objective of “prevent enemy incursion through the straight of Hormuz”, an EvaluationCriterion might be “number of enemy vessels passing through the straight since the start of the operation”. Event An Event records something that has happened in the world that is not part of the plan. Some planning systems term these exogenous events. Actions in the plan may however be conditional on the occurrence of an Event.

CPR Version 4

22


Inventory The Inventory keeps track of the current state of available Resources. This information, along with the planned use of Resources and the record of Resources used during plan execution allows a planner to manage Resources effectively. Objective actions : List of ActionPointer evaluationCriteria : List of EvaluationCriterion subObjectives : List of Objective

Objectives may also contain subordinate Objectives. Objectives point to the Actions that are designed to satisfy them. Objectives also contain EvaluationCriterions which provide a metric for indicating how well the current situations meets the Objective. Plan subPlans objectives actions

: List of Plan : List of Objective : List of Actions

Plan is the aggregate object of this representation. SubPlans are Plans into which this top level Plan may be elaborated. Actions specify in detail how the Plan is accomplished. PlanObject name constraints annotations

: Name : List of Constraint : List of Annotation

This object holds all the common state and behavior of the CPR objects. Every object may contain Uncertainty, Constraints, Annotations and a name. In a specialization, there might be services to turn process Annotations into documentation, or resolve Constraints. ProcessProduct This class is a Role that an Entity can play when it is generated as the result of an Action. Resource There are all sorts of useful specializations of Resource. They are currently believed to be too specific for inclusion in the CPR but some are given in Section 4 below. Resource currently has no attributes. Role Role is a class that represents a role that an Entity may play. Note that the same Entity may play different Roles even within the same plan. Currently, Actor, Resource, and ProcessProduct are given as subclasses of Role. SpatialSpec CPR Version 4

23


A SpatialSpec describes some spatial characteristics of an Action such as the geographic point or area in which it takes place. There are many useful specializations of SpatialSpec. One example is illustrated in Section 4 below. SpatialSpec currently has no attributes. TimeSpec TimeSpec provides information about when an Action should be executed or how long it should take. There are many useful specializations of TimeSpec. One example is illustrated in Section 4 below. TimeSpec currently has no attributes. World Much like Plan, World is a top level object that aggregates other objects. It holds all the information that is known about the world including plans, the record of execution of those plans and other facts about the current and past state of the world. WorldModel The WorldModel contains a snapshot of the relevant features of the state of the world at a point or during an interval of time.

3.8.

Alphabetical List of Attribute Types

ActionPointer

A pointer to the Action class.

Name

The name of an object. In most implementations, this would probably be a String.

ObjectivePointer

A pointer to the Objective object.

Term

The terms in a Constraint expression. There are different possible formats for this. We could allow a object-type reference such as before(action1.end,action2.begin). Action1.end is a term in this expression.

3.9.

CPR Sentences

This section lists a number of English sentences that describe CPR in the same format as the SPAR model. 1. 2. 3. 4.

A PLAN relates ACTION(s) to OBJECTIVE(s) Execution of an ACTION may change the WORLD-STATE An ACTOR is a PLAN-OBJECT that can perform activities and/or hold objectives. An ACTION takes place over a time interval identified by its two ends, the BEGIN time and the END time.

CPR Version 4

24


5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

An ACTION is an EVENT that has or could have (in the domain model) an ACTOR. An ACTOR is a ROLE that an ENTITY can play when it is the motive force behind an ACTION. A RESOURCE is a PLAN-OBJECT that is used, modified, consumed or destroyed during the execution of an ACTION. RESOURCE is a ROLE that an ENTITY can play. A PRODUCT is a PLAN-OBJECT that is created during the execution of an ACTION. PRODUCT is a ROLE that an ENTITY can play. A WORLD-MODEL provides a model of dynamics that allows WORLD-STATEs to be predicted as the result of some ACTIONs A WORLD-STATE describes a snapshot of the world which is actual, expected, or hypothetical Each PROPERTY of each ENTITY may have a VALUE, i.e. PROPERTY(ENTITY)=VALUE VALUEs may be imprecise VALUEs may have a PROBABILITY PROBABILITYs may be partitioned into PROBABILITY-PREDICTION and PROBABILITY-SENSED A PROBABILITY-PREDICTION is the likelihood of a WORLD-STATE-DESCRIPTION being valid in the future A PROBABILITY-SENSED is a likelihood that a WORLD-STATE-DESCRIPTION did in fact have the specified value in the past or at the current time An INFLUENCE-NETWORK is a structure which relates PROBABILITYs and specifies their dependency structure The EFFECTS-RECORD of an ACTION is the record of changes made to the WORLD-STATE by execution of the ACTION An OBJECTIVE may have one or more EVALUATION-CRITERIA An EVALUATION-CRITERION may be applied to WORLD-STATE to create an EVALUATION An EVALUATION may be a predicate (holds/does not hold) or a partial order on the results of [one or more] EVALUATION-CRITERIA A PLAN-LIBRARY contains PLANs or portions of PLANs that may be reused in creating new PLANs. A PLAN-LIBRARY has one or more INDEXes which can be used to catalog PLANs and aid in searching for them

The following list shows which of the CPR sentences correspond to which of the SPAR sentences at the time of writing.[Tate et al, 1998] 1->C.1, 2->C.4, 3->C.5, 4->C.6, 5->E1.1, 6->E1.3, 7->E1.4, 8->E1.5 (comment), 9->E2 (comment 3), 10->E2 (comment 4), 11->E4.1, 12->E4.2, 13->E4.3, 14->E4.4, 15->E4.5, 16->E4.6, 17->E4.7, 18->E5.2, 19->E6.1, 20->E6.2, 21->E6.3, 22->E7.1

Those sentences that are found in SPAR but not in CPR are believed compatible but are not required in the object model. For example, the notion of a PRIMITIVE-ACTIVITY is derivable from counting the number of instances contained in the subActions variable on an instance of Action. There are in addition a few concepts above that require explanation. The EFFECTSRECORD of an Action corresponds to Plans under the WorldModel. The attributes of Actions in

the WorldModel are the record of the effects of Action when it was executed. An Action that is CPR Version 4

25


not part of the WorldModel specifies Resource usage that is required or expected. An Action that is part of the WorldModel specifies the Resources that were actually used during execution of the Action. Probabilities have a similar partitioning of meaning between executed and planned Actions. PROBABILITY-PREDICTED refers to Probability(s) which are associated with planned Actions. PROBABILITY-SENSED refers to Probability(s) which are associated with Actions that have already

taken place. 3.10. Predicate Logic Presentation Note that while this section attempts to be correct it is by no means complete. A complete axiomatization of CPR is beyond the scope of this document. However, this section should provide enough content for a knowledge engineer to merge CPR with his or her ontology or use it as the basis for a more specialized ontology or expert system. Remaining work would include defining axioms for every concept.Note also that although this section provides both CycL/MELD [Cycorp, 1998] and KIF [Genesereth & Fikes, 1992] syntax, and may use some of the Cyc ontology [Cycorp, 1997] , that the ontology has not been completely reconciled with Cyc or any of the ontologies that are loaded with Ontolingua [Ontolingua, 1998]. The MELD section also includes a more traditional notation for logical expression that may aid in understanding for some readers. MELD Presentation (genls Plan TemporalThing) (isa relatedInPlan BinaryRelation) (arg1Isa relatedInPlan Action) (arc2Isa relatedInPlan Objective)

Time Points (isa startingPoint BinaryRelation) (arg1Isa startingPoint TemporalThing) (arg2Isa startingPoint TimePoint) (genls Activity TemporalThing) (implies (and (isa ?ACT Action) (starts ?ACT ?TIME1) (end ?ACT ?TIME2)) (greaterThan ?TIME2 ?TIME1))

CPR Version 4

;; end is later than start

26

Core Plan Representation Request For Comment ∀x∀y∀z[Action(x) ∧ starts(x,y) ∧ ends(x,z) ⇒ z >y]

(isa temporallySubsumes BinaryRelation) (arg1Isa temporallySubsumes Action) (arg2Isa temporallySubsumes Action) (implies (and ;; child action occurs during (temporallySubsumes ?ACT1 ?ACT2) ;; parent action (starts ?ACT1 ?TIME1) (starts ?ACT2 ?TIME2) (ends ?ACT1 ?TIME3) (ends ?ACT2 ?TIME4)) (and (greaterThan ?TIME2 ?TIME1) (greaterThan ?TIME3 ?TIME4))) ∀x,y,a,b,c,d[temporallySubsumes(x,y) ∧ starts(x,a) ∧ ends(x,b) ∧ starts(y,c) ∧ ends(z,d) ⇒ (c>a) ∧ (d>b)]

Spatial Information Note that this section in particular is intended only to give a sense for how an ontology of spatial information might be included in a full axiomatization of CPR. (isa eventOccursAt BinaryPredicate) (arg1Isa location Action) (arg2Isa location SpatialSpec) (implies (eventOccursAt ?ACT ?LOC) (and (not (thereExists ?LOC2 (eventOccursAt ?ACT ?LOC2) (different ?LOC ?LOC2)))))

;; ;; ;; ;; ;; ;; ;; ;; ;;

The same event can’t occur in two different places at the same time. Not to be confused with the fact that two instances of the same class of event can of course occur in different places.

∀x,y[eventOccursAt(x,y) ⇒ ¬∃z eventOccursAt(x,z) ∧ y≠z]

(isa contains BinaryPredicate) (isa contains Constraint) (arg1Isa contains SpatialSpec) (arg2Isa contains SpatialSpec) (implies (contains ?X ?Y) (not (thereExists ?Z (and

;; If Y is inside X then there ;; is nothing inside Y that ;; isn’t also in X (contains ?Y ?Z) (not (contains ?X ?Z)))))) ∀x,y[contains(x,y) ⇒ ¬∃z contains(y,z) ∧ ¬ contains(x,z)]

Actions and subActions (isa actionSpecification BinaryRelation) (or (arg1Isa actionSpecification Plan) (arg1Isa actionSpecification Action)) (arg2Isa actionSpecification Action) (implies (and (actionSpecification ?act1 ?act2) ;; parents temporally subsume (isa ?act1 Action)) ;; child actions CPR Version 4

27


(temporallySubsumes ?act1 ?act2)) ∀x,y[actionSpecification(x,y) ⇒ temporallySubsumes(x,y)]

(isa usesResource BinaryRelation) (arg1Isa usesResource Action) (arg2Isa usesResource Resource)

Evaluation Criteria (isa evaluationCriterionFor BinaryRelation) (arg1Isa evaluationCriterionFor EvaluationCriterion) (arg2Isa evaluationCriterionFor Objective) (isa hasMetric BinaryRelation) (arg1Isa hasMetric EvaluationCriterion) (arg2Isa hasMetric CycFormula) (isa EvaluationFn IndividualDenotingFunction) (arg1Isa EvaluationFn EvaluationCriterion) (arg2Isa EvaluationFn WorldState) (resultIsa EvaluationFn Evaluation)

WorldState (isa WorldState Collection) (genls WorldState TemporalThing)

Roles (genls Role IntangibleIndividual) (genls Resource Role) (genls Actor Role) (isa playsRole TernaryRelation) (arg1Isa playsRole WorldState) (arg2Isa playsRole Entity) (arg3Isa playsRole Role) (implies (playsRole ?SIT ?ENT ?ROLE) (capableOfDoing ?ENT ?SIT ?ROLE)) ∀x,y,z [playsRole(x,y,z) ⇒ capableOfDoing(y,x,z)]

Resources Note that STIF is a function which returns a "short time interval following" the time given in its argument. STIB is a function which returns a "short time interval before" the time given in its argument. (genls ConsumableResource Resource) (implies (and (usesResource ?ACT ?RES) (ends ?ACT ?TIME)) (holdsIn (STIB ?TIME) (amountAvailable ?RES ?AMT1)) (holdsIn (STIF ?TIME) (amountAvailable ?RES ?AMT2))) (greaterThan ?AMT1 ?AMT2)) CPR Version 4

28


∀x,y,z,a,b [usesResource(x,y) ∧ ends(x,z) ∧ holdsIn(STIB(z),amountAvailable(y,a)) holdsIn(STIF(z),amountAvailable(y,b)) ⇒ a (and (temporallySubsumes ?act1 ?act2) (starts ?act1 ?time1) (starts ?act2 ?time2) (ends ?act1 ?time3) (ends ?act2 ?time4)) (and (greaterThan ?time2 ?time1) (greaterThan ?time3 ?time4))))

Spatial Information (define-relation eventOccursAt ((Arity 2) (nth-domain 1 Action) (nth-domain 2 SpatialSpec)) CPR Version 4

29


:axiom-def (subclass-of eventOccursAt BinaryRelation)) (define-relation contains ((Arity 2) (nth-domain 1 SpatialSpec) (nth-domain 2 SpatialSpec)) :axiom-def (subclass-of contains BinaryRelation) (subclass-of contains Constraint) :axioms (=> (contains ?x ?y) (not (thereExists ?z (and (contains ?y ?z) (not (contains ?x ?z)))))))

Actions and subActions (define-relation actionSpecification ((Arity 2) (nth-domain 1 Action) (nth-domain 2 Action)) ;; Note that the first argument should take Action or Plan but I’m not ;; sure how to do this in legal KIF. :axiom-def (subclass-of actionSpecification BinaryRelation) :axioms (=> (and (actionSpecification ?act1 ?act2) (Action ?act1)) (temporallySubsumes ?act1 ?act2)) (define-relation usesResource ((Arity 2) (nth-domain 1 Action) (nth-domain 2 Resource)) :axiom-def (subclass-of actionSpecification BinaryRelation))

Evaluation Criteria (define-relation evaluationCriterionFor ((Arity 2) (nth-domain 1 EvaluationCriterion) (nth-domain 2 Objective)) :axiom-def (subclass-of evaluationCriterionFor BinaryRelation)) (define-relation hasMetric ((Arity 2) (nth-domain 1 EvaluationCriterion) (nth-domain 2 CycFormula)) :axiom-def (subclass-of hasMetric BinaryRelation)) (define-frame EvaluationFn :Own-Slots ((Arity 3) (nth-domain 1 EvaluationCriterion) (nth-domain 2 WorldState) (instance-of IndividualDenotingFunction) (range Evaluation)))

WorldState (define-class WorldState :axiom-def (subclass-of WorldState TemporalThing))

Roles CPR Version 4

30


(define-class Role :axiom-def (subclass-of Role IntangibleIndividual)) (define-class Resource :axiom-def (subclass-of Resource Role)) (define-class Actor :axiom-def (subclass-of Actor Role)) (define-relation playsRole ((Arity 3) (nth-domain 1 WorldState) (nth-domain 2 Entity) (nth-domain 3 Role)) :axioms (=> (playsRole ?sit ?ent ?role) (capableOfDoing ?ent ?sit ?role)))

Resources Note that STIF is a function which returns a "short time interval following" the time given in its argument. STIB is a function which returns a "short time interval before" the time given in its argument. (define-class ConsumableResource :axiom-def (subclass-of ConsumableResource Resource)) :axioms (=> (and (usesResource ?act ?res) (ends ?act ?time)) (holdsIn (STIB ?time) (amountAvailable ?res ?amt1)) (holdsIn (STIF ?time) (amountAvailable ?res ?amt2))) (greaterThan ?amt1 ?amt2)))

3.11. Ontology Presentation There is some overlap between the AI ontology community and those in the objectoriented community who rely principally on association diagrams for modeling. The following entity/relationship diagrams in Figures 5, 6, and 7 may also prove useful to people who utilize this form of represention.The entity/relationship diagram illustrates the classes as entities in a model and the relationship as named associations among them. While associations need not be named, it is valuable information to record when in fact an association can be given a specific name.

CPR Version 4

31


Plan

hasRole

Entity

Actor

does

Action

satisfies

uses changes

Objective


Resource World Model

produces

Spatial Spec

occursAt

Evaluation

Time Spec

occursAt

isRelativeTo

World Model

Figure 5 - Plan hierarchy View Constraint Annotation

displays constrains annotates

Role PlanObject

Actor

Resource

Process Product

Target

Resource

Consumable Resource

Transportation Node

Reusable Resource

Route

Synchronously Reusable Resource

Transport

ExactCapacity Resource

Nonsharable Resource

Driver Pilot

Figure 6 - Specializations

CPR Version 4

32


World

Plan

Action

satisfies

recordsExecutionIn

Objective

Action


Plan

satisfies

recordsPartOf

Objective


produces

WorldModel

Event

Inventory occursAt occursAt

Time Spec

Resource

Evaluation

isRelativeTo

World State

Figure 7 - Execution Constructs

3.12. CPR Language Some practitioners, especially those who are not using an object-oriented language would still like to interoperate with CPR. For those practitioners, a linearization or textual language for CPR may be helpful. As a different presentation of CPR it may also improve understanding of the model even for those who prefer to base their implementation on an object model. Keywords are given in capitals. Fundamental data types are given in . Items in [] may be repeated 0 or more times. []*n means that the item is repeated 0..N times. Mutually exclusive options are given in {} separated by |. plan := Plan common subplans objectives actions subplans := # [plan] common := name constraints annotations name := constraints := # [constraint] constraint := Constraint expression expression := (name # [term]) term := | expression annotations := # [annotation] annotation := Annotation { | } annotations CPR Version 4

33


objectives := # [objective] objective := Objective common stringList evaluationCriteria subObjectives stringList = # [] evaluationCriteria = EvaluationCriterion common evaluations evaluations := # [evaluation] evaluation := Evaluation common worldModel worldModel := WorldModel common actions := # [action] action := Action common stringList subActions actors resources domainObjects location begin end effects subAction = # [action] actors = # [actor] resources := # [resource] domainObjects := # [domainObject] location := # [location]*1 begin := timeSpec end := timeSpec effects := worldState actor := Actor common stringList subActors entity subActors := # [actor] resources := # [resource] resource := Resource common entity domainObjects := # [domainObject] domainObject := DomainObject common entity spatialSpecs := # spatialSpec spatialSpec := SpatialSpec common timeSpecs := # [timeSpec]*2 timeSpec := TimeSpec common entity := Entity common

CPR Version 4

34


4. Specializations of CPR Objects There are many possible specializations of objects within the CPR. Some objects would probably be too specific for inclusion in the design but are still general enough to deserve mention. In addition, by illustrating several specializations, it is hoped that it will be clearer how the CPR may be used in an actual implementation. It should also be pointed out that any specializations need not directly subclass from the CPR definitions. It is sufficient to describe a mapping (see [Pease and Carrico, 1997]) whereby all the information in a specialization may be converted to the CPR. The following specializations are attributed as listed or otherwise original. 4.1.

Resource Specializations Resource

Consumable Resource

Reusable Resource

currentlyRequired currentlyAvailable

totalCapacity capacityAllocated

Transportation Node location routes

Synchronously Reusable Resource

ExactCapacity Resource capacity

Nonsharable Resource

reservationBlocks minSeparation

Route

Transport

DriverPilot

endpoint1 endpoint2 subRoutes

location route direction itemsContained capacity cargoType driversPilots

currentLocation

Figure 8 - Resource Specializations

The following is based on a resource taxonomy from Doug Smith at the Kestrel Institute [Smith, 1997]. ConsumableResource currentlyRequired : Value CPR Version 4

35


currentAvailable

: Value

Examples include fuel or crew time. ReusableResource totalCapacity : TwoDimensionalValue capacityAllocated : TwoDimensionalValue

Examples include parking lots, ramp space, parallel processors, power. SynchronouslyReusableResource reservationBlocks : List of ReservationBlock minSeparation : Time

Examples include ships, aircraft and trucks ExactCapacityResource capacity

: Value

One example is a wafer oven. The processing of wafers is affected by how many wafers there are in an oven and must be optimized for a specific numbers of wafers. NonsharableResource This is really just a degenerate case of ExactCapacity. The capacity is 1. Examples would be berth, runway or crew. TransportationNode location routes

: SpatialSpec : List of Route

This is a junction in a transportation network. It could be an intersection of roads or a router in a transmission network. Route endpoint1 endpoint2 subRoutes

: SpatialSpec : SpatialSpec : List of Route

This is a path such as a road or oil pipeline Transport location route direction itemsContained capacity cargoType driversPilots

: : : : : : :

SpatialSpec Route Value List of Entity Value List of Entity List of DriverPilot

This is an entity like a truck, boat or train. Driver-Pilot CPR Version 4

36


currentLocation

: Value

This is the agent who controls a transport such as the driver of a car or the pilot of a plane. 4.2.

TimePoint Specializations

TimeDate day month year hour minute second msecond

: : : : : : :

DayType MonthType YearType HourType MinuteType SecondType MillisecondType

Most typical specializations of time would only differ in the level of precision allowed. 4.3.

Spatial Point Specializations

MapPoint longitude latitude altitude

: LongitudeType : LatitudeType : AltitudeType

AirspaceVolume boundingBox

: List of MapPoint

VirtualPoint domainName

4.4.

: domainNameType

Annotation Specializations

Authorship author dateOfLastUpdate revisionNumber

: Name : TimePoint : RevNumber

One typical specialization of Annotation would be an object to contain authorship information. It should contain at least the name of the author, the time the object was last updated and possibly some standard revision number format. Assumption data triggerCondition triggerAction

: (undefined) : (undefined) : (undefined)

An Assumption is intended to identify any information on which the plan information depends. TriggerCondition describe what kind of change in the data will activate the CPR Version 4

37


triggerAction. TriggerAction will specify the action to be taken if the data changes according to the triggerCondition.

4.5.

Action Specializations

Mission missionID : base : plannedDeparture : plannedArrival : missionAircraft : refuelingLocations:

MissionIDType AirbaseDesignator TimePoint TimePoint List of Aircraft List of AirbaseDesignator

SequentialAction This Action specializes the returnConstraints method to return a set of constraints that keeps all subActions sequential. This relieves some burden on the user to specify a constraint between the end time of each action and the begin time of the following action. 4.6.

An Objective Specialization

ACPTObjective type name actionSpecs measuresOfMerit parents sequenceRestricts COGs %complete reviewStatus

: : : : : : : : :

ObjectiveType ObjectiveName List of Action EvaluationCriterion List of ACPTObjective List of Constraint CenterOfGravityType Integer List of Annotation

This specialization is based on the work of [Valente, 1996]. 4.7.

Constraint Specialization

There is a set of constraint types that are general enough to warrant mention here. They are >, =,