Templates/Types & Inheritance (Optional)
Starting from a set of templates
Creating Resources and Resource Sets
A note on resource types vs. resource instances
Adding a resource to a resource set
A note on activity types vs. activity instances
Defining resource requirements
A note on compound task types vs. compound task instances
Adding an Activity to a Compound Task
Aurora™ is an intelligent scheduling software solution developed by Stottler Henke, that utilizes advanced artificial intelligence in order to calculate optimal resource-constrained schedules. In addition, Aurora includes many project modeling capabilities not available in other tools that allows the model to more fully represent the real project environment.
There are many different ways to construct models in Aurora. While you can create everything from scratch, often you’ll be working from a “template” that includes pre-made definitions that will help you work more quickly. Depending on your situation you’ll want to approach this tutorial in one of a few slightly different ways: we’ve outlined a few common “paths” through the information presented here to help you get started in the way that makes most sense for your particular setup.
The following are some basic definitions that hopefully will become clearer when put in content below.
Activity: A specific unit of work, with a duration, resource requirements, a calendar, and other properties.
Entity: a thing with distinct and independent existence in the project, such as activities, resources, resource sets, calendars.
Inheritance: Deriving from a parent Template / Type.
Instance: A specific example of that general template being used.
Task: Same as Activity
Template: An abstract construct to represent a preset format for an entity, used so that the format does not have to be recreated each time it is used.
Type: A general template. A compound task type, for example, is a standard process, the series of activities necessary to complete a task.
One option when building models is to use templates for elements (for example, activity also called a task) that are mostly the same. Elements may be tasks, resources, resource sets, etc. Templates can be built from other templates (that is, inherit from another parent template) and then override some things about the original template. Aurora’s creation and editing interface supports templates and inheritance of templates from other templates. These templates are also referred to as Types, because you might build a Type of task used for painting tasks, and another Type of task for wiring. In a specific project you might use the wiring Type to create actual Instances of tasks that are the actual task that will be performed.
An element without a parent is fully independent and, when first created, inherits the system’s default properties.
An element that has a parent (another element was highlighted when you created it, and it is connected with that element from that point on) copies its initial property values directly from that parent. The inheritance link between parent and child remains active even after the child is created, so any changes to the parent’s property values will be reflected in the corresponding value of the child. However, if you directly modify one of the child’s values, the inheritance link for that property will be broken. If you edit any other properties in the parent, the change will still be reflected in the child, but if you edit the changed property in the parent, the change will not propagate.
This value propagation may be active across several generations. Suppose that you have three activities – a base activity, a child, and a child of the child (a grandchild). If you change a value in the base activity, the values will propagate to the child, following standard rules of inheritance. The changes to the child will then propagate to the grandchild.
You can leverage inheritance for a number of things: in compound tasks, you may want to make a general-case compound tasks, and then create special case children; in activities, you may want to create a general type of activities, with several variants as children; and in resources you may want to create categories of resources, and then use children as the sub-categories. In all of these cases it is desirable to be able to propagate common changes, but be able to make case-specific adaptations.
Every element in Aurora is either a type or an instance.
A compound task type might be the series of steps necessary to perform task X. A compound task instance would be the performance of task X in March, 2008. The relationship of type and instance is effectively the relation of general and specific.
The same principle applies to resource types and their instances. A resource type defines a kind of resource – a zone, etc. A resource instance defines a specific example of a resource of that type – zone LWIF on the factory floor, for example.
The differences between a type and an instance may seem fuzzy and abstract, but they have a very fundamental difference:
instances are scheduled; types are not.
Only solid things may be scheduled, things that happen or exist at a given time: hence, only instances are scheduled.
A model may be created with just instances directly, so Types, and Inheritance is NOT a requirement to build an Aurora model. This is a powerful option that is available to make building more complex models more easily
If you’re starting with a completely empty file in Aurora, you’ll need to work from the bottom up to create your schedule:
If you’ve been provided with a file containing additional pre-defined elements, e.g. resources and activities (or created your own at some point), then you can skip to the appropriate step in “Starting from scratch” and work from there. You can always go back and modify the elements that were pre-loaded in your template file- just refer to the section on editing the appropriate element type later in this tutorial.
It is easiest to import schedule information into Aurora, but if you want to add schedule information by hand, here is how you do it.
Note that we are starting with resources, because resources in reality get the project done. The goal of a scheduling tool is to allocate the resources in such a way that all the constraints of the model are satisfied while accomplishing the project in the shortest amount of time possible.
A resource is something required by an activity or another resource in order to do work or operate (e.g. manpower, space, equipment). In general, you should only model resources that are limited or constrained, as these directly influence scheduling outcomes.
Exercise: Try to make a movie showing the creation of a resource type ‘Flour’, and then also Flour_inherit and also Flour_copy. Then delete both Flour_inherit and also Flour_copy so at the end of the video it looks like the image shown in the next section with only Flour
Except where stated otherwise, the methods described below will create resource types.
Consider a bag of white flour: the resource type for a bag of white flour would represent the general properties of a bag of white flour (e.g. that it’s white and not wheat flour) but wouldn’t refer to any particular bag of white flour in the world. From this resource type, however, one could create a number of resource instances that refer to specific bags of white flour, e.g. in a particular warehouse at a particular time. For more information on this idea see “Types vs. Instances” in the Background section. To see an example click here to view a video.
To see an example of creating a resource, click here to view a video.
Resource creation is carried out in the Resources tab. If you want to create a completely new resource type, make sure nothing is selected in the resource list, then click the “New Resource” button at the bottom of the resource list.
Exercise: Please try to create a screencast where you create the resource type “Resource-type-1”, then use the “New Resource” button to create “Resource-type-1_Inherit” & then use the “Copy Resource” button to create “Resource-type-1_Independent”. Then put in some text to introduce the video and put a link to the video
If you want to base your resource type off of an existing resource, select the existing resource, then:
If you want to create a resource instance – a resource that can be allocated in the scheduling process rather than an abstract reusable resource – select the desired resource and click the “New Instance” button. Note that you can still edit instances.
Select the resource that you want to edit from the resource list. Its properties will be displayed in the central property panel.
Edit as necessary; you will probably want to change the name to be an appropriately descriptive name, and the quantity to reflect how much of that resource is available.
Some resources, though representing individual things, don’t have much use all by themselves; a nail, for example, isn’t worth much unless you also have a hammer. In Aurora, resources that should always go together can be grouped into a resource set to formalize this relationship. Resource sets consist of multiple resources that need to be reserved (and thus scheduled) for use at the same time.
Note that unlike many Aurora constructs resource sets do not have a type / instance dual-nature. All resource sets are instances, and thus can only contain resource instances.
Exercise: Try to make a movie, where first the resource type ‘Resource-1’ is created, then the resource instances ‘Resource-1-1’, ‘Resource-1.2’ & ‘Resource-1-3’ are created. Then create the resource set ‘Resource-1’ with the resources, & create the resource set ‘Resource-2;’ so we end up with the result shown in the image below.
To see an example of creating a resource set, click here to view a video
Resource set creation is carried out in the “Resource Sets” tab. Make sure that nothing is selected in the resource set list, then click the “New Resource Set” button at the bottom of the list.
To add a resource instance to a resource set (remember that resource types cannot be added), select the resource set in the resource set list and click the “Resource” button at the bottom of the list. This will pop up a dialog allowing you to choose which resource(s) you’d like to add to the set:
Note that you can select multiple resource instances by holding the shift key while clicking. You can also add the resources from another resource set by choosing them in the “By Resource Set” tab.
When you have selected the resource instance(s) you’d like to add to the resource set being edited click “OK” to add them.
Select the resource set that you want to edit from the resource set list. Its properties will be displayed in the central property panel.
Edit as necessary. Note also that you can edit the resource instances within a resource set by clicking on them in the resource set list to display their properties in the central property panel. See “Editing a resource” for more information.
An activity is a single job. You can also consider it an atomic task. In most cases, activities require a consistent set of resources throughout their duration—though exceptions may apply. They should be a logical unit in which to consider the schedule.
Except where stated otherwise, the methods described below will create activity types.
Activity types can be thought of as templates from which “real” activities (aka activity instances) can be generated.
Consider nailing two boards together: the activity type representing this action would describe the general process of using a hammer and nail to connect two boards. From this activity type one could create a number of activity instances, each of which would represent the activity of nailing two specific boards together in a particular time and place. For more information on this idea see “Types vs. Instances” in the Background section.
Activity creation is generally carried out in the Activities tab (though you can also create activities from the Add Activity dialog in the Projects tab, for now we’ll use the dedicated Activities tab). If you want to create a completely new activity type, make sure nothing is selected in the activity list, then click the “New Task” button at the bottom of the activity list.
To see an example click here to view the video.
Exercise: Try to make a movie, where the resource instances ‘Eggs Instance’ and ‘Flour Instance’ are created, then the activities ‘Add Eggs to Flour’ and ‘Whisk Eggs’ are created; then the resource is added as shown below.
If you want to base your activity type off of an existing activity, select the existing activity, then:
If you want to create an activity instance, you’ll need to do it by adding the corresponding activity type to a compound task instance, which will create an instance of that activity type in the compound task. Activity instances cannot exist alone or in a compound task type because they represent real activities carried out at actual times and in actual places, and so cannot be associated with anything but other real activities. For more information on compound tasks, see “Creating a Compound Task”.
The following information holds for editing activities within the Projects tab (in the context of a compound task) or within the Activities tab (in isolation).
To edit an activity, select it from the element list. The activity’s properties will appear in the central panel for editing.
Edit as necessary; you will probably want to change the name to something appropriately descriptive; the plot name to show an abbreviated name or identification number that you want to see on the schedule result views; the calendar to reflect the appropriate work calendar; the hour duration to indicate how long the task is expected to take – usually 85th percentile duration; and associated sub-assembly.
Select the activity that you want to edit from the element list. Its properties will be displayed in the central property panel. Within this panel select the “Requirements” tab.
You will see any existing resources with an “Add” button at the bottom. Click this button. This will open a dialog box showing all resources available for use; this includes both resource sets (groupings of interchangeable resources) at the top and resource instances (individual resources or pools of resources) at the bottom. Note that you can never add resource types regardless of whether the activity in question is a type or an instance.
Select the element that you want to include as a requirement and click the “OK” button.
You will now see the new requirement, which will assume that you need a quantity of one of the specified resource or resource set. If this is not accurate, edit the number in the property pane appropriately. Note that the quantity metric should be relative to the quantity metric used in defining the resources (e.g., if you defined a piece of space to be in square meters, you should not calculate the required quantity in square feet).
You can always delete requirements by clicking the “Delete” button (marked by a blue “X”,
to the right of the requirement.
All requirements that are lined up together are “and” requirements – all of them are required in the specified quantities in order for the schedule to be satisfied. If you need to specify an alternative set of resource requirements ((A and B and C) or (D and E)), use the “Add Additional Options…” button
at the bottom of the requirements display to add another list of requirements.
This only applies once an activity has been added to a compound task. Please see “Defining Constraints.”
A compound task is a grouping of basic tasks – activities – which go together. The compound task for baking a cake, for example, might include basic tasks for measuring ingredients, mixing them together into a batter, and putting the batter into the oven.
Except where stated otherwise, the methods described below will create compound task types.
Consider baking a birthday cake: the compound task type representing this process would enumerate the steps involved, e.g. mixing ingredients, baking in the oven for some amount of time, adding candles, etc., but wouldn’t refer to the cake for any person in particular. From this compound task type, however, one could create a number of compound task instances, each of which would describe the baking of a particular birthday cake for a particular person. For more information on this idea see “Types vs. Instances” in the Background section.
To create a new compound task type, deselect all current items in the task list, then click the ‘New Project’ button at the bottom of the task list.
If you want to base a compound task type off of an existing compound task, select the existing task, then:
If you want to create a compound task instance – a schedulable task rather than an abstract reusable task – select the desired base task and click the “Instance” button. Note that you can still add and edit activities to instances. Also note that when an instance is created of a compound task type, instances will also be created for each of the activity types in that compound task type- for more information see “Creating Instances.”
To see an example of adding activities to a compound task, click here to view a video.
Select the compound task that you want to expand (selecting an activity within the compound task will do the trick, too).
Exercise: Try to make a movie, showing what is described in this section.
To insert an activity into the compound task, click the ‘Add Activity’ button at the bottom of the list. A dialog will display all available activity types.
Note that if you haven’t yet created any activities nothing will show up in the dialog’s activity list. See “Creating an Activity” for details on creating new activities.
Select the activity you want to add (or the activity off of which you want to base your activity), and click “OK”. Note that you can select and add multiple activities by holding down the shift or control key.
The new activities will be added at the end of the task listing, under the compound task. You can now select them and edit them.
For more information, see “Editing an Activity”.
Select the compound task that you want to edit from the compound task list. Its properties will be displayed in the central property panel. Note that this works for types and instances alike.
Edit as necessary; you will probably want to change the name to be an appropriately descriptive name. Optionally, adjust the ‘Early Start Date’ to define the earliest allowed start time, and the ‘Late End Date’ to set the latest permissible completion time, (e.g., a delivery date). Note that altering these dates will propagate to any activities if their dates lie outside of these bounds.
A constraint is a relationship defined between two activities. The most common kind of constraint (the type we will discuss here) is a temporal constraint, which defines a temporal relationship between two activities.
Make sure that you are in the Activities tab, and that there are at least two activities available for constraint. If you are planning to define a constraint between activities in different compound tasks, the compound tasks (and hence activities) involved should be instances rather than types.
To see an example of defining a constraint, click here to view a video.
Exercise: See if you can make a video showing these steps
Select the activity that you want to edit from the task list. Its properties will be displayed in the central property panel. Within this panel select the “Constraints” tab.
You will see any existing constraints with “Add” and “Delete” buttons at the top. Click the “Add” button.
The Constraint Wizard dialog will open, offering three configuration tabs: ‘Flow Types,’ ‘Resource Instances,’ and ‘Activity Types.’ Click the “Activity Types” tab to display all existing activity types with the current activity italicized and highlighted in red. Find the target activity in this list, and select it. Click “Next”.
You will now see a display showing the available types of constraints. Select “Temporal Constraint” if it is not already selected.
The first property in this new display (below the constraint type combo box) allows you to select the temporal constraint type. The default “Normal” selection indicates that this temporal constraint relates the start or end time of the first activity to the start or end time of the second activity.
Selecting “Normal” in the temporal constraint type combo box enables the activity relationship property combo box directly below it, by default set to Finish <= Start. This property defines the exact nature of the temporal relationship between the two activities. Finish <= Start means the first activity must end before the second activity can begin. Mathematically this can be represented by the equation:
finish(first) <= start(second).
Note that the first activity is the activity you set out to edit.
Next, Offset allows you to introduce slack time into the temporal relationship. Finish <= Start with an offset of one hour, for example, means that the start of the second activity should occur within at most one hour of the finish of the first activity. Or, mathematically:
finish(first) + offset <= start(second)
You can ignore the “bridging constraint” and “Importance” options for now.
The enforce property simply determines whether or not this constraint is active or not: un-checking this will cause Aurora to act as if the constraint doesn’t exist, so we’ll leave it checked for now.
Importance indicates whether this is a soft constraint; ignore this property if this constraint should never be violated.
Click “Create Constraint” to finish.
Each of the three primary data elements in Aurora (compound tasks, activities, and resources) can exist as types, instances, or both, e.g. the compound task type “bake a birthday cake” vs. the compound task instance “bake Jim’s birthday cake,” the resource type “a dozen eggs” vs. the resource instance “the dozen eggs in my refrigerator,” etc. This flexibility is designed to give users maximum power in the creation of models representing their domains. When the models are complete and it’s time to generate a schedule, however; instances are all that matter.
Because a schedule is only useful if it describes real things, compound task, activity, and resource types become meaningless when scheduling. It’s important, therefore, that every compound task, activity, and resource you’d like to be included in your schedule exists in Aurora as an instance, not just a type. It’s fine to have both – an activity type and an activity instance based on that type, for example – but unless at least one instance of a type element exists, that element will be completely ignored.
The processes for creating instances of compound tasks, activities, and resource types are described in the same sections that detail the creation of those types; you can refer back to those sections for specific details. There is one point that bears repeating here, though, and that relates to the creation of compound task instances: when an instance is created of a compound task type, instances will also be created for each of the activity types in that compound task type. This makes sense because a compound task instance (a “real” collection of activities) must contain only “real” activities.
From the Schedule menu, click “Schedule.”
This will pop up a dialog with a few simple scheduling options, this will vary with different versions of Aurora:
The Duration property determines how temporally compact the resulting schedule will be- choosing “Aggressive” will generate the shortest possible schedule using the “aggressive duration” times for all activities, while choosing “Safe” will use the corresponding “safe duration” times to generate a more lenient schedule.
You can use the two checkboxes at the bottom of the dialog to automatically display a summary of the generated schedule once it is complete, and to hide any warnings that might be generated during scheduling, respectively.
Click “OK” to generate a schedule.
Once a schedule has been generated, there are a number of different ways to visually explore the results. You can use the many displays built into Aurora to visualize a schedule’s timeline, see how specific resources are being utilized, or carry out just about any other analysis you might be interested in.
We won’t get into the details of every display Aurora has to offer; instead we’ll focus on three of the most commonly used (and most useful) displays: the Gantt chart, and the Spatial and Histogram resource plots.
While the many displays available in Aurora look and act quite differently from one another, there are a few basic navigational techniques that apply to all of them.
The Gantt chart is a timeline-based view that displays scheduled activities according to their start and end times.
An example Gantt chart is shown above. The X-axis represents time (increasing from left to right), and activities are drawn as rectangles with start points and lengths corresponding to their start dates and completion times respectively. Activities that overlap in time (i.e., activities that occur simultaneously for some or all of their duration) are stacked vertically, leading to a general trend (with the default display settings) of activities being drawn from the chart’s upper-left towards its lower-right.
To display the Gantt chart for your schedule, click the “Displays” menu item and choose “Gantt Chart.”
A new tab will be created displaying the Gantt chart for your schedule. To close the Gantt chart tab, right click it and select “Close.”
Resource plots show how the resources in your model are utilized over time. The spatial plot display is most useful for visualizing the utilization of unitary resources, i.e., resources that are either in use or not in use (like a milling machine) as opposed to resources that can be used partially (like a group of workers).
To create a spatial plot, select “Spatial Plot” from the “Displays” menu item in the main Aurora window. The newly created plot will initially be empty; you’ll need to specify exactly which resources or resource sets you’d like to see displayed. To do this, click the element selection button in the toolbar at the top of the display panel:
This will bring up a dialog that will allow you to add resources to the display.
Resources in the right-hand pane of this dialog will be displayed in the spatial plot. To add a resource, select it in the left-hand pane and click the “Add” button at the bottom of the pane. Note that you can also add entire resource sets in the “By Resource Set” tab, or choose resources by the activities that utilize them in the “By Task” tab.
When you’ve added all the resources you’re interested in plotting, click “OK” in the dialog to draw the plot.
An example spatial plot showing two resources is shown above. The X-axis represents time (increasing from left to right), and each resource is assigned to its own row. Utilization is indicated by a blue box in the resource’s row (representing an activity that uses the resource), the width of which indicates the span of time that the resource is in use. Double clicking on the box will pop up a dialog showing the properties of the activity it represents.
You can see that the spatial plot makes it easy to see how often a resource is used, both in general and compared to other resources in your schedule.
Resource plots show how the resources in your model are utilized over time. The histogram resource plot is most useful for visualizing the partial utilization of resources that can be “split up,” e.g. a work crew consisting of multiple people each of whom can carry out a different task.
To create a histogram plot, select “Histogram Plot” from the “Displays” menu item in the main Aurora window. The newly created plot will initially be empty; you’ll need to specify exactly which resources or resource sets you’d like to see displayed. To do this, click the element selection button in the toolbar at the top of the display panel:
This will bring up a dialog that will allow you to add resources to the display.
Resources in the right-hand pane of this dialog will be displayed in the histogram plot. To add a resource, select it in the left-hand pane and click the “Add” button at the bottom of the pane. Note that you can also add entire resource sets in the “By Resource Set” tab, or choose resources by the activities that utilize them in the “By Task” tab.
When you’ve added all the resources you’re interested in plotting, click “OK” in the dialog to draw the plot.
An example histogram plot showing one resource is display above. The X-axis represents time (increasing from left to right), and each resource is assigned to its own row. Within a row, utilization amount is represented on the vertical axis, with the top of the row indicating the maximum amount of the resource. The background color indicates the availability of the resource: a white background indicates that the resource (or some amount of the resource, depending on the span of the color) is available, while a blue background indicates that it is unavailable. Black boxes represent activities utilizing a resource, with the width of the box indicating the span of usage time and height representing the amount of the resource in use.
Clicking on boxes in the histogram display will show the activities that utilize the resource during the periods spanned by the box. Double clicking on an activity will bring up a dialog displaying its properties.
Most of the creation and editing interface behavior is governed by inheritance. An element without a parent will be completely independent, and when first created will have the system’s default values. An element that has a parent (another element was highlighted when you created it, and it is connected with that element from that point on) copies its initial property values directly from that parent. The connection between parent and child remains open even after the child is created, so any changes to the parent’s property values will be reflected in the corresponding value of the child. If, however, you directly edit one of the child’s values, the connection with the parent will be broken for that property only. If you edit any other properties in the parent, the change will still be reflected in the child, but if you edit the changed property in the parent, the change will not propagate.
This value propagation may be active across several generations. Suppose that you have three activities – a base activity, a child, and a child of the child (a grandchild). If you change a value in the base activity, the values will propagate to the child, following standard rules of inheritance. The changes to the child will then propagate to the grand child.
You can leverage inheritance for a number of things: in compound tasks, you may want to make a general-case compound tasks, and then create special case children; in activities, you may want to create a general type of activities, with several variants as children; and in resources you may want to create categories of resources, and then use children as the sub-categories. In all of these cases it is desirable to be able to propagate common changes, but be able to make case-specific adaptations.
All elements in Aurora are either types or instances. A type is a general template. A compound task type, for example, is a standard process, the series of activities necessary to complete a task. An instance is a specific example of that general template being used. A compound task type might be the series of steps necessary to perform task X. A compound task instance would be the performance of task X in March, 2008. The relationship of type and instance is effectively the relation of general and specific.
The same idea holds for resource types and instances. A resource type defines a kind of resource – a zone, etc. A resource instance defines a specific example of a resource of that type – zone LWIF on the factory floor, for example.
The differences between a type and an instance may seem fuzzy and abstract, but they have a very fundamental difference: instances are scheduled; types are not. Only solid things may be scheduled, things that happen or exist at a given time: hence, only instances are scheduled.
Please enter your contact details, company name and a short message below and we will answer your query as soon as possible.
Contact Us