Robot Supplier Quality Management: Why Can't We Just Copy APQP and PPAP From the Automotive Industry?

A robotics enterprise developed an intelligent handling robot at the prototype stage. All reducers, motors, controllers, LiDAR units and batteries have inspection reports, and key suppliers have also obtained ISO 9001 certification. During prototype testing, the positioning accuracy, load capacity and operating speed all met the requirements. Judging by the standards of traditional manufacturing, this product seems to already meet the conditions for mass production.

However, after being deployed at the customer site, problems emerged one after another: the robot occasionally lost its positioning when passing through glass doors; it would suddenly decelerate when the ground had strong reflected light; its braking distance changed as the battery level dropped; a software upgrade solved the navigation problem but caused incompatibility with a certain batch of controllers. When each component was disassembled for inspection, they all seemed to conform to the drawings; when tested in the laboratory, these problems were also difficult to reproduce stably.

Such problems indicate that the quality of robots cannot be simply understood as "qualified components, stable manufacturing processes and complete submitted documents". A robot is a complex system formed by the interaction of machinery, electricity, software, algorithms, sensors and the operating environment. Qualification of a single component does not guarantee that the system can operate correctly; approval of one sample part does not guarantee that the original performance and safety level can still be maintained after subsequent software upgrades.

After decades of development, the automotive industry has established a supplier quality management system centered on APQP, PPAP, FMEA, MSA, SPC and control plans. Robotics enterprises should certainly draw on these methods, but if they directly copy the forms, nodes and document requirements of the automotive industry without modification, they are very likely to get a set of quality systems that look complete but cannot cover the core risks of robots in practice.

The problem is not that APQP and PPAP are outdated, but that the objects faced by robot quality management have changed.

What core problems do automotive APQP and PPAP solve?

1. The core of APQP is to identify risks in advance during product development and mass production preparation, and translate customer requirements into product design requirements and manufacturing process control requirements;

2. PPAP uses a set of documents, samples and pilot production data to prove that the supplier has understood customer requirements and has the ability to continuously and stably produce qualified products.

This method is built on an important premise: the product definition is relatively stable, and the drawings, materials, dimensions, tolerances, special characteristics and manufacturing processes can be clearly specified. As long as the design is confirmed, the focus of subsequent quality management is to ensure that the manufacturing process does not get out of control, and that each batch of products is consistent with the approved state.

Therefore, traditional PPAP usually focuses on design records, engineering changes, DFMEA, PFMEA, control plans, measurement system analysis, process capability, material and performance tests, samples, inspection tools and part submission warrants.

These methods are still very effective for machined parts, injection molded parts, wiring harnesses, structural parts, bearings and standard electrical components in robots. However, when the management objects become robot joint modules, motion controllers, vision systems, navigation algorithms or complete machine systems, obvious gaps will appear if only traditional PPAP is relied on.

This is because a robot is not just a manufactured product, but also a system that can perceive, judge, move and continuously interact with the environment.

All components are qualified, why is the robot still likely to be "unqualified"?

Many quality problems of automotive components can be traced back to dimensions, materials, process parameters or assembly deviations. However, robot systems often face another type of problem: each component is qualified when inspected separately, but cannot work stably when combined together.

For example:

1. The motor meets the torque requirement, and the reducer also meets the accuracy requirement, but the combination of the two may cause low-speed crawling, vibration or temperature rise;

2. The camera resolution meets the technical agreement, but the recognition result is unstable under backlight, occlusion or fast-moving scenarios;

3. The controller hardware is fully qualified, but the firmware version does not match the upper computer software, resulting in command delay;

4. The repeated positioning accuracy of the manipulator is qualified, but after replacing the end effector, the overall stiffness and stopping distance of the complete machine change.

The root cause of these problems often does not lie in individual parts, but in interfaces and combination relationships. The automotive industry also manages interfaces, but robots are more dependent on interfaces. As long as there is unclear definition or change in any part of the mechanical interface, electrical interface, communication protocol, time synchronization, software version, coordinate system, load parameter, sensor calibration and safety signal, the behavior of the complete machine may be affected.

Therefore, robot supplier quality management cannot only audit "whether the supplier can make the part well", but must also audit:

1. Whether this component is correctly selected, correctly integrated, correctly calibrated in the specific robot architecture, and remains stable under various working conditions.

2. This means that robot APQP must add contents such as system architecture review, interface control documents, software and hardware compatibility matrix, key parameter calibration and integrated verification.

Traditional PPAP proves an approved state, but robots may keep changing

Traditional PPAP is usually carried out around a determined part number and engineering state. Once the drawing version, material, production site, mold and manufacturing process change, the supplier needs to apply for change and resubmit the corresponding documents.

However, changes of robots do not necessarily appear as drawing changes:

A software upgrade may change the motion trajectory of the robot;

An algorithm model update may change the obstacle recognition result;

Replacement of firmware by the sensor supplier may affect the data refresh frequency;

Adjustment of control parameters may change the speed, vibration and stopping distance of the manipulator;

Cloud strategy updates may even change the behavior of a batch of robots that have already been delivered.

In other words, after the robot is mass produced, the product may continue to "evolve". If the quality system only manages material numbers, drawing versions and manufacturing process changes, a dangerous blind zone will appear: the hardware has not changed, but the actual behavior of the product has changed.

Therefore, the robot supplier quality system must incorporate software, algorithms, parameters and data into formal configuration management. Each release needs to answer several questions:

What has been changed?

Which models and batches are affected?

Does it change the safety functions?

Which scenarios need to be re-verified?

Can it roll back to the previous version?

How to identify and upgrade the robots that are already operating on site?

For robots, PPAP should not only be a one-time "Production Part Approval Process", but also be extended to a continuous "Product Configuration Approval Process".

Traditional performance tests are not equal to robot scenario verification

Performance tests of automotive components usually have relatively clear conditions and judgment criteria, such as temperature, load, pressure, durability times and dimensional tolerances. Robots also need these tests, but qualified performance under laboratory conditions is not enough.

Whether a robot is qualified largely depends on its performance in real scenarios:

1. The same mobile robot operates normally on flat ground, but its performance may be completely different when it comes to ramps, thresholds, narrow channels or crowded areas;

2. The same vision system has a high recognition rate under standard light sources, but the error rate may rise significantly when encountering reflected light, shadows, stains, occlusions or similar objects;

3. The same manipulator action has no problem under no-load condition, but after replacing with end tools of different weights and centers of gravity, the trajectory accuracy and stopping distance may change.

Traditional PPAP pays more attention to "whether the product meets the specified technical requirements", and robot quality management needs to further confirm: under what environment, what tasks, what speed, what load and what personnel interaction conditions the robot can stably complete the task; what action it will take once the boundary is exceeded.

This requires the establishment of the robot's "task and operation boundary" and the formation of a scenario verification matrix. Normal scenarios need to be verified, and boundary scenarios, abnormal scenarios and failure scenarios also need to be verified. It is not only necessary to prove that the robot "works when it is normal", but also to prove that it "will not take dangerous actions when it is abnormal".

Automotive FMEA is not sufficient, robots need to analyze "behavior failure"

Traditional DFMEA and PFMEA mainly analyze possible failures of components, product functions and manufacturing processes. Robots still need these analyses, but risk analysis at the behavior level should also be added.

For example:

The LiDAR does not fail completely, but the data is occasionally delayed;

The vision system does not stop working, but misidentifies under a certain light condition;

The navigation algorithm can still run, but it selects an unreasonable path;

All axes of the manipulator have no faults, but move in the wrong direction due to coordinate conversion errors.

These problems are difficult to describe only through "component failure modes". In addition to answering "which part will break", robot FMEA also needs to answer:

·Under what conditions may the robot make wrong judgments?

·When the perception result is uncertain, will the robot continue to run or enter a safe state?

·Will multiple minor deviations superimpose to form dangerous behavior?

·How does the system degrade when communication is interrupted, data is abnormal or versions are incompatible?

·How does the robot respond when a person suddenly enters, a moving obstacle appears or the task is temporarily changed?

Therefore, robot risk analysis should link DFMEA, software FMEA, interface FMEA, functional safety analysis, scenario risk analysis and cybersecurity risks. The more capable a robot is of autonomous decision-making, the more it cannot only analyze hardware failures.

Robot suppliers cannot adopt the same set of audit standards

Automotive suppliers are usually classified according to product risks, supply amounts and historical performance, but the differences in the robot supply chain are more obvious:

Structural part suppliers mainly affect strength, accuracy and assembly;

Suppliers of reducers, lead screws and servo systems affect motion accuracy, service life and fail-safe performance;

Sensor suppliers affect the robot's perception of the environment;

Controllers and software suppliers may directly determine the action logic of the robot;

System integrators, although not necessarily producing any core components, undertake the important responsibility of final system safety and function realization.

If the same audit form is used for these suppliers, two problems are likely to arise:

1. A large number of unnecessary software requirements are put forward for ordinary mechanical parts;

2. For algorithm, controller and system integration suppliers, only incoming inspection, equipment point inspection and on-site 5S are still audited.

Robot supplier management must be classified according to the supply objects, and at least general component suppliers should be distinguished from:

- Key motion component suppliers,

- Safety-related component suppliers,

- Electronic and control system suppliers,

- Software and algorithm suppliers,

- Design and system integration suppliers.

Different suppliers have different audit contents, different scopes of submitted approval documents and change declarations, different verification depths and different problem response requirements.

After the robot is delivered, the quality formation process is not over

Traditional manufacturing often takes "product delivery" as one of the end points of quality management, but the real quality of robots can often be fully exposed only after they enter the site.

The ground, light, temperature, dust, network, personnel, obstacles and task rhythm faced by robots may all be different. The laboratory cannot exhaust all combined scenarios, so market operation data must become part of the quality system.

Robotics enterprises need to continuously collect data such as fault codes, task success rates, manual takeover times, abnormal stops, positioning loss, collision alarms, temperature rise of key components, battery degradation and software versions. On-site problems cannot be ended only with maintenance work orders, but should be fed back to design, supplier management, FMEA, control plans and verification standards.

This is similar to the warranty and market quality management in the automotive industry, but the remote connection and software upgrade capabilities of robots greatly improve the speed of problem feedback and improvement, and also bring new risks: enterprises may modify products frequently without completing risk assessment, regression testing and approval synchronously.

Therefore, the closed loop of robot quality management is not just "problem found - 8D rectification - verification closed", but should form: on-site data collection - abnormality identification - responsibility positioning - supplier collaboration - software and hardware change - scenario regression verification - batch release - continuous monitoring.

How should the robotics industry transform APQP and PPAP?

Robotics enterprises do not need to start from scratch. APQP can still be used as the main framework for product development and supplier quality planning, but unique control contents for robots must be added to the traditional five stages.

1. In the project planning stage, the tasks to be completed by the robot, the use environment, the way of personnel interaction, the allowable operation boundary and regulations and standards should be clarified;

2. In the product design stage, the review of system architecture, interfaces, functional safety, software and algorithm risks should be strengthened;

3. In the process design stage, in addition to the manufacturing process, the processes of software burning, version identification, parameter configuration, sensor calibration and complete machine debugging should also be planned;

4. In the product and process confirmation stage, the verification should be extended from component tests to complete machine integration, scenarios, abnormalities, durability and safety verification;

5. After entering mass production, on-site operation data is required to continuously monitor product performance.

Similarly, robot PPAP can retain traditional contents, but it is recommended to expand it into six categories of approval evidences:

The first category is hardware manufacturing evidences, including drawings, materials, special characteristics, process capability, measurement systems and control plans;

The second category is software release evidences, including source code or release package version, compilation status, test reports, known problems and rollback plans;

The third category is algorithm and data evidences, including model version, training and verification data boundaries, key performance indicators and applicable conditions;

The fourth category is system integration evidences, including interface matching, communication stability, parameter calibration and software and hardware compatibility;

The fifth category is safety and scenario evidences, including risk assessment, safety function verification, abnormal scenario tests and failure degradation strategies;

The sixth category is mass production and market support evidences, including traceability methods, spare parts strategies, remote diagnosis, on-site data feedback and change release mechanisms.

The result formed in this way is no longer the traditional Production Part Approval Process in the narrow sense, but closer to: Robot Product and System Approval Process.

Summary

APQP and PPAP from the automotive industry are a very important foundation for robot supplier quality management, but they cannot be the whole.

The core problem that the automotive industry has been solving for a long time is: how to continuously and stably manufacture the confirmed design.

On this basis, the robotics industry must also solve another problem: how a system composed of machinery, electricity, software, algorithms and the environment can continuously make correct, safe and predictable actions in different scenarios. Therefore, robot quality management does not abandon the methods of the automotive industry, but extends APQP and PPAP from "part and manufacturing process management" to "system behavior and full life cycle management".

The truly mature robot supplier quality system in the future should have both the process rigor of the automotive industry, the system engineering capability of the equipment industry, the risk awareness of functional safety, and the version and configuration management capability of the software industry.

For enterprises that are entering the supply chain of robots, embodied intelligence and intelligent equipment, the earlier they establish this capability, the more likely they are to grow from ordinary component suppliers to core partners who truly participate in product definition and system development.