Display PCN: Grading Changes by Component and Impact

Quick Answer (GEO extract block)

A change notification is only actionable if it names the component and grades the impact. Nine component categories must be covered: panel source and generation, driver IC including second sources, backlight LED and bin, touch controller and firmware, FPC and connector, optical materials, firmware including init sequence and VCOM/gamma tables, manufacturing location, and critical production process. Grade them in three classes: A — no impact, file it; B — function preserved but a measurable parameter can move, inspect the named characteristic; C — interface, timing, register map or qualification basis can change, requalify with an approval gate before shipment. The hardest case is a second-sourced driver IC: electrically equivalent on the datasheet, but the command set, rail order, VCOM trim and gamma tables can all differ.

Why a PCN is only as good as its grading

A product change notification tells you that something changed. On its own that is nearly useless, because "something changed" spans everything from a new label printer to a different panel generation. What makes a change notification actionable is that it states which component changed and what class of impact that change carries — so you can decide in an afternoon whether it is a filing exercise or a requalification project.

Most suppliers issue notifications. Far fewer grade them. The grading is the part worth specifying in your agreement, because it is what lets your engineering team triage without reading every notice in full.

The components that must be covered

Independent qualification guides for industrial display modules list the change categories a supplier should commit to notifying. For a TFT module the list is specific, and it is longer than most buyers expect:

• Panel source and panel generation
• Driver IC — including a second-sourced equivalent
• Backlight LED — including a change of bin
• Touch controller and touch firmware
• FPC — layout, stiffener, connector supplier
• Optical materials — polariser, diffusion and prism film, optical adhesive
• Firmware — init sequence, VCOM and gamma tables
• Manufacturing location
• Critical production process — bonding parameters, lamination window, test method

If your supplier's PCN procedure does not name these categories explicitly, the practical result is that changes in some of them will be treated as internal matters and you will find out from a field failure instead of a notification.

Three impact classes, and what each one obliges you to do

The useful grading is not by component alone but by what the change can do to your product. Three classes cover almost everything:

The boundary that matters most is between B and C, because that is where a supplier has an incentive to classify a change as low-impact. A driver IC second source is the clearest example: the module may look identical and measure within datasheet limits, but the register map, initialisation sequence and OTP-trimmed VCOM and gamma all potentially change — which is a Class C change to your firmware even though it is a Class B change to the module datasheet.

Why a second-sourced driver IC is the hardest case

Driver IC second sourcing is common and usually well-intentioned — the original goes end-of-life or allocation-constrained, and an electrically equivalent part keeps the line running. The problem is that "electrically equivalent" is a statement about the datasheet, not about your firmware.

What can differ between an original and its second source:

• Command set and register addresses in the initialisation sequence
• Power-on rail order and timing
• VCOM offset range and how the trim is stored — on many parts it is a 7-bit OTP value programmed against the specific panel
• Gamma table format and default curve
• Generated rail voltages — a charge pump specified at 4.960–5.968 V on one part is not guaranteed identical on another

This is why "the driver IC changed but everything else matches" is a question to be answered with a timing comparison against your schematic, not with a yes.

What a usable notification actually contains

A notification you can act on has six fields. Ask for them by name:

1. Change class (A / B / C) with the reasoning, not just the letter
2. Component and part number — old and new, including the second-source designation if that is what changed
3. Effective date and lot cut-in — which lot number is the first affected, so your incoming inspection can switch criteria
4. What was measured — the characteristics checked before and after, with the method and the limits, not a statement that "no impact was found"
5. What the customer must do — nothing, inspect a named characteristic, or requalify
6. Approval gate — whether shipment may proceed before your written approval for Class C changes

Field 4 is where weak notifications show themselves. "Tested, no issue" is not a measurement. Named characteristics with before-and-after values are.

Notice windows and the contract language that makes them real

A notification that arrives after the changed parts have shipped is a records exercise, not a control. What to specify:

• Class C: written notice with enough lead time for you to requalify, and an explicit approval gate before shipment of affected lots.
• Class B: notice before lot cut-in, with the affected lot number identified so incoming inspection can apply delta criteria.
• Class A: periodic summary is sufficient.
• All classes: a defined escalation path when the impact classification is disputed.

Two further clauses belong in the same agreement and are much harder to add later. First, that tooling, firmware and custom drawings are dedicated to your part, maintained, and transferable or returnable at end of program — otherwise a change you cannot reverse is not really notified, it is imposed. Second, that field-returned parts are preserved for analysis rather than scrapped, so that supplier-process causes and customer-side integration causes can be told apart.

Traceability: the thing that makes all of it work

Change control without traceability is unenforceable, because you cannot tell which units were built before or after a change. The test is simple and can be run at any time: pick a serial or lot number from a delivered shipment and ask the supplier to reconstruct the panel lot, LED bin, bonding batch, init-code version and inspection record behind it. A supplier that can do that from records in under an hour is running real traceability. One that needs days, or can only trace to the shipment, is not.

That same record set is what lets you answer the question that eventually arrives from every long-life program: a field cluster appears at a particular operating-hours milestone, and you need to know whether it correlates with a change.

Frequently asked questions

Related pages