Jobs
A Job is a request for the shop to produce one or more products by a specific time. The Job is the top-level object that is dealt with in APS.net scheduling. Each Job contains information such as a Need Date, Customer, Priority, etc. as well as one or more Manufacturing Orders.
This is a graphical overview of the Job Structure.
Manufacturing Order (M.O.)
A Manufacturing Order is a request to manufacturing a specific quantity of a specific Product. Each Job contains one or more Manufacturing Orders. Each Manufacturing Order contains one or more Operations and one or more Alternate Paths that describe the sequence in which Operations should be performed.
Operation
An Operation is a definition of a single processing step in a Manufacturing Order. The Operation specifies values such as the Cycle Time, Setup Time, expected Yield, Resource Requirements, Material Requirements, etc. Each Manufacturing Order contains one or more Operations. Operations can be “connected” to establish Predecessor/Successor relationships using the Alternate Path of the Manufacturing Order.
Primary and Helper Resource Requirements
An Operation can specify one or more Resource Requirements — one for every Resource that is needed to perform the Operation. If an Operation, for example, requires a CNC machine and a CNC operator then the Operation would have two Resource Requirements — one specifying a Capability such as CNC and one specifying a Capability such as CNC-Operator.
Every Operation has exactly one Primary Resource Requirement. This is the one that determines the duration of each of the portions of an Activity (Setup, Run, and Post Processing). If an Activity is scheduled across an offline time then the duration of the Activity is lengthened to account for that inactivity. If an Operation has multiple Resource Requirements then the non-Primary Requirements are considered to be Helper Resource Requirements. The main difference is that these do not determine the duration of the Activity, they are scheduled according to the times on the Primary Resource. They must be available during the entire duration of the Activity as specified by the Primary Resource Requirement.
Typically if multiple Resources are required for an Operation, the labor defines the Primary Requirement since people have Capacity Intervals indicating their work hours. A machine could therefore be defined as a Helper Requirement since it is available continuously or usually at least more continuously than are people. However, if the machine will determine the length of the Activity (for example if using sequence-dependent setup) then the Primary Resource must be the machine since only the Primary Resource determines the Activity duration.
Material Requirement
A Material Requirement specifies a raw material that is needed to perform an Operation. Material Requirements can be specified as Constraints to prevent the Activities that require the material from scheduling to start before the material is expected to be available.
Activity
An Activity is the smallest unit of work to be scheduled. Each Operation has one Activity unless it has been Split into multiple. It specifies the Production Status, Reported Qty, Reported Time, etc.
Block / Resource Usage
A Block refers to a rectangle on the Gantt Charts representing a Resource Usage of a specific Activity on a specific Resource. The two terms, Block and Resource Usage are used interchangeably. The Resource is considered to be used by the Activity during the duration of the Block (excluding Offline Intervals over which the Block is stretched of course). The start time of the Block indicates the time when the Resource will start working on the Activity. The end time of the Block indicates the time when the Resource will stop working on the Activity. The Duration of the Block is the difference between its start and end time. The Work Content however, may be less than the Duration since the Block may span one or more Offline Capacity Intervals.
Successor Operations
A Successor Operation is an Operation in the same Manufacturing Order that requires material from a given Operation — the Predecessor Operation. This relationship is defined in the Alternate Path for the Manufacturing Order. A Successor Operation cannot schedule to start until the Predecessor Operation is complete (or partially complete if the Overlap option is used).
Successor Manufacturing Orders
A Successor Manufacturing Order is a Manufacturing Order from the same or different Job that requires material from a given Manufacturing Order. The Successor Manufacturing Order cannot schedule to start before the material will be available from the Predecessor MO.
Alternate Path
An Alternate Path specifies the precedence relationships between Operations thus indicating the path that is followed through the shop to produce a product. Each Manufacturing Order specifies one or more Alternate Paths and exactly one Default Path. When the M.O. is scheduled, the Default Path is used. A Path and converge and diverge, meaning that one Operation can have multiple Successors and multiple Predecessors.
Alternate Path Node
Each Alternate Path is made up of one ore more Nodes. Each node specifies an Operation and (optionally) one ore more Successor Operations for that Operation.
Alternate Path Association
An Alternate Path Association stores values that pertain to the association between an Operation and one Successor Operation in the Path.
Factory Model
Plant
A Plant is a representation of a physical plant/factory. It contains one or more Departments. Each Department belongs to exactly one Plant. Every system must have at least one Plant in order to schedule Jobs. The Enterprise Edition of APS.net can have any number of Plants and Jobs can be defined to be schedulable in only one Plant or spanning multiple Plants.
Department
A Department usually represents a physical department within a factory. Each Department contains Resources. Each Resource belongs to exactly one Department. Each Department’s Resources are displayed together in the Gantt and can have their schedules printed together in reports. Since Departments have no effect on the scheduling process itself, it is best to think about how you want to view your Resources and then setup your Departments accordingly.
Resource
Resources represent machines, people, subcontractors, teams, tools, or any other thing that is used temporarily to perform an operation. Materials are not Resources since they are “consumed” rather than used temporarily. Each Operation in a Job has one or more Resource Requirements, each of which specifies the need for another additional Resource in the production process. Each Resource belongs to exactly one Department.
Capability
A Capability is a specification of a skill or function that can be performed by a Resource. For example, a Capability might be “cutting” or “inspection”. Each Resource has one or more Capabilities that indicate the types of work that it can perform. In addition, each Job Operation Resource Requirement has one ore more required Capabilities indicating the Capabilities that a Resource must have to be considered eligible to perform the Operation. If an Operation, for example, requires a CNC machine and a CNC operator then you would create two Capabilities such as: CNC and CNC-Operator. Then the Operation would have two Resource Requirements — one specifying CNC and one specifying CNC-Operator.
Capacity Interval
Defines an interval of time over which the capacity to do work is affected. Capacity Intervals determine when a Resource is available and how much work can be done over each time span. Capacity Intervals are used to specify Normal Online time, Offline Time, Overtime and Potential Overtime.
If a Capacity Interval is “recurring” then it affects the capacity of multiple time intervals instead of just one. Capacity Intervals are assigned to Resources via the Gantt Chart. Once a Capacity Interval is created and linked to one Resource, it can be “shared” among other Resources by dragging and dropping it on another Resource.
Note that if a Resource has no Capacity Intervals specified then it is assumed to be online at all times. Also, every Resource is assumed to be continuously online after the last Capacity Interval on the Resource so that Activities can always be scheduled.
Eligible Resource
Each Operation has a list of Resources that are considered “eligible” to perform the work. This eligibility is based on the Resource Requirements of the Operation. Each Resource Requirement has a list of Capabilities that a Resource must possess in order to be considered eligible. The Resource must possess ALL of the specified Capabilities to be considered eligible. The system will only schedule Operations on the Resources that are eligible and will only allow manual moving of Operations onto eligible Resources.
Simulation & Optimization
Dispatcher
A Dispatcher provides a means for a Resource to select which Activity to work on next during an Optimization. Specifying Dispatchers is very important since it drives all automatic scheduling decisions and therefore can have a big impact on the quality of schedules created by Optimizations.
Simulation
APS.net creates schedules by simulating the passing of time and reacting to events that are expected to happen at specific times. It is this detailed, time-based method of event processing that is used in Optimizations and all other schedule adjustments to enforce constraints.
System
Scenario
A Scenario contains all of the data associated with one schedule, including:
- Plants
- Departments
- Resources
- Capabilities
- Capacity Intervals
- Recurring Capacity Intervals
- Dispatcher Definitions
- Jobs
- Scenario History
There are three types of Scenarios:
- Live: There is always one Live Scenario. This is the Scenario that is being worked on by the Master Schedulers.
- What-If: There can be zero or more What-If Scenarios. These are used to experiment with the schedule without affecting the Live Scenario. You can later convert a What-If Scenario to a Live Scenario or you can Delete it.
- Published Scenario: This is optional and there can be at most one. If created, this is used to prevent View-only users from seeing the Live Scenario while it is being worked on by the Master Schedulers.
Whenever data is imported into the system using the APS.net Interface or a custom program that creates APS.net Transmissions, all of the Scenarios are updated. Therefore if, for example, a new Job is added in your ERP system and the Interface is run, the new Job will appear in all Scenarios. This is necessary to allow for any Scenario to be converted to the Live/Published Scenario at any time (Otherwise the new Job would be lost when a What-If Scenario for example was converted to the Live Scenario).
Clock
The APS.net Clock indicates the date and time that is treated as the beginning of the schedule, or the “current time” as far as APS.net is concerned. All Activities that have remaining work are scheduled after the Clock time. Only finished work will ever appear “in the past” (before the Clock). The Clock can be, and usually is, set to a time that is different from (usually before) the PC clock. This allows for batch update of status information such as work completions prior to indicating to the system that time has passed. Otherwise the schedule would indicate that time has passed without having completed the work and therefore that expected completion dates of other activities would be postponed due to capacity shortages or predecessor constraints.
Horizons
Planning Horizon
Anything beyond the Clock plus this Span is considered to be unimportant in the scheduling function. The schedule can extend past this time but optimization algorithms are often designed to stop detailed planning past this time. All reasources are considered to be continuously available beyond this time.
Frozen Span
Specifies the amount of time from the Clock time that no schedule changes should be made. The purpose of this is to provide stability on the shop floor in the short term especially when logistics require it. This can be used during Optimizations to prevent scheduled changes within this time period. Manual changes can be made during this time but should be kept to an absolute minimum.
Stable Span
This time span begins at the end of the FrozenSpan. It signifies the period of the schedule, in addition to the FrozenSpan, that should be changed as little as possible in order to provide stability to the users of the schedule. It serves as a visual guideline and global Optimizations can be set to start outside of this period.
Short-term Span
Time span from the Clock that constitutes the ‘short range’ schedule. This can be used by various scheduling and statistical functions.
Keep-feasible Span
Specifies the amount of time from the Clock time that all Constraints must be enforced to ensure a feasible schedule for production to follow. Outside of this time period, predecessor and material constraints can be overriden if the resource is allowed to pre-empt such constraints.
Miscellaneous
ERP System
ERP (Enterprise resource planning) is an industry term for the broad set of activities supported by multi-module application software that helps a manufacturer or other business manage the important parts of its business, including product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service, and tracking orders. ERP can also include application modules for the finance and human resources aspects of a business. Typically, an ERP system uses or is integrated with a relational database system.
Scenario History
A Scenario History is a log that can be stored in the system to make it easier to keep track of recent events and to trace back to the origin of a change. A Scenario History is recorded for each Transmission received by the system as well as for various special events such as the finishing of an Activity or the entry of a new Job. Scenario Histories are used to populate the Scenario History pane, the Demand Monitor pane, the Execution Monitor pane, and the various object Histories that are shown in the Properties Detail window.
Transmission
Whenever any change is made to the system’s data, either manually in the APS.net Client or via an external interface, this change is made using a Transmission. Each Transmission contains information about what action should be performed as well as the data needed to perform that action. An example of a Transmission is a JobT — a Job Transmission. Each JobT contains a list of Job definitions to update the Jobs in the system.
Break Off
A Break Off refers to creating a new Job that produces some of the units originally included in some larger Job. For example, suppose there is a Job for 100 widgets due on Jan 30th but the customer now wants 10 of those units delivered as soon as possible. You could create a Break Off by creating a new Job for 10 of those units and reducing the other Job to the remaining 90 units. This allows the smaller Job to be scheduled and tracked independently of the original Job.