Not applicable.
Not applicable.
This invention relates generally to project management systems and more particularly to a method and apparatus for generating detailed integrated project schedules.
As is known in the art, a project planning technique is a technique that can be used to assemble a project plan (e.g. for a construction project). Some well-known project planning techniques include a dependency structure matrix (DSM), a critical path method (CPM), a precedence diagram method (PDM), a concurrent engineering technique, a critical chain technique, an overlapping framework technique, various system dynamics techniques, a simulation language for alternative modeling technique (SLAM), a graphical evaluation and review technique (GERT), a queue graphical evaluation and review technique (Q-GERT), and a program evaluation and review technique (PERT). Such conventional project planning techniques are thus used to plan and control projects.
Of the above techniques, CPM, PDM, PERT, and GERT will be recognized to be the most common project planning techniques. Such project planning techniques provide a model of a project plan having activities and time relationship linkages between the activities. Software systems implementing one or more of these prior techniques include Primavera Project Planner and Microsoft Project and CACI SimProcess.
Using these prior project planning techniques and systems it is difficult or impossible to reuse most of the project planning logic of one project when constructing a project plan for a second project. This logic includes repeating patterns of predecessor-successor relationships, rules governing the sequencing of work flow, and rules or heuristics for deciding how to make assignments of resources to activities. The difficulty stems largely from the fact that prior project planning techniques and systems require the project plan to be assembled by the user in “bottom-up” fashion, beginning with a description of each of the individual activities in the project including resource assignments and activity durations. Individual predecessor-successor relationships are then expressed in the prior systems between pairs of individual activities, with little or no facility for expressing patterns of predecessor-successor relationships among collections of activities. Once the user has specified this level of detailed data, the system can generate a project schedule by assigning start and finish dates to the individual project activities
Not only is it difficult to reuse the project planning logic of one project in another similar or dissimilar project, it is also usually cost prohibitive to develop multiple detailed and accurate project plans that might be applicable to a single complex project. Therefore detailed project plans are not often used with prior systems to help evaluate multiple possible alternative implementations of a project, nor to evaluate different alternative means and methods of executing the project, nor to evaluate multiple possible outcomes of a project at various decision points during the course of the project.
Thus, in accordance with the concepts, systems and techniques described herein, it has been recognized that it would be desirable to provide a system and technique for computing a schedule for a project utilizing a system and technique capable of accommodating changes in data, precedence and other project attributes (e.g. such as construction attributes) and providing an appropriate schedule which reflects such changes.
In accordance with the present concepts described herein, a simulation system for simulating a project (e.g. such as a construction project) includes a work details table having a user-defined number of columns and having stored therein a plurality of attributes for the project, a schedule generator coupled to receive information from the database and to generate one or more schedules, a pull processor coupled to the schedule generator, said pull processor for scheduling activities by a “just-in-time” (or “JIT”) process which satisfies specific activity completion constraints, and a push processor coupled to the schedule generator, said push processor for scheduling resource constrained activities by means of a simulation model with specific resource availability, precedence, and priority constraints.
With this particular arrangement, a system and technique for computing a schedule for a project by describing a set of allowable resource level rules, a set of precedence rules, and work detail activities to be done with what quantities of effort required by which resources, but without specifying the duration and number of resources engaged in each such quantity of activity and without specifying the individual precedence relationships between any two such activities is provided.
By utilizing a work details table having a variable and user-defined number of columns, the system allows data-driven multidimensional organization of project data. This allows each project to utilize a work details table tailored for that specific project.
The push processor utilizes one technique, namely a simulation processor which executes a simulation model, to determine the schedule (start and finish times) for a subset of the project activities while the pull processor allows the remaining project activities to be scheduled by another technique, namely a just-in-time scheduling process. Thus, the system utilizes two different techniques for scheduling activities in the project. Which technique applies to a given activity is included in the precedence representation. The system also allows changing of precedence constraints and attributes utilizing a precedence editor. A precedence constraint might specify that one activity precedes another. An attribute of that precedence constraint might further specify that the constraint is of type Finish-Start (FS) meaning that the finish of the one activity (i.e. the point in time at which the one activity is considered finished) precedes the start of the other activity (i.e. the point in time at which the other activity is considered to begin). Another attribute might specify that a lag of a certain period of time (e.g. two days) occurs between the finish of the one activity and the start of the other.
In accordance with a further aspect of the concepts described herein, a method for generating a project schedule in response to a given set of project data, resource limits, resource calendars, and precedence is described. The technique uses two different types of data flow operators in a discrete event simulation model. One data flow operator is a work detail actor (WDA) and one data flow operator is a precedence actor (PA). The PA operator tracks satisfaction of precedence constraints and the WDA operator models the allocation of resources to a specific work detail and the scheduling of the work detail onset and completion. The WDA schedules the allocation of resources to the work detail in conjunction with a Resource Manager that associates with each work detail a calendar of available resource work days and work hours. Different calendars may be associated with different work details and hence with different WDAs.
With this particular arrangement, an entire simulation model is constructed from information stored in the work detail table (WDT) and the precedence table. Use of a user-defined WDT and multiple data flow operators (e.g. WDAs and PAs) allows the simulation model to be generated from the project data (vs. the prior art technique in which a fixed simulation model is supplied and the data must conform to it).
The foregoing features of this invention, as well as the invention itself, may be more fully understood from the following description of the drawings in which:
Before describing the various embodiments of the invention, some introductory concepts and terminology are explained.
Described herein is a system and technique for generating a schedule for a project by specifying resource levels, precedence rules, activity and effort to be done but without specifying the duration of each activity to be done. This is accomplished via the use of a database comprising a plurality of dimensional columns and a plurality of measure columns.
Reference is made herein to simulation of a construction project. It should be appreciated, however, that such reference is made only to promote clarity in the text. The description of the broad concepts, systems and techniques described herein find use in a wide variety of applications and projects including, but not limited to any type of application and/or project which has a large number of components and complexities including but not limited to engineering projects, civil works, aerospace, government, IT, communications, telecommunications, individualized manufacturing, oil, gas, utilities, professional services, consulting, manufacturing, requisition, verification, inspection, new product development, demolition, and implementation of new services.
As used herein, the term “effort” is distinguished from the term “duration” in that effort is a measure of an amount of work to be done, while duration is a measure of an elapsed time from the beginning of work to the end of work. For example, ten man-hours of effort can be accomplished by ten men in one hour of duration, or by one man in ten hours duration. Any one of the three variables (i.e. effort, duration, and resources-busy) can be solved by knowing the other two (i.e. effort=resources-busy multiplied by duration). Thus, a value for effort may be computed as a product of a value for resources-busy and a value for duration.
It should also be appreciated that, in the context of a construction project, the term “schedule” means the beginning and end times for each of a (typically large) number of different activities as well as a project duration. The term schedule can also include, but is not limited to, the levels of resources busy (as opposed to available), material cost, and other attributes related to activities, by time and activity.
The term “activities” refers to tasks or actions. In a construction project, actions can be items such as “frame walls,” “hang sheet rock,” etc. Activities are associated with an amount of work to be done. The phrase “Frame walls” is an activity type, but activity values (also referred to as data or tokens) which are input to the system are effort quantities of an activity, For example, frame walls in room 23 for ten crew-hours (together with other possible attributes of the activity), frame walls in room 24 for twelve crew-hours (together with other possible attributes of the activity), hang sheet rock in room 23 for eight crew-hours (together with other possible attributes of the activity), etc.
The phrase “resource levels” refers to items such as the number of plumbers available on a given day or for a given period of time. Available and busy resource levels are distinguished, the former being the number (or amount) or a particular resource that could be busy if work was available for them, the latter being the number of resources (not exceeding the available number of resources) that are actually engaged in work. A “resource limit” is a rule provided by the user which limits the number of resources that are allowed to be busy on activities which meet specific constraints included in the resource limit. For instance a resource limit of ten plumbers on Floor 1 expresses the rule that at most ten plumber resources can be busy at any time with activities which occur on Floor 1.
As used herein the term “constraint” refers to logical constraints.
As used herein the terms “attributes” refers to a set of properties associated with a thing. For example, work details and precedence relationships are two attributes of a construction project. The attributes of a precedence relationship, for example, include whether its type is finish-to-start (FS), start-to-start (SS), or partial-to-start (PS) and whether it includes lag or not. Material cost and crew hours are two attributes related to activities. Numerous other examples also exist.
Referring now to
Database 18 has stored therein a plurality of tables which fully describe a project being simulated (e.g. which fully define a construction project). Database 18 includes a work details table 20 having a plurality of dimensional columns (with five dimensional columns D1-D5 being shown in
A user enters data into the work details table (WDT) 20. Database 18 also includes a Crew Composition table 20a, a Precedence table 20b, a Resource Limits table 20c, a Project Schedule table 20d and a Calendar table 20e. These database tables are normally populated by the user except the Project Schedule table which is populated by the Schedule Generator component of the system 22 when initiated to do so by the user. The Precedence Table 20b is normally populated by the user by means of using the Precedence Editor 30. Similarly, other elements of the User Interface 14 may be used to populate the Crew Composition, Resource Limits and Calendar tables. Alternatively, data for these tables may he entered directly by the user (bypassing the User Interface) or copied from another database or from within the same database.
It should be appreciated that each project being simulated is a partition (i.e. a subset of the rows) of all the tables. The data associated with a single project can be used to generate (via push simulation and/or pull scheduling) one or more project schedules, each of which is stored as a set of rows of the Project Schedule table 20d. It should also be appreciated that other tables may also exist, but for clarity in the drawings and the description, only tables 20-20d are shown in
As mentioned above, schedule generator 22 is coupled to database 18 through data access layer 16. Schedule generator 22 has coupled thereto a pull processor 23 and a push processor 24. Push processor 24 comprises a simulation engine 25 which includes an event list 26, a scheduler 27, a simulation model 28 and a resource manager 29. The simulation model represents the data structure that is constructed out of precedence actors and work detail actors to be described below.
In accordance with one aspect of the techniques described herein, it is possible to add as many columns as desired to the work details table 20. This allows the project or portions of the project to be described in as fine detail or in as course a detail as desired and also allows change of locations, etc. to be made. For example, different alternatives or strategies for assigning work to work crews may be used. For example, given two carpenter crews, it may be desirable to assign work such that one carpenter crew works on even numbered floors and the other carpenter crew works on odd number floors. However, it may instead be desirable to have both carpenter crews work on the same floor but have one crew work on the east side of the floor and the other crew work on the west side of the same floor. The different project schedules generated in these two cases describe alternative project plans, generated for purposes of comparison prior to selecting one plan or the other. It should be appreciated that typically in early design stages of a project tables 20-20d have fewer columns and rows than in later design stages of the project. This is because fewer project details are known earlier in the design stage than later. As a project progresses, more information is known allowing the database to be tailored as needed to accommodate project requirements.
For each simulation, the work details table 20 is populated with data from a customer (e.g. an owner or an architect) and/or data from a construction expert (e.g. a person skilled in identifying construction details, such as a number of work zones in a construction project). The WDT for a project thus includes a user-defined number of columns which number may be changed during a construction project to tailor the WDT 20 to meet the needs of the specific project simulation (the WDT is thus said to be configurable). It should be appreciated that both the number and meaning of the columns can change. By allowing configurable attributes in WDT 20, the WDT 20 is flexible which in turn provides flexibility in the model. This flexibility together with the fact that the Precedence and Resource Limits data refer only indirectly to data in WDT results in a high degree of data reusability in the system. The same or substantially similar Precedence and Resource Limits data can be reused from one project to another with only the WDT data being substantially different between the two projects.
As will become apparent from the description herein below, the work details, precedence data, resource limits data and crew composition data all are provided to a pull processor 23 and a push processor 24. The push and pull processors 23 and 24 write back scheduled data 20 into database table 20d.
A precedence editor 30 exists as part of user interface 14. Precedence editor 30 can be used to modify precedence data (i.e. modify a precedence relationship) and thus allows a user to define a sequence of work. For example, precedence editor 30 enables a user to define a set of rules describing constraints (e.g. logical constraints having physical meaning) which are to be satisfied (and preferably must be satisfied) by a schedule of the activities, including whether activities are to be push scheduled or pull scheduled. The attributes of a precedence relationship, for example, include whether its type is finish-to-start (FS), start-to-start (SS), or partial to start (PS). A FS precedence relationship is one in which the successor activity is allowed to start only after the predecessor activity has finished. Other types and attributes of precedence relationships may also exist.
Once the work details table having a user-defined number of columns is populated and precedences are defined to provide the precedence data, the project can be simulated via a simulation engine 25. It should be appreciated that schedule generator 22 receives precedence information in the form specified by the user and generates a detailed graph of precedence relationships between individual work details for use by simulation engine 25.
It should be appreciated that in preferred embodiments, the simulation system 10 does not utilize fixed predefined simulation models, rather each simulation model is dynamically assembled (i.e. the model is generated on the fly given the data). This is accomplished by reading the precedence graph data (e.g. the precedence relationships) together with the WDT and constructing a data flow graph of work detail actors and precedence actors which constitute the simulation model (see
The push scheduling process is implemented with a simulation engine while the pull scheduling process is implemented with a JIT process (
It should be noted that in the exemplary embodiment of
Referring now to
Referring now to
Referring now to
Referring now to
It should be appreciated that blocks 44a-44n, 46a-46n, 52a-52n do not include duration information. The duration information is computed by the simulation system in accordance with the rules of the given scheduler. For example, a push scheduler (e.g. event scheduler 27 in
It should also be appreciated that a single precedence graph can be used for multiple projects (e.g. multiple work detail tables) because it expresses rules about project activities in terms of the values of attributes of the work details in the project. Thus, a given node in a precedence graph might refer to a number of work details in one project but to a different number of work details, including possibly zero work details, in a different project.
It should also be appreciated that “frame” is a shorthand phrase for “frame walls” and that this is a possible value of the activity attribute or dimension of the work details. Thus, the Frame node (depicted as a stack of nodes 44a-44N) of the precedence graph refers indirectly to that set (possibly empty) of work details in the current project which have the value “frame walls” in the activity column. The total effort associated with these work details can only be determined by summing up the effort quantities of the corresponding work details, since there is no duration or effort information in the precedence graph itself.
Similarly, “hang (which is a shorthand phrase for “hang sheet rock”) is another possible value of the activity column of the work details table, and so the Hang precedence graph node (depicted as stack 46a-46N) refers indirectly to those work details having the value “hang sheet rock” in the activity column.
It should be appreciated that the precedence graph expresses rules about categories of activities by making indirect reference to specific work detail records. This allows a precedence graph to apply the same set of precedence rules to different sets of work details and hence to be reused both within a single project and between two projects. The arrow (directed arc) between Frame (44a) and Hang (46a) in
When this precedence rule is applied to work details in one project having values of Z1 and Z2 in the zone column, it expresses the rule: all work details with activity=“frame” and zone=“Z1” must be finished before any work detail with activity=“hang” and zone=“Z1” can start, and all work details with activity=“frame” and zone=“Z2” must be finished before any work detail with activity=“hang” and zone=“Z2” can start. When applied to work details in another project having “east” and “west” values in the zone, then the same precedence graph expresses the rule all work details with activity=“frame” and zone=“east” must be finished before any work detail with activity=“hang” and zone=“east” can start, and all work details with activity=“frame” and zone=“west” must be finished before any work detail with activity=“hang” and zone=“west” can start.
As illustrated in push portion 40 of
Referring now to
Also, although not explicitly shown, those of ordinary skill in the art will appreciate that other attributes are implicitly included in the nodes and arcs in
Referring now to
It should be appreciated that the data flow model includes two different types of data flow operators, namely: work detail actor (WDA) nodes (as evidenced by work detail actor nodes 60, 64) and precedence actor (PA) nodes (as evidenced by work precedence actor nodes 62, 66). WDA node 60 is connected via directed arc 61 to PA node 62. In turn, PA node 62 is connected via directed arc 63 to WDA node 64 which in turn is connected via directed arc 65 to PA node 66, where arcs 61, 63, 65 represent the flow of information among the nodes. Associated with each work detail is a calendar which describes when the resources involved in the work detail are available. When the WDA associated with the work detail requests an allocation of resources from the Resource Manager, the Resource Manager only allocates resources to the WDA on behalf of the work detail in accordance with the allowable work hours of those resource according to the calendar.
In one exemplary embodiment, suppose the precedence graph of
Each of the PAs 62, 66 corresponds to an arrow illustrated in the precedence editor described above in conjunction with
Referring now to
Referring now to
The precedence relation specified by the user in
In addition to the WorkDetails of
The order in which work on the individual floors proceeds is affected by the Priority values assigned to the corresponding WorkDetails. In
Precedence relations A and B, the stated Resource Limit and the Priorities assigned to WorkDetails together all result in the staircasing of WorkDetail activities WD1 through WD12 as seen in
PActor9 of
In the example, we see that WD7 and WD10 are the only WorkDetails which describe RoughIn activity on Floor 2, and WD7 includes somewhat greater CrewHours of effort than does WD10. This is evidenced by the WD7 Gantt bar being slightly longer that the WD10 Gantt bar in
The rectangular elements (typified by element 120 in
Alternatively, the processing and decision blocks can represent operations performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC) of a field programmable gate array (FPGA). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required of the particular apparatus. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence described is illustrative only and can be varied without departing from the spirit of the concepts described and/or claimed herein. Thus, unless otherwise stated, the processes described below are unordered meaning that, when possible, the sequences shown in
Turning now to
Processing block 123 and decision blocks 124, 125 implement a loop to determine whether each predecessor event p occurred prior to event e. In decision block 124, a decision is made as to whether each predecessor p is a push event. If a decision is made that event p is a push event, then processing flows to decision block 125 in which it is determined whether event p occurred prior to event e.
If, in decision block 124 a decision is made that predecessor p is not a push event, then processing directly flows to processing block 128 in which the latest allowable time tp1 of event p is computed.
Processing then flows to processing block 130 and decision blocks 132, 133 which implement a loop to determine whether event p has occurred and if so, whether event p occurred before time tp1. If event p has not occurred, then processing flows to processing block 134 in which it is recorded that event p occurred at time tp on work detail WDp. Processing then proceeds to processing block 136 in which notice is sent that event p has occurred at time tp on work detail WDp.
If, in decision blocks 132, 137 a decision is made that event p occurred, but not before time tp1, then processing flows to processing block 138 in which recorded event p is moved back to time tp on work detail WDp. Processing again proceeds to processing block 136 in which notice is sent that event p has occurred at time tp on work detail WDp. A new call stack frame is pushed on the processing stack and processing then flows recursively back to processing block 120 and the process is repeated. When loop 123 completes, processing terminates at block 139. The call stack is popped and if a previous stack frame exists, it continues processing at loop 130. When all iterations of loop 130 have completed, processing continues at block 123
Error conditions at block 126 occur when conditions such as that shown in
The kind of scheduling that the Simulation Engine (e.g. simulation engine 25 of
A pull schedule in contrast, determines the latest (e.g. “just-in-time” or JIT) start times for a set of activities given a set of final precedence constraints.
When a Master Integrated Schedule (MIS) is traditionally constructed, the usual process is to first generate the push schedule. This typically describes the on-site construction project. Then holding the push schedule fixed, the pull schedule is deduced by reasoning temporally backwards to determine the latest dates at which certain prerequisite activities must have occurred given the dates of the push activities and given the precedence constraints among the pull activities. The pull activities typically describe off-site activities like procurement, permitting, and design.
The present invention implements pull scheduling in conjunction with the normal simulation driven push scheduling, making it possible to generate an MIS entirely by automated means.
The user constructs the precedence graph for a project to describe both the push and pull precedence rules. Work detail records are supplied both to describe the work performed in push activities and that performed in pull activities. Whether a work detail is to be schedule by the push or by the pull processor is determined by an specified by the user in each node of the precedence graph. As with traditional push activities, there need not be work details present that fall under all Precedence nodes. The PrecedenceGraph can describe more rules than need to be enforced by the current set of work detail records. This supports the reusability of the precedence graph across projects.
Each WorkDetail record for a pull activity is interpreted as a fixed duration activity where the CrewHours value alone determines the length of the activity. If the user supplies two WorkDetail records that fall under a given pull precedence node, then each such WorkDetail corresponds to a separate pull activity (so the user has manual control over parallel pull activities if desired).
The user explicitly indicates in the PrecedenceGraph (e.g. see
The simulation process runs normally, operating only on the subset of WorkDetails that are not pull-scheduled, and obeying only push precedence rules. Resource limits apply only to push scheduled activities. As the simulation runs, pull scheduling automatically records the pull-scheduled events which must have occurred in order to satisfy each push-scheduled one. If a pull-scheduled event has already been recorded as a result of an earlier push event, then the pull-scheduled event is updated if necessary with earlier start and end times to accommodate all simulated push events and still maintain pull precedence rules. This readjustment and recording of the start and end times of pull scheduled events is accomplished by the process depicted in
When the simulation completes, if any pull activities exist which have non-zero associated WorkDetails and which have not been scheduled by some push event, then an error condition occurs which results in a reporting that the schedules for these activities have been underspecified. The user expresses precedence relations on these activities in the precedence graph in order to achieve an error-free simulation run. It would be sufficient for instance, to relate them to some date or to an event which occurs when the simulation ends (such as an implicit “End Of Project” milestone).
To reiterate, the user constructs and edits a PrecedenceGraph or copies one from another project in the database. Some portion of the precedence graph represents push-scheduled activities and some portion represents activities which are to be pull scheduled (i.e. lead-time activated activities). The user connects nodes in the precedence graph to indicate precedence constraints within that portion and also connects nodes in the pull portion of the graph to nodes in the push portion, indicating where the interface points are between the push (simulated) and pull (e.g. just-in-time) portions of the schedule.
Precedence nodes and arcs are used identically in the pull and push portions of the graph. Since all precedence rules are considered push by default, the user explicitly indicates when nodes are to be made pull. This is done by selecting one or more nodes and setting them to be pull, or by choosing this setting in the properties dialog of an individual node. The pull/push indicator is similar to a color attribute except that it has only two possible values. The PrecedenceEditor visually differentiates the pull and push parts of the graph.
Referring now to
Here the nodes A, B, and C refer indirectly to push scheduled (simulated) activities in the work details of the project and X, Y, and Z refer to pull-calculated activities of those work details. The B activity might be Install AHUs and the prerequisite pull Y and X activities might be Order AHUs and Design AHUs, for example.
Precedence nodes are all defined the usual way, namely associated with each is a predicate which selects a subset of WorkDetails. Here it is assumed that the Precedence nodes select values of a column of the work details table which names an activity as indicated.
The simulation runs under the direction of the push processor (see
If pull precedence exists, however, the prerequisite pull activities are automatically either recorded for the first time or modified by pushing them backwards in time as necessary to accommodate the new successor event. This same logic is repeated for each recorded simulation event. The result is that the inferred pull activities all just-in-time satisfy both successor push events and successor pull events. This pull scheduling process is depicted in greater detail in
Referring now to
First, pull precedence Y and then X are inferred as soon as B is detected to start. Using the start time of B and the CrewHours of the WorkDetails falling under Y and X, the start of Y, end of X and start of X times are determined by date subtraction. Every pull predecessor of B must be examined (there might be more than one), and every pull predecessor of a pull predecessor must be examined as well. For each such pull predecessor, each WorkDetail falling under it results in a separate activity being recorded. If any pull predecessor does not yet have a recorded activity, then we create one, as for Y and X in
If a pull predecessor activity has already been recorded, then we check to see if its end date satisfies the given successor. If not, then we update the predecessor activity in place to move it back until it just does so. So in
Notice that any resource limits that might otherwise apply to the resources of the pull-scheduled activities are ignored. Nothing prevents the pull-scheduled activities from overlapping with concurrent push-scheduled activities and using the same resources. It is expected that pull-scheduled resources will generally use resource pools distinct from the push-scheduled resource pools, however. In this case the resource levels required by the pull-scheduled activities will be inferred from the pull schedule rather than imposed upon it.
Referring now to
Referring now to
Push-scheduled events and milestone dates cannot in general have their start and finish time modified without affecting other simulated events unpredictably. Therefore it is possible that the push-scheduled predecessor will cause a simulation runtime error. This would happen if the fixed length pull-scheduled events are found to not all fit inside the push-scheduled window described by the user's precedence rules. However, if the pull-scheduled activities fit within the push-constrained window of opportunity, the result might be as shown in
Another aspect of the feature design is that the user can easily choose to push-schedule any portion of what are normally thought of as pull-scheduled activities. This brings all the capabilities of the simulation model to bear on developing a sub-schedule for procurement and design type activities if resource contention needs to be modeled for these activities.
Specially identified BeginSim and EndSim precedence nodes (i.e. nodes which define either a beginning of a simulation or an end or a simulation, respectively) may be placed in the precedence graph by the user. These behave like push-scheduled milestone dates which automatically receive their date value from the first or last occurrence, respectively, of simulated allocation activity. There can be any number of BeginSim or EndSim nodes in a precedence graph, all BeginSims have the same meaning and occur simultaneously with the first simulation activity. All EndSims likewise occur simultaneously with the last simulation activity.
Implicitly, all push-schedule activities succeed BeginSim and precede EndSim. Therefore the user is not allowed to directly connect any push-scheduled activities to them, nor can pull-scheduled activities be connected as successors to them. However, pull-scheduled nodes can be related to precede either a BeginSim or an EndSim.
This provides a convenient mechanism for pull-scheduling activities to be completed by the start of the first or finish of the last push-scheduled activity, without needing to know which push-scheduled activities happen to occur first or last for a given Simulated schedule. This mechanism will, in fact, be necessary for planning such pull scheduled activities in some cases, because the identity of the first-starting and last finishing activities are usually not known when the precedence graph is composed. Their identity is only known after the push processor finishes simulating.
In view of the above description, it should now be appreciated that there exists a need to improve the reusability of the data and logic governing complex project schedules and to reduce the costs of defining complex project schedules by prior methods and systems, especially for large and complex projects like construction projects.
All publications and references cited herein are expressly incorporated herein by reference in their entirety.
In the figures of this application, in some instances, a plurality of elements may be shown as illustrative of a particular element, and a single element may be shown as illustrative of a plurality of the particular element. Showing a plurality of a particular element or step is not intended to imply that a system or method implemented in accordance with the concepts, structures and techniques described herein must comprise more than one of that element or step. Nor is it intended by illustrating a single element that the concepts, structures and techniques are limited to embodiments having only a single one of that respective element. Those skilled in the art will recognize that the numbers of a particular element shown in a drawing can be, in at least some instances, selected to accommodate the particular user needs.
It is intended that the particular combinations of elements and features in the above-detailed embodiments be considered exemplary only; the interchanging and substitution of these teachings with other teachings in this and the incorporated-by-reference patents and applications are also expressly contemplated. As those of ordinary skill in the art will recognize, variations, modifications, and other implementations of what is described herein can occur to those of ordinary skill in the art without departing from the spirit and scope of the concepts as described and claimed herein. Thus, the foregoing description is by way of example only and is not intended to be and should not be construed in any way to be limiting.
Further, in describing the concepts, structures and techniques and in illustrating embodiments of the concepts in the figures, specific terminology, numbers, dimensions, materials, etc., are used for the sake of clarity. However the concepts, structures and techniques described herein are not limited to the specific terms, numbers, dimensions, materials, etc. so selected, and each specific term, number, dimension, material, etc., at least includes all technical and functional equivalents that operate in a similar manner to accomplish a similar purpose. Use of a given word, phrase, number, dimension, material, language terminology, product brand, etc. is intended to include all grammatical, literal, scientific, technical, and functional equivalents. The terminology used herein is solely for the purpose of description and should not be construed as limiting the scope of that which is claimed herein.
Having described the preferred embodiments of the concepts sought to be protected, it will now become apparent to one of ordinary skill in the art that other embodiments incorporating the concepts may be used. Moreover, those of ordinary skill in the art will appreciate that the embodiments of the invention described herein can be modified to accommodate and/or comply with changes and improvements in the applicable technology and standards referred to herein. For example, the technology can be implemented in many other, different, forms, and in many different environments, and the technology disclosed herein can be used in combination with other technologies. Variations, modifications, and other implementations of what is described herein can occur to those of ordinary skill in the art without departing from the spirit and the scope of the concepts as described and claimed. It is felt, therefore, that the scope of protection should not be limited to or by the disclosed embodiments, but rather, should be limited only by the spirit and scope of the appended claims.