Client identity withheld under NDA — referred to below as “a global leader in autonomous driving.”
When automotive cameras enter mass production, every single unit has to clear six quality dimensions — identity, optics, electrical and link, encryption, reliability and burn-in — and every result has to be measurable, decidable and traceable. This case study shows how those requirements land on a GMSL (SerDes) camera production line: what to watch for, how each test is run and judged, and the tooling underneath it all — the ECFG frame grabber with its Python and C++ SDK.
| Customer | A global leader in autonomous and assisted driving (NDA) |
| Product | Automotive GMSL camera modules — front, surround and rear view |
| Acceptance | Six dimensions, checked on every unit: identity, optics, electrical & link, encryption, reliability, burn-in |
| Test platform | ECFG frame grabbers + SDK (Python and C++) |
In this case study
The customer is a global leader in autonomous and assisted driving; the cameras ship on its production vehicles and perception platforms. What follows is the quality-control method the two teams refined during the production ramp — and it carries over to any GMSL camera program.
For an autonomous-driving stack, the camera is the front door of perception. A camera with a latent defect becomes false positives and missed detections everywhere downstream. The industry already has a hard frame for shipping quality: quality management under IATF 16949, part approval through PPAP with the full validation data set, components selected to AEC-Q100 temperature grades, and functional safety for the perception chain under ISO 26262. Each automaker then adds its own test standards on top — the DV in this program followed the customer’s corporate test standard. For the camera itself, the requirements come down to three words:
On the manufacturing floor, that turns into four hard problems:
C1 · Failures you cannot see
A camera can look perfect while its link margin is nearly gone, and a module that is sharp in the center can be soft in the corners. Obvious failures are easy. The hard ones work today and fail on the road.
C2 · The vehicle environment is unforgiving
Cameras live with constant vibration and wide temperature swings, and adhesive curing keeps moving the optics after the first checks pass. The decisive measurement has to come after stress.
C3 · Data security is mandatory
Perception video is sensitive, so the camera link must be encrypted. “Configured” is not enough: every module has to prove that encryption is active and pairing is unique.
C4 · The line cannot wait
Unit-by-unit testing has to keep pace with takt time. Tests must be automated, verdicts standardized and independent of the operator, and every record retrievable.
In the customer’s acceptance documents, “camera quality” is not a sentence. It is six dimensions, each checked on every unit:
| Dimension | What the customer requires |
|---|---|
| 1 · Identity & traceability | Each module is identified by a unique serial number, with factory OTP data present and readable. Calibration and test records are filed under that serial, so any shipped camera can be traced back to its full measurement history. |
| 2 · Optics & image | Sharpness is quantified at the center and the four corners, with color and exposure covered too. Thresholds are written per module variant — “looks sharp” is not an acceptance criterion. |
| 3 · Electrical & link | PoC supply voltage and current must sit inside written limits, and link margin must stay above a floor — headroom for years of cable and connector aging in the vehicle. |
| 4 · Link encryption | Video travels encrypted end to end, transmitter and receiver are uniquely paired, and plaintext fallback is refused. As a security property it is verified on every unit, never sampled. |
| 5 · Reliability | After vibration sweeps and thermal soaks, image and optical performance must show no visible shift — judged on the re-measurement after stress, not on pre-assembly data. |
| 6 · Burn-in | Under continuous streaming at high temperature: a stable frame rate, no bad frames and no parameter drift. Problems that only appear over time must not reach the vehicle. |
Automotive reliability is delivered in stages, and knowing the structure makes the production tests easier to read.
Design validation (DV) comes first. Before production, the design runs a complete environmental and reliability program against the automaker’s standards and automotive norms such as the IEC 60068 series (environmental testing), ISO 20653 (ingress protection) and UN ECE R10 (EMC). Take one complete automotive camera DV program as a reference: more than 200 samples, about 40 tests and roughly six weeks. This is what such a program covers:
DV at a glance · one reference program
| Category | Typical tests | Example settings |
|---|---|---|
| Mechanical | Combined vibration, mechanical shock (two levels), free fall, housing crush, connector insertion force, strength and mating durability | Shock 25 g / 10 ms and 50 g / 11 ms; 1 m drop; 110 N crush for 1 s; insertion force ≤ 75 N |
| Climatic | Low-temperature storage and operation, high-temperature storage, powered temperature cycling, thermal shock, cyclic and constant damp heat, condensation, salt spray, water and dust | −40 °C for 24 h; 95 °C for 48 h; thermal shock −40 ↔ 95 °C over hundreds of cycles; cyclic damp heat up to 65 °C / 93 % RH; salt spray 12 × 12 h cycles |
| Electrical & EMC | ESD, radiated and conducted emissions, bulk current injection, radiated immunity, portable-transmitter immunity, low-frequency magnetic fields | ESD ±4–8 kV contact and up to ±25 kV air; emissions and immunity graded per ECE R10 |
| Endurance | High-temperature operating endurance; combined vibration after thermal fatigue | 500 h of continuous operation, supply at nominal for 80 % of the time, minimum 10 %, maximum 10 % |
| Process & materials | PCB cross-sectioning, lens abrasion, gravel impact, industrial chemicals, restricted substances | Solder voids ≤ 25 %; plated copper ≥ 25 µm |
| Functional baseline | Five-point function and parameter test before and after every test leg | All five temperature × voltage corners pass (−40 °C to 85 °C, 9 V to 16 V) |
Read: These are settings from a real DV report. Automakers differ in the numbers, but the framework is remarkably similar — learn this table and you can read any automotive camera DV plan.
DV also brings a useful verdict language: functional status classes. Each test names the class the product must hold. Class A means every function works normally during and after the test; a few severe exposures, such as ±25 kV air discharge, only require the product to recover by itself afterwards. Miss the specified class and the design goes back for changes and a retest.
Production validation (PV) comes next. The same kinds of tests — in full or as a key subset — are repeated on parts built with production tooling, on the production line. DV proves the design; PV proves that the process can build it, and its results feed the PPAP submission before start of production.
End-of-line (EOL) testing is the focus of this case study. Validation cannot answer “is the unit coming off the line today good?” — it runs on sample batches over weeks. EOL testing takes the part of the validation program that can run on every unit at line takt, and applies it to every module to stop process drift and individual defects.
| DV · design validation | PV · production validation | EOL · end-of-line test | |
|---|---|---|---|
| Units | Sample batches (200+ in the reference program) | Parts from production tooling and line | Every module shipped |
| When | Before design freeze | Before PPAP and start of production | On the line, at takt |
| Scope | ~40 tests: mechanical, climatic, chemical, EMC, endurance, process | DV tests repeated, in full or as a key subset | Seven gates: identity, optics, electrical, link, encryption, stress & burn-in, record |
| Cycle | ~6 weeks per round, test legs in parallel | Weeks, on production parts | Synchronized with line takt |
| Answers | Does the design meet the automotive spec? | Can the process build it consistently? | Can this unit ship? |
Read: The stages are a relay, not repetition: DV guards the design, PV the process, EOL every unit. The reliability and burn-in checks in section 6 borrow their parameters and pass logic from DV, in a form the line can actually run.
Four lessons come first:
Lesson 1 · Passing first inspection is not passing
Adhesive curing and fixing keep moving the optics after the first checks. The decisive measurement belongs after stress — measure in the wrong order and accuracy no longer matters.
Lesson 2 · Temperature and long cables act together
In the vehicle, thermal stress and a full-length cable are present at the same time. Test them separately and you never see the real answer.
Lesson 3 · Security properties are never sampled
You can debate a sampling rate for sharpness. Not for encryption: one unencrypted camera in a fleet puts the whole chain at risk, so encryption is verified on every unit.
Lesson 4 · Testing must keep pace with takt
Unit by unit, many dimensions, every record filed by serial number — no manual process survives that volume. The flow must be automated and the verdict standardized.
Every gate starts the same way: connect the camera to the frame grabber and bring it up in a few SDK calls.
ret = ecfg_ptr.set_poc_voltage(12000) # 1. PoC supply 12 V (value in mV) ret = ecfg_ptr.poc_power_on(port_id) # 2. power the port ret = ecfg_ptr.init(grp_id, "init.json") # 3. deserializer set-up ret = ecfg_ptr.start(port_id, "start.json") # module set-up, stream on ret = ecfg_ptr.get_frame_data(port_id, raw_buffer) # grab a frame
| Gate | What is checked | Verdict | SDK interface |
|---|---|---|---|
| 1 · Register | Serial number and OTP read; model identity confirmed. Where the sensor exposes safety mechanisms (for example Sony IMX735), its analog BIST, OTP CRC, watchdog and memory-protection checks run here too. | Identity present and matched before the unit moves on | get_i2c_dev_list() lists the chip nodes; read_i2c() reads serial and OTP; imx735_* diagnostics |
| 2 · Optics | Five-spot sharpness (center + four corners, slanted-edge SFR per ISO 12233), color chart and exposure | PASS / NG against the variant’s thresholds; borderline units arbitrated by Imatest MTF50 | get_frame_data() captures chart and color images |
| 3 · Electrical | PoC supply voltage and current; electrical operating range | Live readings inside written limits | get_poc_voltage(), get_poc_current() |
| 4 · Link | GMSL link margin on forward and reverse channels, 10 mV steps | Margin at or above the written floor | link_margin(port_id, alg, t_des, t_ser) |
| 5 · Encryption | Link encryption and pairing | Active, uniquely paired, no plaintext fallback | Parameters delivered in the JSON config; the grabber verifies as the negotiating peer |
| 6 · Stress & burn-in | Vibration sweep, thermal soak, continuous heat run | No shift against pre-stress references; counters within limits | get_frame_rate(), get_dropped_frames_cnt(), get_error_frames_cnt(), get_module_temperature() |
| 7 · Record | All readings and images compiled into a verdict report | PASS archived NG stopped | The test script archives everything under the serial number |
Behind each gate sits one lesson worth taking home:
Discipline
Thresholds are written per module variant and kept under version control, and every module’s data is archived under its serial number. A number stripped of its test conditions is not a measurement.
A streaming picture only tells you the link works right now. Link margin tells you how much safety distance is left. The method follows the GMSL2 Channel Specification from Analog Devices: start at the serializer’s default transmit amplitude, step it down in 10 mV increments, dwell at each step and watch for errors — on the forward channel (video) and on the reverse channel (control). The number of clean steps before the first error is the link’s remaining headroom.
A healthy module keeps running many steps below nominal. A worn cable, a poorly seated connector or a damaged equalizer shows up as early errors — while the camera still streams a perfect picture. That is why link margin is a production gate rather than a lab curiosity: it catches the unit that works today and fails in the field.
On ECFG it is one SDK call. link_margin() takes the port, an algorithm number and the deserializer and serializer nodes, and returns the measured margin. The algorithm follows the serializer on the camera:
| Serializer on the camera | Forward-channel algorithm | Reverse-channel algorithm |
|---|---|---|
| MAX9295A / B | #1 | #3 |
| MAX96717 / K / F | #2 | #3 |
| MAX96793 (GMSL2 mode) | #2 | #3 |
| MAX96793 (GMSL3 mode) | #4 | #5 |
On the grabber side, the MAX9296A/B and MAX96792A deserializers follow the serializer’s setting.
nodes = ecfg_ptr.get_i2c_dev_list() # '/dev/G1-des', '/dev/port1-ser', ... fwd = ecfg_ptr.link_margin(1, 1, '/dev/G1-des', '/dev/port1-ser') # MAX9295A, forward (#1) rev = ecfg_ptr.link_margin(1, 3, '/dev/G1-des', '/dev/port1-ser') # MAX9295A, reverse (#3)
This is the part of acceptance the customer watches most closely: optics keep moving after assembly, and electrical weaknesses only surface under temperature. Every reliability and burn-in check on the line has a prototype in the DV plan — DV proves the design with sample batches and long cycles, the line watches every unit in a form it can run at takt.
| DV test | Production counterpart | Why it is simplified that way |
|---|---|---|
| Five-point function test across temperature × voltage corners | Voltage and current monitoring plus a function check after soak | The corners prove the design; the line holds the operating window |
| High-temperature operating endurance (hundreds of hours) | Continuous streaming at high temperature, watching frame rate, bad frames and drift | Hundreds of hours prove lifetime; the line catches early failures within takt |
| Mechanical shock (two levels) and combined vibration | Three-axis sine sweep after assembly, with before/after image comparison | DV may destroy samples; the line must be non-destructive and per-unit |
| Cyclic damp heat and condensation | Thermal soak combined with long-cable streaming | Climate and cable act together in the vehicle, so the test applies them together |
Read: Two constraints shape every simplification: non-destructive — the module still ships — and per-unit — the test must keep pace with the line.
After adhesive curing, each module rides a three-axis sine sweep; acceleration, frequency range and cycle count follow the variant’s acceptance specification. Sharpness and color images are captured before and after the sweep and compared directly — focus drift and loose mounts show up here.
Modules go into the thermal chamber for a hot soak and a cold soak, with temperature points and dwell times set by the variant’s specification. After each soak the camera streams continuously through a vehicle-length cable, then sharpness and color are re-measured against pre-soak references. Temperature and cable act together, because that is the real operating condition — test them separately and you prove nothing. The DV function test runs all five temperature × voltage corners; the line’s thermal re-measurement and voltage and current checks are its per-unit form.
DV endurance runs for hundreds of hours — 500 hours of continuous operation at high temperature, or hundreds of thermal-shock cycles. The line takes the middle form: continuous streaming at high temperature while watching for an unstable frame rate, bad frames and parameter drift, so early failures and parametric creep stop at this gate. On the SDK side, a burn-in script is three counters and a temperature reading, polled on a cycle and alarmed on limits:
frame_list = ecfg_ptr.get_frame_rate() # frame rate, per port dropped_list = ecfg_ptr.get_dropped_frames_cnt() # dropped frames error_list = ecfg_ptr.get_error_frames_cnt() # error frames temp_list = ecfg_ptr.get_module_temperature() # module temperature
Temperature is easy to leave out of a burn-in bench, and it should not be. Logging module temperature next to the frame counters — and, where needed, sensor and PCB temperature per port — ties every bad frame to the thermal state that produced it.
How the verdicts are structured
| Gate | Check | How it is judged | Verdict |
|---|---|---|---|
| Optics | Center and corner sharpness on the resolution chart | Scores against the variant’s written thresholds, corner by corner | NG if below |
| Optics | Four-corner uniformity (spread ÷ mean) | Against the variant’s uniformity limit | NG if above |
| Optics arbitration | Imatest MTF50 on borderline modules | The arbitration reading confirms the line score | NG if below |
| After stress | Color and sharpness against the reference | Compared with pre-stress reference images | NG on shift |
Read: Thresholds are numeric and written down, agreed per module variant — different FOV variants hold different uniformity limits, for example. The full matrix lives in a versioned specification agreed with the customer and is not published here.
Read: The verdict language comes straight from DV’s functional status classes: during and after the test, every function must hold its specified class. On the line, the name of that class is PASS.
Autonomous-driving perception video is sensitive data. The customer’s specification requires the camera link to be encrypted end to end — not as a configuration item, but as a test item verified on every unit.
Verification runs inside the customer’s security framework. On the tooling side, the link’s encryption parameters are delivered through the same JSON configuration as the rest of the bring-up, the ECFG frame grabber joins the negotiation as the authorized receiver, and the test script confirms encryption state, pairing result and fallback behavior for each unit and writes them into that module’s record. Algorithms and key management belong to the customer’s security system and are not covered here.
Why every unit: Encryption is a security property, and security properties are not sampled. One unencrypted camera in a fleet puts the whole chain at risk — so, like sharpness, it is a required answer for every module.
Look back at the code in sections 4 to 6: seven gates keep calling the same small set of interfaces. The ECFG frame grabber puts those capabilities into one piece of hardware, and its SDK opens them up through Python and C++ interfaces. The design idea fits in two words: node-based configuration.
A GMSL camera link carries four kinds of chips: the deserializer (des), the serializer (ser), the image sensor (sen) and the module MCU. The frame grabber maps each of them to its own I2C device node:
device_list = ecfg_ptr.get_i2c_dev_list() # /dev/G1-des /dev/port1-ser # /dev/port1-sen /dev/port1-mcu ...
From there, reading OTP, checking a register or polling status is a single read_i2c or write_i2c on a node name — as direct as reading a file. Initialization and start-up parameters live in JSON configuration files that can be read, reviewed and versioned, so supporting a new camera variant is configuration work, not code.
Turnkey where it should be, open where it matters
The measurement layer works out of the box: power, link, streaming and telemetry are ready as soon as the camera is connected. The test logic stays yours — test items, thresholds and flow live in your own Python or C++ code, under your own version control. For interactive bring-up — scanning devices, loading deserializer profiles, editing registers, watching voltage, current and frame alarms — UGrab runs on the same ECFG hardware; when the flow becomes an automated line, the SDK takes over.
In this program, burn-in is combined with the temperature runs: after each soak the camera streams continuously through a vehicle-length cable while frame rate, bad frames and image stability are monitored. Duration and operating points follow each project’s acceptance requirements; programs that need longer heat runs extend the same set-up.
No. Key management and algorithms belong to the customer’s security framework. The test verifies the observable security properties — encryption state, pairing result and fallback protection — and writes them into each module’s record.
DV runs before production on sample batches, against the automaker’s standards and norms such as IEC 60068, ISO 20653 and ECE R10, to prove the design. PV repeats those tests on parts from production tooling to prove the process. End-of-line testing runs on every unit, taking the feasible part of the validation program to stop process drift and individual defects.
A good picture only means the link works right now. Margin testing answers how much safety distance is left: step the transmit amplitude down 10 mV at a time, and the first error marks the remaining margin. It finds aging cables and poor connector contact while the camera still works.
An ordinary capture setup solves “get a picture.” ECFG also covers PoC power with electrical measurement, link-margin control, encryption verification, temperature telemetry and stable streaming — every low-level entry point the six dimensions need, in one device and open through the SDK.
You choose. For bring-up and interactive checks, UGrab works out of the box. For an automated line, the SDK (Python and C++) exposes power monitoring, link control, encryption state and image streams, and your team builds the flow and the verdict logic on top — the gate table in section 4 is a ready-made blueprint.
Choose by station parallelism: ECFG-S1 (single channel) suits bring-up and per-unit test stations; ECFG-S16 (16 channels) suits parallel testing, burn-in and data collection. Both share one SDK and one set of JSON configuration files, so a script proven on an S1 today runs on an S16 tomorrow. For FPD-Link cameras, look at ECFG-R4.
Through JSON configuration files: deserializer initialization and module start-up parameters all live in configuration that can be read, reviewed and versioned. Adding a variant is configuration work, not development work.
Start with an ECFG frame grabber and its SDK: power monitoring, link margin, encryption verification and stable streaming are ready — write the flow and the verdicts as your own Python logic.
Request the SDK guide →Explore ECFG frame grabbers
Details under NDA — ask us what we can share.
