A buyer who wants a production line for an Industry 4.0 demonstration factory is usually asked, at the very first meeting, what cycle time the line needs. The honest answer at that point is almost never a number. The specification is still open, the product is still moving, and the person being asked has never seen the line that is supposed to produce it.
Cycle time is the one requirement that decides the rest of the build: how many stations, who loads and unloads, what has to be measured, what has to be recorded, and whether the project is a machine or a system. Getting it wrong does not produce a slow line. It produces a line that has been specified, financed, built and accepted against the wrong job.
This article is written for the buyer in that position - a manufacturer, or the plant-side lead on a line or cell project - and sets out how a manufacturer can work out the cycle-time requirement for a demonstration line before the number is fixed on paper, and what has to be true about the line before any stated figure means anything.
1. Separate the three questions the phrase is hiding
"What cycle time do you need?" collapses three different questions, and a buyer who answers only one of them will be quoted a line that fails on the other two.
- Output question - how many units per shift or per day does the site have to make, at what mix of products, over what working pattern?
- Pacing question - at what interval must a unit leave the line so that the line upstream and the line downstream are not starved or blocked by it?
- Presentation question - at what interval must the line run, in front of visitors, in a way that can be explained and repeated on demand?
On a factory whose whole purpose is demonstration, the third question is not decoration. It is the reason the line exists. But it is also the question buyers answer first, because it is the one their marketing or government-relations colleagues care about - and it is the weakest basis for a machine specification. A line can be specified to present well and still fail the output question, and the failure is only found after the acceptance run.
2. Start from the interval, not from the wish
A cycle time taken from a wish - "we want a unit every few seconds" - cannot be argued with, cannot be tested, and cannot be costed. A cycle time derived from an interval can. The derivation is not complicated, and every input in it is something the buyer already knows or can find out this week:
- the units per day the site is committed to, and how many of those are the product in question rather than the whole family of products;
- the shift pattern, including breaks, changeovers and planned maintenance, not just the clock hours the site is open;
- the working days the site actually runs in a month, once shutdowns and holidays are removed;
- the size of the batch that has to be changed over, and how often that changeover happens per shift.
Dividing committed output by available running time gives an interval the buyer can defend in a meeting, because anyone in the room can re-do the arithmetic. Writing the interval without the inputs, and without naming which shift pattern they assume, is the most common way a cycle-time requirement turns into a dispute later.
Two derived numbers should appear in the requirement, not one: the interval the line has to hold during a normal run, and the interval it has to return to after a stoppage. A line that only ever holds the first number can never recover from the second.
3. Treat the demonstration purpose as a real duty, and cost it
A demonstration line is asked to do two jobs that pull the cycle time in opposite directions. It has to run continuously for visitors, and it has to show the processes that matter, which are usually the slow ones and the ones that need explaining.
The buyer should decide, before the design starts, which of these the line is expected to do:
- run at the production interval while visitors watch, so the speed itself is the message;
- run slower than production, in steps, so that a process can be pointed at - in which case the line's stated interval is a presentation interval and must not be quoted as a production capability;
- switch between the two on request, which is a mode the equipment has to be designed for, not one an operator invents at the panel.
The decision belongs in the requirement because it changes the machine. A line that must present and produce needs a mode selection, a defined start-up, and a way of getting back into step after a tour stops it. None of that appears in a specification written only for throughput.
4. Measure the process you have before you specify the line you want
If the process already exists somewhere - a manual cell, a prototype line, a supplier's line - the cycle-time requirement should be anchored on what that process takes today, with the timing taken apart rather than recorded as one number.
For each step, record five things, in the same order every time so that steps can be compared: what triggers the step; what the step physically does; what the step leaves behind; what it does when it meets a bad part; and where the waiting time actually sits - in the action, in the load or unload, or in the transfer to the next position. Waiting that sits in the transfer is the part buyers habitually blame on the machine.
The slowest step sets the interval that step can hold, not the interval the line will have. Before that figure goes anywhere near a requirement, ask what else is in scope at the same position: feeding, unloading, inspection, rework, cleaning, and the recording a demonstration line is expected to produce. Each of those belongs to a position, and each one the buyer does not claim is still going to happen - it will just happen off the record, and the line will miss the interval without anyone being able to say why.
5. A demonstration line has to generate the records it is demonstrating
The reason a buyer builds a demonstration line rather than a production line is usually to make something visible: traceability, measurement, in-process control, the link between a process setting and a result. All of that has a cost in time, and the cost falls inside the cycle.
So the cycle-time requirement should state, position by position, what the line is expected to produce as data - a measurement, a pass or fail, an image, an event, a serialised record tied to the unit - and how the record is produced: automatically at the station, by an operator, or by a downstream inspection that the line then has to feed. A record captured by an operator at a terminal is a per-unit labour task and belongs in the timing; a record captured by the equipment does not, but it does add to what the station must do inside its interval.
Ask a second question that almost no buyer asks at specification stage: how long a run has to be before the records are worth anything. A line that runs for ten minutes and stops produces a demonstration, not data. Whoever owns the requirement should state the run length the records have to cover, because that determines the buffering, the feeding, and whether the line can be left alone at all.
One caution belongs here. Where a supplier's own product material quotes figures such as an uptime percentage or a cycle time, those figures come from a stated test on a stated item. For one machine class, PowerDe's listing carries uptime and cycle-time figures recorded against a named small-format test; they are records of that test, and they are not transferable to a buyer's part, format or line. The same caution applies in reverse to a demonstration line: whatever figure it eventually shows has to be reported together with the conditions it was produced under, or it is not evidence, it is advertising.
6. What has to be true about the site before a figure means anything
A cycle time is a property of a line inside an environment. Before a number is committed, the buyer should be able to describe, in writing:
- the arrival interval of the input - what feeds the line, how often, and how long a gap in that feed the line can absorb before it stops;
- the take-away interval at the end - what removes finished units, and whether the line has to stop if it does not;
- the utilities and consumables each station needs, and where they are replenished, since a station that runs out mid-cycle has already missed the interval;
- who staffs the line during a demonstration, and what they are allowed to do while it is running;
- the changeover - which parts change, what has to be changed, and who times it.
PowerDe's manufacturing automation service describes its starting point in exactly these terms: process and site research, then an assessment of which processes are suitable for automation, suitable for semi-automatic work, or not suitable to convert at all, before any scheme, rhythm planning, or quotation is produced. That order matters for a cycle-time requirement, because the assessment step is where an unaffordable interval is rejected on evidence rather than after the contract.
7. Put the figure in the specification the way it has to be proven
Once the buyer has worked through the steps above, the requirement can be written in a form a supplier can be held to. It should state the interval, the product and mix it applies to, the shift pattern behind it, the changeover interval, the data the line must produce, the run length those records cover, the input and take-away conditions, and the excluded targets - the processes that stay manual and therefore sit outside the machine's interval.
It should also state how the interval is demonstrated. A demonstration factory is, among other things, a standing answer to that question, and a supplier who is building a line to prove a figure should be asked to prove it under the buyer's own conditions: the buyer's product, a run long enough to be evidence rather than a clip, the changeover timed as part of the run rather than excluded from it, and a restart after a stoppage so the recovery interval can be seen. Where the line is being built alongside an existing product family, ask for the demonstration on your part before the order rather than on the supplier's sample.
8. A short list to take into the next meeting
- Can you state the output you are committed to, the shift pattern you assume, and the interval you get from dividing one by the other?
- Is the interval a production interval or a presentation interval - and would the line be able to hold the first one while doing the second?
- Which positions on the line are expected to produce records, and has the time for producing them been put inside the cycle or left off the books?
- What feeds the line and what takes the finished units away, and how long can the line survive either of them being late?
- If the interval is missed, will the acceptance test be able to show where it was missed - or only that it was missed?
A manufacturer that can answer these five questions in writing arrives at the specification stage with a cycle-time requirement rather than an aspiration. A manufacturer that cannot should not sign an interval with a supplier yet, whichever number has been quoted in the meeting - and should use the equipment manufacturing automation services or the steam cleaning equipment OEM ODM and non-standard automation customisation route to have the process assessed first, before the figure that governs the whole build is fixed.
