Editing IFC - Industry Foundation Classes/IFC concepts/IFC sequence concepts

{{IFC_Documentation}}
Processes are individual events or tasks. Processes may have different meanings when used in different scenarios. When processes are used in construction, they represent construction tasks which have associated sequence relationships, may transform inputs into outputs, and have relationships to costs, products, and resources. When processes are used in facility management, they represent maintenance tasks, including to-do lists and recurring patterns.

The primary classes related to this concept are:

* IfcWorkCalendar
* IfcWorkControl
* IfcWorkPlan
* IfcWorkSchedule
* IfcRelSequence
* IfcTask
* IfcTaskTime
* IfcLagTime
* IfcTaskType

Bits that are currently skipped for further analysis:

* IfcTask: Quantities of resources consumed by the task are dealt with by defining the IfcElementQuantity for the resource and not at the instance of IfcTask.
* IfcTask: Constraints may be applied to a task to indicate fixed task duration, fixed start or fixed finish, where IfcMetric.ReferencePath is set to the corresponding attribute on the IfcTaskTime entity.

== A project has plans related to construction and facility management ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelDeclares -> IfcProject [ label="RelatingContext" ];
  workplan1 [label="IfcWorkPlan"]
  workplan2 [label="IfcWorkPlan"]
  IfcRelDeclares -> workplan1 [ label="RelatedDefinitions[0]" ];
  IfcRelDeclares -> workplan2 [ label="RelatedDefinitions[1]" ];
  Maintenance [shape=ellipse]
  workplan1 -> Maintenance [label="Name"]
  Construction [shape=ellipse]
  workplan2 -> Construction [label="Name"]
}
-->

[[File:Ifc-concept-sequence-workplan.png]]

Work plans group work schedules, typically to distinguish between schedules for construction management purposes and schedules used for facility management purposes.

Note: the purpose attribute seems to have some similarities, but since it is so loosely defined, we don't really know what to make of it. Also note that the docs for IfcWorkPlan seem to suggest that a work plan being declared to the project actually means that a work plan is about constructing the project. With some imaginative interpretation, this could mean that a work plan could be assigned to something else entirely, not with a declares, but instead with a IfcRelAssignsToControl relationship, and therefore only indirectly be assigned to the IfcProject. However, no evidence is found of a usecase of this.

Source: IfcWorkPlan, IfcWorkControl

== A project may have work calendars ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelDeclares -> IfcProject [ label="RelatingContext" ];
  IfcRelDeclares -> IfcWorkCalendar [ label="RelatedDefinitions" ];
}
-->

[[File:Ifc-concept-sequence-workcalendar.png]]

A work calendar is a definition of working time and holiday times. Later on, this calendar can be used to describe when things are available or when tasks are allowed to take place. A typical calendar might be a 5-day working week, when you work on Monday to Friday and take Saturday and Sunday off.

Note: we are unsure whether or not it is more appropriate to store calendars at the project level or at the work plan level (described in another concept with caveats of its own) or both. For now, our implementation stores calendars at the project level.

Source: IfcWorkSchedule

== A project has schedules related to construction and facility management ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  IfcRelDeclares -> IfcProject [ label="RelatingContext" ];
  IfcRelDeclares -> IfcWorkSchedule [ label="RelatedDefinitions" ];
  IfcRelDeclares [color="pink"]
}
-->

[[File:Ifc-concept-sequence-workschedule.png]]

A work schedule is used to group together tasks to achieve a goal.

Note: we are unsure what is the purpose of directly assigning work schedules to the project. It makes more sense to group it within an IfcWorkPlan, which acts as a distinguishing factor between work schedules used for sequencing, compared to facility management, or other currently unknown purposes (perhaps, safety routine checks?). We think this relationship should be removed. The docs for IfcWorkControl also state that you should only relate it to the project as a fallback if no better context may be provided.

Source: IfcWorkSchedule, IfcWorkControl

== A project may contain tasks ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  IfcRelDeclares -> IfcProject [ label="RelatingContext" ];
  IfcRelDeclares -> IfcTask [ label="RelatedDefinitions" ];
  IfcRelDeclares [color="pink"]
  IfcRelNests [color=pink]
  IfcRelNests -> IfcTask [label="RelatingObject"]
  child [label="IfcTask"]
  IfcRelNests -> child [label="RelatedObjects"]
}
-->

[[File:Ifc-concept-sequence-task-project.png]]

When a task has no parent, it is defined globally as a task in your project.

Note: we are unsure what is the purpose of this. Tasks seem to make sense within the context of a work schedule, not elsewhere. We think this relationship should be removed.

Source: IfcTask, IfcWorkSchedule

== A work plan contains schedules ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  IfcRelAggregates -> IfcWorkPlan [ label="RelatingObject" ];
  IfcRelAggregates -> IfcWorkSchedule [ label="RelatedObjects" ];
  IfcRelAggregates [color="pink"]
}
-->

[[File:Ifc-concept-sequence-workschedule-workplan.png]]

A work schedule is used to group together tasks to achieve a goal. That goal is related to the work plan that it is part of. Typically, a work plan will contain multiple schedules. Each schedule may be planned, actual, or a baseline.

Source: IfcWorkPlan

== A work plan may contain tasks ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl [color=pink]
  IfcRelAssignsToControl -> IfcWorkPlan [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcTask [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-sequence-workplan-task.png]]

A work plan may contain tasks, which imply that the tasks are relevant to that work plan.

Note: although this is possible, we don't really see the point of it. It makes more sense for tasks to be related to work schedules, not work plans. We think this relationship should be removed.

Source: IfcWorkPlan

== A work plan may contain resources ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl [color=pink]
  IfcRelAssignsToControl -> IfcWorkPlan [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcConstructionResource [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-sequence-workplan-resource.png]]

A work plan may contain resources, which imply that the resources are relevant to that work plan. These should only be top level resources, such as subcontract or crew resources. Later on, sub resources, such as labour, equipment, or material, may then be related to tasks or calendars in a separate concept.

Source: IfcWorkPlan, IfcConstructionResource

== A work calendar determines when a task can occur ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl -> IfcWorkCalendar [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcTask [ label="RelatedObjects" ];
  IfcTask -> IfcTaskTime [label="TaskTime"]
  WORKTIME [shape=ellipse]
  P10D [shape=ellipse]
  IfcTaskTime -> WORKTIME [label=DurationType]
  IfcTaskTime -> P10D [label=ScheduleDuration]
}
-->

[[File:Ifc-concept-sequence-task-calendar.png]]

If a task is assigned a calendar, its duration may be specified in terms of working days (which IFC calls work time), instead of calendar / elapsed days. In this example, if the calendar is a 5 day working week, the task takes 10 working days, which is equivalent to 2 weeks of actual elapsed time.

Source: IfcWorkCalendar, IfcWorkSchedule

== A work calendar describes when a resource is available ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl -> IfcWorkCalendar [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcConstructionResource [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-resource-availability.png]]

A resource is only available on certain dates and not others.

Source: IfcWorkCalendar

== A work calendar can be inherited through child tasks, procedures, and events ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl -> IfcWorkCalendar [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcTask [ label="RelatedObjects" ];
  IfcRelAssignsToControl [color="pink"]
  IfcRelNests -> IfcTask [label="RelatingObject"]
  child [ label="IfcTask" ]
  IfcRelNests [ color="pink"]
  IfcRelNests -> child [label="RelatedObjects"]
}
-->

[[File:Ifc-concept-sequence-task-calendar-inheritance.png]]

If a task does not have a calendar assigned to it, it inherits the calendar from its parent task. This inheritance makes it easy to assign default calendars to a top level task in a work schedule and only override as necessary in more specific child tasks.

This same inheritance applies to procedures and events.

Note: it is assumed, but no evidence found, that hierarchical resources have this same inheritance behaviour. In other words, it is assumed that if a resource does not have a calendar assigned to it, it inherits the calendar from its parent resource.

Source: IfcWorkSchedule

== A calendar may override the availability of an inherited calendar ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl -> IfcWorkCalendar [ label="RelatingControl" ];
  IfcRelAssignsToControl -> secondcalendar [ label="RelatedObjects" ];
  IfcRelAssignsToControl [color="pink"]
  secondcalendar [label="IfcWorkCalendar"]
  IfcWorkCalendar -> IfcWorkTime [label="WorkingTime"]
  worktime2 [label="IfcWorkTime"]
  secondcalendar -> worktime2 [label="ExceptionTime"]
}
-->

[[File:Ifc-concept-sequence-task-calendar-inheritance-override.png]]

A calendar may be a child of a parent calendar. The exception times of the child calendar will first inherit, and then override the availability of its parent calendar. A calendar is only allowed to have one parent calendar.

It is currently ambiguous as to how the working times of a child calendar interacts with its parent calendar. We currently assume that if a working time is present in a child calendar, it also overrides the availability of its parent calendar.

For example: a parent calendar has a working time of Monday to Friday. The child calendar has a working time of Saturday, and an exception time of Monday. The final availability of the child calendar is therefore Tuesday to Saturday.

Source: IfcWorkCalendar

== A work schedule may be planned ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  PLANNED [shape=ellipse]
  IfcWorkSchedule -> PLANNED [label="PredefinedType"]
}
-->

[[File:Ifc-concept-sequence-workschedule-planned.png]]

In construction scheduling, a work schedule can represent your current plan of tasks, prior to the start of construction. A planned schedule typically has scheduled start, finish, and durations for its tasks. A planned schedule must not have any actual starts, actual finishes, or actual duration data. Similarly, a planned schedule must not have any lag times which are marked as "measured" lag times.

Note: the definition that distinguishing planned from actual is assumed. It is not clear in the docs. Also, the fact that we need to read the docs for IfcConstructionResource to figure this out isn't very nice.

Source: IfcConstructionResource, IfcLagTime

== A work schedule may represent actual dates when the tasks are underway or complete ==

<!--
digraph {
  node [ shape=rect, color="lightblue" ];
  edge [ fontsize=10 ];
  ACTUAL [shape=ellipse]
  IfcWorkSchedule -> ACTUAL [label="PredefinedType"]
}
-->

[[File:Ifc-concept-sequence-workschedule-actual.png]]

A work schedule may be labeled as an actual schedule, if it contains actual start / end dates of tasks, and actual durations of tasks. Similarly, a actual schedule may have lag times which are marked as "measured" lag times.

Note: the definition that distinguishes planned from actual is assumed. It is not clear in the docs. Also, the fact that we need to read the docs for IfcConstructionResource to figure this out isn't very nice.

Source: IfcConstructionResource, IfcLagTime

== Work schedules may be duplicated and compared as a baseline ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelDefinesByObject [color=pink]
  ifcworkschedule1 [label = "IfcWorkSchedule"]
  ifcworkschedule2 [label = "IfcWorkSchedule"]
  IfcRelDefinesByObject -> ifcworkschedule1 [ label="RelatedObjects" ];
  IfcRelDefinesByObject -> ifcworkschedule2 [ label="RelatingObject" ];
  BASELINE [shape=ellipse]
  PLANNED [shape=ellipse]
  ifcworkschedule1 -> BASELINE [label="PredefinedType"]
  ifcworkschedule2 -> PLANNED [label="PredefinedType"]
}
-->

[[File:Ifc-concept-sequence-workschedule-baseline.png]]

A work schedule may be duplicated. The old copy of the work schedule is known as a baseline. You can have multiple baseline work schedules. A baseline schedule can be used to compare between old plans and current plans. This baseline comparison can be used as a benchmark to measure your progress or changes in executing or planning a project.

Note: this usecase is not very clearly described in the docs, and mostly hinted at in the IfcConstructionResource page. However, it is common practice to duplicate and create baselines, and so based on this knowledge, we have attemped to describe this concept the best we can.

Source: IfcConstructionResource

== A work schedule may nest other work schedules ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  parent [label="IfcWorkSchedule"]
  child1 [label="IfcWorkSchedule"]
  IfcRelNests[color=pink]
  IfcRelNests -> parent [ label="RelatingObject" ];
  IfcRelNests -> child1 [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-sequence-subschedule.png]]

Uh. A schedule has subschedules. This is possible, but we have no idea what the usecase is. Nor we do know what it implies for derived dates, calendar inheritance, or cost derivation. We don't currently support this relationship.

Note: there is also an ambiguous note about how work schedules can include other work schedules as sub-items using aggregation instead of nesting. We take a prudent stance that this sentence is just misleading and should be ignored.

Source: IfcWorkSchedule

== A work schedule may contain resources ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl [ color=pink]
  IfcRelAssignsToControl -> IfcWorkSchedule [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcConstructionResource [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-sequence-workschedule-resource.png]]

A work schedule may define the resources that it uses.

Note: this concept is not fully understood, and why it is important to link resources to a work schedule as opposed to simply the tasks within it, or to a work plan.

Source: IfcWorkSchedule, IfcConstructionResource

== A work schedule may contain tasks ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl -> IfcWorkSchedule [ label="RelatingControl" ];
  IfcRelAssignsToControl -> IfcTask [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-sequence-task.png]]

In construction scheduling, a work schedule is a collection of tasks that must be completed over a specific timeline in order to reach the final deliverable for the project, such as constructing and commissioning a building.

Source: IfcWorkSchedule

== A work schedule may contain documents ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssociatesDocuments [ color=pink]
  IfcRelAssociatesDocuments -> IfcWorkSchedule [ label="RelatingDocument" ];
  IfcRelAssociatesDocuments -> IfcDocumentReference [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-sequence-workschedule-document.png]]

A work schedule may contain associated documents, such as gantt chart diagrams, related bid documents, safety and risk registers, and reports.

Source: IfcWorkSchedule

== A task may contain subtasks ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  parent [label="IfcTask"]
  child1 [label="IfcTask"]
  child2 [label="IfcTask"]
  IfcRelNests -> parent [ label="RelatingObject" ];
  IfcRelNests -> child1 [ label="RelatedObjects[0]" ];
  IfcRelNests -> child2 [ label="RelatedObjects[1]" ];
  Floors [shape=ellipse]
  level1 [label="Level 1", shape=ellipse]
  level2 [label="Level 2", shape=ellipse]
  parent -> Floors [label="Name"]
  child1 -> level1 [label="Name"]
  child2 -> level2 [label="Name"]
}
-->

[[File:Ifc-concept-sequence-subtask.png]]

In construction scheduling, a task may contain subtasks. This hierarchy of tasks forms the Work Breakdown Structure (WBS).

Source: IfcTask

== A task may be assigned a task time, to determine duration and scheduling times ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcTask -> IfcTaskTime [label="TaskTime"]
  ELAPSEDTIME [shape=ellipse]
  P7D [shape=ellipse]
  IfcTaskTime -> ELAPSEDTIME [label=DurationType]
  IfcTaskTime -> P7D [label=ScheduleDuration]
}
-->

[[File:Ifc-concept-sequence-task-time.png]]

A task may have its duration described most simply in terms of elapsed time. In this case, the task takes 7 days.

Source: IfcTaskTime

== A child of a recurring task occurs every time its parent task recurs ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelNests[color=pink]
  parent [label="IfcTask"]
  child1 [label="IfcTask"]
  child2 [label="IfcTask"]
  IfcRelNests -> parent [ label="RelatingObject" ];
  IfcRelNests -> child1 [ label="RelatedObjects[0]" ];
  IfcRelNests -> child2 [ label="RelatedObjects[1]" ];
  parent -> IfcTaskTimeRecurring [label="TaskTime"]
}
-->

[[File:Ifc-concept-sequence-task-time-recurring.png]]

Typically in facility management, a parent task would define a recurring time interval at which a maintenance job would need to be performed. Its subtasks, or child tasks, would then typically form the punch list of tasks to be performed in sequence for the parent maintenance job.

Source: IfcTask

== A task may have sequential relationships to other tasks ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  predecessor [label="IfcTask"]
  IfcRelSequence [ color=pink]
  IfcRelSequence -> predecessor [label="RelatingProcess"]
  IfcRelSequence -> FINISH_START [label="SequenceType"]
  IfcRelSequence -> IfcLagTime [label="TimeLag"]
  FINISH_START [shape=ellipse]
  P1D [shape=ellipse]
  ELAPSEDTIME [shape=ellipse]
  IfcLagTime -> P1D [label="LagValue"]
  IfcLagTime -> ELAPSEDTIME [label=DurationType]
  successor [label="IfcTask"]
  IfcRelSequence -> successor [label="RelatedProcess"]
  formwork [shape=ellipse, label="Formwork"]
  pour [shape=ellipse, label="Concrete Pour"]
  predecessor -> formwork [label=Name]
  successor -> pour [label=Name]
}
-->

[[File:Ifc-concept-sequence-sequence.png]]

In this scenario, a predecessor task (setting up formwork) has a finish to start relationship to a successor task (pouring concrete) with a lag time of 1 elapsed day between them.

Note: When lag times are expressed as absolute duration in working days (i.e. not elapsed days), there is an ambiguity as to whether the predecessor or successor task calendar should be applied. Based off testing in existing scheduling software, it seems as though both calendars are applied, and the one resulting in the worse value (i.e. the longest lag time) is chosen.

Source: IfcTask, IfcRelSequence, IfcProcess

== A task may have a lag time expressed as a ratio ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  predecessor [label="IfcTask"]
  IfcRelSequence [color=pink]
  IfcRelSequence -> predecessor [label="RelatingProcess"]
  IfcRelSequence -> FINISH_START [label="SequenceType"]
  FINISH_START [ shape=ellipse]
  IfcRelSequence -> IfcLagTime [label="TimeLag"]
  IfcLagTime -> 0.5 [label="LagValue"]
  0.5 [shape=ellipse]
  successor [label="IfcTask"]
  IfcRelSequence -> successor [label="RelatedProcess"]
  ptasktime -> P10D [label=ScheduleDuration]
  P10D [shape=ellipse]
  predecessor -> ptasktime [label="TaskTime"]
  ptasktime [label="IfcTaskTime"]
}
-->

[[File:Ifc-concept-sequence-sequence-ratio.png]]

A lag time between two tasks may be expressed as a ratio instead of an absolute duration. If taken as a ratio, the lag duration is determined by the ratio multiplied by the scheduled duration of the predecessor task. So in this scenario, assuming the P10D of the predecessor task is elapsed time, the lag time will be P5D.

Note: In the case of a lag time specified as an absolute duration, the worse of two possible calendars is chosen. In the case of a ratio, the duration of the predecessor task is explicitly nominated. Therefore, we also assume that the calendar of the predecessor task is the only calendar that applies in this scenario.

Source: IfcLagTime

== Tasks can construct or install objects ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelAssignsToProduct -> IfcWall [ label="RelatingProduct" ];
  IfcRelAssignsToProduct -> IfcTask [ label="RelatedObjects" ];
  CONSTRUCTION [shape=ellipse]
  IfcTask -> CONSTRUCTION [label="PredefinedType"]
}
-->

[[File:Ifc-concept-resource-task-construction.png]]

A task may be linked to a product. When the task is set as being a construction task, this means that the task results in this wall being constructed.

Source: IfcProcess

== Tasks may consume resources ==

<!--
digraph {
  node [ shape=rect ];
  edge [ fontsize=10 ];
  IfcRelAssignsToProcess -> IfcTask [ label="RelatingProcess" ];
  IfcRelAssignsToProcess -> IfcConstructionResource [ label="RelatedObjects" ];
}
-->

[[File:Ifc-concept-resource-task.png]]

A task consumes resources.

Source: IfcTask, IfcProcess, IfcConstructionResource

== A task request may result in a project order being created ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssignsToControl[color=pink]
  IfcRelAssignsToControl -> IfcTask [ label="RelatedObjects" ];
  IfcRelAssignsToControl -> IfcProjectOrder [ label="RelatingControl" ];
  IfcTask -> task [label="Name"]
  task [label="Fix lightbulbs"]
  task [shape=ellipse]
  IfcProjectOrder -> WORKORDER [label="PredefinedType"]
  WORKORDER [shape=ellipse]
}
-->

[[File:Ifc-concept-sequence-task-projectorder.png]]

A request of work, maintenance, purchasing, or other types of requests may be represented as an IfcTask typically to a helpdesk or building maintenance company. This may then result in a project order being created.

Note: the wording behind this concept is ambiguous in the documentation, and the usecase of a helpdesk is not fully elaborated. Therefore this description should be treated with suspicion.

Source: IfcTask

== A task may move a product from one location to another ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssignsToProcess [color=pink]
  IfcRelAssignsToProduct [color=pink]
  IfcRelAssignsToProcess -> IfcTask [ label=" RelatingProcess" ];
  IfcRelAssignsToProcess -> IfcBuildingElementProxy [ label="RelatedObjects" ];
  IfcRelAssignsToProduct -> IfcTask [label="RelatedObjects"]
  product [label=IfcBuildingElementProxy]
  IfcRelAssignsToProduct -> product [label="RelatingProduct"]
  name1 [label="Jump form", shape=ellipse]
  name2 [label="Jump form", shape=ellipse]
  MOVE [shape=ellipse]
  IfcBuildingElementProxy -> name1
  product -> name2
  IfcTask -> MOVE
}
-->

[[File:Ifc-concept-sequence-task-move.png]]

A task may involve moving products from one location to another. A typical example would be a jump form moving between floors of a building. The product is duplicated at each possible location that it may be at different points of time.

Source: IfcTask

== A task, event, or procedure may contain properties ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelDefinesByProperties [color=pink]
  IfcRelDefinesByProperties -> IfcTask [ label="RelatedObjects" ];
  IfcRelDefinesByProperties -> IfcPropertySet [ label="RelatingPropertyDefinition" ];
  IfcPropertySet -> psetname [label="Name"]
  psetname [label="Pset_Risk", shape=ellipse]
  IfcPropertySet -> IfcPropertySingleValue [label="HasProperties"]
  propname [label="RiskType", shape=ellipse]
  HEALTHANDSAFETY [shape=ellipse]
  IfcPropertySingleValue -> propname [label="Name"]
  IfcPropertySingleValue -> HEALTHANDSAFETY [label="NominalValue"]
}
-->

[[File:Ifc-concept-sequence-task-pset.png]]

A task, event, or procedure may contain properties. Typically this is used for risk assessment. For logistic tasks, it may also contain properties for packing instructions.

Source: IfcTask

== A task may be assigned a classification reference ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelAssociatesClassification [color=pink]
  IfcRelAssociatesClassification -> IfcTask [ label="RelatedObjects" ];
  IfcRelAssociatesClassification -> IfcClassificationReference [ label="RelatingClassification" ];
}
-->

[[File:Ifc-concept-sequence-task-classification.png]]

If tasks are based on an external classification system, such Omniclass, which guides the hierarchy of the work breakdown structure, the task may be assigned to a classification reference.

Source: IfcTask

== A project task may be based off a typical task type or template from a library of tasks ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  IfcRelDefinesByType [ color=pink]
  IfcRelDefinesByType -> IfcTask [label="RelatedObjects"]
  IfcRelDefinesByType -> IfcTaskType [label="RelatingType"]
}
-->

[[File:Ifc-concept-sequence-task-type.png]]

Whereas an IfcTask represents an actual task within a project's work schedule, it may be derived from a task template, also called a task type. Task types are not project specific and may typically be shared within a library of tasks to aid planners in creating schedules.

Source: IfcTask, IfcTaskType

== A task type can nest a task type ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  
  IfcRelNests [color=pink]
  IfcRelNests -> IfcTaskType [label="RelatingObject"]
  IfcRelNests -> subtask1 [label="RelatedObjects"]
  subtask1 [label="IfcTaskType"]
}
-->

[[File:Ifc-concept-sequence-task-type-nest-task-type.png]]

Note: It is currently ambiguous as to what this means.

Source: IfcTaskType

== A task type can nest a task ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  
  IfcRelNests [color=pink]
  IfcRelNests -> IfcTaskType [label="RelatingObject"]
  IfcRelNests -> subtask1 [label="RelatedObjects"]
  subtask1 [label="IfcTask"]
}
-->

[[File:Ifc-concept-sequence-task-type-nest-task.png]]

Note: It is currently ambiguous as to what this means.

Source: IfcTaskType

== A task type can nest a task, that is also typed ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  
  IfcRelNests [color=pink]
  IfcRelNests -> IfcTaskType [label="RelatingObject"]
  IfcRelNests -> subtask1 [label="RelatedObjects"]
  subtask1 [label="IfcTask"]
  
  tasktype1 [label="IfcTaskType"]
  IfcRelDefinesByType [color=pink]
  IfcRelDefinesByType -> subtask1 [label="RelatedObjects"]
  IfcRelDefinesByType -> tasktype1 [label="RelatingType"]
}
-->

[[File:Ifc-concept-sequence-task-type-nest-task-with-type.png]]

Note: it is currently ambiguous as to what this means.

Source: IfcTaskType, IfcRelDefinesByObject

== When a task type is used in a project, its child tasks are linked to the project tasks ==

<!--
digraph {
  node [ shape=rect, color=lightblue ];
  edge [ fontsize=10 ];
  
  { rank = same; IfcRelDefinesByType }
  { rank = max; IfcRelNests irelnests }
  { rank = sink; IfcRelDefinesByObject }
  
  IfcRelDefinesByType [ color=pink]
  IfcRelDefinesByType -> IfcTask [label="RelatedObjects"]
  IfcRelDefinesByType -> IfcTaskType [label="RelatingType"]

  irelnests [label="IfcRelNests", color=pink]
  irelnests -> IfcTask [label="RelatingObject"]
  irelnests -> isubtask1 [label="RelatedObjects"]
  isubtask1 [label="IfcTask"]

  IfcRelNests [color=pink]
  IfcRelNests -> IfcTaskType [label="RelatingObject"]
  IfcRelNests -> subtask1 [label="RelatedObjects"]
  subtask1 [label="IfcTask"]


  IfcRelDefinesByObject [color=pink]
  IfcRelDefinesByObject -> isubtask1 [label="RelatedObjects"]
  IfcRelDefinesByObject -> subtask1 [label="RelatingObject"]

}
-->

[[File:Ifc-concept-sequence-task-type-definesbyobject.png]]

When a task type with subtasks is used in a project, it creates corresponding task instances in your task tree. To correlate these task instances back to the task type, an object relationship is created.

Note: usecases and workflows of this is still currently ambiguous. Also, there is a discrepancy where the documentation in IfcTaskType describes a nesting relationship, whereas the IfcRelDefinesByObject documentation describes an aggregation relationship.

Source: IfcTaskType, IfcRelDefinesByObject

[[Category:Industry Foundation Classes (IFC)]]
@@ Line 107: / Line 107: @@
 Source: IfcTask, IfcWorkSchedule
-== A work plan contains calendars ==
-<!--
-digraph {
-  node [ shape=rect, color="lightblue" ];
-  edge [ fontsize=10 ];
-  IfcRelNests -> IfcWorkPlan [ label="RelatingObject" ];
-  IfcRelNests -> IfcWorkCalendar [ label="RelatedObjects" ];
-  IfcRelNests [color="pink"]
-}
--->
-[[File:Ifc-concept-sequence-workcalendar-plan.png]]
-A calendar within a work plan implies that the calendar is related to the work plan, and may be used later on to describe availability for other concepts within the work plan, such as tasks or resources.
-Note: there is only a single sentence describing this relationship in the source, and it uses a nests relationship which is different from all other work plan relationships, so we are suspicious about this concept and do not currently support it.
-Source: IfcConstructionResource
 == A work plan contains schedules ==