CONVEYOR BELT DESIGN AND PUCK NUMBER OPTIMIZATION IN MANUFACTURING NETWORK FIELD OF THE DISCLOSURE [0001] The present disclosure relates generally to designing aspects of interconnections of machines, such as conveyor belts, as in manufacturing networks. More specifically, the present disclosure relates to conveyor belt design and puck number optimization in a manufacturing network. BACKGROUND OF THE DISCLOSURE [0002] Machines used in certain scenarios and applications interact with other machines. In a manufacturing network, for example, different machines may perform different functions at different stages of the manufacturing process. The machines may be interconnected by conveyor belts that define both a downstream flow and an upstream flow relative to the production of an end product. That is, one set of conveyor belts may pertain to the supply of materials and intermediate products needed by downstream machines to ultimately generate the output of the manufacturing network. Individual pieces and/or batches of such materials and/or intermediate products may be held by a plurality of containers, referred to herein as “pucks”, being carried by said set of conveyor belts. Another set of conveyor belts may pertain to the upstream return of empty pucks that held the materials or intermediate products in place during transport from one machine to a downstream machine. [0003] Each machine may be outfitted with a variety of sensors that can monitor various aspects related to the machine to detect various issues related to the machine. For example, sensors can monitor components and/or materials that are provided to the machine and detect if/when there is an issue with the provided components/materials (e.g., a clog in a filling line). As another example, sensors can monitor moving components of the machine for proper operation (e.g., to detect if/when a grabbing or gripping device did not open, close, etc.). Each sensor may trigger an alarm associated with a detected condition. Based on the number of sensors and machines involved in a given scenario, the alarm data generated (e.g., during manufacturing of a batch of a product) can be substantial. For example, a single assembly line may include over 3000 unique types of alarms, and over 13 million alarm records may be generated during a manufacturing interval (e.g., during the manufacture of a batch of components).
30904 SUMMARY [0004] According to an exemplary embodiment, a system for manufacturing medical devices or components of medical devices includes a plurality of machines in a manufacturing network. Each machine is arranged with one or more sensors for detecting one or more fault conditions. A plurality of conveyor belts interconnects the plurality of machines. Each conveyor belt carries a number of pucks configured to hold one or more manufactured components or intermediate products. The system also includes one or more processors to receive fault data generated by the one or more sensors and input the fault data to a model that has been initialized with parameters related to the plurality of machines of the manufacturing network. The model provides data indicating expected occurrences of wait states at one or more of the plurality of machines based on the fault data. Any of the one or more processors also implement a first function that utilizes the model to obtain an estimate of at least one of an optimal capacity and an optimal number of pucks for each conveyor belt among the plurality of conveyor belts that is expected to minimize wait states of a target machine among the plurality of machines of the manufacturing network. [0005] According to another exemplary embodiment, a method of managing a manufacturing network that includes machines interconnected by a plurality of conveyor belts, with each conveyor belt carrying a number of pucks to hold one or more manufactured components or intermediate products, includes obtaining fault data associated with a plurality of machines in the manufacturing network. The method also includes inputting the fault data to a model that has been initialized with parameters related to the plurality of machines of the manufacturing network. The model provides data indicating expected occurrences of wait states at one or more of the plurality of machines based on the fault data. The method further includes implementing a first function that utilizes the model to obtain an estimate of at least one of an optimal capacity and an optimal number of pucks for each conveyor belt in the plurality of conveyor belts that minimizes modeled wait states of a target machine among the plurality of machines of the manufacturing network, according to the model. [0006] According to yet another exemplary embodiment, a system to manage a manufacturing network that includes machines interconnected by conveyor belts includes memory to store fault data associated with a plurality of machines in the manufacturing network. The system also includes a processor to input the fault data to a model that has been initialized with parameters related to the plurality of machines of the manufacturing network and implement a first function that utilizes the model to obtain an estimate of current capacity of a plurality of the conveyor belts. The processor implements a second function that utilizes
the model to obtain an estimate of optimal capacity of the plurality of conveyor belts that is expected to minimize wait states of a target machine among the plurality of machines of the manufacturing network. The target machine is in one of the wait states when the target machine does not have a fault but is not operational. The processor further estimates, based on the estimate of the current capacity and the estimate of the optimal capacity, a desired length of the plurality of the conveyor belts in the manufacturing network to minimize a wait state of the target machine. [0007] It is noted that techniques for implementing conveyor belt design and/or puck number optimization in a manufacturing network having various different features are disclosed herein, and these features may be combined in various different configurations, including configurations not specifically illustrated or discussed. Although several different combinations of such features are described herein, a person having ordinary skill in the art will realize that further such combinations not explicitly described herein are also possible and enabled by the present disclosure and are within the scope of the present application. Additionally, although various techniques are disclosed herein for attaining the disclosed features, a person having ordinary skill in the art will realize that some modifications to the disclosed techniques may be possible and within the scope of the disclosed techniques. It is also to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. BRIEF DESCRIPTION OF THE DRAWINGS [0008] Various aspects, techniques, and embodiments of the present technology disclosed herein are described below with reference to the accompanying drawings. It should be appreciated that the figures are not necessarily drawn to scale. Items appearing in multiple figures may be indicated by the same reference numeral. For purposes of clarity, not every component may be labeled in every figure. Features of the present technology will become more apparent, and techniques for how to attain the features of the present technology, will be better understood by reference to the following detailed description considered in conjunction with the accompanying drawings, wherein: [0009] FIG. 1 is a block diagram of a manufacturing system according to one or more embodiments. [0010] FIG.2A is a process flow of a method of performing conveyor belt design according to one or more embodiments.
[0011] FIG.2B is an exemplary detailed process flow of a method of performing conveyor belt design according to some embodiments. [0012] FIG.3 is a flow diagram of an exemplary model that may be defined and used in the method of performing conveyor belt design according to some embodiments. [0013] FIG.4 is a block diagram detailing aspects of the controller used in conveyor belt design according to exemplary one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION [0014] Provided herein are techniques for designing conveyor belts in a manufacturing network. The techniques can be used to determine, based on operating data, theoretical or estimated current and effective maximum capacities of upstream and/or downstream conveyor belts. Capacity or puck capacity, as used herein, refers to the number of pucks a given conveyor belt can carry. The capacity of a conveyor belt is related to its length (e.g., capacity increases as belt length increases). Maximum capacity may refer to effective maximum capacity, because the (effective) maximum number of pucks that a given conveyor belt can carry may be less than the length of the conveyor belt divided by the length of an individual puck due to stoppers or other components on the conveyor belt that prevent packing all pucks tightly side by side on the conveyor belt. The techniques can additionally or alternatively be used to determine an optimal capacity of conveyor belts (upstream and/or downstream) and/or an optimal number of pucks for each conveyor belt that can minimize waiting events at one or more target machines. Accordingly, the techniques can facilitate (a) optimization and/or design of manufacturing networks, and/or (b) mitigating or eliminating the wait times resulting at one or more machines in the manufacturing network, such as due to a fault in another machine within the manufacturing network. [0015] The inventors have recognized and appreciated the need to reduce wait times at machines in a manufacturing network by leveraging the supply of components or intermediate products that are in transport on conveyor belts. When a given machine experiences a fault, the fault can result in wait times at other machines. A fault state refers to a non-operational state because of an internal fault or failure in a given machine, while a wait state refers to a non-operational state that is not caused by an internal fault in a given machine. A given machine may experience a wait state because of a lack of input material or intermediate components (from an upstream machine) needed to perform the function of the given machine. A wait state may also result from a lack of empty pucks (returned from a
downstream machine) on which the given machine can supply its output downstream or from a lack of capacity in and/or stoppage of the downstream conveyor belt due to a downstream issue preventing the immediate downstream machine from accepting the output of the given machine. [0016] For example, downstream machines that need a component or intermediate product directly or indirectly from the faulty machine may have to wait for the faulty machine to resume normal operation (e.g., so that the downstream machine can receive a puck or other storage component with the needed component or intermediate product). Similarly, upstream machines that directly or indirectly supply the faulty machine may have to wait to continue the supply (e.g., to wait for empty pucks from upstream that can be filled and passed back downstream once filled). The wait state at a given machine is tied to the condition of the conveyor belts to and from the given machine. That is, an empty incoming conveyor belt (e.g., because an upstream machine is faulty and, thus, not supplying a component or intermediate product) can result in a waiting event. Similarly, a full outgoing conveyor belt (e.g., because a downstream machine is faulty and, thus, not using the output of the given machine) can also result in a waiting event. [0017] The inventors recognized that the longer the conveyor belts within the manufacturing network, the higher the capacity for the output of each machine and, thus, the bigger the buffer for a fault. For example, a downstream machine will not encounter an empty incoming conveyor belt for a longer duration following a fault in an upstream machine if the incoming conveyor belt is longer and, thus, holds more output generated prior to the fault. Similarly, an upstream machine will not encounter a full outgoing conveyor belt for a longer duration following a fault in a downstream machine if the outgoing conveyor belt is longer and has a higher capacity to hold the upstream machine’s output. The longer duration facilitates more time and opportunity to address a fault at a particular machine and resume normal operation with minimal disruption to other machines in the manufacturing network. The inventors appreciated that some conveyor belts’ lengths reduce or preclude the ability to dampen faults in this manner because pucks cannot accumulate without limit. At the same time, the inventors have recognized the need to balance increased length of the conveyor belts with the space and other constraints of a manufacturing facility. By designing the conveyor belts to minimize wait time at a target machine (e.g., the machine with the lowest throughput (number of pucks processed per time interval) among the machines of the
30904 manufacturing network), the inventors have recognized that wait times caused by faults can be reduced throughout the manufacturing network. [0018] Accordingly, as described in detail herein, the inventors have developed various techniques that can be used to determine the length of each conveyor belt that will result in reducing wait times throughout the manufacturing network and, in particular, at a specific target machine. In some embodiments, the techniques can take as input actual or synthesized operating data and output an estimated or theoretical current capacity and effective maximum capacity of conveyor belts in the manufacturing network. In some embodiments, the techniques can estimate an optimal capacity that minimizes the incidence of waiting events at a target machine. In some embodiments, the techniques can also estimate an optimal number of pucks to provide on each conveyor belt so as to minimize the incidence of waiting events at a target machine. These and other techniques described herein can be used to set up a new manufacturing line and/or to optimize an existing line. For example, the techniques can be used to plan an optimization of an assembly line by determining how much to adjust a conveyor belt, or how much to adjust the number of pucks on the conveyor belt, and informing that the adjustment is expected to reduce the incidence of waiting at a particular machine by a particular duration or percentage. [0019] Following below are more detailed descriptions of various concepts related to, and embodiments of, techniques described above. It should be appreciated that various aspects described herein may be implemented in any of numerous ways. Examples of specific implementations are provided herein for illustrative purposes only. In addition, the various aspects described in the embodiments below may be used alone or in any combination and are not limited to the combinations explicitly described herein. In particular, the term “manufacturing” should be interpreted broadly to include not only making, assembling, or creating items, but also inspecting, processing, sorting, and/or packaging items. Generally, the conveyor belt design facilitates a decrease in disruption to machines in the manufacturing network based on a fault in another machine. [0020] FIG.1 is a block diagram of a manufacturing system 100 according to one or more embodiments. The manufacturing system 100 includes a manufacturing network 105. The exemplary manufacturing network 105 shown in FIG.1 includes machines 110-1 through 110-8 (generally referred to as machine (s)110) interconnected by downstream- moving conveyer belts 120a1 through 120g1 (generally referred to as downstream-moving conveyor belt(s) 120) and upstream-moving conveyor belts 120a2 through 120g2 (generally
30904 referred to as upstream-moving conveyor belt(s) 120). For example, machines 110-1 and 110-2 are connected by conveyor belts 120a1 and 120a2, and machines 110-7 and 110-8 are connected by conveyer belts 120g1 and 120g2. Specifically, machines 110-1 and 110-7 are respectively supplied by downstream-moving conveyor belts 120a1 and 120g1 and return empty pucks via upstream-moving conveyor belts 120a2 and 120g2. [0021] As used herein, a conveyor belt 120 is said to be “downstream” of a machine 110 if the conveyor belt 120 is situated closer to the output of the manufacturing network 105 than the machine 110, while a conveyor belt 120 is said to be “upstream” of a machine 110 if the conveyor belt 120 is situated farther from the output of the manufacturing network 105 than the machine 110. This is so regardless of whether the conveyor belt 120 is a downstream-moving conveyor belt 120 or an upstream-moving conveyor belt 120. For example, downstream-moving conveyor belt 120c1 and upstream-moving conveyor belt 120c2 are both said to be “downstream” of machine 110-4, while downstream-moving conveyor belt 120d1 and upstream-moving conveyor belt 120d2 are both said to be “upstream” of machine 110-4. For a given machine 110, an upstream-moving or downstream-moving conveyor belt 120 that connects the given machine 110 to an upstream machine 110 is “upstream” of the given machine 110. Similarly, an upstream-moving or downstream-moving conveyor belt 120 that connects the given machine 110 to a downstream machine 110 is “downstream” of the given machine 110. [0022] The exemplary illustration in FIG.1 is not intended to limit the numbers or arrangements of machines 110 that make up a manufacturing network 105. For example, machines 110-3, 110-5, 110-6, 110-8 are shown obtaining inputs of raw materials or components from outside the manufacturing network 105, while a product is shown output from machine 110-1. In alternate arrangements, other machines 110 in the manufacturing network 105 (e.g., machine 110-1, 110-2, 110-4, and/or 110-7) may also obtain input from outside the manufacturing network 105. The specific numbers of machines 110 and their configuration is not limited by the embodiments detailing aspects of conveyor belt design. Embodiments of the conveyor belt design may be applied to an existing manufacturing network 105 (e.g., to adjust the lengths of existing conveyor belts 120) or to a new manufacturing network 105 (e.g., to determine the lengths of conveyor belts 120 to be installed between specified pairs of machines 110). [0023] Exemplary sensors 125 are indicated in FIG.1. Sensors 125 are shown at an interface between a machine 110 and conveyor belt 120 and within some machines 110.
30904 Each sensor 125 may be associated with one or more alarms 126. For example, sensors 125 may be positioned to monitor operation of actuators and pushers within the manufacturing network 105. Sensors 125 may be positioned at different areas, referred to as stations, for example, within machines 110. These sensors 125 may activate an alarm if expected components are not at the station to facilitate further production. For example, a sensor 125 may indicate that a linear track at a given station within a given machine 110 is starved for components. It should be appreciated that these examples are only illustrative and not indicative of the numerous sensors 125 and associated alarms 126 that may be distributed throughout a given manufacturing network 105. [0024] For purposes of conveyor belt design, according to some embodiments, fault data may be obtained from the sensors 125 as a 1 x T vector ^
^ associated with each machine 110-i, with T representing a duration made up of a number of time intervals t and the value of ^
^ being 1 if the machine 110-i is stopped at time interval t due to an internal fault or 0 otherwise. Additionally, the sensors 125 may be used to obtain observed waiting data ^
^,^^^ for each machine 110-i, which is a 1 x T vector of 1 (indicating a wait state for a given time interval t) or 0 (indicating no wait at interval t). In alternate embodiments (e.g., when a new manufacturing network 105 is being designed), the fault data ^
^ and observed waiting data ^
^,^^^ may be simulated and/or may be generated from
by sensors 125 in other manufacturing networks 105. [0025] The manufacturing system 100 also includes a controller 130 that may perform aspects of the conveyor belt design detailed herein to facilitate reduction in wait times in the manufacturing network 105. The controller 130 is further discussed with reference to FIG.4. The controller 130 may obtain data from one or more sensors 125 of the manufacturing network 105, may obtain or generate synthetic data (e.g., simulated data synthesized through a simulation), and/or may obtain data from one or more other manufacturing networks (e.g., with the same or a similar configuration of machines). For example, the controller 130 may obtain ^
^ and ^
^,^^^ vectors for each machine 110-i. The
controller 130 may additionally obtain
ideal throughput ^^ ^ for each machine 110-i from a manufacturer of each machine 110-i and/or from historical data related to each machine 110-i
or its type, where throughput ^^ ^ indicates a number of components that machine 110-i is expected to complete per
time.
[0026] As further discussed with reference to FIG.2B, the controller 130 may implement a model to determine the conveyor belt state vectors ^
^^^ (representing a current state of conveyor belts in the manufacturing network) and ^
^^^ (representing an optimal state of conveyor belts in the manufacturing network, as discussed and explained further herein). Generally, for each pair of machines, 110-i and 110-j, in the manufacturing network 105 that is connected by downstream-moving and upstream-moving conveyor belts 120, vector θ includes ^
^ ^ ,
^ and ^
^ ^ ,
^ , the number of (supply or return) pucks on a conveyor belt 120 from machine 110-j and from machine 110-j to machine 110-i, respectively. The
^
^ ^ ,
^ and ^
^ ^ ,
^ may also be referred to herein as the “load” or “loading” on the conveyor machine 110-i to machine 110-j and from machine
110-j to machine 110-i, The vector θ also includes ^
^ ^ ,
^ ^^ and ^
^ ^ ,
^ ^^, which indicate the maximum number of pucks that may be carried by a conveyor belt 120 from machine 110-i to machine 110-j and from machine 110-j to machine 110-i, respectively. For example, ^
^ ^ ,^ may indicate the number of pucks with a component or intermediate product provided by machine 110-7 to machine 110-4 on downstream conveyor belt 120f1 (i.e., the “load” on downstream-moving conveyor belt 120f1), while ^
^ ^ ,^ may indicate the number of empty pucks provided by machine 110-4 to machine 110-
upstream conveyor belt 120f2 (i.e., the “load” on upstream-moving conveyor belt 120f2). Similarly, ^
^ ^ ,^ ^^ may indicate the maximum number of pucks that may be carried on downstream-moving conveyor belt 120f1 going from machine 110-7 to machine 110-4, while ^
^ ^ ,
^ ^^ may indicate the maximum number of empty pucks that may be carried on upstream-
conveyor belt 120f2 going from machine 110-4 to machine 110-7. Thus, each pair of machines, 110-i and 110-j, in the manufacturing network 105 that directly interacts with each other generates four values comprising part of the vector θ = (…, ^
^ ^ ,
^ , ^
^ ^ ,
^ , ^
^ ^ ,
^ ^^, ^
^ ^ ,
^ ^^, …). [0027] In some embodiments, the
^
^ ^ ,
^ ^^ may not be known and may not be straightforward to determine, even in the
conveyor belt state vector ^
^^^. Instead, as detailed with reference to FIG.2B, the controller 130 may use a function (e.g., argmin) along with the model to determine the current conveyor belt state vector ^
^^^ and optimal conveyor belt state vector ^
^^^. The controller 130 may then determine the desired conveyor belt lengths using the current conveyor belt state vector ^
^^^ and optimal conveyor belt state vector ^
^^^.
[0028] FIG.2A is a process flow of a method 200 of performing conveyor belt design according to one or more embodiments. The method 200 may be performed based on identification of one of the machines 110 in the manufacturing network 105 as a target machine 110. At 210, obtaining observed wait states refers to historic or synthesized waiting events at various machines 110 of the manufacturing network 105. At 220, obtaining fault data refers to historic or synthesized fault events at the various machines 110. As previously noted, while fault events correspond to non-operation of a machine 110 due to an internal fault, waiting events correspond to non-operation of a machine 110 that does not have an internal fault but, instead, is not operational due to a fault at another (upstream or downstream) machine 110 or some other event that has disrupted the normal flow of pucks on the conveyor. [0029] At 240, obtaining an estimate of current conveyor belt capacity may include using a model, as detailed with reference to FIG.2B, and may include estimating maximum conveyor belt capacity for a current or hypothetical (synthesized) manufacturing network 105. At 250, obtaining an estimate of optimal conveyor belt capacity may include using the model to minimize waiting events at the target machine 110. The functions at 240 and 250 generally may be computations or series of computations that generate an output based on a set of input parameters. Non-limiting examples of functions are discussed with reference to 240’ and 250’ in FIG.2B. The model (e.g., model 300, FIG.3) may generally be a computational algorithm, process, or module that predicts or simulates the behavior of some aspect of a modeled system (e.g., manufacturing network 105) based on certain input parameters (e.g., fault data ^
^). [0030] According to some embodiments, achieving the optimal conveyor belt capacity, determined at 250, to minimize waiting events at the target machine 110 may involve designing or adjusting conveyor belt lengths, as discussed with reference to 270. As discussed with reference to 250’, minimizing waiting events at the target machine 110 may instead be achieved by determining an optimal number of pucks (i.e., loading) for a fixed length of some or all of the conveyor belts 120 (i.e., optimizing conveyor belt capacity by adjusting only puck loading) according to some alternate embodiments. According to other alternate embodiments, conveyor belt lengths and number of pucks on each conveyor belt 120 may both be optimized to obtain optimal conveyor belt capacity. Once the optimal conveyor belt capacity, loading, and/or both are determined, these parameters may be input
30904 into the model (e.g., model 300, FIG.3) to estimate expected waiting times at the target machine 110 resulting from such parameters. [0031] At 270, estimating desired length of the conveyor belts may include using the estimated current conveyor belt capacity and the estimated optimal conveyor belt capacity. More specifically, the estimate of current conveyor belt capacity may be used to determine a relationship between belt lengths and belt capacity. This relationship may then be used with the estimated optimal conveyor belt capacity to estimate desired length of the conveyor belts for modification or installation in a manufacturing network 105. [0032] No matter whether optimal conveyor belt design is determined and addressed via conveyor belt lengths, puck loading, or a combination of the two, once the optimization is implemented, resulting wait times may optionally be compared with expected wait times. That is, as discussed with reference to 250, the optimal conveyor belt capacity is determined with a goal of minimizing waiting events at a target machine 110. Once the optimal conveyor belt capacity is implemented, waiting events at the target machine 110 may be observed over a monitored time period having some duration. Waiting events at the target machine 110 may be determined using data from sensors 125, or another set of sensors (not shown). If the number of observed (actual) waiting events at the target machine 110 differs from the expected (optimal) waiting events at the target machine 110, an alert may be issued or another output may be provided, as indicated in FIG.2B (280’). Alternatively or in addition, a cumulative wait time experienced by the target machine 110 during the monitored time period may be computed based on the observed waiting events. This cumulative wait time may be compared to an expected cumulative wait time output by the model (e.g., model 300). If the observed cumulative wait time experienced by the target machine 110 during the monitored time period differs from the expected (optimal) cumulative wait time experienced by the target machine 110, an alert may be issued or another output may be provided, as indicated in FIG.2B (280’). [0033] FIG.2B is an exemplary detailed process flow of a method 200’ of performing conveyor belt design according to some embodiments. The method 200’ is performed by first identifying or selecting a target machine 110 among the machines 110 of the manufacturing network 105. As previously noted, the target machine 110 may have the lowest throughput (number of pucks processed per time interval) among all the machines 110 of the manufacturing network 105, for example.
30904 [0034] At 210’, obtaining observed wait states refers to obtaining observed waiting data ^
^,^^^ for each machine 110-i from one or more sensors 125 and/or through simulation. As previously noted, the value of the observed waiting data ^
^,^^^ for a given machine 110-i at a given time interval may be 0 (to indicate no wait) or 1 (to indicate wait). At 220’, obtaining fault data ^
^ for each machine 110-i may involve obtaining data from one or more sensors 125 and/or through simulation. As previously noted, the values of the vector of fault data ^
^ for a given machine 110-i at a given time interval may be 0 (to indicate no internal fault) or 1 (to indicate an internal fault). At 230’, a model 300 is defined or obtained as further discussed with reference to FIG.3. The model 300 defined or obtained at 230’ is used in the minimization functions at 240’ and 250’. [0035] FIG.3 is a flow diagram of an exemplary model 300 that may be defined or obtained (at 230’) and used in the method 200’ of performing conveyor belt design according to some embodiments. Generally, the model 300 uses conveyor belt state vector θ and historical or simulated fault data ^
^ for each machine 110-i in the manufacturing network to provide estimated waiting data wi for a specific target machine i. Thus, the model 300 may be
expressed as wi(θ, ^^) or wi(θ, ^^, ^^, … , ^^) assuming N machines 110 in the manufacturing network 105, and with fi = 0 a wait at machine 110-i assumes that the fault is not at
machine 110-i). As indicated, ideal throughput ^^ ^ is used in the model 300, along with conveyor belt state vector θ and fault data ^
^. The conditions indicated for Ii apply, as well, to Ij with nij and nji reversed. That is, Ij =
^^^
when nji = ^
^,^ (blocked), nij = 0 (starved), or fj = 1 (faulted).
[0036] The model simulates the number of pucks on each conveyor belt (nij) between each pair of machines 110-i and 110-j for each time step of a plurality of time steps within a simulated period. At each time step, the number nij is updated according to the set of rules shown within the box labeled "Model" in FIG.3. Specifically, the rate at which the number ^ of pucks on a certain conveyor belt connecting machine 110-i to machine 110-j, (
^^ ^
^^), is
equal to ^^ ^ (the number of pucks being put onto the belt by machine 110-i) minus ^^ ^ (the number of pucks being taken off the belt by machine 110-j). The only times when this might not be true is captured by the conditions I
i and I
j. Specifically, the number of pucks will not
increase by ^^ ^ if the conveyor belt going from machine 110-i to machine 110-j is full (i.e., nij = ^
^ ^ ^
^^), or
return conveyor belt from machine 110-j to machine 110-i is empty and not supplying empty pucks (i.e., n
ji = 0), or machine 110-i is in a fault state (i.e., f
i = 1). The model is initialized by setting the starting number of pucks on each conveyor belt equal to
30904 ^
^ ^ ^ , then the model is run for a plurality of time steps. In this way, the model can simulate or estimate the number of pucks n (i.e., loading) on each conveyor belt 120 for each time step. And from that simulated number of pucks, the model can determine when machine 110-i is in a wait state (w
i) because it is (i) starved of upstream incoming pucks bearing needed input materials or components, (ii) unable to offload completed pucks bearing completed components to its offloading conveyor belt, (iii) starved of empty pucks from its downstream machine, and/or (iv) unable to offload empty pucks to its upstream machine. [0037] Returning to the method 200’ detailed in FIG.2B, at 240’, the model (defined at 230’) is used to determine the current conveyor belt state vector θcur. Specifically, a minimization function is used to determine the values of ^
^ ^ ,
^ , ^
^ ^ ,
^ , ^
^ ^ ,
^ ^^, ^
^ ^ ,
^ ^^ for each pair of machines 110-i and 110-j that are connected in a difference between the
observed waiting data ^
^,^^^ and the output of the way, the current conveyor belt state vector θcur should provide the observed waiting data ^
^,^^^ such that, ideally, the difference between the observed waiting data ^
^,^^^ and the output of the model 300 is a 1 x T vector of 0s. The double-sided arrow between 230’ and 240’ indicates the iterative nature of the processes at 240’ (e.g., iterative gradient descent algorithm). As indicated in FIG.2B, the current conveyor belt state vector θ
cur may be determined from: ^
= !"^#^ ∑ ^ − ^ (), ^ , , + ^ ^
^^ $ ^ & ^,^^^ ^ ^ ^^ … ^* & , [EQ.1] Each
operation &^^,^^^ − ^^(), ^^, ^^, … ^*+&^ provides a scalar value (for each machine 110-i) that
vectors in the time space (T). Thus, the minimization function aims to obtain the conveyor belt state vector θ that minimizes a sum of the scalar values over all the machines 110-i. [0038] At 250’, the model 300 may be used again (iteratively, as indicated by the double-sided arrow between 230’ and 250’) to determine an optimal conveyor belt state vector θopt. In this case, the model 300 may be used only for the target machine 110. That is, instead of w
i for all the machines 110-i, the model may be implemented to obtain w
target for the target machine 110-target. Then the optimal conveyor belt state vector θopt may be determined from: ^
= !"^#^ ^- , ^^, ^^, … ^^+&^ + 3 +
30904 The term C(θ) may be added as a penalty related to belt length, for example. The term C(θ) term may be used to introduce a practical component to the theoretical consideration of puck capacity in minimizing wait times. The term C(θ) may be a function of capacity of each conveyor belt 120 to carry pucks (which, in turn, is a function of belt length and puck dimensions) and may increase with belt length. The term C(θ) may also be affected by factors such as space constraints or other limitations within the manufacturing facility that houses the manufacturing network 105. That is, while wait times w
i may theoretically decrease with increasing puck capacity and corresponding belt length, the term C(θ) penalizes and, thus, constrains belt length increase and helps ensure that optimal belt length according to EQ.2 is feasible. An iterative gradient descent algorithm or other known techniques may be used to solve the minimization functions in both EQs.1 and 2. [0039] As previously noted, the optimal conveyor belt state vector θopt determined at 250’ includes (…, ^
^ ^ ,
^ , ^
^ ^ ,
^ , ^
^ ^ ,
^ ^^, ^
^ ^ ,
^ ^^, …) for a given pair of machines, 110-i and 110-j. According to the conveyor belt lengths may be regarded as fixed. In
this case, ^
^ ^ ,
^ ^^ and which indicate the maximum number of pucks that may be carried by a machine 110-i to machine 110-j and from machine 110-j to
machine 110-i, respectively, would be unchanged for the current conveyor belt state vector θ
cur and the optimal conveyor belt state vector θ
opt. Instead, the minimization function of EQ. 2 would solve for the new number of pucks ^
^ ^ ,
^ and ^
^ ^ ,
^ (i.e., the new loading) to obtain the optimal conveyor belt state vector θopt as
the previous number of pucks ^
^ ^ ,
^ and ^
^ ^ ,
^ used to obtain the current conveyor belt state vector θcur. According to the alternate when conveyor belt lengths cannot be adjusted due to space limitations in the manufacturing facility, for example, wait times may still be reduced by adjusting loading instead. Loading may be adjusted by simply increasing or decreasing the number of pucks (if space is available on the conveyor belts 120) or, as noted below, by adjusting puck size. [0040] At 260’, the current (effective) conveyor belt lengths are obtained. In the case of a new manufacturing facility, the current conveyor belt lengths may refer to lengths that were assumed in order to obtain the simulated observed waiting data ^
^,^^^ and simulated fault data ^
^ . Puck capacity of a given conveyor belt 120 is affected by puck width, as well as by belt length. That is, for the same conveyor belt 120, puck capacity may be increased by decreasing width of the pucks. According to exemplary embodiments, a given puck width is assumed to be known and unchanged, for both an existing manufacturing network 105 and a new manufacturing facility. As such, effective conveyor belt length alone
30904 may be considered for adjusting puck capacity according to some embodiments. According to other embodiments, puck width may be changed along with conveyor belt length. [0041] At 270’, the obtained current conveyor belt state vector θ
cur (from 240’), optimal conveyor belt state vector θopt (from 250’), and current conveyor belt lengths (from 260’) may be used to determine desired conveyor belt lengths. These may be regarded as optimal conveyor belt lengths (for a given puck width) that result in the optimal conveyor belt state vector θ
opt and the desired length of each conveyor belt between each pair of connected machines 110-i and 110-j may be obtained as: ^^^^45^ 6457^8 ^9 ^46^ 9^^^ ^ ^^ ^
× D^^^^ ^ ^!E^ )^^^F [EQ. 3] $5
<=> 9^
,^ :,; ^^ ?
@AB, for the
×
D^ ^!E^ )^ F [EQ. 4] $5
<=> 9^^^ ? ,
^,^ ^^ ;,: @AB for the processes
at 270’, a new manufacturing network 105 may be assembled or an existing manufacturing network 105 may be modified such that the conveyor belts have the determined desired lengths. As previously noted, at 270’, the optimal conveyor belt design determined at 250’ may alternately or additionally be achieved via changing the number of pucks on the conveyor belts 120 (i.e., loading). [0042] At 280’, the effect of any optimization action taken at 270’ may optionally be monitored. The optimization performed as part of the processes at 270’ aims to minimize the waiting events at a target machine 110-target. Thus, after adjustment of the conveyor belt lengths and/or loading according to 270’, waiting events at the target machine 110-target may be observed for some duration of time, e.g., during a monitored time period. This monitoring may be repeated over several durations, for example. If the observed number of waiting events or the observed cumulative wait time at the target machine 110-target during the monitored time period differs from the wtarget for the target machine 110-target obtained at 250’ (i.e., the expected number of waiting events or expected cumulative duration of waiting events at the target machine 110-target based on the optimization), an alert may be issued or another output may be provided. The difference between the observed number and/or cumulative duration of waiting events and wtarget may be compared with a threshold value, and action (e.g., alert) may be taken based on the difference exceeding the threshold value or based on an average of the difference over multiple durations exceeding the threshold value, for example.
30904 [0043] FIG.4 is a block diagram detailing aspects of the controller 130 that performs conveyor belt design according to exemplary one or more embodiments. The controller 130 may include one or more processors 410 that implement the processes shown in FIGs.2A and 2B, for example. Instructions processed by the one or more processors 410 to implement the method 200 (or, more particularly 200’ according to some embodiments) may be stored in non-transitory computer-readable media such as non-volatile storage 420, for example. Any one or more processors 410 may be referred to as “a processor,” and subsequent reference to “the processor” should be interpreted to refer to any one or more of the processors 410. That is different ones of the processors 410 may implement different aspects of the method 200 and other processes discussed herein. Memory 430 may store fault data fi and other data. A display 440 may indicate changepoints associated with alarm patterns, for example. [0044] Techniques operating according to the principles described herein may be implemented in any suitable manner. The processing and decision blocks of the flow charts above represent steps and acts that may be included in algorithms that carry out these various processes. Algorithms derived from these processes may be implemented as software integrated with and directing the operation of one or more single- or multi-purpose processors, may be implemented as functionally-equivalent circuits such as a Digital Signal Processing (DSP) circuit or an Application-Specific Integrated Circuit (ASIC), or may be implemented in any other suitable manner. It should be appreciated that the flow charts included herein do not depict the syntax or operation of any particular circuit or of any particular programming language or type of programming language. Rather, the flow charts illustrate the functional information one skilled in the art may use to fabricate circuits or to implement computer software algorithms to perform the processing of a particular apparatus carrying out the types of techniques described herein. It should also be appreciated that, unless otherwise indicated herein, the particular sequence of steps and/or acts described in each flow chart is merely illustrative of the algorithms that may be implemented and can be varied in implementations and embodiments of the principles described herein. [0045] Accordingly, in some embodiments, the techniques described herein may be embodied in computer-executable instructions implemented as software, including as application software, system software, firmware, middleware, embedded code, or any other suitable type of computer code. Such computer-executable instructions may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.
30904 [0046] When techniques described herein are embodied as computer-executable instructions, these computer-executable instructions may be implemented in any suitable manner, including as a number of functional facilities, each providing one or more operations to complete execution of algorithms operating according to these techniques. A “functional facility,” however instantiated, is a structural component of a computer system that, when integrated with and executed by one or more computers, causes the one or more computers to perform a specific operational role. A functional facility may be a portion of or an entire software element. For example, a functional facility may be implemented as a function of a process, or as a discrete process, or as any other suitable unit of processing. If techniques described herein are implemented as multiple functional facilities, each functional facility may be implemented in its own way; all need not be implemented the same way. Additionally, these functional facilities may be executed in parallel and/or serially, as appropriate, and may pass information between one another using a shared memory on the computer(s) on which they are executing, using a message passing protocol, or in any other suitable way. [0047] Generally, functional facilities include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the functional facilities may be combined or distributed as desired in the systems in which they operate. In some implementations, one or more functional facilities carrying out techniques herein may together form a complete software package. These functional facilities may, in alternative embodiments, be adapted to interact with other, unrelated functional facilities and/or processes, to implement a software program application. [0048] Some exemplary functional facilities have been described herein for carrying out one or more tasks. It should be appreciated, though, that the functional facilities and division of tasks described is merely illustrative of the type of functional facilities that may implement the exemplary techniques described herein, and that embodiments are not limited to being implemented in any specific number, division, or type of functional facilities. In some implementations, all functionality may be implemented in a single functional facility. It should also be appreciated that, in some implementations, some of the functional facilities described herein may be implemented together with or separately from others (i.e., as a single unit or separate units), or some of these functional facilities may not be implemented. [0049] Computer-executable instructions implementing the techniques described herein (when implemented as one or more functional facilities or in any other manner) may,
30904 in some embodiments, be encoded on one or more computer-readable media to provide functionality to the media. Computer-readable media include magnetic media such as a hard disk drive, optical media such as a Compact Disk (CD) or a Digital Versatile Disk (DVD), a persistent or non-persistent solid-state memory (e.g., Flash memory, Magnetic RAM, etc.), or any other suitable storage media. Such a computer-readable medium may be implemented in any suitable manner. As used herein, “computer-readable media” (also called “computer- readable storage media”) refers to tangible storage media. Tangible storage media are non- transitory and have at least one physical, structural component. In a “computer-readable medium,” as used herein, at least one physical, structural component has at least one physical property that may be altered in some way during a process of creating the medium with embedded information, a process of recording information thereon, or any other process of encoding the medium with information. For example, a magnetization state of a portion of a physical structure of a computer-readable medium may be altered during a recording process. [0050] Further, some techniques described above comprise acts of storing information (e.g., data and/or instructions) in certain ways for use by these techniques. In some implementations of these techniques—such as implementations where the techniques are implemented as computer-executable instructions—the information may be encoded on a computer-readable storage media. Where specific structures are described herein as advantageous formats in which to store this information, these structures may be used to impart a physical organization of the information when encoded on the storage medium. These advantageous structures may then provide functionality to the storage medium by affecting operations of one or more processors interacting with the information; for example, by increasing the efficiency of computer operations performed by the processor(s). [0051] In some, but not all, implementations in which the techniques may be embodied as computer-executable instructions, these instructions may be executed on one or more suitable computing device(s) operating in any suitable computer system, or one or more computing devices (or one or more processors of one or more computing devices) may be programmed to execute the computer-executable instructions. A computing device or processor may be programmed to execute instructions when the instructions are stored in a manner accessible to the computing device or processor, such as in a data store (e.g., an on- chip cache or instruction register, a computer-readable storage medium accessible via a bus, a computer-readable storage medium accessible via one or more networks and accessible by the device/processor, etc.). Functional facilities comprising these computer-executable instructions may be integrated with and direct the operation of a single multi-purpose
30904 programmable digital computing device, a coordinated system of two or more multi-purpose computing device sharing processing power and jointly carrying out the techniques described herein, a single computing device or coordinated system of computing device (co-located or geographically distributed) dedicated to executing the techniques described herein, one or more Field-Programmable Gate Arrays (FPGAs) for carrying out the techniques described herein, or any other suitable system. [0052] A computing device may comprise at least one processor, a network adapter, and computer-readable storage media. A computing device may be, for example, a desktop or laptop personal computer, a personal digital assistant (PDA), a smart mobile phone, a server, or any other suitable computing device. A network adapter may be any suitable hardware and/or software to enable the computing device to communicate wired and/or wirelessly with any other suitable computing device over any suitable computing network. The computing network may include wireless access points, switches, routers, gateways, and/or other networking equipment as well as any suitable wired and/or wireless communication medium or media for exchanging data between two or more computers, including the Internet. Computer-readable media may be adapted to store data to be processed and/or instructions to be executed by processor. The processor enables processing of data and execution of instructions. The data and instructions may be stored on the computer-readable storage media. [0053] A computing device may additionally have one or more components and peripherals, including input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output. Examples of input devices that can be used for a user interface include keyboards, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computing device may receive input information through speech recognition or in other audible format. [0054] Embodiments have been described where the techniques are implemented in circuitry and/or computer-executable instructions. It should be appreciated that some embodiments may be in the form of a method, of which at least one example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.
30904 [0055] Various aspects of the embodiments described above may be used alone, in combination, or in a variety of arrangements not specifically discussed in the embodiments described in the foregoing and is therefore not limited in its application to the details and arrangement of components set forth in the foregoing description or illustrated in the drawings. For example, aspects described in one embodiment may be combined in any manner with aspects described in other embodiments. [0056] Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements. [0057] Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” “having,” “containing,” “involving,” and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. [0058] The word “exemplary” is used herein to mean serving as an example, instance, or illustration. Any embodiment, implementation, process, feature, etc. described herein as exemplary should therefore be understood to be an illustrative example and should not be understood to be a preferred or advantageous example unless otherwise indicated. [0059] To clarify the use of and to hereby provide notice to the public, the phrases “at least one of <A>, <B>, ... and <N>” or “at least one of <A>, <B>, ... <N>, or combinations thereof” or “<A>, <B>, ... and/or <N>” are defined by the Applicant in the broadest sense, superseding any other implied definitions hereinbefore or hereinafter unless expressly asserted by the Applicant to the contrary, to mean one or more elements selected from the group comprising A, B, ... and N. In other words, the phrases mean any combination of one or more of the elements A, B, ... or N including any one element alone or the one element in combination with one or more of the other elements which may also include, in combination, additional elements not listed. [0060] While various embodiments have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible. Accordingly, the embodiments described herein are examples, not the only possible embodiments and implementations. Furthermore, the advantages described above are not
30904 necessarily the only advantages, and it is not necessarily expected that all of the described advantages will be achieved with every embodiment. [0061] Various aspects are described in this disclosure, which include, but are not limited to, the following aspects: [0062] 1. A system for manufacturing medical devices or components of medical devices, the system comprising: a plurality of machines in a manufacturing network, each machine configured with one or more sensors for detecting one or more fault conditions; a plurality of conveyor belts interconnecting the plurality of machines, wherein each conveyor belt carries a number of pucks configured to hold one or more manufactured components or intermediate products; and one or more processors configured to: receive fault data generated by the one or more sensors, input the fault data to a model that has been initialized with parameters related to the plurality of machines of the manufacturing network, wherein the model provides data indicating expected occurrences of wait states at one or more of the plurality of machines based on the fault data, and implement a first function that utilizes the model to obtain an estimate of at least one of an optimal capacity and an optimal number of pucks for each conveyor belt among the plurality of conveyor belts that is expected to minimize wait states of a target machine among the plurality of machines of the manufacturing network. [0063] 2. The system according to aspect 1, wherein the processor is further configured to: implement a second function that utilizes the model to obtain an estimate of current capacity for each conveyor belt of the plurality of conveyor belts; and estimate, based on the estimate of current capacity and the estimate of optimal capacity for each conveyor belt, a desired length for each conveyor belt in the plurality of conveyor belts to minimize the wait states of the target machine. [0064] 3. The system according to aspect 2, wherein estimating the desired length of the plurality of conveyor belts is based additionally on current lengths of the plurality of the conveyor belts. [0065] 4. The system according to any one of aspects 2-3, further comprising obtaining or synthesizing observed wait states for the machines of the manufacturing network, wherein implementing the second function includes estimating a current capacity for each conveyor belt of the plurality of the conveyor belts that results in modeled wait states for the machines of the manufacturing network, provided by the model, that approximate the observed wait states for the machines of the manufacturing network.
30904 [0066] 5. The system according to aspect 4, wherein implementing the second function includes performing an iterative gradient descent algorithm on a minimization function minimizing a difference between the modeled wait states and the observed wait states. [0067] 6. The system according to any of aspects 1-5, wherein implementing the first function includes performing an iterative gradient descent algorithm on a minimization function minimizing the modeled wait states for the target machine. [0068] 7. The system according to aspect 6, wherein implementing the first function includes estimating the optimal capacity subject to user-defined constraints on lengths of the plurality of conveyor belts in the manufacturing network. [0069] 8. The system according to aspect 1, wherein implementing the first function includes estimating the optimal number of pucks for each conveyor belt in the plurality of conveyor belts subject to user-defined constraints on the capacity of each conveyor belt in the plurality of conveyor belts in the manufacturing network. [0070] 9. The system according to aspect 8, wherein the user-defined constraints on the capacity of each conveyor belt is equal to the current capacities of each conveyor belt. [0071] 10. The system according to any of aspects 1-9, wherein the model is initialized with an expected throughput indicating a number of components expected to be processed per unit time for each machine in the plurality of machines. [0072] 11. The system according to aspect 10, wherein the model simulates a number of pucks on each conveyor belt of the plurality of conveyor belts for each time step of a plurality of time steps. [0073] 12. The system according to aspect 11, wherein the model predicts an occurrence of a wait state at a specific machine at a specific time step when at least one of the following is true at the specific time step: (i) a conveyor belt immediately downstream of the specific machine is at capacity and cannot accept any more pucks, (ii) a conveyor belt immediately upstream of the specific machine does not contain any pucks. [0074] 13. The system according to any of aspects 1-10, wherein the plurality of conveyor belts includes a plurality of downstream-moving conveyor belts configured to carry pucks containing one or more manufactured components or intermediate products as well as a plurality of upstream-moving conveyor belts configured to carry empty pucks. [0075] 14. The system according to aspect 13, wherein: the model simulates a number of pucks on each conveyor belt of the plurality of conveyor belts for each time step of a plurality of time steps; and the model predicts an occurrence of a wait state at a specific
30904 machine at a specific time step when at least one of the following is true at said specific time step: (i) a downstream-moving conveyor belt immediately downstream of the specific machine is at capacity and cannot accept any more pucks, (ii) a downstream-moving conveyor belt immediately upstream of the specific machine does not contain any pucks, (iii) an upstream-moving conveyor belt immediately downstream of the specific machine does not contain any pucks, and (iv) an upstream-moving conveyor belt immediately upstream of the specific machine is at capacity and cannot accept any more pucks. [0076] 15. The system according to any one of aspects 1-14, wherein the one or more processors are further configured to: receive waiting event data generated by the one or more sensors during a monitored time period, wherein the waiting event data indicates a plurality of wait events actually experienced by the target machine during the monitored time period, compute based on the waiting event data a cumulative duration of wait events actually experienced by the target machine during the monitored time period, determine, using the model, an expected cumulative duration of wait events experienced by the target machine during a modeled time period having a same duration as the monitored time period, determine a difference between the cumulative duration of wait events actually experienced by the target machine and the expected cumulative duration of wait events, and output an alert if the difference is greater than a pre-determined threshold. [0077] 16. The system according to any one of aspects 1-15, wherein the one or more processors are further configured to: determine, using the model, an expected number of wait events experienced by the target machine during the modeled time period, determine a difference between the number of wait events actually experienced by the target machine and the expected number of wait events, and output an alert if the difference is greater than a second pre-determined threshold. [0078] 17. A method of managing a manufacturing network that includes machines interconnected by a plurality of conveyor belts, wherein each conveyor belt carries a number of pucks configured to hold one or more manufactured components or intermediate products, the method comprising: obtaining fault data associated with a plurality of machines in the manufacturing network; inputting the fault data to a model that has been initialized with parameters related to the plurality of machines of the manufacturing network, wherein the model provides data indicating expected occurrences of wait states at one or more of the plurality of machines based on the fault data; and implementing a first function that utilizes the
30904 model to obtain an estimate of at least one of an optimal capacity and an optimal number of pucks for each conveyor belt in the plurality of conveyor belts that minimizes modeled wait states of a target machine among the plurality of machines of the manufacturing network, according to the model. [0079] 18. The method according to aspect 17, further comprising: implementing a second function that utilizes the model to obtain an estimate of current capacity for each conveyor belt of the plurality of conveyor belts; and estimating, based on the estimate of current capacity and the estimate of optimal capacity for each conveyor belt, a desired length for each conveyor belt in the plurality of conveyor belts to minimize the wait states of the target machine. [0080] 19. The method according to aspect 18, wherein estimating the desired length of the plurality of the conveyor belts is based additionally on current lengths of the plurality of the conveyor belts, and the current lengths of the plurality of the conveyor belts are real or synthesized lengths. [0081] 20. The method according to any of aspects 17-19, further comprising obtaining or synthesizing observed wait states for the machines of the manufacturing network, wherein implementing the second function includes estimating a current capacity of each conveyor belt of the plurality of the conveyor belts that results in modeled wait states for the machines of the manufacturing network, provided by the model, that approximate the observed wait states for the machines of the manufacturing network. [0082] 21. The method according to any of aspects 17-20, wherein implementing the second function includes performing an iterative gradient descent algorithm on a minimization function minimizing a difference between the modeled wait states and the observed wait states. [0083] 22. The method according to any of aspects 17-21, wherein the fault data is obtained by sensors in the manufacturing network or one or more other manufacturing networks or is synthesized through simulation. [0084] 23. The method according to any of aspects 17-22, wherein implementing the first function includes performing an iterative gradient descent algorithm on a minimization function minimizing the modeled wait states for the target machine. [0085] 24. The method according to any of aspects 17-23, wherein implementing the first function includes estimating the optimal capacity subject to
30904 user-defined constraints on the length of the plurality of the conveyor belts in the manufacturing network. [0086] 25. Non-transitory computer-readable media storing instructions that, when executed by one or more processors, are configured to cause the one or more processors to implement the method of any one of claims 1-24. [0087] 26. A system to manage a manufacturing network that includes machines interconnected by conveyor belts, the system comprising: memory configured to store fault data associated with a plurality of machines in the manufacturing network; and a processor configured to: input the fault data to a model that has been initialized with parameters related to the plurality of machines of the manufacturing network and implement a first function that utilizes the model to obtain an estimate of current capacity of a plurality of the conveyor belts; implement a second function that utilizes the model to obtain an estimate of optimal capacity of the plurality of conveyor belts that is expected to minimize wait states of a target machine among the plurality of machines of the manufacturing network, wherein the target machine is in one of the wait states when the target machine does not have a fault but is not operational; and estimate, based on the estimate of the current capacity and the estimate of the optimal capacity, a desired length of the plurality of the conveyor belts in the manufacturing network to minimize a wait state of the target machine. [0088] 27. The system according to aspect 26, wherein the fault data is obtained by sensors in the manufacturing network or one or more other manufacturing networks or is synthesized through a simulation.