| Latest revision |
Your text |
| Line 1: |
Line 1: |
| − | {{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. | | 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. |
| | | | |
| Line 13: |
Line 12: |
| | * IfcLagTime | | * IfcLagTime |
| | * IfcTaskType | | * IfcTaskType |
| − | | + | * IfcEvent |
| − | Bits that are currently skipped for further analysis:
| + | * IfcProcedure |
| − | | |
| − | * 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 == | | == A project has plans related to construction and facility management == |
| Line 41: |
Line 37: |
| | Work plans group work schedules, typically to distinguish between schedules for construction management purposes and schedules used for facility management purposes. | | 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 |
| − | | |
| − | Source: IfcWorkPlan, IfcWorkControl | |
| | | | |
| | == A project may have work calendars == | | == A project may have work calendars == |
| Line 80: |
Line 74: |
| | A work schedule is used to group together tasks to achieve a goal. | | 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. | + | 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. |
| | | | |
| − | Source: IfcWorkSchedule, IfcWorkControl | + | Source: IfcWorkSchedule |
| | | | |
| | == A project may contain tasks == | | == A project may contain tasks == |
| Line 223: |
Line 217: |
| | Source: IfcWorkCalendar | | Source: IfcWorkCalendar |
| | | | |
| − | == A work calendar can be inherited through child tasks, procedures, and events == | + | == A work calendar can be inherited through child tasks == |
| | | | |
| | <!-- | | <!-- |
| Line 242: |
Line 236: |
| | | | |
| | 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. | | 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. | | 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. |
| Line 288: |
Line 280: |
| | [[File:Ifc-concept-sequence-workschedule-planned.png]] | | [[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. | + | 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. |
| | | | |
| | 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. | | 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 | + | Source: IfcConstructionResource |
| | | | |
| | == A work schedule may represent actual dates when the tasks are underway or complete == | | == A work schedule may represent actual dates when the tasks are underway or complete == |
| Line 307: |
Line 299: |
| | [[File:Ifc-concept-sequence-workschedule-actual.png]] | | [[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. | + | A work schedule may be labeled as an actual schedule, if it contains actual start / end dates of tasks, and actual durations of tasks. |
| | | | |
| | 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. | | 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 | + | Source: IfcConstructionResource |
| | | | |
| | == Work schedules may be duplicated and compared as a baseline == | | == Work schedules may be duplicated and compared as a baseline == |
| Line 395: |
Line 387: |
| | | | |
| | 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. | | 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 | | Source: IfcWorkSchedule |
| Line 462: |
Line 436: |
| | | | |
| | Source: IfcTaskTime | | 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 == | | == A task may have sequential relationships to other tasks == |
| Line 490: |
Line 441: |
| | <!-- | | <!-- |
| | digraph { | | digraph { |
| − | node [ shape=rect, color=lightblue ]; | + | node [ shape=rect ]; |
| | edge [ fontsize=10 ]; | | edge [ fontsize=10 ]; |
| | predecessor [label="IfcTask"] | | predecessor [label="IfcTask"] |
| − | IfcRelSequence [ color=pink]
| |
| | IfcRelSequence -> predecessor [label="RelatingProcess"] | | IfcRelSequence -> predecessor [label="RelatingProcess"] |
| | IfcRelSequence -> FINISH_START [label="SequenceType"] | | IfcRelSequence -> FINISH_START [label="SequenceType"] |
| | IfcRelSequence -> IfcLagTime [label="TimeLag"] | | IfcRelSequence -> IfcLagTime [label="TimeLag"] |
| − | FINISH_START [shape=ellipse]
| |
| | P1D [shape=ellipse] | | P1D [shape=ellipse] |
| | ELAPSEDTIME [shape=ellipse] | | ELAPSEDTIME [shape=ellipse] |
| Line 506: |
Line 455: |
| | formwork [shape=ellipse, label="Formwork"] | | formwork [shape=ellipse, label="Formwork"] |
| | pour [shape=ellipse, label="Concrete Pour"] | | pour [shape=ellipse, label="Concrete Pour"] |
| − | predecessor -> formwork [label=Name] | + | predecessor -> formwork [label=DurationType] |
| − | successor -> pour [label=Name] | + | successor -> pour [label=ScheduleDuration] |
| | } | | } |
| | --> | | --> |
| Line 514: |
Line 463: |
| | | | |
| | 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. | | 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 | | 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 == | | == Tasks can construct or install objects == |
| Line 568: |
Line 484: |
| | | | |
| | Source: IfcProcess | | 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)]]
| |
