1 / 51

CPM Guide to Objects and Relations (CPM 3.3h)

CPM Guide to Objects and Relations (CPM 3.3h). D Mott v9. Purpose. These slides are aimed at two audiences: viewers of the IBM plan visualisation screenshots; information is provided about the nature and visualisation of the objects and their relationships

aiko
Download Presentation

CPM Guide to Objects and Relations (CPM 3.3h)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CPMGuide to Objects and Relations(CPM 3.3h) D Mott v9

  2. Purpose • These slides are aimed at two audiences: • viewers of the IBM plan visualisation screenshots; information is provided about the nature and visualisation of the objects and their relationships • users of the CPM; information is provided about the OWL/RDF names of the entities and the relationships

  3. What is shown • The visual icons are taken from the IBM Plan Visualiser • The names on the arrows are the Controlled English version of the relation • Controlled English for the diagrams are given in blue boxes • The RDF entity and relation names (in purple) are that of the CPM. • Note that: • short names are given, and the full namespaces for each prefix is given at the end • not all of the possible entities and relations are shown, and relations may occur over different types than that shown • Therefore these diagrams should only be used as a guide, and the CPM documentation may need to be consulted for the complete details

  4. Tasks,Goals, Missions,Intents

  5. MISSION and INTENT MISSION1 log:contextItem CONTEXT1 • MISSION1 is to be achieved in the context of CONTEXT1. It is set by a superior agent (the setter) for another subordinate agent to achieved (the author) • INTENT1 is the plan that will achieve the MISSION1. It is created and executed by an agent (the executor), and is the executing agent’s interpretation of its mission. • A collaboration states that there a problem solving relation between a problem (eg a mission) and a solution (eg an intent) • A mission and an intent are containers, that contain goals and tasks (see below). • A context item is something that provides relevant background information to the mission or intent. This may be any other container, and a mission or intent may have more than one context item mil:Mission cps:problemSetter=US DIV log:author=UK BDE MISSION1 cps:collaboration INTENT1 mil:Intent pla:planExecutor=UK BDE there is a mission MISSION1 that has the division ‘US DIV’ as setter and has the brigade ‘UK BDE’ as author. there is an intent INTENT1 that has the agent ‘UK BDE’ as executor the mission MISSION1 has as context the container CONTEXT1. the mission MISSION1 collaborates with the intent INTENT1.

  6. GOALs cps:GoalSpecification cps:owningAgent=US DIV mil:HostileUnit • A goal is some condition about the world that is desired to be achieved by the owner. • G7 in some way “is about” Hostile2 • G9 is to be achieved after G8 is achieved (other timing relations are also possible, see below) • G5 is broken down into the subgoals of G6 and G14 • to achieve G5 then G6 and G14 must be achieved • Goal is also used for endstate GOAL7 cps:goalObject HOSTILE2 GOAL8 att:teAfter GOAL9 GOAL5 cps:hasSubGoal GOAL6 there is a goal named GOAL7 that has the division ‘US DIV’ as owner. the goal GOAL7 has as object the hostile unit HOSTILE2. the goal GOAL9 occurs after the goal GOAL8. the goal GOAL5 has as subgoal the goal GOAL6 and has as subgoal the goal GOAL14.

  7. Contents of Mission and Intent • The mission MISSION1: • contains the goal G3 • has the goal G3 as the main effort • The intent INTENT1: • contains the goals G1 and G2 • has the goal G1 as the desired endstate • has the goal G2 as the main effort MISSION1 mil:misMainEffort GOAL3 MISSION1 log:contains GOAL3 the mission MISSION1 contains the goal GOAL3 and has as main effort the goal GOAL3. the intent INTENT1 contains the goal GOAL2 and contains the goal GOAL1 and has as main effort the goal GOAL2 and has as endstate the goal GOAL1. INTENT1 mil:intMainEffort GOAL2 INTENT1 mil:endState GOAL1 INTENT1 log:contains GOAL2 INTENT1 log:contains GOAL1

  8. TASKs pla:PlanTask • A task is something given by one agent (assigning agent) to another agent (executor) in order to achieve a goal, by performing some form of activity that causes a change in the world, which takes time and uses resources pla:planTaskAgent pla:planTaskAssigningAgent att:teEarliestStart att:teLatestStart att:teEarliestFin att:teLatestFin att:teMinDur att:teMaxDur pla:achievable the task TASK1 has the agent INFUNIT1 as executor and has the agent UNIT1 as assigning agent and has 600 as earliest start time and has 700 as latest start and time has 650 as earliest completion time and has 800 as latest completion time and has 50 as minimum duration and has 100 as maximum duration. NB there are other types of task eg pla:MovementTask

  9. TASKs and GOALs cps:GoalSpecification • T29 is performed in order to achieve G3 • Every task must have a goal • In the set of tasks in a mission, ideally they should have a single goal. This is called the “unifying purpose” • T1 has been broken down into subtasks T2 and T3. • For T1 to be achieved, T2 and T3 must be achieved • T2 and T3 are seen as subcomponents of T1 • The times of T2 and T3 must be within the time of T1 • The subtask relation allows an understanding of how a higher level task is broken down into a set of smaller sub-tasks. • Note that T2 does not precondition T1 (see below under “effects”), it is part of T1. TASK29 pla:realises GOAL3 pla:PlanTask TASK1 pla:hasSubTask TASK2 the task TASK29 realises the goal GOAL3. the task TASK1 has as subtask the task TASK2 and has as subtask the task TASK3.

  10. Objects related to tasks • T23 “is about” HOSTILE1. (This is a generic relation and could point to many different objects) • Note difference in name to the Goal object (see above) TASK23 pla:taskObject HOSTILE2 the task TASK23 has as object the hostile unit HOSTILE1

  11. Further relations between tasks and goals • The goal GOAL4 is “to perform the task T30” (This allows the turning of a mission task back into goal to achieve the task – is this needed now?) • The achievement of GOAL11 will provide an effect that is necessary to TASK32 but is not sufficient (other things are also necessary) (is this needed?) • The achievement of GOAL10 will provide an effect that is sufficient to permit TASK31 to be achieved (this is like “preconditions?”) GOAL4 pla:toPerform TASK30 GOAL11 pla:supports TASK32 GOAL10 pla:enables TASK31 the goal GOAL4 is to perform the task TASK30. the goal GOAL11 supports the task TASK32. the goal GOAL10 enables the task TASK31. None of these relations are used in the current BDE plan for evaluation

  12. Time

  13. Timings • T5 must start immediately after T4 has finished • T7 must start sometime after T6 has finished • T18 must occur at exactly the same time as T17 • T11 must be contained in time within T10 (but T11 may be shorter) TASK6 att:teImmediatelyAfter TASK4 TASK7 att:teAfter TASK6 TASK18 att:teSimultaneously TASK17 TASK11 att:teWithin TASK10 the task TASK5 occurs immediately after the task TASK4. the task TASK7 occurs after the task TASK6. the task TASK18 occurs simultaneously with the task TASK17. the task TASK11 occurs within the task TASK10.

  14. Timings (contd) • T15 must start after T14 has started • T13 must end before T12 has ended • T20 must not overlap in time with T21 • Note that these timings can occur across other temporal entities: • goal • resource request • spatiotemporal location TASK15 att:teStartedBy TASK14 TASK13 att:teEndedBy TASK12 TASK20 att:teNoOverlap TASK21 the task TASK15 is started by the task TASK14. the task TASK13 is ended by the task TASK12. the task TASK20 does not overlap the task TASK21.

  15. Timings (contd 2) • T7 is the first task in the set of tasks that T1 is broken down into; this means that T1 and T7 start at the same time • T8 is the last task in the set of tasks that T1 is broken down into; this means that T1 and T8 end at the same time • Together with the fact that T8 occurs after T7, this provides a total temporal order in the set of tasks that T1 is broken down into. TASK7 pla:firstTask TASK1 TASK8 pla:lastTask TASK1 the task TASK7 is first in the task TASK1. the task TASK8 is last in the task TASK1 and occurs after the task TASK7.

  16. Temporal Entities • Many entities are “Temporal entities” (eg task, goal, resource request, allocation, etc). • These contain the properties, defining timing constraints: • earliest start time (att:teEarliestStart) • latest start time (att:teLatestStart) • earliest completion time (att:teEarliestFinish) • minimum duration (att:teMinDur) • maximum duration (att:teMaxDur) • Currently, these values are to be interpreted as integers that represent “decimal hours”, eg: • 100 = 1am • 150 = 1:30 (am) • 120 = 1200 noon • 2150= 21:30

  17. “SOM parts” • An SOM part is a collection of tasks from within an Intent (and Scheme of Maneuver) that are grouped in some meaningful way. No additional timing constraints are implied by placing tasks in a SOM part. mil:SOMPart mil:Intent Brigade Intent log:contains TASK1 Brigade Intent log:contains TASK2 the intent ‘Brigade Intent’ contains the SOM part SOMPart1 and contains the task TASK3 and contains the task TASK1 and contains the task TASK2. the SOM part SOMPart1 contains the task TASK1 and contains the task TASK2.

  18. Effects and Preconditions

  19. EFFECTS TASK25 act:actProvidesPrecondition TASK26 • T25 (in some unspecified way) “causes” something that is required for T26 to occur. • This is taken to be a timing relation, equivalent to T26 occurs after T25 • T27 has a specific effect Effect1 that is required for T28 to occur • The optional proposition link to PROP1 provides a more logical means to specify what the effect is. • This could also be an unstructured proposition eg “the bridge on the river will be cleared” TASK27 act:actEffect Effect1 TASK28 act:actPrecondition Effect1 act:PrecondEffect Effect1 log:hasProposition PROP1 log:Proposition the task TASK25 preconditions the task TASK26. the task TASK27 has as effect the condition Effect1. the task TASK26 has as precondition the condition Effect1. the condition Effect1 has as proposition the proposition PROP1. the proposition 'PROP1' states that the bridge b1 has clear as property1 .

  20. EFFECTS (2) TASK3 act:actEffect Effect2 TASK4 act:actPrecondition Precondition2 Effect2 log:propImplies Precondition2 act:Effect act:Precondition • More detailed logical relations between effects and preconditions may be specified • Here Effect2 implies Precondition2; thus Effect2 and Precondition2 may not necessarily be identical • The effects and the preconditions may also have associated propositions; it is assumed that these propositions also enter into the corresponding implies relation between them the task 'TASK3' has as effect the effect 'Effect2' . the task 'TASK4' has as precondition the precondition 'Precondition2' . the effect 'Effect2' implies the precondition 'Precondition2' .

  21. Space

  22. Geography mil:PhaseLine mil:IntentArea mil:CircularAreaOfOperations mil:IntentMove mil:LandRoute • the map MAP1 contains a number of items: • the intent area INTENTAREA1 is a place where a task is to be undertaken (see next slide). It is defined as a sequence of line segments • the intent move INTENTMOVE1 is a movement in the direction of the arrow to be performed by a task (see next slide). It is defined as a sequence of line segments • the land route Route1 is a sequence of route segments defining a route to be used by units • the phase line PL1 is a sequence of line segments • OA1 is a circular area of operations ats:BitmapCoordinateSystem the map MAP1 contains the intent move INTENTMOVE1 and contains the circular area of operations OA1 and contains the land route Route1 and contains the phase line PL1.

  23. Task geography • T23 occurs in intent area INTENTAREA1 • T24 occurs as an intent move INTENTMOVE1 • NB Goals may also be geographically located • NB Units may also be geographically located, and may have spatio-temporal locations, changing over time TASK23 mil:hasIntentArea INTENTAREA1 TASK24 mil:hasIntentMove INTENTMOVE1 the task TASK23 is performed in the intent area INTENTAREA1. the task TASK24 is performed in the intent move INTENTMOVE1.

  24. Artillery Geography • the ara ARA2 is an artillery reserved area, where artillery may be placed, and no other units may enter • the ama AMA2 is an artillery maneouver area, where artillery may be placed but other units may enter • A target position is defined in the same way as a geographic area (see below) mil:ARA mil:AMA there is an ara named ARA2 that has '289:286,366:286,366:361,289:361' as path points. there is an ama named AMA2 that has '289:386,366:386,366:461,289:461' as path points. Do we need to assign specific artillery units to these – there is an owner property – needs clarification?

  25. Geographics – maps ats:mcsLT 0,0 (Virtual) ats:mcsImageName wngo_top_big.gif X Y X:Y ats:mcsRB 739:150 (Virtual) ats:mcsWH 1080:383 (Pixel) ats:BitmapCoordinateSystem • A map has an image name which is to be displayed, and points on the map are defined in pixel coordinates in the form X:Y where X is the distance going right from the left edge, and Y is the distance going down from the top edge. • There are two coordinate systems defined: • the actual pixels on the map; defined as 0,0 on the top left and image Width, image Height on the bottom right (WH) • the virtual coordinates of the map, defined by the virtual coordinates of the top left corner point (LT) and the bottom right (RB) corner point. The combination of the actual and the virtual define a coordinate transform. • All values are integers • We will agree and define a suitable virtual coordinate system, eg in decimeters (1/100 of a kilometer) and where (ideally) each pixel is square – in the above the image size is 1080:363 and the decimeter size is 930:630; thus the transform from pixels to decimeters is 1.46 in the X direction and 2.55 in the Y direction (and is hence not very square – but this was derived from the handdrawn map in the OPORD) the map MAP1 has ‘1080:383’ as image size and has ‘0:0’ as top left point and has ‘739:150’ as bottom right point.

  26. Geographics – sample maps Some non square pixels The virtual coordinates match the grid image onto the centre rectangle of the other maps Changed

  27. Geographics – areas etc mil:IntentArea mil:CircularAreaOfOperations and ats:Circle ats:circRadius= distance1 ats:staticLocation=355:158 ats:Distance distance1 ats:distance=39 ats:LineSeq ats:ep1 = 40:41 ats:ep2 = 199:41 ats:LineSeq ats:ep1 = 199:41 ats:ep2 = 199:197 ats:pathPoints • A line segment is defined by two points, start and end. • All points are in the pixel coordinates not the virtual coordinates • An area has three line segments (and it is assumed that a fourth line segment closes it • A path (land route, river, Phase line) has a set of route line segments, these being a line segment together with explicit terrain information • An operational area is a circle with a centre point and radius • A location (named “spatial entity”) below has a single point and is constant over time (thus is suitable for bridges, towns intent areas etc) • A dynamic location has a single point but is only held for a time interval as defined by the timing information (thus is suitable for modelling units that move over time) • ARAs, AMA, and targets are also defined areas (eg like INTENTAREA1) ats:LineSeq ats:ep1 = 199:197 ats:ep2 = 40:197 ats:SpatialEntity ats:staticLocation=395:315 mil:RouteLineSeq ats:ep1 = 241:316 ats:ep2 = 256:375 ats:SpatioTemporalLocation ats:staticLocation=404:395 mil:RouteLineSeq ats:ep1 = 256:375 ats:ep2 = 302:443 ats:pathPoints mil:LandRoute ter:genericClass=Metalled mil:RouteLineSeq ats:ep1 = 302:443 ats:ep2 = 275:516 Notes: 1) each point above (eg 40:41) is actually a pointer to an ats:Point with an ats:locationValue of X:Y 2) the order of points in the CE path points property is topleft,topright,bottomright,bottomleft the intent area INTENTAREA1 has ’40:41,199:41,199:197,40:197 as path points. the land route Route1 has the route segment seg1 as route segment and has the route segment seg2 as route segment and has the route segment seg3 as route segment and has metalled as classification. the route segment seg1 has ‘241:316’ as start point and has ‘256:375’ as end point. the route segment seg2 has ‘256:375’ as start point and has ‘302:433’ as end point. the route segment seg3 has ‘302:433’ as start point and has ‘275:516’ as end point. the circular area of operations OA1 has ‘355:158’ as location and has 39 as radius. the spatial entity LOC1 has '395:315' as location . the dynamic location 'DLOC1' has '404:395' as location and has 100 as earliest completion time and has 10 as earliest start time and has 100 as latest completion time and has 10 as latest start time .

  28. ORBATs

  29. ORBAT • Agents can perform Tasks. They have no direct visualisation, but are subclassed into “units” of various military and non-military types, and these do have visualisations • UNIT1 is a unit, INFUNIT1 is an infantry unit, SUPUNIT1 is a supply unit • the units have various military command relations • Other military relations of OPCON, TACON, “command of” and non-military “influence” relations are available mil:Unit (subclass of log:Agent) UNIT1 mil:hasTACOMof SUPUNIT1 UNIT1 mil:hasOPCOMof INFUNIT1 mil:Supply mil:Infantry the unit UNIT1 has OPCOM of the infantry unit INFUNIT1 and has TACOM of the supply unit SUPUNIT1.

  30. ORBAT (continued) • a unit such as ARMOR1 (an armored unit) , also has an echelon (eg a division) and an organisation (eg a US unit) and an affiliation (eg friendly) • NB this latter is perhaps more of use for defining non military organisations mil:Armor subclass of mil:USMilitary subclass of mil:Division mil:affiliation the armored unit ARMOR1 is a US military unit and is a division and has friendly as affiliation.

  31. Resources and Allocations

  32. RESOURCE “Types” or “typical members” mil:Asset_FireSupport atr:range mil:Asset_ArtilleryArea • Resources are of a certain type, of which some examples are shown: • general fire support resource • an artillery area • ammunition • general artillery • light gun • general rotary wing • general fixed wing • Strictly speaking these are not types (which are second-order concepts) but individuals that act as “typical members” or “archetypes” which may be used to define: • the nature of the resource that is defined in a resource requirement (“we need N resources just like the archetype”) • the nature of the resource in a resource pool (“we have N resource just like the typical member) • These “types” have properties, which define the characteristics of the typical members • These are all subclasses of atr:Resource mil:Asset_Ammunition mil:Asset_Artillery atr:range mil:AS90 atr:range mil:L118LightGun atr:range mil:Asset_RotaryWing atr:range mil:tonnage mil:Asset_FixedWing atr:range mil:tonnage there is a fire support asset named FIRES1 . there is an artillery area asset named ‘ARA/AMA1' . there is an ammunition asset named AMMO1. there is an artillery asset named ARTILLERY1 that has 20 as range . there is an as90 named AS901 that has 25 as range. there is a l118 light gun named LIGHTGUN1 that has 20 as range . there is a rotary wing asset named ROTARY1 that has 60 as range and has 100 as tonnage . there is a fixed wing asset named 'FIXEDWING1' that has 100 as range and has 80 as tonnage .

  33. RESOURCEs and RESOURCE POOLs log:Unit mil:Asset_Artillery atr:resOwnedBy • A resource pool is a set of N resources of a given type: • the resource pool BSG Guns contains 5 Artillery and is owned by the unit BSG • the resource pool HELO Pool contains 5 Helos and is owned by the unit 663 SQN • Resource pools may comprise other resource pools: • the resource pool RESPOOL1 contains sub resource pools, RESPOOL2 and RESPOOL3. • These pools may be provided by different units: • (Bty A and Bty B) under the command of the BSG mil:ResourcePool log:quantity = 5 log:qArchetype mil:Asset_RotaryWing the resource pool is owned by the unit BSG and has as type the artillery asset ARTILLERY and has 5 as quantity. the resource pool ‘HELO Pool’ is owned by the fixed wing unit ‘663 SQN and has as type the rotary asset HELO. the unit BSG has command of the unit ‘Bty A’ and has command of the unit ‘Bty B’. the resource pool RESPOOL1 is owned by the unit BSG and has as type the artillery asset ARTILLERY and contains the resource pool RESPOOL2 and contains the resource pool RESPOOL3. atr:subResource

  34. RESOURCE REQUESTS pla:ResourceReq pla:rrResource pla:rrPlanTask log:quantity = 10 mil:Assert_FireSupport (subclass of atr:Resource) pla:rrHasPriorityOver: • Resource requests may be issued as part of the plan. These specify a required quantity of a given resource type, to support a given task: • TASK3 places a resource request TC Task3 for 1 off HELO (Troop Carrier) or to support all the tasks in a SOMPart: • SOMPart1 places a resource request FS Part1 for 10 off Fire Support or to support all the tasks in a Mission • BG Mission places a resource request FS BG for 1 off Fire Support • A resource request occurs in time, with the same time constraints on the task that is requiring it (ie it is required for the entire task) • One resource request may have priority over another: • FS Part1 has priority over FS BG the resource request ‘FS Part1’ requires the fire support asset FIRES and has 10 as quantity and is required by the SOM part SOMPart1 and has priority over the resource request ‘FS BG’

  35. RESOURCE ALLOCATIONS • A resource allocation allocates a resource pool to a resource request: • the resource allocation “alloc 3 off” allocates 3 items from BSG Guns to FS Part1 • There are different types of allocation: • a fire support commitment, specifically for fire support resources (these can also assign targets, see later) • a resource commitment, for all other resources • A resource allocation also has an associated time, which may further constrain the tasks being allocated • An allocation may be partial, in that not all of the required resources are provided or not all of the required time coverage is provided. • An allocation has an agent that has made the decision to allocate • Note that the resource pool may not contain the exact same resources as in the request (eg FS BG asks for “Firesupport” whereas “Artillery” are actually allocated); this is ok if the allocated resource is a subtype of the requested one (Artillery is a subtype of Fire support) pla:rcSatisfies mil:FireSupportCommitment pla:allocatedQuantity =3 log:piBelievedBy -> ‘#BSG’ pla:ResourceCommitment pla:allocatedResource att:teEarliestStart =100 there is a fire support commitment named ‘fires alloc 3 off’ that satisfies the resource request ‘FS Part1’ and has 3 as allocated quantity and allocates the resource pool ‘BSG Guns’ and has the battlegroup 'BSG' as decider. there is a resource commitment named 'helo alloc 1' that has 100 as earliest start time and allocates the resource pool 'HELO Pool' and satisfies the resource request 'TC Task3' . Changed

  36. RESOURCE ALLOCATIONS (contd) • For a given resource request, RESREQ1 of we can allocate secondary resources, such as HE (High Explosive), with associated quantities atr:Resource mil:ResourcePool the resource pool ‘100 off HE’ has as type the resource HE and has 100 as quantity. the resource commitment ALLOC2 satisfies the resource requirement ‘RESREQ1’ and allocates the resource pool ‘100 off HE’.

  37. Artillery Resources, Targets

  38. Targets • A target is a geographic area that must be “hit” by the action of a military resource, eg an area where fire support is to be supplied to destroy or deter enemy contained in that area • Each target is associated with a task on behalf of which the action is to be performed • A target position is defined in the same way as a geographic area (see below) • See below for assignment of targets to resources mil:Target Target1 mil:tgtTask TASK1 there is a target named TARGET1 that has '348:239,448:239,448:289,348:289' as path points. the target TARGET1 is to support the task TASK1. the target TARGET2 is to support the task TASK1.

  39. Assigning Targets mil:Target mil:fcsSecondaryAssignment mil:FireSupportCommitment • When a fire support allocation is made, then there is a corresponding assignment of targets to the resource pool: • target1 and target2 are assigned to the BSG guns as secondary resources the fire support commitment ‘fires alloc 3 off’ assigns as secondary the target TARGET1 and assigns as secondary the target TARGET2 and allocates the resource pool 'BSG Guns' and satisfies the resource request 'FS Part1'.

  40. Assigning AMAs/ARAs (simple way) • As part of the requirement to provide fire support, an AMA or ARA may be necessary. • A simple way to model this is to assign the ARA/AMA as a secondary resource • Here the allocation fsa1 allocates both the target (see previous slide) and the ARA to the resource pool A Guns. • The timing of the use of the ARA/AMA will be that of the allocation itself. • This is a simplification that can only be removed by using the more complex way, see next slide there is a fire support commitment named fsal1 that assigns as secondary the ara 'ARA3' and assigns as secondary the target 'TARGET1' and allocates the resource pool 'A Guns' and satisfies the resource request 'FS ASSAULT' .

  41. Assigning AMAs/ARAs (detailed way) mil:MovementTask mil:FireSupportTask • If the details of the actual fire support tasks and movements of the resources from one area to another area is to be modelled (eg to assist the definition of timings) then fire support tasks and movement tasks may be planned in. • The fire support task FIRES1 represents the task that is actually to be done in order to realise the FS Assault requirement (ie the requirement is treated as a goal). It requires both: • a suitable GUN resource pool (requirement rr1 of type AS90) • a suitable ARA (requirement rr2 of type ARA) • The requirements are then allocated resources: • fsal1 allocates A Guns to satisfy rr1 (as well as target1 as secondary resource) • al1 allocates the ARA3 to satisfy rr2 • The MVT1 task is planned to get the guns to ARA3, and preconditions the FIRES1 task (and thus occurs before it). • The allocation of the ARA (al1) occurs after the movement, thus constraining the timing of the use of the ARA • The MVT1 task is set to start at 0 and have a duration of 100, thus the FIRES1 task has a earliest start of 100 (via the preconditions) • The allocation of ARA3 (“al1”) also has 100 as earliest start (via the occurs after); thus the timing of the allocations may be automatically calculated from the timing constraints there is a fire support task named 'FIRES1' that realises the resource requirement ‘FS ASSAULT’ and has the company 'A BTY' as executor . the task ‘ASSAULT LONDON’ has as subtask the fire support task 'FIRES1' . there is a movement task named ‘MVT1' that has the agent 'A Bty' as executor and has 0 as earliest start time and has 0 as latest start time and has 100 as earliest completion time and has 100 as latest completion time and has 100 as minimum duration and has 100 as maximum duration and preconditions the fire support task ‘FIRES1’ and is performed in the intent move move1. there is a resource request named rr1 that is required by the fire support task 'FIRES1' and requires the as90 'AS901' . there is a fire support commitment named fsal1 that assigns as secondary the target 'TARGET1' and allocates the resource pool 'A Guns' and satisfies the resource request rr1 . there is a resource request named rr2 that is required by the fire support task 'FIRES1' and requires the artillery area asset 'ARA' . there is a resource commitment named al1 that occurs after the movement task 'MVT1' and allocates the ara 'ARA3' and satisfies the resource request rr2 . Changed

  42. Decision Points

  43. NAIs and Observations pla:taskObject mil:DPCriterion mil:crLocation mil:NAI log:hasProposition log:Proposition • A criterion is something that is being assessed or observed about an NAI (named area of interest). The NAI is located somewhere on a map. • The criterion/observation “Enemy Present” is the object of a recce task and is located in the NAI1 • Here the observation is further detailed by an optional proposition the proposition 'PROP2' states that the hostile unit IAB has the nai NAI1 as location . the criterion 'Enemy Present' is located at the nai 'NAI1' . the task 'recce task' has as object the criterion 'Enemy Present' . the criterion 'Enemy Present' has as proposition the proposition 'PROP2' .

  44. DECISION POINTS • Branch1 – enemy is north • Branch2 – enemy is south • Use NAI1 to determine the “Enemy Present” criterion • “the hostile unit IAB has the nai NAI1 as location”

  45. General Entities

  46. General “Things” log:ConceptualThing log:relFrom1 • In order to represent new entities and relations not in the CPM, it is possible to use some generic relations and entities: • the ISTAR “thing” is the first item in a relationship called “observes for” that has the task TASK1 as second item. This could be interpreted as “ISTAR1 observes for TASK1” • there is a relation called “embeds” that goes from UNIT1 (first item) and an LNO “Thing” (second item) and is directed to a UNIT3. This could be interpreted as “LNO from UNIT1 is embedded in UNIT2” • Note: the interpretation of these relations is NOT defined in CPM, this is up to the user to define. The purpose of these relations is to capture additional information in a semi-structured way when necessary. • Note: the term “target” does NOT mean a military target, but merely the thing to which the relation is pointing. • There is a third input relation not shown here (log:relFrom3, “is third into”) log:ConceptualRelation log:relTo log:relFrom1 log:relFrom2 there is a thing named 'ISTAR1' . there is a relation named 'observes for' . the thing 'ISTAR1' is first into the relation 'observes for' . the relation 'observes for' targets the task 'TASK1' . there is a relation named embeds. there is a thing named ‘LNO’. the unit 'UNIT1' is first into the relation embeds . the thing 'LNO' is second into the relation embeds . the relation embeds targets the unit 'UNIT3' . The ConceptualThing is not output in the OWL. This is a bug.

  47. Constraints at:constrainedEntity • A generic constraint may be attached to one or two entities, with a proposition defining the constraint (may be in structured or unstructured CE) • A “cant allocate” constraint specifically states that a resource (pool) cannot be allocated to a task. at:Constraint at:constrainedEntity2 log:Proposition at:constrainedEntity atr:ResourceNotAllocatable at:constrainedEntity2 the constraint 'CONSTRAINT1' has as proposition the proposition prop1 and has as first entity the task 'TASK1' . the proposition prop1 states that it is true that "the task must be done in the dark" . the resource allocation constraint 'CANTALLOC1' constrains the task 'TASK2' and has as second entity the resource pool 'RESPOOL1'.

  48. Rationale, Assumptions

  49. Assumptions and Decisions • A assumption may be used to record a decision by an agent about some aspect of the plan. • The aspect is defined in CE • Assumptions may be used via the rationale to track down how problems in the plan have arisen from assumptions made by planners. it is assumed by the unit 'FIRESUPPORT' that the resource commitment 'ALLOC1' allocates the resource pool 'RESPOOL2' .

  50. Rationale Only explicit rationale is included at present. • Explicit: • structured the task ta1 has 100 has earliest completion time because the task ta1 has 10 as earliest start time and has 90 as minimum duration. • Explicit • unstructured there is a movement task named 'Fly OA London' because "The 1 IRISH must get to OA London as soon as possible“. • Implicit • via goals there is a task named t1 because the task t1 realises the goal g1. • via preconditions there is a task named t1 because the task t1 preconditions the task t2. • via effects • there is a task named t1 because the task t1 has as effect the effect Effect1 and the t2 has as precondition the effect Effect1. The OWL structures are documented in https://www.usukitacs.com/?q=node/6074

More Related