Industrial Ethernet & TSN Compliance & Certification
← Back to: Industrial Ethernet & TSN
Compliance & certification is not “knowing standards”—it is building a ship-ready, reproducible evidence chain that maps every claim to test setups, logs, and pass criteria.
The core workflow is: targets → requirement matrix → pre-compliance → official tests → change-control re-test → evidence pack traceability.
Scope & Definition: What “Compliance” Means Here
Compliance is not “knowing standards.” It is delivering a ship-ready evidence chain that can be tested, audited, and reproduced across labs and production.
Practical definition (execution view)
- Compliance = requirements that can be tested + results that can be reproduced + artifacts that can be audited.
- Certification = third-party validation of a declared device profile / feature claim under controlled setups.
- A “pass” is only meaningful when it is tied to exact setups (fixtures, firmware config, cables, temperature, instruments) and a traceable version.
Three targets (what is actually being delivered)
Regulatory (CE/FCC/UKCA…)
Output is a documentation set: test reports, declarations, labeling/manual statements, and traceability to hardware/firmware versions.
Industry certification (PI / ETG / ODVA…)
Output is a conformance report + profile declaration + branding rules compliance (logo usage, version constraints, documented behaviors).
Interoperability (plugfests / works-with)
Output is a compatibility record: peer device matrix, topology/config snapshots, issue logs, and reproduction steps for edge cases.
Evidence pack (minimum reproducible set)
- Test plan: test list, limits, sample count, temperature corners, roles/profiles.
- Setup proof: fixtures/cables, photos, instrument settings, calibration IDs.
- Config snapshots: firmware build ID, feature flags, network topology, traffic model.
- Raw logs: counters, captures, timing traces; plus a summary with pass/fail thresholds.
- Traceability: BOM revision, PCB revision, component alternates, known deviations and waivers.
Out of scope (keeps this page lean)
- Detailed PHY SI/equalization theory, TSN gate-list parameterization, or PTP calibration algorithms (handled by their dedicated pages).
- Layout-by-layout EMC fixes (this page focuses on test plans, evidence, and auditability).
- Protocol implementation internals (this page focuses on certification outputs and test readiness).
Diagram: Compliance triangle → Evidence Pack → Ship-ready output
Standards Landscape Map (IEEE / IEC / ITU / Industry Orgs)
The goal is not to memorize standards. The goal is to map: organization → standard family → what it governs → what evidence must be produced.
IEEE trunks (what they govern in certification terms)
- IEEE 802.3: link electrical conformance and interoperability expectations (what labs measure on ports, channels, and stress modes).
- IEEE 802.1: bridging/TSN feature claims, management behavior, and deterministic forwarding proof (what must be demonstrated under traffic and time conditions).
- A feature claim is “real” only when it is supported by config snapshots + captures/counters + pass criteria.
Time & sync families (how to keep evidence clean)
- PTP (IEEE 1588) + 802.1AS: time distribution and timestamp behavior (evidence focuses on offset statistics, topology, and role/config traceability).
- SyncE (ITU-T G.826x): frequency synchronization and holdover expectations (evidence focuses on jitter/wander templates and temperature/aging corners).
- White-Rabbit-style: tighter bidirectional delay measurement and frequency lock (evidence focuses on calibrated delay chains and reproducible delay symmetry records).
Industrial organizations (certification is an output format)
- PI (PROFINET), ETG (EtherCAT), ODVA (CIP / EtherNet-IP): certification typically produces a conformance report plus a profile/device declaration.
- IEC / ISO (safety/environment): compliance focuses on documented limits, test setup validity, and traceability (not just a one-time lab pass).
- The same “evidence pack discipline” applies across electrical, timing, TSN, and industrial protocol certifications.
Diagram: Organization → Standard family → Compliance domain → Evidence outputs
Certification Targets & Profiles: What Exactly Is Being Certified?
Certification is validated against a declared target: device type, port set, feature claims, and a profile scope. Clear declarations prevent scope creep, retest surprises, and “claim vs proof” gaps.
Target decomposition (execution-ready granularity)
Device archetype (root of test paths)
- End device / Remote I/O: port conformance + EMC + protocol conformance outputs.
- Switch / Bridge / Gateway: 802.1 feature claims + timing evidence + management proofs.
- Controller/SoC: “profile declaration” typically dominates pass/fail scope.
Port archetype (where labs measure)
- RJ45 copper: link electrical conformance + EMC exposure at connector/magnetics.
- SPE (T1L/T1S/T1): reach/PoDL scope and cable assumptions must be declared.
- PoE/PoDL: power class + fault/event logging often becomes a certification evidence item.
- Fiber (if used): module/channel assumptions must be fixed for reproducibility.
Feature claims (must bind to evidence)
- TSN subset: Qbv / Qci / Qav / Qbu… (declare scope; avoid undefined “TSN supported”).
- Timing: PTP / 802.1AS roles + SyncE holdover expectations (declare measurement windows).
- Ops: LLDP / LLDP-MED / NETCONF (declare discovery & config surfaces to be audited).
Certification mode (output format)
- Conformance: formal test cases → conformance report.
- Interop: compatibility matrix + event records → “works-with” credibility.
- Profile: declared subset/behavior constraints → profile declaration artifacts.
Declaration checklist (prevents scope drift)
Must be explicit
- Device type, intended role(s), and profile scope (which subsets are in/out).
- Port list (RJ45/SPE/PoE/PoDL), rates/modes, and cable/fixture assumptions.
- Firmware build ID, feature flags, security posture, and management interfaces in scope.
- Temperature corner(s), sample size, and pass criteria definition (mean vs percentile).
Evidence handles (what auditors can verify)
- Config snapshots: profile declaration, TSN/queue mapping, time roles, and policy knobs.
- Counters/captures: drops/CRC, shaping behavior, and timing statistics windows.
- Setup proof: fixtures/cables, instrument settings, calibration IDs, topology records.
Quick routing (from selections to paths)
- RJ45 + switching → 802.3 conformance + 802.1 claims + EMC evidence.
- SPE + PoDL → reach/cable assumptions + power class evidence + field interop records.
- PTP/802.1AS → timing pass criteria + topology calibration records + percentile reporting.
- PROFINET/EtherCAT/CIP → conformance report + profile declaration + interop matrix (as required).
Diagram: Product → Ports → Claims → Profiles → Required tests (scope is what gets certified)
Build a Compliance Matrix: Turn Standards into Requirements
A compliance matrix converts standards and certification claims into executable test rows with clear pass criteria, reproducible setups, and explicit retest triggers.
Matrix = traceability backbone (from clause to evidence)
- Every claim must map to at least one test item and a named evidence artifact.
- Every pass/fail must reference a reproducible setup and a stable definition (mean vs percentile, window, corner).
- Every change must be evaluated against explicit retest triggers to prevent silent certification breakage.
Standard matrix row (recommended fields)
What (basis and claim)
- Standard / Clause: audit anchor for “why this test exists.”
- Test item: executable action with a stable scope.
- MUST / SHOULD / Optional: prevents optional features from expanding certification scope.
How (reproducible execution)
- Setup: fixtures, cables, topology, and environmental assumptions.
- Instrument: tool + settings + calibration ID (prevents lab-to-lab drift).
- Firmware config: build ID + feature flags + role/profile toggles.
- Sample size / Temperature: required corners and pass stability across them.
Proof (pass criteria and evidence)
- Limit / Pass criteria: threshold definition (include percentile/window when needed).
- Evidence: file names/paths for logs, captures, plots, and reports.
- Owner: accountable role for maintaining this row over time.
- Re-test trigger: changes that invalidate the result (BOM/PCB/FW/tooling).
Freeze points (prevent last-minute test invalidation)
- Feature freeze: claim scope and profiles stop changing.
- Test freeze: test plan, setups, and pass criteria definitions are locked.
- Sample freeze: BOM/PCB revision and golden fixtures/cables are fixed for submission.
- Submission freeze: any change must be screened by the matrix retest triggers.
Diagram: One matrix row = clause → test → setup → criteria → evidence → owner → retest trigger
PHY / Link Conformance: IEEE 802.3 What Labs Actually Measure
This section stays in the certification test viewpoint: what gets measured, why failures happen, and how to run pre-compliance with controlled baselines—without drifting into PHY SI design details.
A) Conformance test buckets (what evidence these produce)
- TX bucket: transmitter templates, timing/jitter-oriented outputs, and pattern behavior under defined modes.
- RX bucket: receiver tolerance and error behavior under controlled stress conditions (repeatable windows).
- Channel bucket: channel-oriented limits (return-loss/insertion/crosstalk-style exposure) measurable via fixtures.
- Link bring-up bucket: multi-rate training consistency, loopback/PRBS workflow, and mode matching checks.
- Stress bucket: temperature and environmental corners executed with fixed setup and stable pass criteria definitions.
Evidence shapes (typical outputs)
- Plots/reports (template-style compliance evidence).
- Logs/counters (error counts, training states, link stability windows).
- Setup traceability (fixtures/cables, instrument settings, topology records).
Diagram: Conformance buckets → evidence outputs
B) Failure attribution tree (fastest-first checks)
- Tier 0 (fixtures/cables/jigs): swap checks and golden assets first; many “mystery failures” live here.
- Tier 1 (config/mode): mode mismatch, rate selection, and training assumptions; isolate by locking mode and replaying.
- Tier 2 (board coupling): environment/corner sensitivity; validate reproducibility across temperature and controlled activity.
- Tier 3 (silicon boundary): only after controlled baselines still fail; document margins and retest triggers.
Fast validation actions (per tier)
- Swap cable/fixture; verify instrument preset; compare against known-good baseline.
- Lock rate/mode; confirm loopback/PRBS workflow and training state consistency.
- Re-run corner set (temp/power window) and check if failures cluster by condition.
- Freeze version + capture evidence; map to compliance matrix retest triggers.
Diagram: Failures usually resolve from fixtures/config before deeper causes
C) Pre-compliance checklist (controlled experiment loop)
- Golden assets: golden cable/fixture + known-good reference board for stable baselines.
- A/B comparisons: same setup, DUT vs reference vs known-good, to isolate scope quickly.
- Corner plan: temperature points and defined operating windows; record clustering behavior.
- Evidence discipline: config snapshots + instrument presets + topology/cable IDs per run.
- Freeze rule: scope and builds are locked before submission; map changes to retest triggers.
Minimal run record (per experiment)
- Build ID + mode/rate + feature flags.
- Cable/fixture ID + topology note + instrument preset ID.
- Evidence links: report/plot + logs/counters + capture (if used).
Diagram: Pre-compliance loop (declare → baseline → A/B → corners → submission)
TSN / Bridging Conformance: IEEE 802.1 Feature Claims vs Proof
TSN conformance is not “TSN supported” marketing text. Acceptable certification outcomes require a claim scope, evidence artifacts, and repeatable test scenarios—without turning this page into a parameterization guide.
A) Claim → Evidence → Test (the minimal acceptance chain)
Claims that require proof (examples)
- Time windows / shaping / scheduling behaviors.
- Queue isolation, congestion behavior, and drop policy consistency.
- Filtering/policing/admission control under defined traffic models.
- Management/observability surfaces used for auditing and forensics.
Evidence shapes (what “proof” looks like)
- Config snapshots (claim scope + policy knobs + schedule IDs).
- Traffic model definition (key flows + background + bursts).
- Captures/counters (drops/queues/latency windows) aligned with pass criteria.
- Clock baseline record (role, reference source, measurement window).
Diagram: Claim → Evidence → Test (repeatable acceptance)
B) Determinism under congestion (definitions, not parameterization)
Metrics that must be defined and recorded
- Latency: define window and reporting method (e.g., percentile vs average).
- Jitter: define observation window and reference clock baseline.
- Loss policy: define drop behavior and verify counters align with captures.
- Isolation: define what “isolated” means under congestion, and where it is observed.
Minimal scenario model (repeatable)
- Key flow (critical traffic) + background flow + burst injector.
- Fixed topology snapshot and fixed clock role/reference record.
- Evidence includes config snapshot + captures + counters + summary plot/report.
Diagram: Traffic model → switch behavior → measured determinism
C) Evidence pack blueprint (auditable, retest-safe)
- Config: claim scope, schedule IDs, policy knobs, and role declarations.
- Captures: representative scenarios; captures aligned to pass criteria windows.
- Counters: queue/drop/health counters and timestamps that corroborate the captures.
- Clock: clock role/reference, measurement window, and baseline stability record.
- Versioning: firmware build ID, topology snapshot, and claim/profile revision.
Retest triggers (examples)
- Claim scope change (TSN subset, roles, drop policy).
- Topology change (paths, link speeds, clock boundaries).
- Clock reference change (source, mode, holdover behavior).
- Firmware behavior change that affects scheduling, counters, or management surfaces.
Diagram: Evidence pack structure (config/captures/counters/clock + freeze & retest)
Time & Sync Compliance: PTP / 802.1AS / SyncE / WR-like (Proof-Driven)
Passing acceptance often fails not because timing “looks OK,” but because the evidence chain is incomplete or not repeatable. This section focuses on acceptance fields and auditable proof artifacts (not implementation details).
A) Acceptance fields (define the audit trail before measuring)
Topology snapshot (must be recorded)
- Clock roles per node (GM / BC / TC / Slave) and clock domain boundaries.
- Path description (crossing switches/bridges), and whether E2E or P2P correction is used as a test dimension.
- Asymmetry risk flags (directional delay sources) and calibration scope/ID.
Configuration snapshot (must be frozen)
- PTP / 802.1AS: role, one-step/two-step mode, E2E/P2P selection, profile name, message rate interval.
- SyncE: reference source, enable state, holdover policy ID, switching policy ID.
- WR-like: bidirectional delay measurement enable state, frequency-lock state, calibration version.
Metrics definition (must be explicit)
- Offset/jitter: sampling rate, statistics window, and reporting method (e.g., P99 / Max) with acceptance threshold “X”.
- SyncE: output jitter / wander observation window and holdover duration, with pass criteria “X”.
- Temperature drift: temperature record alignment with offset series and plot span.
- Asymmetry calibration: method ID, before/after comparison, and validity bounds.
Evidence artifacts (minimum set)
- Raw logs/time series (offset, sync state, event markers).
- Summary plots (offset/jitter distribution, drift curve, holdover/wander trend).
- Config + topology IDs bound to the same measurement window.
- Event record (link flap, reference switch, restart, re-lock) aligned to timelines.
Diagram: Timing evidence pack (Topology → Config → Metrics → Plots → Pass/Fail)
B) “Looks OK” pitfalls (evidence-level failure causes)
- Window mismatch: short windows look clean while long windows expose wander/drift.
- Metric mixing: mean vs percentile vs max are blended without definition; tails are hidden.
- Topology drift: maintenance changes the path, but no topology snapshot exists for comparison.
- Asymmetry untracked: calibration exists but is not traceable (no method ID / bounds / before-after plot).
- Event holes: reference switch or re-lock events are missing, so plots cannot be explained or accepted.
Minimal correction rule (audit-ready)
- Any plotted result must reference: topology ID + config ID + window ID.
- Any pass decision must reference: metric definition + threshold “X”.
- Any exception must reference: event marker + timeline alignment.
Diagram: Window definition decides “pass” (short vs long)
C) Retest triggers (change → measurement gate)
- Firmware updates on any clock boundary node (GM/BC/TC) or on bridging/switch nodes affecting timing paths.
- Profile/role/mode changes (one-step/two-step, E2E/P2P) or message rate changes.
- Topology/path changes (link speed changes, queue policy changes, new hops).
- Reference source or holdover policy changes (SyncE reference, switching, holdover).
- Expanded environmental envelope (temperature range, power range) beyond validated conditions.
Minimal retest gate output
- Updated topology/config IDs and new window IDs.
- Before/after plots under the same metric definitions.
- Event record showing no unexplained re-lock or reference switch behavior.
Diagram: Change categories → retest gate → updated evidence
Industrial Protocol Certifications: PROFINET / EtherCAT / CIP (Conformance + Interop)
A demo is not a certification. Certification is a pipeline: official conformance results + interop records + profile declarations, all bound to versions and evidence artifacts.
A) The three required outputs (what “certified” means in practice)
Output 1 — Conformance report
- Official test coverage mapped to declared profile/features.
- Reproducible fail conditions (state machine boundary / timing definition / error mapping).
- Version binding: firmware build + device declaration + test setup snapshot.
Output 2 — Interop event record
- Peer device list, topology, load model, and exception scenarios.
- Results and known limits recorded for field expectation control.
- Retest triggers: peer version changes or stack changes.
Output 3 — Profile declaration (device statement)
- Device class/role and supported subset declared (no “undefined support”).
- Descriptor artifacts delivered (e.g., device description files by type).
- Branding release is valid only when declaration matches test evidence.
Diagram: Certification pipeline (Dev → Pre-test → Official test → Interop → Release)
B) Per-protocol path cards (same structure, no encyclopedia drift)
PROFINET — path card
- Target: device role/class and declared subset (profile-driven).
- Deliverables: device declaration artifacts (descriptor file type), diagnostics statement, version IDs.
- Common fails: state boundary handling, timing definitions, diagnostic consistency, reconnect behavior.
- Evidence: official report + interop record + declaration bound to build.
EtherCAT — path card
- Target: slave/device category and supported feature set.
- Deliverables: device description artifacts (by type), diagnostics behavior statement, revision IDs.
- Common fails: error mapping, timing/timeout semantics, state transitions, recovery consistency.
- Evidence: conformance result + interop notes + declaration consistency.
CIP / EtherNet-IP — path card
- Target: adapter/device class and declared objects/features subset.
- Deliverables: device description artifacts (descriptor file type), object/diagnostic declaration, version IDs.
- Common fails: exception codes, timing semantics, reconnect strategy, diagnostics consistency.
- Evidence: conformance report + interop record + profile/device statement.
Diagram: Protocol certification path (deliverables + retest loop)
C) Delivery artifacts (types only, to avoid protocol-internals)
- Descriptor files: device description file types required by the ecosystem (deliverable category, not format details).
- Diagnostics statement: what is reported, when it is reported, and which states trigger it.
- Profile declaration: role/class + supported subset + version IDs.
- Evidence links: official report + interop record + release note mapping to the same build ID.
Field expectation control (why artifacts matter)
- A declaration without a report is a claim without proof.
- An interop record without peer/version detail is not repeatable.
- Any released branding must match the declared subset and the tested evidence pack.
Diagram: Artifacts bundle (declaration + report + interop + version binding)
EMC & Safety Compliance: Immunity/Emission + Safety + Environment
Lab “once-pass” results are not a compliance system. This section turns EMC and safety into a reproducible engineering loop: planned evidence, version binding, retest gates, and audit-ready records.
A) EMC evidence chain (emission + immunity) — make results repeatable
What the lab expects (as proof, not theory)
- Test plan mapping: item → setup → limit → pass criteria “X” → sample count.
- Setup reproducibility: cable/fixture IDs, grounding scheme, power mode, and port states.
- Result package: raw data + plots + limit overlay + exception notes.
- Fix loop trace: change log + before/after comparison + retest gate record.
Mandatory record fields (minimum set)
- Environment: temperature/humidity + shielding/grounding notes.
- Power & ports: supply mode, PoE/PoDL state, port speed/mode, link state.
- Traffic/load model: load level, flow template ID, worst-case scenario ID.
- Instrument snapshot: key settings IDs (e.g., bandwidth / detector / distance fields).
- Version binding: HW rev + FW build + config snapshot + fixture/cable IDs.
- Event markers: link flap, reset, mode switch, reference changes aligned to timelines.
Retest triggers (keep certification valid)
- Any change in enclosure/shield bonding/connector mechanics that alters return paths.
- Cable, magnetics, common-mode components, or protection part vendor substitutions.
- Firmware updates affecting port modes, power states, or recovery behavior.
- Fixture revisions, probe changes, or instrument setting template updates.
- Expanded operating conditions (wider temperature range or new power modes).
Diagram: EMC compliance loop (Design hooks → Pre-compliance → Lab test → Fix loop → Evidence)
B) Safety evidence chain (electrical safety + documentation)
Structural proof (what must be verifiable)
- Clearance/creepage declarations tied to drawings and PCB revisions.
- Insulation system statement (materials and applicable ratings), version-bound.
- Dielectric/insulation tests: setup snapshot + limit “X” + sample count.
- Marking/labeling and safety-relevant mechanical constraints, version-bound.
Documentation proof (what auditors check)
- Risk assessment version and scope (what configurations are covered).
- Material declarations and supplier traceability for safety-relevant parts.
- Manufacturing consistency notes (build options and controlled variants).
- Change control log linking design changes to retest decisions.
Environmental claims (certification-only lens)
- Operating temperature range must match the tested envelope and evidence pack.
- If reliability evidence is required, it must be declared as a deliverable type with sample definition.
- Any expanded envelope is a retest trigger unless covered by the original evidence chain.
Diagram: Safety evidence pack (structure + docs + retest gate)
Pre-Compliance Lab Setup: Fixtures, Golden Units, and Reproducibility
Certification risk drops sharply when pre-compliance becomes an asset: controlled fixtures, golden references, version tags, and logs that allow the same result to be reproduced on demand.
A) Checklist: build a reproducible bench (fields-first, not technique-first)
1) Fixtures & jigs control
- Consistency: fixture ID + revision + calibration date + allowed substitutions list.
- Grounding: grounding scheme ID + connection points + photos/diagrams as artifacts.
- Version tags: fixture revision bound to every measurement run.
2) Golden references (DUT / cable / config)
- Golden DUT: stable hardware build used for correlation and drift detection.
- Golden cable: controlled cable type/length/batch to remove “swap-a-cable” variance.
- Golden config: config snapshot ID + profile/mode ID frozen for baseline runs.
- Replacement triggers: any golden replacement must create a new golden ID and re-baseline.
3) Logging & naming (make runs auditable)
- Environment fields: temperature/humidity + power supply mode + grounding scheme ID.
- Instrument fields: instrument template ID + key setting snapshot IDs.
- Network fields: topology snapshot ID + traffic/load template ID + event markers.
- Naming rule: date + build ID + setup ID + scenario ID (consistent and searchable).
4) A/B correlation (prove drift is real, not setup noise)
- Run A/B with the same setup tags before blaming the DUT.
- Cover temperature points as declared conditions (not ad-hoc).
- If results diverge, treat it as a setup drift until proven otherwise.
Diagram: Reproducible bench stack (DUT + cable + load + instruments + logger + version tags)
B) Minimal “bench pass” template (declare what is comparable)
Comparable runs require the same tags
- Same golden cable ID + fixture ID + instrument template ID.
- Same DUT config snapshot ID and declared scenario ID.
- Same environment envelope or the envelope is explicitly recorded as a variable.
Bench “pass” must include these artifacts
- Plot + raw data + limit overlay (threshold “X”).
- Setup snapshot (instrument + topology + port states) with IDs.
- Change log if the run is after any fix loop.
Diagram: Comparable vs non-comparable runs (tag match)
tokens: bg=#0b1120 card=#0b1224 border=#1f2a44 text=#e5e7eb muted=#cbd5e1 accent=#3b82f6 good=#22c55e warn=#f59e0b bad=#ef4444
H2-11 · Evidence Pack & Change Control: What Auditors Ask For
Goal: convert “we comply” into a ship-able evidence chain that stays valid after BOM/layout/firmware/process changes.
This section focuses on what to archive, how to trace, and when to re-test—not on how each lab test is performed.
A) Evidence Pack Template (copy-paste structure)
- 00-Readme: scope, claim list, tested configuration list, pass/fail summary (with dates).
- 01-TestPlan: test items → limit X → sample size → temperature points → setup template ID.
- 02-Setup: photos, topology snapshot, fixture/cable IDs, grounding/shield notes.
- 03-Config: config dumps (hash), feature flags, profile declarations, port modes.
- 04-RawData: instrument exports, captures, waveforms, measurement files.
- 05-Logs: device/system logs with time stamps and event markers.
- 06-Stats: defined windows, percentiles, counter deltas, criteria mapping.
- 07-Traceability: serial/HW rev/BOM rev/FW build/config hash, calibration certificates.
- 08-Deviations: deviation ID, justification, risk note, expiry, retest decision.
- 09-Release: branding basis, certificate references, shipping rule (what must match).
B) Change → Risk → Retest Gates (minimal regression set)
- Change triggers: BOM substitutions, PCB/layout edits, firmware feature toggles, manufacturing process changes.
- Risk buckets: EMC drift / signal integrity drift / timing drift / protocol behavior drift / safety margin drift.
- Retest decision: run Minimal Regression Set by default; expand only when the risk bucket is hit.
- Audit-friendly output: “trigger → reasoning → retest set → result” recorded as a deviation/retest ticket.
C) Production Sampling (keep compliance reproducible)
- Sampling basis: by lot, by supplier batch, by critical process window, and after any approved deviation.
- What to re-run: the Minimal Regression Set plus “golden unit” A/B comparison.
- What to archive: the same traceability spine fields (serial/HW/FW/config/fixture/cable/cal).
H2-12 · Applications & IC Selection: Compliance-Driven Selection Logic (with Part Numbers)
Selection principle: choose silicon that can produce auditable evidence (dumps/logs/counters/self-test modes)
and reduce “claim ≠ proof” risk during conformance and interoperability events.
The part numbers below are examples; exact variants should match temperature grade, package, and certification scope.
PHY
Compliance axes: built-in loopback/PRBS, robust status counters, clear mode/config dumps, reference ecosystem for pre-compliance.
- 10/100 PHY examples: TI DP83822I
- Industrial 1G PHY examples: ADI ADIN1300
- SPE 10BASE-T1L examples: ADI ADIN1100 (PHY), ADI ADIN1110 (MAC-PHY)
- Automotive 100BASE-T1 examples: NXP TJA1100
- ESD protection (Ethernet/T1): Nexperia PESD1ETH10L-Q (low C), Semtech RClamp0524PA (TVS array)
Evidence outputs to require: PHY mode snapshot, PRBS results, error counters (CRC/alignment), link training/status events, temperature point tags.
Switch / TSN
Compliance axes: TSN claim→evidence mapping, per-port counters, mirroring/telemetry, config export, deterministic features that can be proven.
- TSN switch examples: Microchip LAN9662 (TSN switch w/ integrated CPU), NXP SJA1105 (TSN/AVB switch family)
- PoE PSE controller example: TI TPS23881 (IEEE 802.3bt PSE controller)
- Interop-proof hooks: port mirroring + storm control + per-queue statistics (exportable).
Evidence outputs to require: gate-control lists snapshots, queue counters, drop policies, capture points (mirror), and “tested config hash”.
Timing
Compliance axes: proof-ready sync metrics (windows/percentiles), SyncE/holdover records, topology/asymmetry records, reproducible clock configuration exports.
- Jitter attenuator / clock generator examples: Skyworks (SiLabs) Si5341
- SyncE / IEEE 1588 network synchronizer examples: Microchip ZL30772
- PTP system synchronizer examples: Renesas 8A34001
Evidence outputs to require: offset/jitter stats (window defined), holdover/wander logs, servo parameters, clock source selection logs, topology/asymmetry calibration record IDs.
Stack / SoC
Compliance axes: conformance-ready behavior (state machine edges), exportable device description artifacts, stable diagnostics, and traceable builds.
- EtherCAT slave controller example: Microchip LAN9252 (EtherCAT controller w/ integrated PHYs)
- Multiprotocol industrial comm SoC example: Hilscher netX 90
- PoE PD controller examples (when PoE is in scope): TI TPS2372 (802.3bt PD), ADI LTC4269-1 (802.3at/af PD)
Evidence outputs to require: exported device description files (by protocol family), standardized diagnostics/events, interoperability test logs, build+config hashes aligned to the evidence pack.
Scope guard: the part numbers above are listed only to anchor compliance-relevant capabilities.
Configuration procedures, PHY/SI design details, and TSN parameter tables belong to their dedicated sibling pages to avoid content overlap.
Recommended topics you might also need
Request a Quote
H2-13 · FAQs (Field / Lab / Re-test Troubleshooting)
Focus: close out field / official lab / re-test long-tail issues without expanding the main chapters.
Each answer is exactly four lines: Likely cause / Quick check / Fix / Pass criteria (with data placeholders X, W, Pxx, N, T, etc.).
Lab says fail, but the bench looked fine — first sanity check: fixture/cable/instrument settings?
Likely cause: fixture/cable mismatch, instrument preset drift, or calibration/template inconsistency versus the official lab setup.
Quick check: compare Fixture ID, Cable ID, Adapter Rev, Preset ID, RBW/VBW, averaging, limit-line version, and latest Cal Cert dates.
Fix: freeze a golden fixture + golden cable + golden preset, run A/B against the same DUT, and archive setup photos + preset exports in the evidence pack.
Pass criteria: two independent runs match within X% (or X dB) margin to limit, under the same preset ID and IDs {fixture, cable, adapter} with window W.
Same DUT passes once, then fails after a “minor” firmware change — what change-control field is missing?
Likely cause: missing traceability fields (FW build/config hash/feature flags) causing a silent behavior change without a mapped re-test set.
Quick check: verify FW Build ID, Git SHA, Config Hash, feature-flag snapshot, and test-plan version; diff “default” settings versus the last certified run.
Fix: enforce “trigger → risk bucket → minimal regression set” tickets; lock the tested configuration and rebuild the evidence spine for the new firmware.
Pass criteria: minimal regression set R executed with identical topology and config; error counters stable within X/10^6 frames over W, and hashes match the pack manifest.
EMC ESD passes, but the link becomes fragile later — what degradation evidence is fastest?
Likely cause: latent damage (leakage/capacitance shift), shield/connector contact changes, or margin erosion not captured by “pass once” ESD records.
Quick check: run a post-stress baseline vs pre-stress golden record: CRC/BER counters, link retrains, return-loss proxy metrics, and TVS leakage at X V (if available).
Fix: add “post-ESD health check” to the plan; replace suspect protection/connector parts; document a delta-budget and archive both baselines in the pack.
Pass criteria: post-stress deltas stay within X% of baseline, BER < X over W, and no monotonic drift across N re-check cycles.
PTP offset meets average spec, but fails percentile requirement — what window/percentile definition mismatch?
Likely cause: different window W, percentile Pxx, warm-up exclusion, filtering, or outlier policy between lab/customer computations.
Quick check: export raw offset series + timestamp rate R; recompute using the customer’s declared W/Pxx and compare to the lab report headers.
Fix: standardize a metric contract: include W, Pxx, sampling R, filtering, and computation version/hash in every evidence pack.
Pass criteria: Pxx offset ≤ X ns over window W at rate R, with computation hash matching the archived script/version.
SyncE holdover looks OK in lab, fails in field — what temperature/profile evidence is missing?
Likely cause: lab profile does not match field: temperature ramp, loss duration T, reference quality, or load conditions were not represented in evidence.
Quick check: compare the profile definition: temp range [A..B], ramp rate, loss duration T, and output mask/template; confirm oscillator grade + board temperature logs exist.
Fix: define a field-valid profile P; re-run holdover under P with recorded temp/time stamps; archive holdover drift and mask compliance traces.
Pass criteria: holdover stays within mask/template for profile P; drift ≤ X ppb (or equivalent) over T, with traceability IDs bound to the run.
PROFINET/EtherCAT conformance fails only on exception paths — what state-machine edge is usually forgotten?
Likely cause: missing error-state transitions, timeout boundaries, or diagnostics/code mapping on rare paths not covered by “happy path” testing.
Quick check: run the official exception vector subset (N cases); capture pcap + response codes; compare against the device’s declared error handling matrix.
Fix: implement the missing state edges; align diagnostics with declared artifacts; add unit tests for exception vectors and re-run the conformance subset before resubmission.
Pass criteria: 100% pass over exception suite N; response time within X ms where applicable; error codes/diagnostics consistent across retries and reconnects.
Interop event passes, but customer network flaps — what “claim vs proof” gap is common in TSN features?
Likely cause: TSN “feature claim” was not backed by proof artifacts: missing config dumps, GCL alignment, admission/guard settings, or sync topology calibration records.
Quick check: export GCL snapshot, Qbv/Qci/Qav settings, sync status, and per-queue counters; verify topology record + timebase IDs match the tested profile.
Fix: freeze a “tested TSN profile” (config hash + topology + traffic model) and archive dumps/counters/pcaps as the evidence pack proof set.
Pass criteria: flap rate ≤ X/hour under load L over W; gate-miss counters = 0; latency P99 ≤ X µs for declared flows.
802.3 electrical test fails only at hot — what pre-compliance step catches it earliest?
Likely cause: temperature-driven margin collapse (clock/power/analog drift), or hot-chamber setup not aligned with the lab fixture/cabling/preset.
Quick check: run pre-compliance at T_hot using golden cable/preset; log supply V/I, temperature, link mode, EQ/training state, and error counters across window W.
Fix: add thermal points to the pre-test plan; tighten power/clock margins and stabilize configuration; lock hot-fixture IDs and record them in the evidence spine.
Pass criteria: at T_hot ± X°C, margin ≥ X (per metric), BER < X over W, repeatable across N runs with identical IDs.
After BOM alternates, EMC margin collapses — what re-test trigger rule should have fired?
Likely cause: “alternate” changed parasitics (capacitance/leakage/magnetics/choke behavior) or shield bonding; the change was not classified as a critical trigger.
Quick check: compare BOM Rev, supplier/lot IDs, critical component list, and pre/post EMC baselines; verify whether the trigger table maps this swap to the extended set.
Fix: tag protection/magnetics/shield/clock/power parts as critical components; enforce “alternate → extended regression” and archive A/B evidence for each qualified source.
Pass criteria: EMC peak margin ≥ X dBµV; immunity errors ≤ X events over W; alternate lots match baseline within X% across N samples.
Cable diagnostics differs by vendor tester — how to build a golden reference to avoid tool bias?
Likely cause: different algorithms, reference-plane definitions, calibration kits, or sweep ranges across testers.
Quick check: align ref impedance, calibration method/kit ID, sweep band B, reference plane, and cable length; compare against a known-good “golden cable” set.
Fix: define a golden reference: golden cable set + golden preset + archived raw traces; evaluate testers by correlation metrics before accepting results.
Pass criteria: tester-to-tester deltas ≤ X% on key metrics (RL/IL) over band B; trace correlation ≥ X (defined method) across N repeats.
Certification takes forever — what minimum evidence pack structure speeds review most?
Likely cause: incomplete pack: unclear tested configuration scope, missing traceability spine, or missing raw data and computation definitions.
Quick check: audit the pack against the 00–09 folder template; ensure every result binds to Serial/HW Rev/BOM Rev/FW Build/Config Hash/Fixture ID/Cable ID/Cal Cert.
Fix: publish a pack index manifest, include raw logs + stats windows/percentiles, and document computation version/hash for every derived metric.
Pass criteria: reviewer follow-ups ≤ X requests, turnaround ≤ X days, and any metric can be reproduced from raw artifacts using the declared IDs.
Passed certification, production yield drops — what station-to-station correlation record is usually missing?
Likely cause: station presets diverged, fixture wear, calibration lapse, environment drift, or FW/config mismatch not tracked across production stations.
Quick check: compare Preset IDs, Cal Cert dates, fixture/cable IDs, temperature/PSU logs, and FW/config hashes; run a golden unit A/B across stations.
Fix: implement station correlation SOP: lock presets, schedule fixture replacement, add golden runs per shift, and archive correlation reports in the evidence pack tree.
Pass criteria: station deltas ≤ X% on key margins/counters, yield stable within Xσ over W, and correlation logs are traceable by station ID + run IDs.
ICNavigator helps engineers find verified ICs, alternatives, and fast quotes.
Categories
- Power Management
- MCU
- Automotive ICs
- Sensors
- Interface & Transceivers
- Analog Front-End
Get in Touch
- Email: hello@icnavigator.com
- WeChat/WhatsApp: +86-xxxx