The Figures below illustrate an embodiment of the demand-pull system, which can be implemented using a software system with a database.  In this embodiment, a .NET service bus and MSSQL database running on a networked Microsoft Windows server are connected via the local area network (LAN) to individual clients in the various WCs.  These clients contain the browser-based AngularJS user interface and connect with the service bus through its Application Programming Interface (API).

system architecture thumbsystem infrastructure thumb

    Likewise, other enterprise-level software applications (ERP, CRM and so forth) interface with the software implementation and can inject new WOs and extract data on those WOs as they flow through the factory.  The demand-pull system can include an Enterprise Resource Planning (ERP), Materials Resource Planning (MRP) or other similar system that creates WOs for parts to be produced by the factory.  This system should also be capable of storing the associated operation sequence (Workflow), the WCs associated with each operation in the Workflow, standard processing hours per unit (HPU) at each operation, and quantities of units (# Units) to be produced.  

    WOs and their associated data (Workflows, HPU, # Units, and Batch sizes, if applicable, at a minimum) are then introduced into the demand-pull system.  Initially, WOs have a Status code of "Pending" and when ready to begin production, the WOs are accepted into production through the demand-pull system user interface, which action changes the Status to “Open.”  When a WO is accepted, a time-stamp is created and it is “moved” to the Queue of the first operation in the Workflow.  This is the beginning of the "demand-pull" production process.

    When demand is detected at the next WC in the WO's Workflow, the WO is assigned a Pull Tag, which authorizes work activities at the first operation in its Workflow.  This "detection" can be based on an affirmative result to the aforementioned test in Equation 22:

equation 22

Where, in this case, N is the next WC in the WO's Workflow.  This test is done in the demand-pull system software through continuous polling of all WCs in the factory, as well as instantaneously any time a WO is Started or Finished at a WC.  In other words, when a WO is started into production at a given WC, the system immediately "looks" upstream for a candidate WO to refill its queue. Likewise, when a WO is completed and moved to its subsequent WC’s queue, a pull-test is performed both upstream and downstream to detect demand.   When a pull-test is performed on a WC, a record can be logged with a time-stamp and the order of polling of the WCs can be based on this time-stamp.  The WC with the oldest time-stamp can be polled first.  The polling frequency is a user-defined interval in the demand-pull system.

    All the parameters of the demand-pull system are tracked, or calculated (such as by the software) on each execution of the Pull-test.  The relevant parameters can include:

Database stored:
CN, tWO1, n-1, tT,N-1,N, CN-1, B, ON

Calculated:
XN, tR,N, tR,N-1, tQ,N-1, QN, YN, WN

    In addition, some of the calculated values are based on other parameters that are system generated or stored in the database.  

    Specifically:

    tR,N - is the remaining Clear Time for the WO in WCN with the least Clear Time remaining and is calculated as the difference between the Clear Time for the relevant WO in WCN and the elapsed time since the WO was started.  Therefore, the system captures the Elapsed Processing Time for each WO.  Then:  

    tR,N = Clear Time – Elapsed Processing Time

    Likewise, tR,N-1 is a similar calculation done on the WOs in WCN-1 to determine the remaining Clear Time for the WO in WCN-1 with the least Clear Time remaining.

    tQ,N-1 is the sum of the Clear Times for WCN-1 for all WOs in its queue that have been assigned a PT.  Since this calculation depends on the demand-pull system’s ability to determine which WOs have WCN as the next WC in their Workflow, the demand-pull system stores all the operations in the WO's Workflow as well as the sequence of those operations and their associated WCs. Then it stores in its database all PTs, their associated WOs and WCs so that it can identify the WOs that are UA to WCN and that have been authorized for production in their current WC (assigned a PT).  

    Likewise, YN relies on calculating its Clear Times for WCN and relies on the association of PTs.  This calculation knows that:
 
    a. a PT has been assigned to the WO; and
    
    b. the next WC in the WO's Workflow is WCN - so for that reason, the demand-pull system has stored all the steps in the WO's Workflow as well as the sequence of those steps.
 
    QN and WN are calculated on the basis of Clear Times, since no PT association is needed for these two values.

    A flowchart of the pull-system logic is shown inthe Figure below. Explanations of the terms used therein are found in the Table of Definitions.

flow chart w queue thumb

 

Newsletter Sign-up

Subscribe

Engagements

Xilinx, Inc.

xilinx web

San Jose, CA, Module Five

Designed a new engineering lab to accommodate growth in the SERDES Product Engineering group, 4,000 square-feet in total, built in three phases to prevent productivity losses during current-space renovation. Primary project objectives were doubling bench capacity, improvements in wire management, reduced acoustical noise levels, and improvements in Electrostatic Discharge prevention. Deliverables included facility designs and accompanying CAD files, utility requirements for Power, Networking, Clean Dry Air, and Chilled Coolant loops for chillers that serviced coolant to test fixtures. Additional Details

San Jose, CA, Module Four

Designed a new engineering lab and back-end test lab, 10,000 square-feet in total, for a new domestic site housing the company's Complex Programmable Logic Device Product Line.

Read more ...