Run at rate: how to verify capacity for PPAP, step by step
What a run at rate is, what AIAG PPAP, GM, Ford and VW ask for, how to plan it, which conditions make it valid, how to calculate OEE and demonstrated capacity, and how to judge it against APW and MPW.
A run at rate (R@R) proves that a new or changed line makes the customer volume under series conditions: production tools, released gauges, trained operators, the planned cycle time and the control plan in use. It is part of PPAP and of the capacity analysis IATF 16949 asks for in manufacturing process design (8.3.5.2), and almost every automotive customer describes it in its customer-specific requirements.
What customers ask for
| Source | Typical requirement |
|---|---|
| AIAG PPAP | Significant production run: 1 to 8 hours, at least 300 consecutive parts, unless the customer specifies otherwise |
| GM | Run at rate per GP-9, judged against the required daily and weekly volume |
| Ford | Run@Rate in Phased PPAP with a capacity analysis against APW and MPW |
| Volkswagen | Two-day production (2TP) under series conditions |
| VDA 2 (PPF) | Production process and product approval with evidence of capacity |
These are typical requirements, not the full text. Always read the current CSR of your customer: duration, number of parts and the volume to judge against differ.
1. Plan the capacity before the run
Start with the volume and the time the line really has. Example: the customer needs 4,800 parts a week, the line runs 5 days, 2 shifts of 7.5 hours net.
- Net available time: 5 × 2 × 7.5 h = 75 h a week.
- Takt time: 75 h × 3,600 s / 4,800 = 56.3 s per part.
- Required OEE per operation = takt-based demand ÷ theoretical capacity. An operation with an ideal cycle of 45 s makes 6,000 parts in 75 h, so it needs an OEE of at least 80 %.
Do this for every operation. Machines shared with other parts only give this part their allocated share. The operation that needs the highest OEE is your expected bottleneck.
2. Check that the run is valid
A run at rate counts only under series conditions. Agree the list with the customer and record the evidence before the start:
- Production tooling and fixtures, no prototype tools
- Released gauges with acceptable MSA
- Trained production operators, normal staffing
- Planned cycle time and process parameters, no extra people or overtime tricks
- Control plan, work instructions and reaction plans in use
- Series material from approved suppliers, series packaging
Mark which conditions are critical. If a critical one is missed, the run is not valid, however good the numbers look.
3. Log every stop and every hour
During the run, record each stop with its start, end and category (breakdown, changeover, material, quality, waiting), and the good parts every hour. Keep starved and blocked time apart: a machine waiting for parts is not the cause. The hourly log also shows whether the rate held over the whole run or dropped after the customer left.
4. Calculate OEE and demonstrated capacity
- Availability = run time ÷ planned time
- Performance = (parts made × ideal cycle time) ÷ run time
- Quality = good parts first time ÷ parts made
- OEE = availability × performance × quality
- Demonstrated capacity = good parts ÷ run duration × net available time per week
Example: an 8-hour run makes 470 good parts, 58.8 per hour. Over 75 hours that is 4,406 parts a week, 92 % of the required 4,800: not approved. The lowest demonstrated capacity of all operations is the line capacity; that operation is the bottleneck.
5. Judge and report
Compare the line capacity with the volume the customer set (APW or MPW), and check the run duration, the consecutive parts, the first-time quality and the capability of the special characteristics from the run. The result is one of three:
- Approved: valid run, capacity and every check met.
- Approved with actions: capacity met or close, with open points that have an owner and a date.
- Not approved: invalid run, or capacity clearly below the requirement. Fix the bottleneck and repeat.
One page is enough: the decision, the checks, capacity per operation, the bottleneck, a short conclusion and the signatures of supplier and customer.
Common mistakes
- Counting all parts instead of good parts made right first time.
- Using the 24-hour week instead of the working pattern the line will really run.
- Forgetting that a shared machine only gives part of its time to this part.
- Running with extra people or the best operators only.
- Judging against APW when the customer wanted MPW.
Frequently asked questions
What is a run at rate?
A production trial at the quoted rate, under series conditions (production tooling, gauges, operators, cycle time and control plan), that proves the line can deliver the customer volume with the required quality.
How long does a run at rate take?
The AIAG PPAP manual asks for a significant production run of one to eight hours with at least 300 consecutive parts, unless the customer says otherwise. Many OEMs ask for longer: Volkswagen for example runs a two-day production (2TP). The customer-specific requirements decide.
What is the difference between run at rate and capacity verification?
Often none: both names are used for proving the line rate. Some customers use capacity verification for the whole analysis (plan, run and judgement) and run at rate for the trial itself.
APW or MPW: which volume must the line reach?
APW is the average planned weekly volume, MPW the maximum the customer may call. Most customers judge the run against MPW or ask for a margin above APW. Check the CSR and write the basis in the report.
What if the run fails?
Find the bottleneck operation and the biggest losses from the downtime log, act on them, and repeat the run. Keep the earlier runs in the record so the customer sees the progress.
Calculate a single run online with the free run at rate calculator, and check the rest of the submission with the PPAP checklist.
Excel template: Run at Rate & Capacity Verification
Everything above in one workbook: requirement profiles, capacity plan for 20 operations, 18 validity checks, downtime and hourly logs, OEE per operation, quality results, one-page report and run history. Example and blank file, no macros.
See the template