Patent Application
20230297089
This disclosure is generally directed to production scheduling systems. More specifically, this disclosure is directed to a resource-task network (RTN)-based templated production schedule optimization (PSO) framework.
Production scheduling generally refers to the process of determining how processing units in a processing or manufacturing plant will be used to produce one or more materials or other products. The processing units typically represent equipment that can be used to perform specific processing functions on one or more materials. For example, production scheduling may involve determining how equipment in a chemical manufacturing plant will be used to produce chemical products or how equipment in a food processing factory will be used to produce food products. Production scheduling for a plant or a portion thereof typically involves dictating the production schedule (such as by defining one or more products to be produced, quantities of the one or more products to be produced, and timing of the one or more products to be produced) for the processing units contained in the plant or the portion thereof over a forward-looking scheduling horizon.
This disclosure relates to a resource-task network (RTN)-based templated production schedule optimization (PSO) framework.
In a first embodiment, a method includes using templates to identify constraints and terms of at least one objective function associated with at least a portion of one or more processing targets. At least one of the templates is based on an RTN representation of resource nodes and task nodes associated with at least the portion of the one or more processing targets. The method also includes generating one or more optimization problems, where the constraints and the at least one objective function represent at least part of the one or more optimization problems. The method further includes generating at least one candidate production schedule for at least the portion of the one or more processing targets using the one or more optimization problems.
In a second embodiment, an apparatus includes at least one processing device configured to use templates to identify constraints and terms of at least one objective function associated with at least a portion of one or more processing targets. At least one of the templates is based on an RTN representation of resource nodes and task nodes associated with at least the portion of the one or more processing targets. The at least one processing device is also configured to generate one or more optimization problems, where the constraints and the at least one objective function represent at least part of the one or more optimization problems. The at least one processing device is further configured to generate at least one candidate production schedule for at least the portion of the one or more processing targets using the one or more optimization problems.
In a third embodiment, a non-transitory computer readable medium stores computer readable program code that, when executed by one or more processors, causes the one or more processors to use templates to identify constraints and terms of at least one objective function associated with at least a portion of one or more processing targets. At least one of the templates is based on an RTN representation of resource nodes and task nodes associated with at least the portion of the one or more processing targets. The non-transitory computer readable medium also stores computer readable program code that, when executed by the one or more processors, causes the one or more processors to generate one or more optimization problems, where the constraints and the at least one objective function represent at least part of the one or more optimization problems. The non-transitory computer readable medium further stores computer readable program code that, when executed by the one or more processors, causes the one or more processors to generate at least one candidate production schedule for at least the portion of the one or more processing targets using the one or more optimization problems.
Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
For a more complete understanding of this disclosure, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
As noted above, production scheduling generally refers to the process of determining how processing units in a processing or manufacturing plant will be used to produce one or more materials or other products. The processing units typically represent equipment that can be used to perform specific processing functions on one or more materials. For example, production scheduling may involve determining how equipment in a chemical manufacturing plant will be used to produce chemical products or how equipment in a food processing factory will be used to produce food products. Production scheduling for a plant or a portion thereof typically involves dictating the production schedule (such as by defining one or more products to be produced, quantities of the one or more products to be produced, and timing of the one or more products to be produced) for the processing units contained in the plant or the portion thereof over a forward-looking scheduling horizon.
Unfortunately, production schedule optimization (PSO) typically involves a custom formulation for each new industrial use case. For example, prior PSO approaches typically use detailed optimization formulations and algorithms for specific facilities or use cases, such as specific chemical plants or specific food processing factories. As a result, these approaches tend to focus only on a specific industry, and these approaches are relatively rigid and lack extensibility and adaptability to new use cases. Moreover, this can make it labor-intensive, time-consuming, and costly to implement production schedule optimization for a new use case, which can delay or prevent the use of production schedule optimization for the new use case.
This disclosure provides an apparatus, method, and computer readable medium supporting a resource-task network (RTN)-based templated PSO framework. As described in more detail below, a templated PSO framework that supports the use of a resource-task network is disclosed. The RTN-based templated PSO framework can be used to formulate a production schedule optimization problem based on a resource-task network, which can be industry- or use case-agnostic. As a result, the RTN-based templated PSO framework can be abstracted and can support a “plug-and-play” type of functionality, which allows the RTN-based templated PSO framework to be used for production schedule optimization across a wide range of industries. In other words, the RTN-based templated PSO framework is not limited to a specific optimization procedure or use case. Also, the RTN-based templated PSO framework can provide plug-and-play templates of constraints, variables, and objective functions, and the RTN-based templated PSO framework can be configured to optimize the framework for large-scale problems (such as those involving multiple interconnected facilities) using techniques like model decomposition and simplification that preserve accuracy. Because of this, the RTN-based templated PSO framework can ease the process of providing accurate results across various organizations, including complex organizations such as those with interconnected networks of facilities. Further, the RTN-based templated PSO framework is not limited to any specific optimization procedure (such as multiple-stage, two-stage, or single-stage approaches), thereby supporting use in a wide range of applications. In addition, the RTN-based templated PSO framework can integrate with state-of-the-art custom or standard optimization solvers.
Overall, these approaches allow different RTN-based templated PSO frameworks to be customized for use with different industries or use cases much faster compared to prior approaches. Moreover, the RTN-based templated PSO framework handles the optimization of production scheduling in a generic way so that it is generally applicable to various settings under different business constraints across different industries. In addition, the RTN-based templated PSO framework allows users to formulate optimization problems to their business settings with minimal effort.
Example embodiments of an RTN-based templated PSO framework are described below. Note that the specific details provided below are for illustration only and can vary as needed or desired. For instance, specific equations and use cases are provided below, and these equations and use cases may be modified as needed or desired. As a particular example, while use in the food processing industry may be described below, the RTN-based templated PSO framework may be used in any other suitable application. Also note that while the RTN-based templated PSO framework may be described as being used for production scheduling involving processing units in a plant or across multiple plants, the RTN-based templated PSO framework may be used for production scheduling involving any suitable subset of processing units in one or more plants
The network 104 facilitates communication between various components of the system 100 For example, the network 104 may communicate Internet Protocol (IP) packets, frame relay frames, Asynchronous Transfer Mode (ATM) cells, or other suitable information between network addresses. The network 104 may include one or more local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of a global network such as the Internet, or any other communication system or systems at one or more locations. In some cases, the network 104 may represent an internal or private network used by an owner or operator of one or more processing or manufacturing plants
The application server 106 is coupled to the network 104 and is coupled to or otherwise communicates with the database server 108. The application server 106 supports the use of the RTN-based templated PSO framework described below. For example, the application server 106 may execute one or more applications 112 that use data from the database 110 to perform production schedule optimization using the RTN-based templated PSO framework. Note that the database server 108 may also be used within the application server 106 to store information, in which case the application server 106 may store the information itself used to perform production schedule optimization.
The database server 108 operates to store and facilitate retrieval of various information used, generated, or collected by the application server 106 and the user devices 102a-102d in the database 110. For example, the database server 108 may store various information related to customer product orders and other information used during production schedule optimization. The database server 108 may also store results produced during the production schedule optimization.
In this example, at least some of the information used by the application server 106 and/or stored in the database 110 may be received over at least one additional network 114 from one or more customer systems 116a-116n. For example, the network 114 may represent a public data network (such as the Internet) or other network that allows the one or more customer systems 116a-116n to provide information to and receive information from the owner or operator of one or more processing or manufacturing plants. As a particular example, the one or more customer systems 116a-116n may be used by customers to provide order information or other information to the owner or operator of the processing or manufacturing plant(s), where that information can be used by the application server 106 to perform production schedule optimization.
A determined production schedule produced by the application server 106 may be used in any suitable manner. For example, the determined production schedule may be presented to one or more users, such as via one or more of the user devices 102a-102d The one or more users may review the determined production schedule, make changes to the determined production schedule, or perform other actions using the determined production schedule. The determined production schedule may also or alternatively be used by the application server 106 or other device to automatically schedule operations to be performed to produce one or more products or control operations being performed to produce one or more products. In general, one or more production schedules may be used in any suitable manner with or without user interaction.
Although
As shown in
The memory 210 and a persistent storage 212 are examples of storage devices 204, which represent any structure(s) capable of storing and facilitating retrieval of information (such as data, program code, and/or other suitable information on a temporary or permanent basis). The memory 210 may represent a random access memory or any other suitable volatile or non-volatile storage device(s). The persistent storage 212 may contain one or more components or devices supporting longer-term storage of data, such as a read only memory, hard drive, Flash memory, or optical disc.
The communications unit 206 supports communications with other systems or devices. For example, the communications unit 206 can include a network interface card or a wireless transceiver facilitating communications over a wired or wireless network, such as the network 104 or 114. The communications unit 206 may support communications through any suitable physical or wireless communication link(s).
The I/O unit 208 allows for input and output of data. For example, the I/O unit 208 may provide a connection for user input through a keyboard, mouse, keypad, touchscreen, or other suitable input device. The I/O unit 208 may also send output to a display, printer, or other suitable output device. Note, however, that the I/O unit 208 may be omitted if the device 200 does not require local I/O, such as when the device 200 represents a server or other device that can be accessed remotely.
Although
As shown in
Within the one or more processing or manufacturing plants (or one or more portions thereof), various processing units 306 can be used to process the one or more raw materials 302 or the one or more intermediate products. Each processing unit 306 represents equipment or other assets that can be used to manufacture or process one or more materials in order to perform one or more tasks In some cases, one or more processing units 306 may be used to represent one or more tasks performed by human personnel, such as when one or more employees or other people perform one or more tasks manually (which may or may not involve the use of monitored or other equipment). The task or tasks performed by each processing unit 306 can vary depending on the application. Flows of various intermediate or work-in-progress (WIP) materials 308 are also shown in
Scheduling problems are often solved by transforming the scheduling problems into optimization formulations. For example, a resource-task network (RTN) proposed in Pantelides, “Unified Frameworks for Optimal Process Planning and Scheduling,” Proceedings of the Second International Conference on Foundations of Computer-Aided Process Operations, July 18-23, 1993, pages 253-274 (which is hereby incorporated by reference in its entirety) represents a general scheduling problem in multi-purpose facilities using a connected graph with resource nodes and task nodes. The resource-task network 350 shown in
Resource-task networks can be defined for any suitable arrangement of resources and tasks associated with a single facility or multiple facilities. Also, the resource-task networks may or may not include tasks related to transportation between facilities. For example, in some embodiments, a resource-task network may be defined for an arrangement 370 as shown in
Although
As noted above with respect to
Each constraint template 406 may be expressed in any of a variety of formats, such as discrete-time, continuous-time, two-phase, one-phase, soft or hard, etc. Hard constraints represent constraints that cannot be violated, while soft constraints represent constraints that may be violated (but the extent of the violation is treated as a cost in an objective function). Each constraint template 406 can be used to create various embodiments 408 of that constraint template 406. Different embodiments 408 of the same constraint template 406 may implement the same underlying constraint and can be interchanged based on implementation needs, such as when different embodiments 408 of a constraint template 406 are associated with different domains 410. The domains 410 may represent different use cases or applications, such as when the domains 410 are associated with chemical, pharmaceutical, oil, pipeline, food, dairy, consumer good, manufacturing, steel, paper, and/or other industries. Note that when physical or business rules are embodied into specific constraints (via the embodiments 408 of the constraint templates 406) for each domain 410, variables associated with those constraints can also be generated dynamically. Moreover, the embodiments 408 of the constraint templates 406 can be compatible with additional auxiliary constraints in each domain 410. This indicates that not all constraints in a final formulation need to come from constraint templates 406, and users can have the flexibility to choose which of the constraints come from constraint templates 406 (more generality and less implementation effort) and which ones of the constraints are domain-specific (more flexibility and more implementation effort).
In this particular example, two constraint templates 406 are provided, which are referred to as template a and template b. Each constraint template 406 may be embodied into one or more constraint embodiments 408, which in this example include constraint embodiments a1, a2, a3 and constraint embodiments b1, b2, b3, respectively. Each constraint embodiment 408 has associated variables, which in this example are denoted as variable sets a1, a2, a3 and variable sets b1, b2, b3, respectively. Note that the same constraint template 406 could result in different types of constraint embodiments 408, such as linear, bilinear, quadratic, or integer constraint embodiments 408. For each nonlinear constraint embodiment 408 (such as bilinear, quadratic, or integer constraint embodiments 408), there could be an extended embodiment 408′ (which in this example are denoted as a2′ and a3′) that simplifies the original embodiment 408. The simplifications represented by the extended embodiments 408′ may be useful when discussing decomposition or simplification techniques that this disclosure enables.
For the terms in the objective function, a similar process can be applied. For example, the optimization objectives section 404 allows objective terms to be expressed using one or more objective templates 412. Any suitable objective templates 412 may be used here, such as objective templates related to revenue, cost, customer satisfaction, environmental footprint, etc. Note that each of these objective templates 412 need not simply be used to look up values for these objectives but may instead include one or more complex dynamic elements, instructions, or functions (such as an equation) that can be used for a domain or an optimization objective. Multiple terms can be generated using multiple objective templates 412 and appended to an objective function in order to handle multi-objective optimization problems. Each objective template 412 can be linked to a specific subset of components (such as nodes and edges) in a resource-task network, such as when revenue is linked to a subset of resource nodes that represent sellable products Embodiments 414 of the objective templates 412 define exact formulations that convert the objective templates 412 into objective terms. Variables associated with each term in the objective function can be generated at the same time. In the specific example shown in
For a specific domain 410, embodiments 408 and 414 of the constraints and terms in the objective function can be selected to generate a final formulation of an objective function for that specific domain 410. For example, in a first domain 410 (such as a food industry with a discrete-time formulation and a two-stage procedure), constraint embodiments a1 and b1 may be selected, along with two domain-specific constraints called “auxiliary constraint 1” and “auxiliary constraint 2” in this example. Also, objective term embodiments α1 and β2 may be included in the objective function, along with a domain-specific term called “auxiliary objective 1.” Finally, the variable sets associated with the constraints and objective terms can be reconciled (as described below) to ensure that each variable is constrained by a set of constraints and there are no conflicts between variables, which leads to the generation of a final set of variables. Note that the templates 406 and 412 for constraints and terms in the objective function described above are formulation- or procedure-agnostic, which means that their embodiments 408 and 414 can be applied across time-continuous formulations, time-discrete formulations, single-phase procedures, multiple-phase procedures, etc.
The following provides two examples of how physical or business rules may be used as templates and how those templates may be embodied into specific constraints. The first example is a material balance template, and the second example is an expiration template.
Based on this, an expiration rule can be represented by an inequality that keeps cumulative consumption always above cumulative expiration (ideally for all consumable resources in a resource-task network)
Note that in the examples shown in
As can be seen here, it is possible for users to define a complete optimization formulation by defining one or more embodiments 408 of one or more constraint templates 406 and by defining one or more embodiments 414 of one or more objective templates 412. As particular examples of the one or more embodiments 408 of the one or more constraint templates 406, a user may define one or more material constraints and one or more capacity constraints. Each material constraint is associated with one or more resource nodes 352 and could be defined using an associated constraint template 406. One example of a material constraint is a raw material balance constraint. Each capacity constraint is associated with one or more task nodes 354 and could be defined using an associated constraint template 406. One example of a capacity constraint may define operating hours during which the one or more associated task nodes 354 may operate. As particular examples of the one or more embodiments 414 of the one or more objective templates 412, a user may define one or more cost terms and one or more value terms Each cost term is associated with one or more task nodes 354 and could be defined using an associated objective template 412. Examples of cost terms could include production costs, labor costs, changeover costs (costs associated with switching from producing one product to another product), and/or utility costs. Each value term is associated with one or more resource nodes 352 and could be defined using an associated objective template 412. Examples of value terms could include revenue, margin, profit, sales value of production (SVOP), and/or fill rate. Thus, it may be relatively easy for users to define complete optimization formulations using a limited number of embodiments 408, 414 for a limited number of constraint templates 406 and objective templates 412.
Note that, in some embodiments, the constraint templates 406 can represent processing unit-level templates, such as when the constraint templates 406 are associated with processing units 306 Also, different templates 406 can be associated with different types of processing units 306. In these embodiments, the templates 406 may be highly disparate since the processing units 306 may be distinctly different. Even in these cases, however, the same template 406 or templates 406 may be used multiple times, such as to create multiple embodiments 408 of the same template 406 or templates 406 in different domains 410.
Although
After all embodiments of constraints, terms, and variables associated with an objective function are generated, conflicts and redundancies in the variables can be automatically reconciled in order to produce a complete optimization formulation. In some cases, this allows the complete optimization formulation to be solved by an off-the-shelf optimization solver or other optimization solver. The reconciliation of conflicts can extend naturally from the use of objectives, constraints, and variables to their dependencies on input data. Conflict and dependency reconciliation can be very useful or important in helping to ease the use of an RTN-based templated PSO framework in a particular use case, since it enables rapid resolution of any issues during the generation of the optimization formulation for that particular use case.
In the past, despite large similarities among optimization problems across many different industries, no framework enabled a shared optimization-building process. As a result, a large amount of effort was often required to duplicate the same optimization-building procedures from one problem to another. Considerable development effort was needed to refactor an existing code base or redevelop a new solution from scratch. The approaches described above help to abstract the building of a complete optimization formulation based on the use of constraint and optimization templates. Moreover, a dependency management framework can be provided that allows developers or other users to select the desired templates and assemble them into a new solution for a new application or use case. Dependency management is performed to help ensure that selected templates are compatible and that all supporting mathematical components (such as matrices, variables, constraints, and objectives) are automatically generated. This approach can reduce the development time required for solving a new optimization problem.
In some embodiments, to improve the scalability and generalizability of optimization approaches, the constraint and optimization templates described above can be used with a dependency graph The dependency graph can be used to allow for reusing of existing optimization approaches, which can free developers from translating business objectives to formulation details repetitively The dependency graph can also enable automatic dependency building and help to ensure that component dependencies are introduced into the optimization formulation. In addition, the dependency graph can allow automatic dependency reconciliation, which helps to ensure that there are no conflicting optimization objectives or constraints.
In the example shown in
As a particular example of this functionality, due to the use of templates, a user may only be required to partially fill in the contents of a template (such as by filling in about half of the template). Because of dependencies, the system may be able to auto-complete the remaining portion of the template (such as by automatically filling in the other half of the template). The system can also determine dependency relations and reconcile any conflicts in those dependency relations. For instance, assume that multiple templated constraints include energy balance constraints that depend on the same variable(s) or input data. A conflict might exist if a user defines the same variable in different ways, such as by defining a mass variable differently for different energy balance constraints. The use of the dependency graphs as described above can allow the system to automatically determine that mass refers to the same input data 818 in both templates, so mass in both templates can be directed to the proper (common) variable. This same type of approach may be used with all input data 818 that is applied to constraints or objectives.
Although
Referring again to
With respect to detecting weak connections in a resource-task network 350 in order to divide an original optimization problem into multiple smaller optimization problems, this may also be referred to as network decomposition. During network decomposition, a resource-task network 350 representing a single facility (such as a single processing or manufacturing plant) or multiple interconnected facilities can be decomposed based on the network structure and other information. In some embodiments, for example, the decomposition can be performed based on graph-based decomposition, time-based decomposition, other business rule-based decomposition, or other decomposition approach.
An optimization problem can therefore be defined for each of the sub-networks 1004 and 1006. Any conflicts on the boundary between two sub-networks can be reconciled, such as by using one or more iterative mathematical techniques (examples of which may include Bender’s decomposition, Lagrangian decomposition, Dantzig-Wolfe decomposition, etc.). The RTN-based templated PSO framework of this disclosure enables users to quickly replicate similar but different constraints to different optimizations in multiple sub-networks 1004 and 1006 In some specific use cases, original constraints and objective terms in a sub-problem may be replaced with a linearized (simplified) variation to achieve a less-granular or less-accurate solution for better performance. In those scenarios, the RTN-based templated PSO framework helps to create those linearized variations with much less effort, such as by supporting the use of the extended embodiments 408′, 414′
For time-based decomposition, a similar advantage can be achieved via the RTN-based templated PSO framework.
Network decomposition can also have a broader use case for interconnected facilities.
In cases where a resource-task network 350 representing a single plant or multiple interconnected plants can be decomposed into multiple sub-networks, each sub-network can be associated with a subset of the resource nodes 352 and task nodes 354 of the resource-task network 350. Also, different embodiments 408, 414 of the same template 406, 412 or templates 406, 412 may be used for different ones of the sub-networks. Further, the optimization problems that are created for the sub-networks may be solved independently or combined and solved as a single optimization problem. In addition, it is possible to easily scale the described approaches to any desired level of granularity, such as by providing templates and performing optimizations at the processing unit-level, for groups of processing units, for an entire plant, or for a collection of plants.
Although
In this example, the RTN-based templated PSO framework can be used to perform various operations during a planning stage 1306 and a scheduling stage 1308. During the planning stage 1306, the RTN-based templated PSO framework can process various data in order to generate a production schedule for part or all of the horizon 1302. Often times, the production schedule produced during the planning stage 1306 can identify specific products to be produced in specific quantities during specific timesteps 1304. While this gives a general idea of the production schedule for one or more facilities during at least part of the horizon 1302, it does not indicate how specific tasks are to be performed during each timestep 1304. Thus, during the scheduling stage 1308, the RTN-based templated PSO framework can process various data in order to generate a production schedule for each of at least some of the timesteps 1304 (such as individual days within at least part of the horizon 1302). The production schedule for an individual timestep 1304 can identify tasks to be performed, when or the order in which the tasks are to be performed, which processing units are to be used when performing the tasks, and what materials are to be processed using the processing units.
As can be seen in this example, the scheduling stage 1308 can be divided into a set of sub-processes 1310, where different sub-processes 1310 can be used to generate production schedules for different timesteps 1304. As a result, it is possible to determine a schedule of production tasks within an individual timestep 1304, and this can be done for multiple timesteps 1304 using outputs of the planning stage 1306. In some cases, at least some of the sub-processes 1310 can be performed in parallel, which can help to greatly reduce the amount of time needed to perform the scheduling stage 1308.
Overall, the planning stage 1306 may be performed for planning purposes on a day-by-day basis or other basis over the planning horizon 1302, which may typically span months or years. One goal of the planning stage 1306 may be to identify optimal production quantities for each day or other timestep 1304 within the horizon 1302 An objective function may be used during the planning stage 1306 to minimize an amount of missed demand for products to be produced. In some embodiments, the objective function may be used to achieve a number of objectives, such as minimizing an amount of missed demand for products to be produced, minimizing a number of products produced during each timestep 1304, minimizing use of expensive raw materials, minimizing an amount of wasted raw materials, minimizing an amount of worker overtime, maximizing a number of makeahead days, minimizing an amount of wasted finished goods, and minimizing an amount of wasted byproducts. The planning stage 1306 can involve the use of various constraints, one or more of which may represent embodiments 408 defined using constraint templates 406 (although this is not necessarily required). Examples of definitional constraints that may be used include raw material inventory (which can be defined as starting inventory plus arrivals minus waste minus consumption), finished product/good inventory (which can be defined as starting inventory plus production minus usage), and Yi (which can be defined as a binary form of production). Other constraints may indicate that byproduct consumption needs to be less than production, each raw material expires after its shelf life, each finished product/good expires after its shelf life, processing unit runtime is limited to a specific number of hours per day plus overtime (up to a maximum number of hours per day total), and physical quantities need to be non-negative and less than maximum physically possible values. Note that these constraints are for illustration and explanation only.
The scheduling stage 1308 may be performed for planning purposes on a day-by-day basis or other basis over a shorter period of time, such as one or several weeks within the planning horizon 1302 (this shorter period of time is referred to as a scheduling horizon below). One goal of the scheduling stage 1308 may be to identify an optimal sequencing of tasks to be performed on each processing unit. An objective function may be used during the scheduling stage 1308 to minimize a total time (also referred to as a makespan) spent on production and changeovers. The scheduling stage 1308 can involve the use of various constraints, one or more of which can represent embodiments 408 defined using constraint templates 406. Examples of constraints that may be used include production time being defined as production quantity multiplied by time per quantity, start times for production needing to occur before end times for production, the start and end times for production needing to be within the makespan, some products requiring changeover times, byproduct balance being defined as cumulative production of byproducts minus cumulative consumption of byproducts at each timestep, byproduct balances not being allowed to drop below zero, and the makespan being less than or equal to regular production time plus overtime. Again, note that these constraints are for illustration and explanation only.
This approach results in the generation of a production schedule (such as a production schedule defining scheduled operations by processing unit and by shift) for a given length of time (such as a fourteen-day period) for all production lines.
This type of approach can result in various benefits or advantages depending on the implementation. Among other things, this type of approach allows production schedules to be generated that improve the ability of manufacturing or processing plants to satisfy customer demands. Moreover, this can be accomplished while reducing the number of product changeovers, which can provide significant time and cost savings and possibly reduce the amount of unusable products produced during the changeovers. Further, the effort needed to generate production schedules can be reduced significantly, such as by decreasing manual effort up to 96% or more. In addition, since actual constraints can be implemented as embodiments 408 of templates 406 and objectives can be implemented as embodiments 414 of templates 412, users can easily initiate multiple production optimization operations by altering constraints and terms of one or more objective functions to generate multiple potential production schedules. This allows users to compare potential production schedules, select desired production schedules, or perform other operations based on changes to constraints and terms of objective functions associated with production scheduling.
In some cases, the two-stage process 1300 can consider product demands that may arise after the planning horizon 1302. An example of this is shown in
Although
The following now describes a specific embodiment of an RTN-based templated formulation in the context of a food processing industry. This embodiment uses a discrete-time formulation and is solved using a two-stage procedure, namely a planning stage 1306 and a scheduling stage 1308. Note that the constraints and the terms in objective functions below may, in some embodiments, be defined using constraint templates 406 and objective templates 412 as described above (although this is not necessarily required). To connect the templated framework introduced above with the constraints used in the specific embodiment described below, the templates used in the planning stage (the first stage) 1306 include material balance templates (Equations (1b), (1c), (1d), (1g), and (1h) below), an expiration template (Equation (1e) below), batch production templates (Equations (1i), (1j), (1k), (1l), (1m), (1n), and (2c) below), time balance templates (Equations (1p) and (1q) below), storage capacity templates (Equations (2h), (2i), and (2j) below), and lock production templates (Equations (2d) and (2e) below). The templates used in the scheduling stage (the second stage) 1308 include time balance templates (Equations (30b), (30c), (30d), (30e), (30f), (30g), (30h), (30f), (30m), and (30n) below) and lock production templates (Equations (30j) and (30k) below).
Note that while the following discussion may involve a food industry example, the same or similar approach may be used for optimizing a production schedule for any other suitable processing or manufacturing industry and in some cases may be aimed at a facility with relationships between processing lines that can be defined using a production graph within the facility This approach can accommodate products with limited shelf lives. Also, the facility can have down-steam interconnections to one or more distribution centers, such as when a production facility is associated with multiple distribution centers To this end, the production schedule optimization can be broken into two stages, namely the planning stage and the scheduling stage as noted above. During the planning stage, the total quantity of each production task to be performed each day or other timestep can be determined. During the scheduling stage, the ordering of each production task within a single day or other timestep can be determined, and this may be performed in parallel for all days or other timesteps using the outputs of the planning stage.
In the discussion below, the scheduling problem is considered for production facilities with generalized production graphs, which means the scheduling problem can involve independent production lines or a production graph. Referring back to
Each processing unit 306 is denoted j and can perform a single task i or multiple tasks i’s. All of the processing units 306 can be represented by a set unit, and all of the tasks performed by the processing units 306 can be represented by a set task. In some cases, if the same task can be performed using different processing units 306, the task as performed using the different processing units 306 may be treated as different tasks and may have distinct task identifiers. Tasks are also known as production versions, and processing units are also known as lines. The task notation can be used to represent all tasks under consideration.
The sets fg, wip, and task can be divided into subsets (such as fgstd, fgstk, wipstd, wipstk, taskprod, and taskshad) below to accommodate a stock transport requisition (STR) formulation. In general, the stk and std subscripts for each material category represent “stocked” and “standard” subsets of the material category, respectively. The prod and shad subscripts for the task category represent “production” and “shadow” subsets of the task category, respectively. As a convention, the expression |set| can be used to denote the number of elements in the set. For example, |task| would denote the total number of tasks under consideration. For some facilities, there may not be raw material arrival constraints, and the inventory or expiration of raw materials may not be considered (due to on-demand order for the raw materials). However, as will be shown below, arrivals can be included in the formulation to make the formulation itself generally applicable to all cases. The formulation introduced below supports production schedule optimization while considering stock transport requisitions of downstream distribution centers (DCs).
The production of material with task i follows an input recipe matrix Rin ∈ ℝ|task|×|mat| (which defines how much of each input material is consumed by each task) and an output recipe matrix Rout ∈ ℝ|task|×|mat| (which defines how much of each type of product is generated by each task). Under these definitions, element Rin[i, l] represents the amount of an input material l that is needed for a task i. The notations
represent the mth columns of Rin, and Rout, respectively. Note that the quantity of the task i performed is usually measured by the quantity of its primary output. Let a time cost matrix for all tasks be denoted as C ∈ ℝH×|task|×|unit|, where element C[d, i, j] denotes the time it takes on the date d to produce one unit of the primary output of the task i on the processing unit j. Note that the task i could include multiple operations, each of which might take place on a different line. Therefore, multiple entries in C[d, i, :] may be non-zero While the formulation below is limited to a single operation per task for convenience, other embodiments may support multiple operations per task
The following additional notations are used in the discussion below and have the following meanings.
exclusiveset – An exclusive task set, where only one task in the set of tasks can be performed on any given day.
in(m) – A set of tasks that take an input material m as an input.
Kc – A set that includes demand from a variety of categories, including from different customers, of different types, etc.
MTS (subscript) – A specific category of tasks related to “make to stock” products.
λ1, ..., λ12 – Penalties to be applied as part of an optimization.
ξ – A number of work shifts.
Ω ∈ {0, 1}η×H|task| – A shift-combination variable indicating whether time consumption on a task should be considered for a processing unit time constraint.
Ω0 – A shift combination matrix.
Π ∈ 0, 1|task|×|exclusiveset| – An assignment of tasks to an exclusive set.
Φ ∈ {0, 1}H×|task| – Configurable product planning rules, where Φ[d, i] = 1 if a task i cannot be planned on a day d.
cD,k ∈ ℝ|mat| – A cost of missing a demand for each type of material if the material belongs to a category k. The dimension of cD,k can be extended to be consistent with a matrix Dk (described below), but essentially
since there is no explicit customer demand for raw materials, WIPs, or standard finished goods
cot ∈ ℝξ×H×|unit| – A fixed operation cost for overtime production (such as over the weekends), where non-zero elements are used only for work shifts with zero regular working hours.
cp – A penalty applied to low-priority tasks.
cw ∈ ℝ|mat| – A cost of wasted material.
C ∈ ℝH×|task|×|unit| – A processing time for each task on each processing unit. Cv and Cf are the same as C and represent unit time spent for variable-duration and fixed-duration operations, respectively. In some cases, the processing time can be measured by the hours it takes for producing one unit (such as a specified number of pounds) of the primary output for each task on each processing unit.
Cmd ∈ ℝ|task|×|unit| – A required time (such as in days) for multi-day processes. If task i is a single-day process, Cmd[d, i, j] = 0. On the other hand, if task i is a multi-day process,
dH ∈ ℝH – A discount factor over time such that costs closer to the start of a planning period are given greater weights than costs later in the planning period.
A mapping matrix that maps all tasks to tasks that can be performed on the processing unit j.
G – A total number of processing unit groups defined.
A safety stock and a maximum inventory level for a specific material m, which are valid only if m belongs to the MTS category (represented by the set prodMTS).
A maximum quantity and a minimum quantity, respectively, for one leg in fixed-duration operations (each of which can be ignored if the associated element is zero).
A maximum quantity for one leg in variable-duration operations (which can be ignored if the associated element is zero).
M – A large positive scalar value.
ns, nmax ∈ ℝη×H×|unit| – A maximum number of timesteps of production for each shift combination in each day for each processing unit without and with overtime, respectively.
Olp,p ∈ ℝH×|mat| – Pre-specified “lock puck” quantities.
Pre-specified lock puck quantities and legs for variable-duration and fixed-duration processes, respectively.
An amount of locked puck input material balance slack. For each locked puck, there is a chance that it is impossible to produce enough input material for the action, so an optimizer can use this slack variable for those specific materials on specific days that the locked action would consume those materials (BOM lead time offset included). The amount of slack possible can be limited by the maximum amount of consumption the lock puck would ever need (see Equation (2f) below). The total amount of the slack used can be penalized and, in general, the penalty multiplier can be strictly greater than the penalty for missed demand, avoiding abuse of this material balance slack when unnecessary.
Plp,p ∈ℝH×|mat| – A matrix defining the lock puck for the planning stage.
A procurement window for a material m. An element in
can be equal to one if the corresponding date and the material m are within the procurement window. Note that, in general,
which means only raw materials are affected by the procurement window.
Poco ∈ {0, 1}H×|punits| – An overnight changeover penalty for each processing unit for each day, indicating that two tasks incur an overnight changeover penalty if the processing unit performed one task on one day and another task on the following day
Ppd and Ppd, max ∈ ℝη×H×|unit| – A total amount of planned downtime aggregated on a given shift combination for each date within a working hour and for a maximum working hour (with overtime) on each processing unit, respectively.
V, U ∈ ℝH×|task| – Matrices representing minimum and maximum lot sizes, respectively (where a corresponding constraint can be ignored if the associated element in a matrix is zero).
1d ∈ ℝd – A vector of dimension d with all elements equal to one.
1d,d′ E ℝd – A vector of dimension d with its first d′ elements set to one and its remaining elements set to zero. For example, 15,3 ∈ R5 = [1, 1, 1, 0, 0]T.
δi,j – A Kronecker delta.
Δ-1 E ℝH×H – A lower triangular matrix with only ones as non-zero elements.
e1 ∈ ℝdng – A vector having one for its first element and zero for its remaining elements.
Ja×b --- A matrix of dimensions a × b with all elements equal to one.
Lk ∈ ℝH×H – Lower shift matrices.
∈ ℝH×H – A slight variation of Lk that fills the first abs(k) columns in the first row with ones.
Lgr(m), Lsl(m) ∈ ℝH×H – Lower shift matrices that represent a good receipt time (or transition time) for a material m and a shelf life for a material m, respectively.
blt(i,m) – A bill of materials (BOM) component lead time offset for a material m with a task i.
Lblt(i,m) ∈ ℝH×H –A shift matrix that is shifted upwards if blt(i,m) is a negative number.
∈ ℝH×H – A variation of Lblt(i,m).
dng – Negative days, which typically is the negative BOM lead time offset days with the largest magnitude, such as dng = max(-blt(i, m)), ∀i, m.
gr(m) – A good receipt time for a material m, which denotes the time it takes for the material m to be registered in inventory, such as one day.
sl(m) – A shelf life for a material m, which represents the time between the material m is produced and its expiration.
test ∈ ℝH×|task| – An estimated transition time from or to a task. One issue with determining test lies in the fact that it should be as accurate as possible, but a computation of the actual changeover time may not be desired since it can introduce nonlinearity into the planning stage.
A ∈ ℝH×|task| – A production of a WIP material or a finished good from a task i and a processing unit j for each step in the horizon. In some cases, this can be quantified by the quantity (such as pound value) of the primary output of the task i.
Amo ∈ ℝH×|task|×|unit| – A high-dimensional version of A to account for multi-operation recipes For example, the matrix A may be projected to Amo via an even split across all operations inside the same task (such as |Ji|, which is the number of operations for a task i).
Ar ∈ ℝH×|mat| – A matrix denoting arrivals of materials from suppliers. In some cases, it is expected that only the columns corresponding to raw will have non-zero values in Ar, since only raw materials are typically purchased from suppliers.
Ar0 ∈ ℝH×|mat| – An “off-the-truck” quantity for a material. This concept may only apply to purchased materials (such as raw materials) Oftentimes, a purchased material will take a “good receipt time” to be registered in inventory. One exception of this is the “off-the-truck” quantity, which can be registered into inventory on the same day of delivery.
∈mi ∈ ℝH×|fg
represents a column in the matrix ∈mi, which corresponds to a specific stocked finished good m
∈ot ∈ ℝη×H×|unit| – A slack variable that represents the overtime production for each shift combination in each day on each processing unit.
∈ss ∈ ℝH×|fg
represents a column in the matrix ∈ss, which corresponds to a specific stocked finished good m.
D0 ∈ ℝH×|mat| – A same-day shipment on each day. This concept may only apply to finished goods and can refer to demand that is satisfied by production on the same day (instead of from inventory from a previous day). In some cases, this behavior may be discouraged.
Dk ∈ ℝH×|mat| – A demand (such as firm orders or demand forecasts) for each material at each day for a category k, where
denotes one column in the matrix Dk. Note that
∀m ∈ wip U raw since there is no explicit demand for raw materials or WIP materials.
Dmiss,k ∈ ℝH×|mat| – A missed demand on each day for a given category k. Here, k ∈ Kc. Note that the columns of Dmiss,k can be extended to include wip and raw for dimensional consistency in the equations. In fact,
∀m ∈ wip U raw. The same extension can also apply to the demand matrix Dk.
N ∈ ℝH×|mat| – Available net production quantities for materials. The available net production quantity differs from true net production quantity due to the good receipt time, BOM lead time offset, etc Note that Nm ∈ ℝH represents a column in the matrix N, which corresponds to a specific material m.
Nprior ∈ ℝdng×|mat| – Available net production quantities for materials prior to day 0 of the optimization. The variable dng represents negative days, which may typically be the negative BOM lead time offset days with the largest magnitude.
W ∈ ℝH×(|mat|) – Quantities of raw materials, WIP materials, and finished goods wasted each day due to expiration. Note that Wm ∈ ℝH represents a column in the matrix W, which corresponds to a specific material m.
X ∈ ℝH×|mat| – Available inventories of materials at the end of each day over the optimization horizon, which include raw materials, WIP materials, and finished goods. The available inventory differs from the true inventory due to the good receipt time, BOM lead time offset, etc Note that Xm ∈ ℝH represents a column in the matrix X, which corresponds to a specific material m.
X0 ∈ ℝH×|mat| – An available quantity of the initial inventory on each day, since some items may not be immediately available due to good receipt time. The variable
is the mth column of X0.
Xprior ∈ ℝdng×|mat| – Available inventories of materials at the end of each day for dng days prior to day 0 of the optimization.
Xtrue ∈ ℝH×|mat| – True inventories of materials at the end of each day over the optimization horizon. Note that
represents a column in the matrix Xtrue, which corresponds to a specific material m.
ζot ∈ {0, 1}ξ×H×|unit| – An overtime production at each shift for each day on each processing unit
Y ∈ {0, 1}H×(|task|) – An indication whether or not a task is being performed on a specific day.
Bf ∈ ℕH×(|task|×|unit|) – An encoding of the number of legs produced for a fixed-duration operation (such as a task i on a processing unit j) on a specific day.
Bv ∈ ℕH×(|task|×|unit|) – An encoding of the number of legs produced for a variable-duration operation (such as a task i on a processing unit j) on a specific day.
Mrv ∈ ℝH×|task| – A matrix representing a rounding value for each task, where production of the primary output of a task occurs in an integer multiple of the rounding value (which can be ignored if the associated element is zero).
Br ∈ ℕH×(|task|) – An indicator of a multiplier on a rounding value with a task i on a processing unit j on a specific day.
ZG ∈ ℤ+G×ξ – A total number of processing units within a given processing unit group g that can be activated in a given shift s. In some cases, the value of Z can be constant throughout a horizon, meaning the limitation set on Z can be the same for any day d within the horizon
Z ∈ ℝH×|mat| – A projected expiration of an initial inventory of materials throughout a horizon.
Start and end times (such as in relative hour numbers like hour 1.5, hour 5, etc.) associated with each task in a processing unit j (including planned downtime). The hour numbers can be relative to the beginning time of the processing unit for the day.
|Ij| – A number of elements in the set Ij.
|Ĩj| – A total number of tasks performed on a processing unit j for a given day d. This information can be retrieved from the matrix A.
– Each individual planned downtime for a processing unit j in a day d.
A total number of planned down periods for a processing unit j in a day d.
A largest number of planned down periods for any processing unit across all days in the horizon.
sj [: |Ĩj|], sj [|Ĩj| :] – The first |Ĩj| elements and the last maxj
elements in sj, respectively.
Adjusted start and end times associated with each task in a processing unit j (including planned downtime), such as in relative hour number. The adjustment can be done to align the beginning hour for all processing units in use for a given day.
A so-called “makespan” that quantifies the length of the schedule for each processing unit j.
∈sot ∈ ℝ|unit|×Ĩ
Optimization variables describing the order of production on a processing unit j. A value of one for δj[i, k] means that, in the processing unit j, the task i is performed prior to the task k. The columns or rows corresponding to
indicate that the current “task” is a planned down period.
Quantities of a material m that are produced and consumed, respectively, by continuous processes (tasks) at each timestep.
Quantities of a material m that are produced and consumed, respectively, by operations with batch inputs or outputs at each timestep.
A number of legs completed at each timestep for the tasks that are producing and consuming, respectively, a material m. In some cases, this variable may only apply to operations with batch input or output. Note that notations
and
can be identical to bq and correspond to the elements in bq that related to variable-duration and fixed-duration, respectively. The same can be true for
and
A sub-day level inventory of WIP products at each timestamp.
Each material balance check-point in a day, which can represent a start and an end of each task performed on that day.
During the first stage (the planning stage 1306) of the production schedule optimization process, an optimal schedule for all dates within a planning horizon H can be produced, which can be accomplished by grouping production of each finished good into as few dates as possible while accounting for the availability of raw materials, shelf life constraints, etc. The following formulation defines an example optimization problem that may be used during the planning stage 1306 of the production schedule optimization process.
The following auxiliary constraints may be associated with the objective function of Equation (1a).
Note that matrices and tensors are often sliced in the equations above. It can be assumed that the dimensions of each matrix or tensor will be reduced if only one slice is picked from any axis For example, if M ∈ ℝA×B×C and i is an index (i ≤ B), M[:, i, :] ∈ ℝA×C. As noted above, matrices of the form Lk ∈ ℝH×H are lower shift matrices, where the element Lk[i,j] = δi,j+k such that (LkA)[i,j] = A[i-k,j]. Note here that the positive or negative sign on k determines in which direction the matrix shifts (upper or lower). The notation
is a slight variation of Lk that fills the first abs(k) columns in the first row with ones. The following demonstrates L̃-1 when H = 4.
The ⊙ operator represents a Hadamard product, which performs element-wise multiplication between two matrices Note that if a material m can only come from one specific task i, some specific gr(m) information (such as “micro-hold”) can come from the associated task i. The notation Ij represents a set (or equivalently a list of indices) of all tasks i’s that can be performed on a processing unit j. Similarly, the notations
and
respectively represent the set of variable-duration operations and the set of fixed-duration operations that can be performed on the processing unit j. The notations i and I in general represent tasks; however, once a set Ij (which is a set of tasks associated with a processing unit) is defined, that set of tasks is equivalent to operations under that processing unit. In the matrix expressions, a set and a list of indices are used interchangeably. The notation
denotes the set of tasks on the processing unit j that require multiple days to complete.
An exclusive task set (exclusiveset) includes one or more sets of tasks where only one of the tasks in a set can be performed on any given day. In some cases, these task sets may be constructed using “same-day disallowed” changeovers between tasks For example, if one task i produces chicken and a second task j produces beef and these two products cannot be produced on the same day, the set exclusiveset may contain an entry (i, j), and the corresponding column of Π will contain ones in rows i and j and zeros everywhere else. In many cases, only pairs of tasks may be considered, so the length of each entry in exclusiveset may be two. However, no changes to the formulation would be needed to consider larger groups of exclusive tasks. In practice, increasing the size of each exclusive set and reducing the total length of exclusiveset can sometimes improve optimization performance. A set of ordered task pairs tasksoco
In the optimization problem of Equations (1a)-(1s), the cost function in Equation (1a) includes fourteen terms. The first and second terms ensure that production is grouped and penalizes spreading production across days, across legs, and across processing units. The third and fourth terms penalize an MTS material that is higher than the maximum inventory level or lower than the minimum inventory level. The fifth term penalizes missing demand, where missed demand for each finished good carries a different cost (which may be specified by CD). The sixth term penalizes the use of raw materials. The seventh and eighth terms penalize overtime production on each processing unit and over the weekends, respectively. The ninth term penalizes waste of materials, where the waste of each material may carry a different cost (which may be specified by CW). The tenth term penalizes same-day shipment, the eleventh term penalizes off-the-truck arrivals, and the twelfth term penalizes production with recipes of lower priority. The thirteenth term penalizes overnight changeovers on a processing unit, and the fourteenth term penalizes locked puck input materials’ material balance slack variables.
The constraints in Equations (1b) and (1d) denote the material balance of the materials over the horizon. The constraint in Equation (1c) defines the net production, and the constraint in Equation (1e) defines the behavior of wasted materials. The constraint in Equation (1f) defines the same-day shipment, and the constraint in Equation (1g) denotes the material balance in the period prior to day 0 of the optimization. The constraint in Equation (1h) defines the net production in the period prior to day 0 of the optimization, and the constraint in Equation (1i) defines the rounding value of the quantities of the materials that can be produced on each day The constraint in Equation (1o) ensures that, for each set of tasks that cannot be performed on the same day, a maximum of one of the tasks is performed on each day. The soft constraint in Equation (1p) ensures the capacity constraint of the processing unit is kept unless there is a need to introduce additional capacity through overtime production, and the constraint in Equation (1q) ensures that even overtime production does not take capacity past its absolute physical limit (such as a limit of 24 hours per day or until the next shift starts). Note that those two constraints can be applied for each of the shift combinations. The constraint in Equation (1s) enforces overnight changeovers between tasks sharing the same processing unit that preferably are not run on consecutive days If a processing unit performs such a sequence of actions, the Poco variable for that processing unit’s day can trigger an objective penalty.
Within the auxiliary constraints of Equations (2a) through (2n), the constraint in Equation (2a) enforces the limitation on multi-day production processes. The constraint in Equation (2b) allows a user to apply configurable planning rules, and the constraint in Equation (2c) defines the minimum lot size for production. The constraint in Equation (2g) indicates that missed demand for MTO material cannot exceed the actual demand for the material on that day. The constraints in Equations (2h)-(2j) set the limit on maximum and minimum inventory and define the behavior of the slack variables ∈mi and ∈ss for MTS materials. The constraint in Equation (2ℓ) enforces the waste of standard materials (those materials are made-up and do not physically exist) to be zero. Finally, the constraint in Equation (2n) enforces that all decision variables take values greater than or equal to zero.
By solving the optimization problem as defined in Equations (1a)-(1s) and (2a)-(2n), it is possible to use A as the production quantities for each task for each day of the horizon. As a result, solving for A can be performed to complete the planning stage 1306 of the production schedule optimization process Depending on the implementation, in some embodiments, a solution for A can be generated using an off-the-shelf optimization solver or other optimization solver. This enables the subsequent scheduling stage 1308 to solve the scheduling problem for each day of the horizon, which in some cases can be performed independently and in parallel.
Note that it is possible to extend the PSO formulation defined above to handle transportation between multiple facilities, including production facilities (PFs) and distribution centers (DCs) For example, the PSO formulation defined above can be extended to handle transportation requirements such as stock transfer orders (STOs), as-your-ship (AYS, also referred to as demand-push), and demand-pull. The optimization results on transportation can be stored as stock transfer requests (STRs). Depending on the implementation, arbitrary transportation of materials between production facilities may or may not be supported, and there may or may not be support for more than two layers of chained distribution centers. Moreover, it may or may not be possible to ship excessive initial inventory accumulated on day 0 during the optimization run. If not, it may be possible to overcome this limitation by running rule-based pre-processing of the initial inventory to ship excessive initial inventory to a reasonable storage location before the optimization run.
One possible use of the transportation extension is to create “dummy” tasks to represent transportation activities and create copies of “dummy” materials to represent the same material at different locations and with various statuses. Tracking materials at different locations separately makes it easier to represent transportation by recipes, such as a task with a recipe of consuming material at a production facility and producing material at a distribution center that is intuitively a transportation lane carrying the material from the production facility to the distribution center. The need for tracking materials in the same facility with various statuses may be less obvious. In some cases, various statuses of the same material can be designed to ensure that shelf-life and expiration logic are honored both before and after transportation. For example, for a regular production task that consumes a WIP product and produces a finished good, the tracking of the shelf-life for the produced finished good can start at zero on the date of production. For a transportation task that consumes a finished good at a production facility and produces a finished good at a distribution center (after the finished good has already stayed at the production facility for two days before the shipment), tracking the shelf-life for the finished good at the distribution center cannot start at zero The description further below describes in full detail how the consistency of shelf-life can be ensured.
Transportation tasks and dummy materials can be naturally incorporated into the objective formulation by extending the dimensions of the matrices involved. For example, the set task and the set mat can be extended in the following manner.
Here, the set of finished goods (fg) now includes the set of stocked finished goods (fgstk), the set of imported finished goods (fgimport), and the set of exported finished goods (fgexport). The same is true for the WIP materials Note that fgstk includes stock finished goods across all facilities (such as FG PF STOCK and FG DC1 STOCK in the previous example). Also note that all original finished goods may have at least a copy of fgstk since they will have to be stocked somewhere. However, whether the finished goods will have copies of imported/exported finished goods depends on whether there are transportation lanes for those finished goods. The set of tasks now includes both the regular production tasks (taskprod) and the transportation tasks (tasktrans).
Arrows 1508 connecting these dummy materials represent production, transportation, or other tasks. Some of the arrows 1508 point from/to materials within the same facility, and these arrows 1508 represent production tasks (such as RM ----> WIP or WIP ----> FG) or trivial tasks that transit the status of the material (such as WIP:EXPORT → WIP:STOCK or WIP:STOCK ⇢ WIP:IMPORT). Other arrows 1508 connect materials from different facilities, and these arrows 1508 represent transportation tasks. Note that transportation tasks may connect materials of the same type (such as WIP → WIP or FG → FG) with different statuses, which is expected since a material (such as a WIP) cannot be transported from one facility to another facility and become a different material (such as an FG).
“Push” and “pull” indicators 1510 next to the transportation arrows 1508 in
In some embodiments, all EXPORT and IMPORT dummy materials may not have positive inventory. That is, all of these dummy materials may need to be consumed (not wasted) immediately on the date of production in order to keep the end-of-day inventory to be exactly zero In these embodiments, only STOCK materials may have positive inventory levels (which is where the description “STOCK” comes from). Also note that tasks to convert the same material between different statuses may not be attached to any processing units in the production facility 1502, which make sense since those tasks are either just for bookkeeping purposes or only utilize transportation lanes.
In the top potion of
Notice that the BLTOs for all push tasks are set to zero. Also, the GRTs on the output materials are used to track the transportation lead times, the specific GRTs on the recipient facilities (which differ from the GRTs used in the formulation), or the dwell time. Further, notice that the GRTs on WIP:IMPORT tasks are set to zero for all pull tasks, and the BLTOs are used to track the transportation lead times and the specific GRTs on the recipient facilities. One reason for modeling these “lagging times” in this manner is because no inventory may be kept for EXPORT or IMPORT materials. Each task (arrow 1508) that connects WIP:IMPORT and FG:EXPORT is a production task. Note that FG:EXPORT may have zero days of BLTO or GRT since neither WIP:IMPORT nor FG:EXPORT may be stocked. Push tasks that transport FG:EXPORT to each of the facilities resembles those tasks for WIP:EXPORT.
At the bottom of
While converting the transportation extension into a suitable formulation, various structures and values may be introduced into the matrices along with some additional constraints For example, the good receipt time for a stocked material m can satisfy the following.
Here, m represents the original material before being copied as a dummy material, and m : STOCK represents the stocked dummy material. The notation gr(.) represents the GRT in the formulation (which is a data field in the model), and GRT(facility) represents the good receipt time associated with a facility (which is in the input data). The notation LT(lane) denotes the lead time on the transportation lane, and DT (·) represents the dwell time for the material. The BLTO (such as blt(·,·)) for tasktrans can be expressed as follows.
Here, m represents the original material before being copied as a dummy material, and m : IMPORT represents the imported dummy material. The notation blt(·,·) represents the BLTO in the formulation (which is a data field in the model), and BLTO(i, m) represents the BLTO associated with the original material and task (which is in the input data) The notation LT(lane) again denotes the lead time on the transportation lane.
Note that the rounding value, minimum and maximum lot sizes, and minimum and maximum batch sizes for the dummy tasks associated with transportation can be set to zero. This may be expressed as follows
These constraints can therefore be ignored by an optimizer. The time cost C can also be set to zero for shadow tasks, which can be expressed as follows
In addition, the recipe matrices Rin and Rout can be expanded to represent the recipes of the transportation tasks (such as when an element will be set to one on the “ship from” dummy material in Rin and set to one on the “ship to” dummy material in Rout). Additional constraints may be used to enforce the fact that IMPORT and EXPORT materials cannot have positive end-of-day inventories, which in some cases can be expressed as follows.
Although
Returning to the optimization problem of Equations (1a)-(1s) above, shift scheduling constraints for the planning stage 1306 are expressed in Equations (1p) and (1q). These constraints can be enforced via the concept of “shift combination.” As noted above, ξ represents the maximum number of shifts that can happen across all processing units within the planning horizon. The total number of “shift combinations” is denoted as η, which can be expressed as follows.
If a matrix Γ ∈ {0, 1}ξx|task| is used to denote whether a task i can be performed on a shift s, a simple example with ξ ::: 3 and |task| ::: 3 can be defined as follows.
The first column of the matrix Γ indicates that a task t1 can only be performed during a shift S1. The second column of the matrix indicates that a task t2 can either be performed during a shift S2 or S3. The third column of the matrix indicates that a task t3 can only be performed during a shift S2.
Based on the definition above, it is possible to consider whether tasks can be performed in any combination of shifts (such as whether the task t1 can be performed during either shift S1 or S2). If all possible combinations of shifts are examined, there will be at most 2ξ combinations. However, since the scenario of empty combinations is not considered, 2ξ - 1 (meaning η combinations remain. Here, the shift combination matrix Ω0 ∈ {0, 1}(2 - 1)×|task| may be defined as follows.
Following the example of Γ ∈ R3x3 above, the corresponding shift combination matrix Ω0 ∈ R7x3 can be expressed as follows
Note here that there are seven rows in the shift combination matrix Ω0 (since 23 - 1 = 7). The first column in Ω0 indicates that processing unit time constraints for all of the following shift/shift combinations need to include time used for task t1: shift S1. shift combination {S1, S2}, shift combination {S1, S3), and shift combination {S1, S2, S3}. The other columns can be interpreted in a similar manner. Note that the zeros in the second, third, fourth, and fifth rows of the second column in the matrix of Equation (20) may appear a bit counter-intuitive. For example, one would not consider the time used for the task t2 when applying the time constraints for the shift S2 alone since (i) the task t2 can span across both shifts S2 and S3 and (ii) its operation time should not be bounded by the hours available in the shift S2. Equations (1p) and (1q) make sure the time limitations for each of the shift combinations are satisfied accordingly. In some cases, single shifts {S1, S2, and S3 in the above example) may always be included the first ξ rows of the shift combination matrix Ω0, which is the reason why only the first ξ rows in the seventh term of the objective function in Equation (1a) are added. The concept of “shift combination” can be easily extended to the scheduling stage 1308, which will be explained in detail below.
With respect to the constraint for multi-day processes expressed in Equation (2a) above, this constraint enforces that (if a multi-day task i is planned on a day d) no other tasks on a processing unit j can be planned on the processing unit j within the duration of the task i (meaning Cmd[i,j]). This applies to both multi-day tasks
and single-day tasks
When there are not any multi-day tasks planned, single-day tasks on the processing unit j can be freely planned. A more straight-forward expression of Equation (2a) is shown in Equation (21) below For multi-day processes, Y[d, i] = 1 indicates that a task i begins on a date d, not that the task i is performed at some point on the date d.
If the first term in Equation (21) is one, it indicates that the processing unit j is still within a multi-day task duration on a day d. Therefore, no tasks can be planned on that day d. Otherwise, if the first term in Equation (21) is zero, it means no multi-day tasks are planned, and single-day tasks are free from any limits. Note that comparing M′ in Equation (21) and M in Equation (2a), it can be shown that M′ = M - 1. A reasonable value for M′ here can be
Equation (2a) forces multi-day tasks to have a non-zero value in the matrix A on its first day being planned and a zero value in the matrix A for the consecutive days. The corresponding good receipt time (gr) and shelf life (sl) for the material(s) as output from each multi-day task can be updated. For example, the updated good receipt time and shelf life for material m (denoted as gr(m)′ and sl(m)′) may be expressed as follows.
The notation out(m) depicts a set of tasks with the material m as an output material Note that this update can be done in a data preparation step and may not affect any formulation in Equations (1a)-(1s). Once the variable Y and corresponding A matrix are determined in the planning stage 1306, the fact that a task is a multi-day process may not affect the scheduling formulation, which is discussed below. If a multi-day task is planned, Equation (2a) ensures that no tasks on the same processing unit are planned within the task duration, so no conflict will occur during the scheduling stage 1308.
In some cases, additional constraints can be added to enable the use of configurable optimization parameters. For off-the-truck arrivals, if it is set to “disallowed”, the following can be obtained.
Similarly, for same-day shipment, if it is set to “disallowed”, the following can be obtained.
For overtime production, if it is set to “disallowed”, the following can be obtained.
Finally, for production version priority, Ilow can be defined to represent tasks with lower priority or priorities. The following constraint can be used if the configuration is set to “only allow top priority ”
The decision variables associated with the matrix A determined in the planning stage 1306 can be used as input for the scheduling stage 1308
Note that the exclusive task sets constraint in Equation (1o) provide an efficient way to prevent tasks from occurring on the same days when this is not possible However, other formulations are possible and could have superior performance in some situations. One alternative is the use of “exclusive group sets.” In this approach, the tasks on a processing unit j could belong to multiple groups, and those groups could form multiple exclusive sets. The groups involving the processing unit j and in an exclusive set k can be represented by groupj,k. For example, assume that all tasks for the processing unit j can be categorize into four groups, such as soy, milk,fish, and chicken. Also assume that the groups soy and milk are exclusive to each other and that the groups fish and chicken are exclusive to each other. Therefore, groupj,0 = {soy, milk} and groupj,1 = {fish, chicken}. The set of all groups across all processing units can be represented by group. This leads to the following expressions.
In this formulation, µj,k ∈ {0, 1}H×|group| is an additional decision variable representing whether a task belonging to certain groups is being executed in the processing unit j and the exclusive set k. Note that the groups in the processing unit j and in the exclusive set k are represented by groupj,k, which is a subset of group here, so all not-used elements in µj,k can be set to zero. The matrix Gj,k ∈ {0, 1}|I|×|group| is a mapping matrix that maps tasks to groups. The superscript k denotes a specific group of the processing unit j, where each member in that group is exclusive to other member(s) in that group. For any processing unity, there may be only |groupj,k| columns out of |group| that are used in Gj,k, and the remaining columns from Gj,k can be set to zero. Here, the element Gj,k[i, l] can have a value of one if a task i can be categorized into a group l. Note that one task can be categorized into multiple groups if desired.
Having described the first (planning) stage 1306 of the production schedule optimization process, the second (scheduling) stage 1308 is now described. Notice that, having determined the solution to the optimization problem as described above, the production requirements for each of the production lines for each day d have also been determined. For example, having solved the production planning optimization problem for all days in the horizon H, row d of matrix A summarizes the production requirements for a task i on a processing unit j for a day d. This enables the framework to optimize the schedule for each day such that (i) byproducts are produced prior to being used and (ii) the end time of each line is minimized. The following optimization problem defines the scheduling stage 1308 in some embodiments Since the formulation below can be repeated for each day d in the horizon H, the notation d in the majority of the matrix definitions is omitted below for simplicity.
In addition, sub-day inventory balance constraints may be associated with the objective function in Equation (30a) as follows. Note that i, j, k, and m applied to these constraints can be inferred, so redundant notations at the end of those constraints are omitted below for simplicity.
There can also be constraints for multi-operation recipes, which support multiple dependency modes across each of the operations under the same task. For example, the following constraints may be associated with the same objective function.
Before introducing how the matrices come from the input data, it should be pointed out that the notations
are fully defined in Equations (31d) and (31e). Those two notations exist only to simplify mathematical equations and to remove redundancy in the expressions. They need not be considered variables for the optimization problem, and thus the dimension information for those two notations are not provided.
The notations τs, τe ∈ Rξx|unit| denote the shift starting time and shift ending time for each shift of each processing unit in the day. The notations Plp,s ∈ {0, 1}|unit|×|task| and
represent the pre-specified “lock puck” and the planned downtime, respectively. Matrices Slp,s ∈ R|unit|×|task| represent the corresponding start timestamp for each “lock puck” and
are the start and end for planned downtime. Note that
can be taken to make sure that the total number of columns for each row are aligned. In fact, each processing unit j can have a different
The elements in the gap between
and
in each row can be set to zero and excluded as a decision variable.The matrices
represent the required transition times between products for the processing unit j such that
is the time required between a task i and a task k.
As noted earlier,
and
denote the active fixed-duration and variable-duration processes on a given day. The notation
denotes the maximum quantity for variable-duration process This matrix can default to A[d, i] on a given day if not provided. The notations Cv and Cf are not new matrices, and they both are equal to the C matrix defined earlier and correspond to the elements in C that relate to variable-duration and fixed-duration, respectively.
In the sub-day inventory balance in Equations (31a)-(31t) and the multi-operation recipe in Equations (32a)-(32c), the vector ƒ ∈ R|unit| denotes the relative shift of the beginning hours for each processing unit. The notation Δtblt (no dimension specified) denotes a dictionary that stores the sub-day BOM lead time offset in hours for each of the task-material pairs. Note that the value of Δtblt is often a negative number. The notation in(m) denotes all tasks or processing units that consume a material m, and the notation out(m) denotes all tasks or processing units that produce the material m. The notation Ji denotes all processing units (operations) associated with a task i. In some cases, for the majority of tasks, |Ji| = 1 since most tasks may have single-operation recipes. However, for tasks with multi-operation recipes, |Ji| > 1, and the starting time of the task i across multiple units in some cases can be the same.
The dictionary Δmd contains dependency mode information for multi-operation tasks and essentially functions as a “dictionary of dictionaries.” Keys for a first dictionary layer may include an index of tasks, and keys for a second dictionary layer may include strings representing dependency modes. The value under each key of Δmd[i] can contain a list of pairs of processing units that follow the dependency mode prescribed by the key (where i is the task index). For example, Δmd[i][‘START - START’] = [[0, 1], [4, 5]], where 0, 1, 4, and 5 are processing unit indices.
The objective function in Equation (30a) contains two terms. The first term minimizes the makespan of each line in order to ensure that production occurs over the shortest total time possible. The second term minimizes the violation of the shift end constraint. The constraint in Equation (30c) ensures that the time scheduled for a task i on a processing unit j satisfies the required daily production time, and the constraint in Equation (30d) ensures that the makespan is smaller than the maximum timesteps allowed in a day based on the demand planning stage 1306 The constraints in Equations (30e) and (30f) enforce that all production occurs between timestamp zero and the makespan and that production end times follow start times. Equations (40a) and (40b) below enforce the shift constraints. Note that in Equation (40a), the entries with zero in the matrix Ω can be excluded from the min statement. The constraints in Equations (30i), (30j), and (30k) enforce “lock puck” and planned downtime requirements. Note that here only the starting time is enforced, and the end time can be computed based on Equation (30c). The constraint in Equation (30ℓ) enforces an ordering in production in each processing unit and ensures that only one task is performed at each timestamp. It also ensures that sufficient transition time between tasks is maintained as specified by
Equations (30m) and (30n) enforce that δj is a skew-symmetric matrix.
Within the constraints for sub-day material balance. Equations (31c) and (31r) are the governing equations and help to ensure that WIP materials do not run out of stock on a sub-day time granularity. This may not be needed if the “good receipt time” for all materials in a facility is longer than a day. The constraints in Equations (31a) and (31b) apply the relative time adjustments for the start time and end time on each of the processing units. Equations (31d) and (31e) define temporary notations for complicated expressions and are not constraints. The constraints in Equations (31f) and (31g) represent production and consumption quantities by continuous tasks. The constraints in Equations (31h) and (31m) represent production and consumption quantities in batches. The constraint in Equation (31s) enforces that sub-day check-points are on the start and end of each task. Note that the union sign means concatenation when it is applied to vectors instead of sets.
In some cases, users may have the option to pass an “invalid” planning output for scheduling. These plans could be invalid in various ways, such as insufficient line (processing unit) capacity or insufficient input material for a task. Once the user has acknowledged those issues and still choose to pass on the resulting plan to the scheduling stage 1308, the constraints in Equations (30d) and (31r) can be excluded for the corresponding processing unit or the input material.
The following now explains the constraints that are relevant to multi-operation dependency. The notation Δmd ∈ ℝ1x|task| denotes existing multi-operation dependency relationships between processing units. Each element in this list, Δmd[i], denotes the dependency relationships for a task i. These constraints enforce start/end times according to dependency mode. For example, a “start-start” pair of processing units can be forced to have the same start times.
Some facilities may use custom sequencing rules beyond minimization of changeovers. These rules can lead to substantial performance degradation and might be discouraged in some cases. However, the following additions to the scheduling objective function can account for these rules.
In this formulation, the binary matrices
are inputs describing the “ideal” production order for each processing unit j, where (like δj) a value of one for yj[i, k] indicates that a finished good i would ideally be produced on a processing unit j prior to a finished good k. The matrices
describe the importance of the production order δj being equal to the ideal order γj for each pair of products. For example, if γj[i, k] = 1 while yj[i, m] = 0.5, it is twice as important that δj[i, k] = yj[i, k] as it is that δj[i, m] = γj[i, m]. The matrices
represent the importance of each pair of products being produced one after the other (“adjacently”) on each processing unit j. A value greater than zero for αj[i, k] indicates that a penalty can be applied in the objective function for each hour that i and k are separated in the production timeline for a processing unit j. The term with λ14 minimizes the discrepancies between the production order δi and the ideal production order γi, weighted by the importance of each element of the production order as defined in θi. The term with λ15 minimizes the gap between products that are desired to be adjacent or nearby one another. Note that these two terms with λ14 and λ15 are optional.
In a production setting, each task can be assigned multiple attribute key-value pairs based on the properties of the input materials. For example, Task 1 may be assigned raw material type: beef and allergen type: egg at the same time. Here, raw material type and allergen type are attribute keys, while beef and egg are attribute values. On the other hand, each processing unit may belong to one or more processing unit groups. For example, group 1 may include processing unit 1 and processing unit 2, and group 2 may include processing unit 2, processing unit 3, and processing unit 4. One example goal of attribute constraints and objective terms can be to make sure (on all processing units within the processing unit groups) that, for each attribute key, only tasks with the same attribute value can be scheduled at the same time. These attribute constraints may impact both the planning stage 1306 and the scheduling stage 1308. The following identifies the impacts on each stage, along with an identification of which constraint equations to add or replace for planning and scheduling, respectively.
During the planning stage 1306, additional constraints and terms can be introduced into the objective function. Similar to the idea of the estimated changeover time in the planning stage 1306, one goal of adding attribute constraints in the planning stage 1306 may be to limit the total number of hours scheduled on each processing unit so that (once the scheduling stage 1308 is entered) there is adequate buffer to fully honor the attribute constraints for the scheduling stage 1308. In some embodiments, for simplification, all processing units in a processing unit group are assumed to have the same working shift hours. However, this need not be the case in other embodiments.
In the following, κ can be used to denote an attribute key, such as when this key represents a raw material type Also, Aκ can be used to denote a full set of attribute values associated with the key κ, such as when Aκ = {beef, pork, chicken}. Further, ακ ∈ Aκ can be used to denote a specific attribute value for the key κ. In addition, αmax = maxκ(|Aκ|) can be used to denote the maximum number of values available across all keys. Example additional constraints that may be introduced to the planning stage 1306 are as follows.
The decision variables used here can be defined as follows.
T ∈ Rη×H×|task|×|unit| - A time spent per day per task per processing unit per shift-combination. By default, s may be used to denote the index for the shift-combination.
Γl ∈ RK×η×H×αmax×|unit|_ A time spent per attribute constraint per processing unit. A dimension K here denotes the total number of attribute constraints in the problem Each of the constraints is also known as a group-attribute key pair (or a g-κ pair).
Γg∈ ℝK×η×H×αmax - A maximum time spent per attribute value across all lines within a line group. Again, the dimension K here denotes the total number of attribute constraints in the problem. For each attribute constraint index k, there is a processing unit group g(k) and an associated attribute key κ(k). Note that ακ(k) is used flexibly here to denote the index corresponding to the attribute value.
∈ot,g,κ ∈ RK×η×H_ A slack variable that represents an overtime production for each shift combination in each day for each g-κ pair
The notation
represents the number of working hours for each shift-combination in each day without overtime in the processing unit group g(k). The notation
represents the number of working hours for each shift-combination in each day including overtime in the processing unit group g(k). The notation Λn(k)∈ {0,1}|task|×αmax represents a task-to-attribute mapping for each attribute constraint index k, and JG,gk) ∈ {0, 1} |unit| represents a set of processing units in the processing unit group g(k) for each attribute constraint index k. An additional term can also be added to the objective function used during the planning stage 1306, where the additional term corresponds to the penalization added on the slack variable ∈ot,g,κ. This additional term may be expressed as follows.
In the scheduling stage 1308, additional constraints can be enforced so that (for certain processing unit groups) tasks on the processing units within the group with different attribute values cannot have overlaps on the schedule for the same attribute key κ. Since the formulation below can be repeated for each day d in the horizon H, the notation d is eliminated in the majority of the matrix definitions below for simplicity.
For the equations in this formulation, κ and g can correspond to the same attribute constraint k. The variables used here can be defined as follows.
Adjusted start and end times, respectively (such as in relative hour number), associated with each task i on a processing unity, with an attribute value ακ(k).
Adjusted start and end times, respectively (such as in relative hour number), associated with each task i′ on a processing unit j′, with an attribute value different from ακ(k) (for the same attribute key κ).
Optimization variables describing the order of tasks performed on processing units j,j′ within the same processing unit group g. A value of one for γjj′ [i, i′] means that a task i with a specific attribute value ακ(k) that runs on a processing unit j is performed prior to a task i′ with an attribute value different from ακ(k) that runs on another processing unity j′. As mentioned above,
represents a set of all tasks with a specific attribute value ακ(k) that are planned to be performed on the processing unit j on a specific day.
In some cases, active processing unit constraints may be used. One goal of using active processing unit constraints may be to ensure that (for certain processing unit groups) only a limited subset can be activated during the same shift, such as when only seven out of eight processing units may be active at any given time. These constraints may exist due to various reasons, such as labor shortages or other labor limitations. These constraints can be applied at the shift level of granularity, rather than at the timestamp level. The active processing unit constraints can impact both the planning stage 1306 and the scheduling stage 1308. The following identifies the impacts on each stage, along with an identification of which constraint equations to add or replace for planning and scheduling, respectively.
During the planning stage 1306, to consider active processing unit constraints, Equation (2m) can be deactivated, and additional constraints can be introduced to the planning stage 1306 as follows.
The decision variables used here can be defined as follows.
Ys ∈ {0, 1}ξ×H×|task| - A binary variable that indicates whether a task i is activated on a given day d for a given shift s, where:
Ψ ∈ {0, 1}ξ×H×|units|_ A binary variable that indicates whether a processing unit j is activated on a given day d for a given shift s, where:
The notation JG ∈ {0, 1}G×|unit| indicates whether a processing unit j is included in a given processing unit group g The notation ZG ∈ Z+G×ξ represents the total number of processing units within a given processing unit group g that can be activated in the given shift s, where the notation G denotes the total number of processing unit groups defined. Note that the value of ZG may be constant throughout the horizon, meaning the limitation set on ZG can be the same for any day d within the horizon.
The following provides an example to better understand the use of active processing unit constraints. Assume that there are three processing units in a facility, such as when unit = {PU0 PU1, PU2}. Also assume that there are two processing unit groups, such as when group0 = {PU0, PU1} and group1 = {PU1, Pu2}. Based on this, JG[0, :] = [1, 1, 0] and JG[1, :] = [0, 1, 1] For each of the processing unit groups, the maximum number of processing units that can be activated in the same shift is one, so ZG[0, :] = ZG[1, :] = 1. The notation M is a large positive number, and Γ ∈ {0, 1}ξ×|task| is the shifts-allowed matrix. The notation Ξ ∈ {0, 1}η×ξ is a specially-designed shift-transformation matrix used here to enforce the consistency between Ys and Ω. The Ξ matrix helps to transform Ys from shift (ξ) into shift-combination (η). Let PS denote the power-set for the set of available shifts (S) without the empty set Based on this, the Ξ matrix can be defined as follows.
As an example, consider the case where there are three shifts available, meaning S = {S1, S2, S3} and ξ = |S| = 3. Here, PS = {{S1}, {S2}, ⋯, {S1, S2, S3}} with |PS| = 2ξ - 1 = 7. Therefore, Ξ can be expressed as follows.
In non-technical terms, if the shift associated with a column does not belong to the set associated with a row, the corresponding element is one, otherwise, it is zero. Looking at thefirst row of the matrix Ξ here, S1 (in the first column) belongs to the set of S1 (in the first row), so Ξ[0, 0] = 0. Also, S2 and S3 (in the second and third columns) do not belong to the set of S1 (in the first row), so Ξ[0, 1] = Ξ[0, 2] = 0.
For scheduling, consider the variables Ys and Ψ from the solution of the planning stage 1306 that satisfy active processing unit constraints. Scheduling constraints may now be defined as follows.
In Equation (40a), I+ denotes the indexes of nonzero elements in Ys[:, d, i].
If an unconstrained processing unit formulation is needed or desired, existing constraints can be modified both in the planning and scheduling stages 1306-1308 in order to accommodate unconstrained processing units. Note that a processing unit can be constrained or unconstrained depending on the day of the horizon H. Also note that this flexibility can be introduced onto line capacity constraints and can be used to handle other nonphysical exceptions from the input data (such as overlapping lock pucks).
In the planning stage 1306, it is possible to simply ignore lines in line capacity constraints. More explicitly, let
where
denotes the set of days where line j is unconstrained. In cases where the line is always constrained,
would be an empty set. Based on this, the line capacity constraints can be modified as follows.
One modification here involves the introduction of
in Equation (41b)
In the scheduling stage 1308, there may be no need to enforce and order among the processing unit tasks, so neither transition times between tasks nor overlaps may be relevant Furthermore, since planning is unconstrained, a span time constraint may not need to be enforced for unconstrained lines. Consequently, these two constraints can be modified as follows.
In some embodiments, the framework can support simultaneous grouping and scheduling That is, solving an optimization problem using a two-stage approach (the planning and scheduling stages 1306-1308) is numerically efficient. However, it may result in infeasibility in the scheduling stage 1308 for a date d if a byproduct balance cannot be kept above zero throughout the day while keeping all production within the time limit defined by ni [d] + ∈i[d]. In order to avoid such issues, the constraint of Equation (30d) can be removed so that the makespan for each line can be minimized but is not guaranteed to exactly fit within the overtime specified by the planning stage 1306.
Although the above description has provided a specific approach for performing RTN-based templated production schedule optimization, this disclosure is not limited to the specific approach described above. Other approaches (including ones that do not use a two-stage process or that use different equations) may be performed by the RTN-based templated PSO framework of this disclosure. As a particular example, the two-stage process described above may be used with other optimization problem formulations. Also, while the specific approach described above has used days as the timesteps for the two-stage process, the two-stage process may use any other suitable timesteps.
As shown in
As shown in
Using this information, the framework can develop a production schedule for the processing facility 1702. A portion of a production schedule 1746 is shown in
In some embodiments, at least some of the information related to the production schedule 1746 can be presented to one or more users for review, approval, or modification. In some cases, for instance, a user might invoke an option to change one or more constraints or other inputs used by the framework to produce the production schedule 1746, and the framework may generate one or more additional production schedules for comparison or selection. When a particular production schedule is selected by a user for implementation, that production schedule may become the master schedule for the processing facility 1702. The master schedule generally represents the production schedule that is currently in use by the processing facility 1702. The master schedule may remain in use by the processing facility 1702 until the master schedule is updated or replaced by a new master schedule
Although
As can be seen in this example, the architecture 1800 supports a machine learning model-driven architecture for performing production schedule optimization. In this particular example, the architecture 1800 includes a library 1804 of various artificial intelligence/machine learning (AI/ML) functions. Among other things, the library 1804 can provide various AI/ML functions that facilitate the development of machine learning models and other machine learning algorithms. For example, the library 1804 can provide various deep-code tools and low-code environments for developing, deploying, and operating enterprise-level AI applications. In some cases, the library 1804 may, for example, represent the AI STUDIO product from C3.AI, INC. The AI STUDIO product, for instance, can provide a cohesive development experience on a visual canvas and support data ingestion, data modeling, machine learning feature engineering, machine learning model lifecycle management, and a metadata-driven user interface (UI) development tooling.
The architecture 1800 also includes an AI/ML visual designer tool 1806, which allows users to develop, scale, and apply AI insights without writing code. For example, the visual designer tool 1806 may allow users to identify data to be processed, use automated machine learning (AutoML) to automatically train high-performing machine learning models (such as for any regression, classification, or clustering problem), and deploy the machine learning models for use. One or more of these functions can be performed graphically, such as when the visual designer tool 1806 allows users to visually define dataflows between AI/ML-based tasks or other tasks In some cases, the visual designer tool 1806 may, for example, represent the AI EX MACHINA product from C3.AI, INC.
A data integration function 1808 is used by the architecture 1800 to obtain suitable data for processing using AI/ML models or other logic. For example, the data integration function 1808 can be used to integrate, federate, and unify data from multiple disparate sources, such as the external systems or tools 1802 (which may include data sources internal to an organization and external to the organization), into a single logical data image. In some embodiments, the data integration function 1808 can use metadata transformation expressions or other techniques to combine data entities, leverage AI-based data reconciliation capabilities, maintain data lineage, and enforce data governance rules. Also, in some embodiments, the data integration function 1808 can support the use of various connectors for interacting with various data sources, and data that is retrieved by the data integration function 1808 can be stored in a virtual data lake and used to create a unified data image. The data integration function 1808 may support the use of standard (pre-built) and custom data models. In some cases, the data integration function 1808 may represent an example integration function available in the C3 AI Platform from C3.AI, INC.
Information from the library 1804 and the visual designer tool 1806, as well as information from the data integration function 1808, are provided to an AI/ML application pipeline 1810, which is generally used to create, modify, and manage machine learning models and applications that use the machine learning models (where the machine learning models can process data from the data integration function 1808) For example, the AI/ML application pipeline 1810 may support various functions related to data exploration, feature engineering, machine learning model development, and machine learning model deployment. These functions can be used to support the creation of one or more machine learning models, such as those used to implement various prediction functions or other functions of the RTN-based templated PSO framework described above. The AI/ML application pipeline 1810 may also support various functions related to machine learning model inferencing or other operations performed using machine learning models, governance or other management of machine learning models, and application development to support the design and use of application user interfaces or other components to expose AI/ML insights and data or to otherwise use outputs generated by the machine learning models. In some cases, the AI/ML application pipeline 1810 may represent various AI enterprise functions available in a model-drive architecture, such as the C3 AI Platform from C3.AI, INC.
Operations and security services 1812 represent a collection of functions associated with the usage of machine learning models and data security for the machine learning models For example, the operations and security services 1812 may include services supporting data persistence, batch and stream processing of data, time-series normalization of data, auto-scaling of data, data encryption, attribute and role-based access control, and various AI/ML services. The operations and security services 1812 may also include cybersecurity-related services, such as those used for protecting online data. In some cases, the operations and security services 1812 may represent various functions available in a model-drive architecture, such as the C3 AI Platform from C3.AI, INC.
In some embodiments, the architecture 1800 may be supported by infrastructure as a service (laaS) functionality 1814, which generally allows integration of the architecture 1800 (when implemented using cloud-native, multi-cloud, or on-premise applications) with existing data storages, enterprise source systems, tools, and underlying infrastructures. For example, the IaaS functionality 1814 can allow the architecture 1800 to be implemented using various cloud computing systems, such as AMAZON WEB SERVICES (AWS), MICROSOFT AZURE, GOOGLE CLOUD PLATFORM, and IBM CLOUD, and integrated with data sources and other components that are available in a particular user’s environment or domain. In some cases, the IaaS functionality 1814 may represent various functions available in a model-drive architecture, such as the C3 AI Platform from C3.AI, INC.
Among other things, the architecture 1800 can be used to generate one or more graphical user interfaces 1816, which can be provided to one or more users (such as via one or more of the user devices 102a-102d). The one or more graphical user interfaces 1816 may support any of various functions described above For example, the one or more graphical user interfaces 1816 may allow users to define and change constraints and objective terms, display information about generated production schedules, and compare production schedules generated using different constraints or objective terms. Note, however, that the one or more graphical user interfaces 1816 may be used to present any other or additional information to users. One specific example of a graphical user interface 1816 is described in more detail below.
Example embodiments of the RTN-based templated PSO framework described in this disclosure can be used with a model-driven architecture that includes a type system. A model-driven architecture is a term for a software design approach that provides models as a set of guidelines for structuring specifications. An example model-driven architecture can include a type system that may be used as a domain-specific language (DSL) within a platform used to access data, interact with data, and/or perform processing or analytics based on one or more type or function definitions within the type system. By using an abstraction layer provided by a type system, the complexity of a production schedule optimization problem can be reduced by orders of magnitude, such as to the order of a few thousand types, for any given production schedule optimization application that a programmer manipulates using JAVASCRIPT or other language to achieve a desired result. Thus, all of the complexity of the underlying foundation (with an order of M×S×T×A×U using structured programming paradigms) is abstracted and simplified for the programmer. Here, M represents the number of process modules (APACHE Open Source modules are examples of process modules), S represents the number of disparate enterprise and extraprise data sources, T represents the number of unique sensored devices, A represents the number of programmatic APIs, and U represents the number of user presentations or interfaces. Example technologies that can be included in one or more embodiments may include nearly-free and unlimited compute capacity and storage in scale-out cloud environments, such as AWS; big data and real-time streaming; smart connected devices; mobile computing; and data science including big-data analytics and machine learning to process the volume, velocity, and variety of big-data streams.
The type system of the model-driven architecture may include types as data objects and at least one of: associated methods, associated logic, and associated machine learning classifiers. One or more of the data objects may be associated with at least one of: one or more customers, one or more companies, one or more accounts, one or more products, one or more employees, one or more suppliers, one or more opportunities, one or more contracts, one or more locations, and one or more digital portals. Type definitions may include properties or characteristics of an implemented software construct.
Employing the type system of the model-driven architecture may include performing data modeling to translate raw source data formats into target types. Sources of data may be associated with at least one of: accounts, products, employees, suppliers, opportunities, contracts, locations, digital portals, geolocation manufacturers, supervisory control and data acquisition (SCADA) information, open manufacturing system (OMS) information, inventories, supply chains, bills of materials, transportation services, maintenance logs, and service logs. Among other things, the type system can be employed to perform data modeling in order to translate raw source data formats into target types. Sources of data for which data modeling and translation can be performed may include accounts, products, employees, suppliers, opportunities, contracts, locations, digital portals, geolocation manufacturers, SCADA information, OMS information, inventories, supply chains, bills of materials, transportation services, maintenance logs, or service logs.
The model-driven architecture enables capabilities and applications including precise predictive analytics, massively parallel computing at the edge of a network, and fully-connected sensor networks at the core of a business value chain. The model-driven architecture can serve as the nerve center that connects and enables collaboration among previously-separate business functions, including product development, marketing, sales, service support, manufacturing, inventory, finance, shipping, order management, human capital management, etc. Some embodiments may include a product cloud that includes software running on a hosted elastic cloud technology infrastructure that stores or processes product data, customer data, enterprise data, and Internet data. The product cloud may provide one or more of: a platform for building and processing software applications; massive data storage capacity; a data abstraction layer that implements a type system; a rules engine and analytics platform; a machine learning engine; smart product applications; and social human-computer interaction models One or more of the layers or services may depend on the data abstraction layer for accessing stored or managed data, communicating data between layers or applications, or otherwise storing, accessing, or communicating data.
An example model-driven architecture for integrating, processing, and abstracting data related to a production schedule optimization development platform can include tools for machine learning, application development and deployment, data visualization, automated control and instruction, other tools (such as an integration component, a data services component, a modular services component, and an application that may be located on or behind an application layer), etc. The model-driven architecture may operate as a comprehensive design, development, provisioning, and operating platform for industrial-scale applications in various industries, such as chemical, pharmaceutical, oil, pipeline, food, dairy, consumer good, manufacturing, steel, and paper industries. Other example industries may include energy industries, health or wearable technology industries, sales and advertising industries, transportation industries, communication industries, scientific and geological study industries, military and defense industries, financial services industries, healthcare industries, manufacturing industries, retail, government organizations, and/or the like. The system may enable integration and processing of large and highly dynamic data sets from enormous networks and large-scale information systems.
An integration component, data services component, and modular services component may store, transform, communicate, and process data based on the type system. In some embodiments, the data sources and/or the applications may also operate based on the type system. In an example embodiment, the applications may be configured to operate or interface with the components based on the type system. For example, the applications may include business logic written in code and/or accessing types defined by a type system to leverage services provided by the system.
In some embodiments, the model-driven architecture uses a type system that provides type-relational mapping based on a plurality of defined types. For example, the type system may define types for use in the applications, such as a type for a customer, organization, device, or the like. During development of an application, an application developer may write code that accesses the type system to read or write data to the system, perform processing or business logic using defined functions, or otherwise access data or functions within defined types. In some embodiments, the model-driven architecture enforces validation of data or type structure using annotations/keywords. The types in the type system may include defined view configuration types used for rendering type data on a screen in a graphical, text, or other format. In some embodiments, a server, such as a server that implements at least a portion of the system, may implement mapping between data stored in one or more databases and a type in the type system, such as data that corresponds to a specific customer type or other type.
One example of a type system is given by way of the following non-limiting example, which may be used in various embodiments and in combination with any other teachings of this disclosure. In some embodiments, the fundamental concept in the type system is a “type,” which is similar to a “class” in object-oriented programming languages. At least one difference between “class” in some languages and “type” in some embodiments of the type system disclosed here is that the type system is not tied to any particular programming language. As discussed here, at least some embodiments disclosed here include a model-driven architecture, where types are the models. Not only are types interfaces across different underlying technologies, they are also interfaces across different programming languages. In fact, the type system can be considered self-describing, so below is presented an overview of the types that may define the type system itself.
A type is the definition of a potentially-complex object that the system understands. Types may be the primary interface for all platform services and the primary way that application logic is organized. Some types are defined by and built into the platform itself. These types provide a uniform model across a variety of underlying technologies. Platform types also provide convenient functionality and build up higher-level services on top of low-level technologies. Other types are defined by the developers using the platform. Once installed in the environment, they can be used in the same ways as the platform types. There is no sharp distinction between types provided by the platform and types developed using the platform.
The production schedule optimization functionality described above can also be used with various enterprise functions, such as messaging, reporting, alerting, etc. processes to update systems based on triggers, detecting anomalies, real-time data streams, etc. In example enterprise environments, the production schedule optimization functionality can control or instruct manufacturing or resource planning systems. As a particular example, the production schedule optimization functionality can be used to schedule (automatically or after user approval) production of various products and may control (again automatically or after user approval) processing units to support this production.
Although
In some embodiments, the inputs 1904 may generally be classified into four groups of input data, such as product details, process details, supply chain details, and cost details. The product details relate to specific products to be or being manufactured or processed and may include product recipes, bills of material, product attributes, transition wheels (how transitions can be made between producing different products), transportation requirements, maximum/minimum lot sizes, batch sizes, product qualities, and product shelf lives. The process details relate to processes to be or being used to produce the products, such as process dependencies (like how one process may depend on another), product planning rules (like when a process can only occur on one or more specified days of the week), multi-day process definitions, a product-to-processing unit compatibility matrix (like one defining which processing units can produce which products), processing unit attributes, locked production processes, work shifts, work shift combinations, and overtime rules. The supply chain details relate to the overall supply chain in which the products are to be or are being produced and the processes used, such as a planning horizon identification, raw material lead times, good receipt processing times or dwell times, inventory management parameters, intermediate product quantities, finished good surpluses, and finished good deficits. The cost details relate to costs associated with the products or processes, such as missed demand costs, fixed overtime costs, low-priority process penalties, wasted material costs, same-day production penalties, and same-day shipment penalties. Note, however, that any other or additional inputs or input types may be used here
The production schedule optimization function 1902 here generally operates to produce at least one production schedule 1906 based on the inputs 1904. Each production schedule 1906 in this example takes the form of a series of makesheets. In this particular example, each makesheet identifies start and end times for a production task, a quantity of material to be produced, one or more input raw materials or byproducts to be used, one or more output finished goods or byproducts to be produced, and a number of makeahead days (which indicate how far ahead of time the one or more output finished goods or byproducts are being produced). The series of makesheets can thereby identify tasks to be performed in order to produce products over a specified period of time.
Although
In this example, a user has elected to view information associated with a facility, and a control 2004 (such as a drop-down menu or text search box) can be used to select a specific facility. Additional controls 2006 allow the user to access various contents related to different aspects of production schedule optimization for the selected facility. In this particular example, the controls 2006 allow the user to choose to view information about a master plan and schedule for the selected facility, inventory for the selected facility, one or more production schedule optimization scenarios that have been defined for the selected facility, and a configuration for the selected facility. General information 2008 is also provided for the selected facility, such as the current end date of the master schedule being used by the facility, an update date for the master schedule, a user who last updated the master schedule, and a status of the master schedule. A control 2010 allows the user to invoke creation of a new production schedule scenario for the facility. Controls 2012 allow the user to view various information about the selected facility, such as the current production schedule, alerts, transactions, overview, history, and parameters of the selected facility
In this example, the user has elected to view the current production schedule of the selected facility, and the graphical user interface 2000 provides a detailed production schedule 2014. In this particular example, the detailed production schedule 2014 includes various rows of production indicators 2016, where each row can be associated with a processing unit or a group of processing units. Each production indicator 2016 can identify one or more operations to be performed using the associated processing unit or group of processing units In some cases, the production indicators 2016 may be color-coded or otherwise marked to identify the types of products to be input to or output from the processing units associated with the production indicators 2016 Also, in some cases, each production indicator 2016 can have a unique identifier, and each production indicator 2016 may be selectable to view more-specific information about the one or more operations to be performed using the associated processing unit or group of processing units.
A legend 2018 can identify time periods associated with the production indicators 2016, and a control 2020 can be used to scroll through the current production schedule backwards and forwards in time Controls 2022 can be used to edit various aspects of the production schedule, such as when the controls 2022 can be used to add/modify/delete orders, edit recipes, move orders, and extend or find future open slots when operations can be scheduled. An alert section 2024 can be used to present and manage any alerts or other notifications associated with the production schedule, such as when the alert section 2024 identifies constraints that are violated using the production schedule. In some cases, the alert section 2024 can be used by the user to manage item-level alerts for unfilled demand. Also, in some cases, explainable alerts can be provided here, where the explainable alerts can provide detailed information identifying why the alerts were generated. One example of this is described below.
If the user elects to define and manage scenarios (such as via the appropriate control 2002), a graphical user interface 2100 as shown in
If the user elects to define a new scenario (such as via selection of the control 2010), a graphical user interface 2200 as shown in
In some embodiments, when an alert is presented in the graphical user interface 2000, the alert may be selected in order to view an explanation 2400 as shown in
Note that the graphical user interfaces described above may support a wide variety of features and functions depending on the implementation. For example, when a production schedule is shown, users may be given the option to view and edit fourteen-day schedules or other schedules generated by an optimizer. In some cases, users may be able to view the schedules at the product code level for each production line. Users may also view historical key performance indicators (KPIs) for things like sales, shipments, inventory levels, planned production, and actual production, and users may view planned or estimated KPIs based on the latest master schedule to be approved for use Users may be able to zoom in and zoom out of the production schedule in order to view the production schedule over various time horizons, such as over a period of several minutes to several days. Users may be allowed to edit the production schedule by adding, deleting, shifting, expanding, reducing, locking, and unlocking processing units and reverting to an original or previous schedule generated by the optimizer. Users may be able to view the impacts of changes on planned KPIs, possibly in near-real-time as the users make changes to a schedule. Users may be able to review fill rates at risk and resource utilizations based on a planned production schedule Users may be able to view downgrades made by the optimizer, view changeovers required between product codes for a scenario generated by the optimizer, and view errors and warnings for changes to a scenario that fail to meet soft and hard constraints.
When a scenario schedule is shown, users may be given the option to generate a scenario schedule with adjustable demands (such as at the product code and day levels), adjust capacity (such as at a production line level for run rate and hours of production), adjust an objective function to modify costs of production or missing demands, and adjust working days. Users may be able to edit a scenario schedule and compare the scenario schedule and a master schedule, and users may be able to promote the scenario schedule to the master schedule (meaning the master schedule is replaced with the scenario schedule). Users may be able to initiate exporting of data related to the master schedule or a scenario schedule, such as makesheets and product pick lists.
Although
It should be noted that the functions shown in or described with respect to
As shown in
Context related to templates associated with constraints and terms of at least one objective function associated with at least a portion of the one or more processing targets is identified at step 2504. This may include, for example, the processing device 202 of the application server 106 identifying various contextual information associated with constraint templates 406 and objective templates 412. The contextual information may include information such as formulation math configuration preferences, such as whether one or more constraints or objective terms should be implemented using linear, quadratic, piecewise-linear, bilinear, or other versions or whether continuous, discretized, or other formulations should be used. The contextual information may also include information identifying facility characteristics of one or more plants or portions thereof. The contextual information may further include information identifying a domain configuration, such as any domain-specific information that can control or affect how constraints and objectives are formulated. As a specific example, waste may need to be considered in one or more embodiments of one or more material balance constraint templates for the food processing industry, but waste may not need to be considered for the chemical industry. The context may be identified here in any suitable manner, such as based on user input or stored data.
Embodiments of the constraints and terms are generated to produce an optimization problem associated with at least the portion of the one or more processing targets at step 2506. This may include, for example, the processing device 202 of the application server 106 generating embodiments 408 of the constraint templates 406 and embodiments 414 of the objective templates 412. For instance, the mapping process from templates to embodiments could be accomplished using a variety of techniques, such as by using dictionary look-ups or a machine learning classification model. In some cases, a user may fill in portions of at least one of the templates, and dependency management can be used to automatically fill in other portions of the at least one template based on the information provided by the user. Also, in some cases, conflict detection can be used to identify variables or other parameters of different constraints that might conflict, and dependency reconciliation can be performed to reconcile the constraints. As particular examples, the techniques described above with respect to
Production schedule optimization is performed based on the optimization problem to produce a potential production schedule at step 2508. This may include, for example, the processing device 202 of the application server 106 using an optimizer to identify a solution to the optimization problem defined above, where the solution represents a candidate production schedule for the one or more processing targets. In some cases, the processing device 202 of the application server 106 may use the two-stage process described above to identify an overall production schedule within a planning horizon and identify a production schedule for each day or other timestep within a scheduling horizon based on the overall production schedule.
A determination is made whether an additional scenario is to be created at step 2510. This may include, for example, the processing device 202 of the application server 106 determining whether a user has requested creation of a new scenario with one or more modified constraints, objective terms, or other parameters If so, the process can return to step 2506 to generate another solution to another optimization problem, where the other solution represents another candidate production schedule for the one or more processing targets.
At some point, the candidate production schedule (or one of the candidate production schedules) can be selected for use as a master schedule at step 2512 and placed into use at step 2514. This may include, for example, the processing device 202 of the application server 106 receiving a user selection of a candidate production schedule for use as the master schedule with the one or more processing targets. The selected production schedule may be used as the master schedule until the selected production schedule has run its course or been replaced by another production schedule In some cases, this may also include the processing device 202 of the application server 106 using the selected production schedule to actually control processing units and other components in the one or more processing targets.
Note that it may be assumed above that the optimization problem is associated with the resource-task network However, as described earlier, it may be possible to divide the resource-task network into multiple sub-networks. In that case, steps 2504-2514 may be performed for each sub-network of the resource-task network In some embodiments, optimization problems associated with different sub-networks can be solved separately. In other embodiments, optimization problems associated with different sub-networks can be combined and solved collectively.
Although
In some embodiments, various functions described in this patent document are implemented or supported by a computer program that is formed from computer readable program code and that is embodied in a computer readable medium. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive (HDD), a compact disc (CD), a digital video disc (DVD), or any other type of memory A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links that transport transitory electrical or other signals. A non-transitory computer readable medium includes media where data can be permanently stored and media where data can be stored and later overwritten, such as a rewritable optical disc or an erasable storage device
It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer code (including source code, object code, or executable code). The term “communicate,” as well as derivatives thereof, encompasses both direct and indirect communication. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrase “associated with,” as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, have a relationship to or with, or the like. The phrase “at least one of,” when used with a list of items, means that different combinations of one or more of the listed items may be used, and only one item in the list may be needed. For example, “at least one of: A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.
The description in the present application should not be read as implying that any particular element, step, or function is an essential or critical element that must be included in the claim scope. The scope of patented subject matter is defined only by the allowed claims. Moreover, none of the claims invokes 35 U.S.C § 112(f) with respect to any of the appended claims or claim elements unless the exact words “means for” or “step for” are explicitly used in the particular claim, followed by a participle phrase identifying a function. Use of terms such as (but not limited to) “mechanism,” “module,” “device,” “unit,” “component,” “element,” “member,” “apparatus,” “machine,” “system,” “processor,” or “controller” within a claim is understood and intended to refer to structures known to those skilled in the relevant art, as further modified or enhanced by the features of the claims themselves, and is not intended to invoke 35 U.S.C. § 112(f).
While this disclosure has described certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.
This application claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Pat. Application No. 63/306,970 filed on Feb. 4, 2022. This provisional application is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63306970 | Feb 2022 | US |
