123 Main Street, New York, NY 10001

Submit Your BOM

Bus Diagnostics / Monitor IC: Fault Events & Counters

Bus Diagnostics / Monitor IC: Fault Events & Counters

← Back to: Automotive Fieldbuses: CAN / LIN / FlexRay

A Bus Diagnostics / Monitor IC turns analog bus anomalies into trustworthy digital evidence—events, timestamps, and counters—so faults can be attributed correctly and fixed faster.

The focus is on detection coverage, threshold/time-window semantics, logging models, and verification-by-injection so diagnostics stay accurate from lab bring-up to production and service.

H2-1 · Definition & Scope: What is a Bus Monitor / Diagnostics IC?

A bus monitor/diagnostics IC is a high-impedance observer that converts analog bus abnormalities into structured digital events (fault type + time behavior + counters/logs) for fast attribution and serviceability. It does not participate in communication arbitration or waveform driving.

Core role Signal → Rule → Event → Evidence
  • Signal (observable): bus voltages and derived metrics (single-ended, differential, common-mode, symmetry).
  • Rule (decision): thresholds + time windows (deglitch, persistence, hold-off) define when a condition becomes a fault.
  • Event (structured): a fault becomes a record with fields like fault_id, enter/exit timestamp, duration, optional peak/min.
  • Evidence (serviceable): counters and logs are readable by the ECU for diagnosis, correlation, and field return reduction.

What it monitors (expressed as observables)

Single-ended voltage (CANH / CANL or LIN line)
Primary input for detecting short-to-battery, short-to-ground, and over-voltage conditions.
Differential voltage (Vdiff = CANH − CANL)
Used for stuck-level signatures, amplitude anomalies, and as a diagnostic cue for bus health (without decoding frames).
Common-mode voltage (Vcm = (CANH + CANL)/2)
Key observable for ground offset and common-mode drift cues that influence robustness and false alarms.
Symmetry / imbalance indicators
A structured way to quantify CANH/CANL asymmetry (dominant/recessive bias or mid-level shift) as a fault cue. The page focuses on eventization of imbalance, not the PHY waveform details.

What it is not (scope guard)

  • Not a PHY/transceiver: it does not drive dominant/recessive, shape edges, or manage bit timing. PHY waveform/timing details belong to the dedicated transceiver pages.
  • Not a controller: it does not parse frames, IDs, CRC, or schedule messages. Protocol behavior and gateway logic belong to controller/bridge pages.
  • Not an EMC/protection component: it does not replace TVS/CMC/split termination networks. Protection sizing and layout belong to the EMC/protection co-design page.
Deliverable (reusable standard block)
Terminology map: Signal (CANH/CANL/Vdiff/Vcm) → Fault class (open/short/over-voltage/imbalance) → Event (fault_id + time behavior) → Evidence (counters/log).
Boundary list: “Not PHY / Not Controller / Not EMC” routing rules to prevent cross-page overlap.
SVG-1 · Where it sits (system placement)
Connector Harness Protection Block only CAN/LIN PHY Transceiver MCU/ECU Diagnostics Monitor IC Hi-Z sense → Events Bus tap IRQ I²C/SPI Key point Monitor IC observes (Hi-Z) and reports events; it does not drive the bus or decode frames.

H2-2 · Why It Exists: Attribution, Serviceability, and “Black-Box” Evidence

The same diagnostic symptom can be caused by harness issues, node behavior, or environmental stress. A monitor IC exists to turn ambiguity into evidence by logging what happened, when, how long, and how often (counters + timestamps + context flags), enabling faster root-cause routing and fewer ineffective part swaps.

Evidence-first model (what makes it “black-box” useful)

Time behavior beats single snapshots
Persistent faults, bursty glitches, and intermittent contact problems can look identical in a single capture. Time windows and event duration separate these cases without expanding the PHY page.
Counter semantics prevent misleading diagnosis
A raw count is not enough. Evidence needs defined windows (X ms / Y s), hold-off, and clear policy so service does not lose critical history after a reset or a manual clear.
Context flags turn “faults” into attribution cues
Binding events to simple context (awake/sleep, supply state, temperature zone, ignition cycle) improves routing without requiring frame decoding or controller-level logic.

Attribution triangle (same symptom, different domains)

  • Harness (wiring/connector): intermittent open/short patterns, vibration-linked bursts, contact degradation signatures. Evidence cue: bursty counts + short duration clusters.
  • Node (ECU/transceiver/power domain): persistent over-voltage conditions, state-dependent faults after wake/reset, thermal-linked recurrence. Evidence cue: long persistence + state correlation.
  • Environment (EMI/ESD/external stress): sparse but high-amplitude excursions, seasonal/dry-air patterns, transient-induced glitches. Evidence cue: peaky events + very short duration (after deglitch definition).

What it improves (measurable outcomes)

Faster MTTR (mean time to repair)
A field case can be routed using event frequency, duration distribution, and context flags instead of repeated part swaps and non-reproducible bench captures.
Stronger diagnostic coverage (without decoding)
The page focuses on fault observables and event rules (thresholds + time), which increases confidence in detection/false-flag management without expanding protocol pages.
OTA regression detection via evidence deltas
Comparing event rates and persistence across versions helps detect regressions in wake policy, power behavior, or noise sensitivity—without changing PHY-level content.
Deliverable (event → attribution routing examples)
Bursty open events
Likely domain: harness/connector intermittency. Next action: inspect contact/vibration path; keep controller/PHY pages out of scope.
Long over-voltage persistence
Likely domain: node/power-domain behavior. Next action: correlate with awake/sleep and supply state; defer protection sizing to EMC page.
Short spikes with high peaks
Likely domain: environmental transient coupling. Next action: tighten deglitch/persistence definitions; route mitigation networks to EMC page.
Imbalance events tied to a specific harness
Likely domain: harness asymmetry or connection mismatch. Next action: confirm measurement reference and tap placement; keep SIC/FD waveform details in PHY pages.
Counters increase, but logs are empty
Likely domain: reporting semantics (window/clear/IRQ readout). Next action: align event/counter definitions and readout order; avoid protocol-stack expansion.
SVG-2 · From analog fault to evidence (black-box chain)
Fault sources Harness Node Environment Measured CANH / CANL Vdiff Vcm Imbalance Classifier Threshold Time window Evidence Counters Event log Service decision / Root-cause routing Goal: convert ambiguous faults into structured, time-aware evidence.

H2-3 · Internal Architecture: Sensing Front-End → Filter → Classifier → Reporter

A monitor IC is best understood as a signal-to-evidence pipeline. It senses bus observables with high impedance, applies time-aware filtering to reject transients, classifies faults without decoding frames, and reports structured events through counters, logs, and interrupts.

The 5 building blocks (what each block does, and what to check)

Block A
Sensing Front-End (AFE, Hi-Z bus observation)
  • Purpose: sample CANH/CANL (or LIN line) without adding meaningful bus load.
  • Key “do-no-harm” checks: input leakage, effective input R/C, and common-mode range so the tap does not distort edges.
  • Survivability checks: input absolute maximum and tolerance to excursions (conceptually: clamp behavior), without relying on TVS details.
Block B
Window Comparator or ADC (detection primitive)
  • Comparator path: fast threshold crossing detection; best for “stuck level” and quick fault onset.
  • ADC path: enables quantized evidence (peak, duration estimates, symmetry metrics) with higher configurability.
  • What to check: threshold accuracy, response latency, sampling rate (if ADC), and power vs resolution trade-offs.
Block C
Digital Filter (deglitch, persistence, hold-off)
  • Deglitch: ignores excursions shorter than a minimum width to reduce false events.
  • Persistence window: requires a condition to remain true for a duration before it becomes a fault event.
  • Hold-off / rate limiting: prevents oscillating faults from flooding IRQs and counters.
  • What to check: programmable timing ranges, enter/exit rules, and how intermittent events are grouped.
Block D
Fault Classifier (conditions → fault_id)
  • Purpose: map observables (single-ended, Vdiff, Vcm, imbalance indicators) to fault categories.
  • Key boundary: classification is based on analog observables and time behavior, not frame decoding.
  • What to check: supported fault IDs, priority rules (which fault wins), and whether coexistence is recorded as multiple events.
Block E
Reporter (counters, ring buffer log, IRQ, host interface)
  • Counters: windowed vs total vs consecutive counts; semantics matter more than raw totals.
  • Event log: ring buffer depth, overwrite vs freeze policy, and timestamp availability.
  • IRQ: trigger modes (first occurrence vs every occurrence vs threshold-crossing) must match system needs.
  • Host: I²C/SPI readout with minimal overhead; no protocol-stack dependency.
Deliverable · “Specs-to-check” module checklist (what to look for in datasheets)
AFE: input leakage, effective input R/C, common-mode range, abs max, excursion tolerance.
Comparator/ADC: threshold accuracy, latency, sample rate/resolution (if ADC), power budget.
Filter: deglitch min width, persistence window range, enter/exit behavior, hold-off/rate limit.
Classifier: fault IDs supported, priority/coexistence handling, mapping to observables.
Reporter: counter semantics, log depth, timestamp support, IRQ modes, I²C/SPI interface behavior.
SVG-3 · Monitor IC block diagram (signal → evidence pipeline)
Bus inputs CANH/CANL Derived Vdiff / Vcm AFE Hi-Z sense Clamp concept Window Comparator ADC Sample / peak Digital Filter Deglitch Persistence Fault Classifier Conditions → ID Priority Counters Windowed Ring log Host IF I²C / SPI IRQ Config Threshold Time window Programmable Structure: observe → filter → classify → record → report

H2-4 · Fault Taxonomy: Open / Short / Over-Voltage / Imbalance (What you can detect, and how)

Fault taxonomy becomes actionable only when each fault is defined as observable signatures mapped to detection primitives (threshold + time window). This section focuses on event definitions and boundaries—PHY waveform design and EMC networks are routed to their dedicated pages.

Detectable definitions (signature → primitive → boundary)

Open (broken wire / intermittent contact)
Observable signature
Abnormal static bias windows, unreachable bus levels during state changes, or bursty excursions that correlate with movement/vibration.
Detection primitive
Window checks on single-ended levels plus a persistence / burst grouping rule to separate persistent opens from intermittent contact faults.
Boundary / confusion
Without time rules, intermittent opens can be misread as noise spikes. Deglitch and burst window definitions prevent misleading counts.
Short to VBAT/GND (stuck-level faults)
Observable signature
One line pinned near VBAT or GND, prolonged stuck dominant/recessive behavior, and common-mode drift as the bus loses symmetry.
Detection primitive
Single-ended window comparators for “pinned” detection, reinforced by a minimum persistence window to ignore momentary excursions.
Boundary / confusion
Short-like signatures may appear during strong transients. Separating transient over-voltage from persistent pinning requires consistent time semantics.
Over-voltage (transient vs persistent)
Observable signature
Single-ended or common-mode values exceed a defined window. The time profile differentiates short spikes from sustained stress.
Detection primitive
Two event classes using the same window: OV-transient (passes deglitch but fails persistence) and OV-persistent (meets persistence). This supports separate counting and risk interpretation.
Boundary / confusion
If deglitch is too short, the system may overcount spikes. If persistence is too short, sustained stress can be miscategorized and lose service significance.
Imbalance (asymmetry as an attribution cue)
Observable signature
CANH/CANL symmetry deviates beyond a defined window: dominant/recessive bias shifts, mid-level drift, or Vcm–Vdiff coupling patterns.
Detection primitive
Compare measured symmetry indicators against thresholds, then apply a persistence rule so imbalance becomes an event rather than a noisy metric.
Boundary / confusion
Imbalance indicates asymmetry but does not replace PHY waveform analysis. Root-cause mitigation and network tuning belong to PHY/EMC pages.
Deliverable · Fault → signature → primitive (compact reference)
Open
Signature: bias window shift / unreachable levels / bursty clusters
Primitive: window + persistence + burst grouping
Short
Signature: pinned single-ended / stuck level / Vcm drift
Primitive: pin window + minimum persistence
Over-voltage
Signature: SE or Vcm exceeds window; time profile matters
Primitive: OV-transient vs OV-persistent using deglitch/persistence
Imbalance
Signature: symmetry indicator out of window
Primitive: symmetry threshold + persistence
SVG-4 · Fault map matrix (fault types vs observables)
Fault → Observable map (P = primary, A = auxiliary) Vdiff Vcm Stuck Asym Persist Fault type Open Short Over-V Imbalance A A P P A P P P A P A A A Interpretation: P = main observable for the fault; A = supporting observable. Time windows convert observables into events.

H2-5 · Thresholds, Time Windows, and Debounce: Avoid False Flags

Diagnostic quality is determined by a simple rule: thresholds define what is “seen”, and time windows define what is “believed”. Reliable events require a stateful definition: enter, validate, exit, and re-trigger suppression.

Core
Why a single threshold produces false flags
  • Noise spikes cross a threshold briefly and look like faults.
  • Boundary jitter (e.g., intermittent contact) causes repeated enter/exit toggles and counter inflation.
  • Process + temperature drift pushes signals to hover near the threshold, amplifying false events.
Enter/Exit thresholds: define direction and reduce toggling
Event rule (portable definition)
Enter when signal ≥ TH_enter for T_deglitch. Validate when the condition persists for T_persist. Exit when signal ≤ TH_exit for an exit-confirm window. Use TH_exit ≠ TH_enter to prevent chattering.
Timing “dictionary”: what each parameter fixes
Deglitch (T_deglitch)
Rejects short excursions. Too short → overcount spikes; too long → misses brief but real faults.
Persistence (T_persist)
Converts a condition into a “validated event”. Enables transient vs persistent classification.
Hold-off (T_holdoff)
Suppresses re-triggering during fault recovery, preventing IRQ storms and log floods.
Counter window / Rate limit
Defines a comparable counting basis (events per X seconds). Prevents “numbers without a denominator”.
Burst grouping: keep evidence usable (avoid log overflow)
  • Merge window: group repeated triggers of the same fault within a short interval into one burst event with a burst_count.
  • Priority capture: keep first occurrence timestamps and peak metrics even if later triggers are merged.
  • Rate-limited reporting: use IRQ for “new burst started” rather than “every spike”.
Temperature and aging: keep a portable margin rule (without full drift modeling)
  • Margin rule: thresholds should include headroom for process spread, temperature drift, and measurement noise.
  • Versionability: store a config_id / threshold profile ID so evidence remains comparable across OTA updates.
  • Mode policy: allow separate profiles for service vs production (principle only; values are platform-specific).
Deliverable · Threshold/time-window design checklist (define semantics before numbers)
  1. Choose the observable: SE level, Vcm, Vdiff, or an imbalance metric.
  2. Define event classes: transient vs persistent vs bursty (grouped) behavior.
  3. Define thresholds: TH_enter and TH_exit (hysteresis) and the direction of the rule.
  4. Define deglitch: minimum width to reject spikes.
  5. Define persistence: minimum duration to validate a fault event.
  6. Define hold-off: suppress re-triggering and IRQ storms after a valid event.
  7. Define counting basis: counter window and rate limit (events per X seconds).
  8. Define burst merge: merge window and burst_count semantics.
  9. Define portability: margin rule + config_id for OTA comparability.
SVG-5 · Timing window waveform (enter/exit thresholds + deglitch/persistence/hold-off)
Time Level TH_enter TH_exit T_deglitch T_persist Validated T_holdoff Enter Exit Rule: enter + deglitch → persist → valid event; exit uses TH_exit to prevent chattering

H2-6 · Event Counters & Reporting Model: What to Count, How to Stamp, How to Clear

Evidence becomes usable only when counters and logs have clear semantics. A practical model answers three questions: what to count, how to timestamp, and how to clear without destroying context.

Counter taxonomy (each solves a different service question)
  • Total: long-term trend across lifecycle.
  • Windowed: events per X seconds/minutes (comparable rate, recent burst detection).
  • Consecutive: repeated triggers without recovery (severity cue).
  • Per-state: sleep vs awake (prevents mixed attribution).
  • Optional per-mode: per bus mode / per channel (when multiple networks exist).
Timestamp model (relative vs absolute, with portability)
Principles
Use monotonic relative time for ordering and duration, and optionally record absolute time for cross-ECU correlation. Always tag events with time-base context (e.g., synchronized / unsynchronized) so evidence is interpretable.
Clearing without losing evidence (service clear vs decay)
  • Service clear: clear “active/latched alarm state” while preserving historical summaries (e.g., totals or last-N).
  • Auto-decay: windowed counters naturally roll off to keep “recent rate” meaningful.
  • Audit hook: record clear reason/time (minimum: a flag + clear counter) to preserve chain-of-custody.
Reporting channels (IRQ for alert, polling for detail)
  • IRQ: indicates a new validated event or burst threshold crossing.
  • Polling readout: host reads ring buffer entries and counters via I²C/SPI.
  • Separation of duties: IRQ is not a data bus; evidence is carried in structured reads.
Event schema (minimum usable fields)
Recommended fields
fault_id, enter_ts, exit_ts, duration, peak (optional), count/burst_count, context_flags (sleep/awake, transient/persistent, severity), bus_id/channel_id (optional but recommended), config_id (threshold profile/version for OTA comparability)
Deliverable · Practical event record (schema sketch)
fault_id · enter_ts · exit_ts · duration · peak(optional) · burst_count · count
context_flags(sleep/awake, transient/persistent, severity) · bus_id(optional) · channel_id(optional) · config_id
SVG-6 · Event pipeline & storage (detection → builder → ring buffer → counters → host readout + IRQ)
Detection Primitive Event Builder Ring buffer Event log (N) Overwrite/freeze Counters Total / Windowed Consecutive Host I²C / SPI Readout Clear policy Service / decay IRQ Evidence flow: detect → build → store → summarize → report (with explicit semantics)

H2-7 · System Integration: Tap Point, Host Interface, and “Do-No-Harm” Rules

Integration is successful only when evidence stays interpretable and the measured bus remains unchanged. This chapter focuses on tap point, host interface, and do-no-harm checks without expanding into PHY timing or EMC component selection.

Decision
Tap point: connector-side vs PHY-side (attribution vs risk)
Option A · Connector-side tap
  • Attribution strength: harness / connector / external disturbance entry.
  • Main risk: closer to external stress paths → stricter Hi-Z / low-C discipline.
Option B · PHY-side tap
  • Attribution strength: local board effects, grounding, interface reuse, local bias shifts.
  • Main risk: observations include local network influence → evidence must carry context.
Host interface: separate alerting from evidence transport
I²C / SPI (readout)
Carries structured evidence: ring-buffer entries, counters, status, and configuration IDs. Keep semantics stable so service logs remain comparable across updates.
GPIO IRQ (alert)
Indicates “new validated event” or “burst threshold crossed”. Avoid encoding detail on the IRQ line; use reads for full context.
Pin reuse note (principle)
If diagnostic pins are multiplexed with other functions, ensure sleep behavior, power sequencing, and event attribution remain unambiguous. Record the active mode in context flags to prevent “mixed evidence”.
Do-No-Harm
Prevent “diagnostics creating faults”: leakage, capacitive load, clamp paths
  • Leakage: verify worst-case leakage cannot shift DC bias or recessive levels across temperature.
  • Capacitive loading: keep effective input capacitance low enough to avoid edge-rate distortion and asymmetry inflation.
  • Clamp/ESD conduction paths: ensure abnormal events do not introduce new coupling/return paths that change what is being measured.
  • Reference consistency: confirm the monitor’s reference (ground/domain) matches the intended evidence meaning.
Power domain & sleep semantics (evidence meaning depends on it)
Always-on vs switched supply
Always-on supports long-window trends and sleep attribution. Switched supply compresses evidence history and changes counter-window interpretation.
Sleep behavior
Define whether events are recorded in sleep, whether wake is allowed, and how counters split by sleep/awake states. Keep the definition consistent with service expectations.
Minimal integration verification (prove “no harm” with a compact loop)
  1. Baseline: capture the bus behavior without the monitor connection (reference record).
  2. With monitor: confirm waveform shape and system stability remain unchanged at nominal conditions.
  3. Controlled faults: inject reproducible open/short/over-voltage/imbalance scenarios and verify event stability.
  4. Flood resistance: confirm rate limits, merge windows, and hold-off prevent log/IRQ storms.
Deliverable · Integration checklist (tap / pins / IRQ / power / sleep)
Tap plan
Option A/B selection aligned with attribution goal; document the chosen placement rationale.
Pins & reference
Sense pins mapped to the intended observable; reference domain defined to avoid Vcm interpretation drift.
Host & IRQ
I²C/SPI used for evidence transport; IRQ used only for alerting; reuse modes logged via flags.
Power & sleep
Always-on vs switched supply decided; sleep logging and wake behavior semantics defined for serviceability.
SVG-7 · Placement options (connector-side tap vs PHY-side tap)
Option A: Connector-side tap vs Option B: PHY-side tap (evidence meaning changes with placement) Option A · Connector-side tap Option B · PHY-side tap Connector Protection Block PHY MCU Monitor IC Hi-Z Tap IRQ I²C/SPI Attribution: Harness Risk: External Connector Protection Block PHY MCU Monitor IC Hi-Z Tap IRQ I²C/SPI Attribution: Local Risk: Bias

H2-8 · Pitfalls: When Diagnostics Misleads (and how to design against it)

Misleading diagnostics usually comes from semantics mismatch: a measured condition is treated as evidence without stable thresholds, timing rules, placement meaning, or counter definitions. The list below uses a fixed pattern: Symptom → First check → Fix direction.

Pitfall 1 · Threshold too tight → frequent false alarms
Symptom: light noise triggers repeated events and noisy counters.
First check: hysteresis (TH_enter vs TH_exit) and margin policy at temperature corners.
Fix direction: add hysteresis + margin; classify transient vs persistent with timing windows.
Pitfall 2 · Observable mismatch → the “right” fault never triggers
Symptom: a visible anomaly exists, but events remain rare or absent.
First check: whether the chosen observable (SE, Vcm, Vdiff, imbalance metric) matches the fault signature.
Fix direction: align observable to taxonomy; keep config_id/version so evidence stays comparable.
Pitfall 3 · Deglitch too short → spike counting and IRQ storms
Symptom: event counters explode while the bus still appears “mostly OK”.
First check: T_deglitch and whether hold-off / rate limit exists.
Fix direction: strengthen deglitch; add hold-off + burst merge; use IRQ only for validated/burst events.
Pitfall 4 · Exit rule too sensitive → one persistent fault becomes many fragments
Symptom: long faults show as many short events, making service decisions unstable.
First check: exit-confirm window and TH_exit vs TH_enter symmetry.
Fix direction: use explicit enter/validate/exit state machine; merge repeated triggers within a merge window.
Pitfall 5 · Tap point meaning ignored → wrong attribution
Symptom: field returns blame harness, but lab analysis blames board (or the reverse).
First check: whether evidence was collected connector-side or PHY-side and whether that meaning is documented.
Fix direction: align placement with attribution goal; carry placement context in the event record.
Pitfall 6 · Monitor changes the bus → “diagnostics creates instability”
Symptom: stability worsens only after adding the monitor tap.
First check: effective input capacitance and leakage at temperature; clamp/return path side-effects.
Fix direction: re-qualify do-no-harm metrics; keep sensing Hi-Z and avoid creating a new coupling path.
Pitfall 7 · Ground reference drift → Vcm events become misleading
Symptom: common-mode related events appear only on certain ECUs or certain conditions.
First check: monitor reference domain vs bus domain; presence of large ground offsets.
Fix direction: mark domain context in evidence; if cross-domain is inherent, evaluate isolation at the isolated-bus page boundary.
Pitfall 8 · Vehicle-level environment → “bench clean, car noisy” mismatch
Symptom: bench results look stable, but vehicle integration triggers sporadic events.
First check: whether time semantics (persistence/merge) match the real environment variability.
Fix direction: adjust transient vs persistent definitions; log context flags for operating state correlation.
Pitfall 9 · Counters without a denominator → numbers not comparable
Symptom: a “large count” exists but cannot support a service decision.
First check: whether a counter window and rate limit are defined consistently across modes.
Fix direction: enforce windowed counters, burst_count semantics, and stable reporting rules.
Pitfall 10 · Clearing destroys evidence → the root cause disappears
Symptom: after clearing, key history is gone and reproduction becomes hard.
First check: whether clear wipes ring buffer and historical summaries, and whether clears are audited.
Fix direction: service clear should preserve totals/last-N and record clear_reason/clear_count.
SVG-8 · Pitfall radar (grouped causes around “misleading diagnostics”)
Misleading Diagnostics Threshold No hyst Tight Timing Short No Placement Tap Bias Ground ref Vcm drift Domain Counter No window Flood Clear policy Group the causes; then design thresholds, timing, placement meaning, and counters as a coherent evidence system

H2-9 · Verification & Fault Injection Matrix (Lab → HIL → Production)

Verification must be executable and repeatable: each injected fault is mapped to conditions, expected events, and tolerances. The goal is not only detection, but stable evidence semantics across lab, HIL, and production.

Test layers: purpose boundaries
Lab (bench)
Proves detection primitives: threshold policy, timing windows, classification rules, counter semantics, and clear behavior.
HIL / vehicle-level integration
Proves system semantics: real harness variability, power/sleep domains, gateway wake behavior, and environment-driven false flags.
Production
Proves delivery: minimal coverage, station-to-station correlation, and locked configuration/calibration for traceable evidence.
Injection methods (controllable, repeatable)
  • Open: controlled disconnect or intermittent contact to cover transient vs persistent opens and fragmentation risk.
  • Short: controlled short-to-domain with defined dwell and release patterns to avoid “storm” pollution.
  • Over-voltage: controlled bias/step/pulse injection; separate transient vs sustained semantics and recovery behavior.
  • Imbalance: controlled asymmetry injection; observe differential/common-mode coupling and signature stability.
Acceptance targets (evidence must remain interpretable)
Latency & stability
Detection latency from injection start; stable enter/exit behavior without burst fragmentation.
False flags
False event rate bounded under no-injection conditions and across environment corners.
Evidence integrity
Ring buffer entries, counters, and clear audit fields remain complete and consistent.
Deliverable · Fault Injection Matrix (Fault × Condition × Expected event × Tolerance)
Fault
Open / intermittent contact
Conditions: cold/room/hot; nominal vs disturbed supply; sleep/awake modes.
Expected: event enter/exit stable; fragments merged; context_flags reflect mode.
Tolerance: latency ≤ X; false rate ≤ Y; log loss = 0; counter window consistent.
Fault
Short to domain (stuck / chattering)
Conditions: defined dwell/release patterns; repeated bursts; cross-ECU scenarios.
Expected: stuck-level signature classified; rate limit prevents IRQ storms; recovery semantics stable.
Tolerance: latency ≤ X; burst_count semantics stable; counter flood bounded by window.
Fault
Over-voltage (transient vs sustained)
Conditions: step/pulse profiles; temperature corners; supply ripple interaction.
Expected: transient and sustained events separated; peak/duration recorded; recovery logged.
Tolerance: latency ≤ X; duration error ≤ Δt; peak error ≤ ΔV; log loss = 0.
Fault
Imbalance / asymmetry
Conditions: controlled asymmetry levels; harness variants; ground reference variation.
Expected: imbalance metric stable; coupling to Vcm tracked via context flags.
Tolerance: latency ≤ X; false rate ≤ Y; classification stable across temperature corners.
SVG-9 · Injection matrix (Inject → Observe → Validate counters/log → Pass)
Fault Injection Matrix: executable verification from injection to evidence and acceptance Inject Open / Short / OVP / Imb Observe SE / Vcm / Vdiff Validate counters / ring log Pass tolerance Open Method: controlled disconnect Condition: temp / supply / mode Expected: stable enter/exit Short Method: controlled dwell/release Condition: burst patterns Expected: flood bounded Over-voltage Method: step / pulse Condition: transient vs sustained Expected: peak & duration Imbalance Method: controlled asymmetry Condition: harness variants Expected: stable metric Matrix

H2-10 · Engineering Checklist: Design → Bring-up → Production

This checklist compresses the deliverables into three gates. Each gate locks semantics, verifies real-system behavior, and ensures station-to-station consistency for production evidence.

Gate
Design gate (freeze definitions)
  • Threshold policy frozen: enter/exit/hysteresis definition and margin rationale.
  • Timing policy frozen: deglitch/persistence/hold-off/rate-limit semantics.
  • Event schema frozen: enter_ts/exit_ts/duration/peak/context_flags/config_id.
  • Clear policy defined: service clear vs preserved totals/last-N plus clear audit record.
  • Tap point decision recorded with attribution goal and do-no-harm assumptions.
  • Do-no-harm checks passed: leakage, capacitance, and clamp path side-effects reviewed.
Gate
Bring-up gate (prove semantics on real harness)
  • Real harness re-check: baseline vs with monitor comparison remains stable.
  • False-flag statistics collected across temperature and supply disturbance corners.
  • Log readability validated: event fields remain interpretable and comparable across runs.
  • Flood resistance verified: burst merge and rate limit prevent IRQ/log storms.
  • Mode coverage validated: sleep/awake and power-domain transitions preserve evidence meaning.
Gate
Production gate (coverage, correlation, lock)
  • Minimal ATE/HIL coverage locked to the injection matrix with tolerance placeholders.
  • Station-to-station correlation established for counters and log semantics.
  • Configuration/calibration locked and traceable via config_id.
  • Clear procedure audited: clear_reason and clear_count recorded for serviceability.
  • Field evidence pipeline defined: how logs/counters are extracted and compared after returns.
SVG-10 · Gate flow (Design → Bring-up → Production) with check boxes
Engineering gate flow: lock semantics, validate in system, and deliver consistent evidence in production Design Freeze thresholds Freeze timing Freeze schema Clear policy Tap decision Do-no-harm Bring-up Harness re-check False stats Log readable Flood resistant Mode coverage Production Min coverage Station corr Config lock Clear audit Field pipeline Release

H2-9 · Verification & Fault Injection Matrix (Lab → HIL → Production)

Verification must be executable and repeatable: each injected fault is mapped to conditions, expected events, and tolerances. The goal is not only detection, but stable evidence semantics across lab, HIL, and production.

Test layers: purpose boundaries
Lab (bench)
Proves detection primitives: threshold policy, timing windows, classification rules, counter semantics, and clear behavior.
HIL / vehicle-level integration
Proves system semantics: real harness variability, power/sleep domains, gateway wake behavior, and environment-driven false flags.
Production
Proves delivery: minimal coverage, station-to-station correlation, and locked configuration/calibration for traceable evidence.
Injection methods (controllable, repeatable)
  • Open: controlled disconnect or intermittent contact to cover transient vs persistent opens and fragmentation risk.
  • Short: controlled short-to-domain with defined dwell and release patterns to avoid “storm” pollution.
  • Over-voltage: controlled bias/step/pulse injection; separate transient vs sustained semantics and recovery behavior.
  • Imbalance: controlled asymmetry injection; observe differential/common-mode coupling and signature stability.
Acceptance targets (evidence must remain interpretable)
Latency & stability
Detection latency from injection start; stable enter/exit behavior without burst fragmentation.
False flags
False event rate bounded under no-injection conditions and across environment corners.
Evidence integrity
Ring buffer entries, counters, and clear audit fields remain complete and consistent.
Deliverable · Fault Injection Matrix (Fault × Condition × Expected event × Tolerance)
Fault
Open / intermittent contact
Conditions: cold/room/hot; nominal vs disturbed supply; sleep/awake modes.
Expected: event enter/exit stable; fragments merged; context_flags reflect mode.
Tolerance: latency ≤ X; false rate ≤ Y; log loss = 0; counter window consistent.
Fault
Short to domain (stuck / chattering)
Conditions: defined dwell/release patterns; repeated bursts; cross-ECU scenarios.
Expected: stuck-level signature classified; rate limit prevents IRQ storms; recovery semantics stable.
Tolerance: latency ≤ X; burst_count semantics stable; counter flood bounded by window.
Fault
Over-voltage (transient vs sustained)
Conditions: step/pulse profiles; temperature corners; supply ripple interaction.
Expected: transient and sustained events separated; peak/duration recorded; recovery logged.
Tolerance: latency ≤ X; duration error ≤ Δt; peak error ≤ ΔV; log loss = 0.
Fault
Imbalance / asymmetry
Conditions: controlled asymmetry levels; harness variants; ground reference variation.
Expected: imbalance metric stable; coupling to Vcm tracked via context flags.
Tolerance: latency ≤ X; false rate ≤ Y; classification stable across temperature corners.
SVG-9 · Injection matrix (Inject → Observe → Validate counters/log → Pass)
Fault Injection Matrix: executable verification from injection to evidence and acceptance Inject Open / Short / OVP / Imb Observe SE / Vcm / Vdiff Validate counters / ring log Pass tolerance Open Method: controlled disconnect Condition: temp / supply / mode Expected: stable enter/exit Short Method: controlled dwell/release Condition: burst patterns Expected: flood bounded Over-voltage Method: step / pulse Condition: transient vs sustained Expected: peak & duration Imbalance Method: controlled asymmetry Condition: harness variants Expected: stable metric Matrix

H2-10 · Engineering Checklist: Design → Bring-up → Production

This checklist compresses the deliverables into three gates. Each gate locks semantics, verifies real-system behavior, and ensures station-to-station consistency for production evidence.

Gate
Design gate (freeze definitions)
  • Threshold policy frozen: enter/exit/hysteresis definition and margin rationale.
  • Timing policy frozen: deglitch/persistence/hold-off/rate-limit semantics.
  • Event schema frozen: enter_ts/exit_ts/duration/peak/context_flags/config_id.
  • Clear policy defined: service clear vs preserved totals/last-N plus clear audit record.
  • Tap point decision recorded with attribution goal and do-no-harm assumptions.
  • Do-no-harm checks passed: leakage, capacitance, and clamp path side-effects reviewed.
Gate
Bring-up gate (prove semantics on real harness)
  • Real harness re-check: baseline vs with monitor comparison remains stable.
  • False-flag statistics collected across temperature and supply disturbance corners.
  • Log readability validated: event fields remain interpretable and comparable across runs.
  • Flood resistance verified: burst merge and rate limit prevent IRQ/log storms.
  • Mode coverage validated: sleep/awake and power-domain transitions preserve evidence meaning.
Gate
Production gate (coverage, correlation, lock)
  • Minimal ATE/HIL coverage locked to the injection matrix with tolerance placeholders.
  • Station-to-station correlation established for counters and log semantics.
  • Configuration/calibration locked and traceable via config_id.
  • Clear procedure audited: clear_reason and clear_count recorded for serviceability.
  • Field evidence pipeline defined: how logs/counters are extracted and compared after returns.
SVG-10 · Gate flow (Design → Bring-up → Production) with check boxes
Engineering gate flow: lock semantics, validate in system, and deliver consistent evidence in production Design Freeze thresholds Freeze timing Freeze schema Clear policy Tap decision Do-no-harm Bring-up Harness re-check False stats Log readable Flood resistant Mode coverage Production Min coverage Station corr Config lock Clear audit Field pipeline Release
–accent:#11A7FF; –ink:#0B2A3C; –muted:#3B5566; –card:#F7FBFF; –line:#CFEAFF; –chip:#E9F6FF;

H2-11 · IC Selection Logic (What specs actually matter)

Selection should be driven by evidence quality: coverage → threshold semantics → logging → low-power continuity → safety hooks. Part numbers below are representative BOM candidates (verify grade/package/orderable codes per project).

A) Requirement Profiles (decide the “job” before the part)

Profile 1 · Serviceability / Attribution
Target: reduce “no fault found” returns by recording durable evidence (enter/exit/duration/context) and keeping counters consistent.
Profile 2 · Harsh Harness / Robustness
Target: withstand bus faults and keep false flags low under ground shifts, long stubs, heavy loads, and noisy environments.
Profile 3 · Always-On Low-Power / Wake Evidence
Target: keep sleep current budget intact while preserving wake attribution and evidence continuity across sleep/awake states.
Profile 4 · Functional Safety / Auditability
Target: provide hooks for fault-injection verification, configuration traceability, and diagnosable states for safety cases.

B) Selection Scorecard (turn “specs” into checkable engineering items)

1) Detect Coverage
  • What to check: open/short/over-voltage coverage; imbalance/asymmetry support; transient vs sustained over-voltage semantics.
  • Common trap: “supported” faults without persistence/exit semantics → fragmented evidence and high false flags.
  • Deliverable: a fault_id list + per-fault enter/exit/duration definition (used by lab + service tools).
2) Accuracy & Survivability (threshold + input range)
  • What to check: threshold accuracy/hysteresis; drift notes; input common-mode/over-voltage range; fail-safe indication behavior.
  • Common trap: good thresholds on paper but ground reference shifts break Vcm-based classification.
  • Deliverable: enter/exit thresholds + margin rationale; corner plan for temperature, VBAT ripple, ground offset.
3) Logging & Counters (evidence quality)
  • What to check: counter types (total/consecutive/windowed); ring buffer depth; fields (enter_ts/exit_ts/duration/peak/context/config_id).
  • Common trap: shallow buffers + event storms → evidence overwritten; clear policy deletes the only proof.
  • Deliverable: event schema + clear policy + host readout plan (IRQ for urgent + polling for full logs).
4) Low-Power Continuity (sleep evidence)
  • What to check: sleep IQ; which detectors/counters remain alive in sleep; whether wake attribution is preserved.
  • Common trap: low sleep current but no “sleep-state evidence” → critical window is unobserved.
  • Deliverable: sleep/awake counter semantics + wake-source attribution mapping.
5) Safety Hooks & Verifiability
  • What to check: built-in diagnostics flags; test modes or hooks for fault injection; configuration lock + traceability.
  • Common trap: “ASIL-ready” claims without field-level evidence or injection-friendly interfaces.
  • Deliverable: safety hook list (status mirrors, self-check, config_id) + production lock checklist.

C) Concrete Part-Number Buckets (representative BOM options)

These are example devices commonly used to implement “monitor/diagnostics + reporting” functions via fault pins, SPI/I²C control, wake logic, and status registers. Choose by bucket first, then validate timing/EMC/grade/package/orderable codes.

Bucket 1 · Diagnostic-rich HS-CAN / CAN FD Transceivers (fault pins + status)
  • TI TCAN1043-Q1 / TCAN1043H-Q1 (CANH/CANL fault detection + bus monitor behavior)
  • TI TCAN3413 / TCAN3414 (low-power receiver with bus monitor / wake patterns)
  • NXP TJA1044 / TJA1044GT (high-speed CAN transceiver family, standby mode)
  • Infineon TLE9255W (CAN FD / partial networking class options)
  • Microchip MCP2562FD (CAN FD transceiver family)
Typical use: attach to MCU counters/logging; treat fault pins + status as event sources; define clear policy in firmware.
Bucket 2 · SIC-capable (imbalance/asymmetry resilience) CAN FD Transceivers
  • TI TCAN1462-Q1 (Signal Improvement Capability / SIC)
  • NXP TJA1462 (CAN SIC transceiver family)
Typical use: large networks / heavy stubs where bit-timing symmetry and ringing control are needed; treat “SIC mode + bus state” as part of the evidence context.
Bucket 3 · CAN XL Physical Layer (higher-rate domain)
  • TI TCAN6062-Q1 (CAN XL transceiver class)
Typical use: gateway/ADAS domains where a higher-rate segment is used; integrate evidence logging on the host side (counters + timebase alignment).
Bucket 4 · Isolated CAN / CAN FD (large ground potential differences)
  • TI ISO1042-Q1 (automotive isolated CAN transceiver class)
  • Analog Devices ADM3055E / ADM3057E (isolated CAN transceivers with integrated isolated DC/DC variants)
Typical use: HV/e-drive domains or noisy grounds; use isolation to keep Vcm-based diagnostics meaningful and reduce “false imbalance” flags.
Bucket 5 · SBCs with CAN/LIN + SPI (power + wake + diagnostics reporting)
  • NXP FS23 (SBC integrating CAN + LIN and safety/system features)
  • NXP UJA1169A (mini HS-CAN SBC with SPI + watchdog + low-power modes)
  • Infineon TLE9262-3BQX (SBC family class with CAN FD / PN + LIN options)
  • onsemi NCV7429 (LIN SBC with SPI + switches/diagnostics class)
Typical use: body/comfort ECUs where low-power policy and wake attribution matter; keep “config_id + clear policy + wake-source” consistent across stations.
Bucket 6 · LIN Transceivers (diagnostics + safety artifacts)
  • TI TLIN14313-Q1 / TLIN14315-Q1 (LIN transceiver family with functional safety collateral)
Typical use: LIN nodes with stringent wake/sleep behavior; integrate fault evidence into a uniform event schema shared with CAN-side logs.
Host-side Evidence Helper (optional, when external controller is used)
  • Microchip MCP2518FD (external CAN FD controller with SPI; use controller error counters/interrupts as part of evidence)
Note: this is not a PHY/monitor IC by itself; it becomes useful when the architecture logs controller-level error counters alongside transceiver/SBC fault signals.

D) Selection Decision Ladder (fast convergence)

  • Q1 Coverage: imbalance/asymmetry needed?
  • Q2 Evidence: timestamp + ring log needed?
  • Q3 Low-power: sleep-state evidence continuity needed?
  • Q4 Safety: hooks for injection + audit needed?
Q1 · Need imbalance / asymmetry? NO → Basic bus-fault + counters YES → Go Q2 (evidence) Q2 · Need timestamp + ring log? NO → SIC-capable diagnostics YES → Go Q3 (sleep continuity) Q3 · Need sleep-state evidence? NO → Evidence-grade logger YES → Go Q4 (safety hooks) Q4 · Need safety hooks / audit? NO → Ultra-low power wake YES → Safety-ready monitor Example BOM buckets Basic: TCAN1043-Q1, TJA1044 SIC: TCAN1462-Q1, TJA1462 CAN XL: TCAN6062-Q1 Isolated: ISO1042-Q1, ADM3055E
The ladder above is a selection aid. Final choice must also pass the project’s verification matrix (fault injection, environment, and station consistency).

E) Selection Deliverables (what “done” looks like)

  • Scorecard record: 5-dimension scoring + rationale (coverage/accuracy/logging/low-power/safety).
  • Event schema: fault_id, enter_ts, exit_ts, duration, peak, count, context_flags, config_id.
  • Clear policy: service-clear vs auto-decay rules; proof-retention requirements.
  • Verification link: mapping from each fault to the injection test and pass criteria (latency/false rate/recovery/log completeness).
  • Production lock: configuration lock + station-to-station consistency items (version, calibration, readout tooling).

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-12 · FAQs (Troubleshooting, fixed 4-line answers)

Each FAQ is a compact execution path. Pass criteria uses placeholders (X) to be filled by the project’s verification matrix.

Open-fault counter is high, but the bus looks normal on a scope — check thresholds or tap point first?
Likely cause: Threshold semantics are too tight, or the tap point observes a different reference/segment than the scope probe.
Quick check: Compare counter rate vs (a) tap location A/B and (b) enter/exit thresholds; correlate spikes to harness movement or mode transitions.
Fix: Widen hysteresis or persistence window, and align the tap/reference so the monitor and measurement observe the same electrical point.
Pass criteria: false_event_rate ≤ X/hour and counter_rate_change ≤ X% between tap A/B over Y minutes (Y = X placeholder).
Short-to-VBAT is occasional and very brief — how should deglitch be set to avoid misses and false flags?
Likely cause: Deglitch is longer than the real fault pulse, or too short and counting noise as “short.”
Quick check: Sweep deglitch across 2–3 candidate values and compare detection probability vs false count under “no-injection” idle.
Fix: Use a two-stage policy: short deglitch + persistence for “confirmed,” plus hold-off to prevent burst inflation.
Pass criteria: miss_rate ≤ X% for pulse width ≥ X ms, and false_event_rate ≤ X/hour in the same mode and temperature corner.
Over-voltage count is low, but each event lasts a long time — how to clear without losing evidence?
Likely cause: Clear policy wipes the only proof of long-duration stress, or the system clears before service reads logs.
Quick check: Inspect whether “clear” also resets totals/last_peak/last_duration; verify service readout happens before any auto-clear.
Fix: Separate “service clear” from “lifetime totals,” and keep last-N ring records (or last_peak/last_duration) across clears.
Pass criteria: After a clear, lifetime_totals unchanged; last_peak/last_duration preserved for ≥ X days or ≥ X key cycles.
Imbalance alarm appears only on one vehicle — harness issue or ground-reference offset?
Likely cause: Vehicle-specific harness topology/connector asymmetry, or ECU ground shift that skews common-mode interpretation.
Quick check: Compare imbalance metric vs measured Vcm across vehicles under the same mode; check if the alarm tracks ground offset or a physical harness change.
Fix: Normalize classification using both differential and common-mode context, and tighten the tap/reference definition for consistent observation.
Pass criteria: For “known-good” harness, imbalance alarms ≤ X/day; cross-vehicle metric spread ≤ X% at the same operating state.
Same fault: ECU A logs an event, ECU B only increments a counter — inconsistent semantics or readout timing?
Likely cause: ECU B reads too late (ring overwrite), or event-building rules differ (thresholds/windows/clear policy).
Quick check: Compare config_id + threshold/window registers and readout cadence; verify ring depth vs event rate during the fault.
Fix: Standardize event schema and timing windows across ECUs; add IRQ-driven “snapshot read” for high-rate periods.
Pass criteria: For the same injected fault, event_presence_match ≥ X% across ECUs and timestamp_delta ≤ X ms under a shared time base.
Many false flags during bring-up, but fewer in-vehicle — environment noise or thresholds/windows too tight?
Likely cause: Bench setup induces artifacts (grounding, floating references), or thresholds/windows are tuned without real harness dynamics.
Quick check: Re-run with a “known-good harness + vehicle-like ground reference” and compare false_event_rate before any parameter change.
Fix: Set thresholds based on the verified harness baseline; use persistence + hold-off so noise bursts do not become events.
Pass criteria: false_event_rate ≤ X/hour in both bench (vehicle-like setup) and vehicle; parameter delta ≤ X% between environments.
Counters get “blown up” by a chattering fault — how to apply rate limit / hold-off?
Likely cause: No re-trigger suppression, or the counter window is too short and counts every bounce.
Quick check: Plot count increments vs time and identify whether increments are periodic (bounce) or correlated to mode transitions.
Fix: Add hold-off after an event (no re-trigger for X ms), and count in a fixed window (events per X seconds) with saturation.
Pass criteria: max_count_rate ≤ X per minute during chatter, and a single physical fault produces ≤ X events in a window of X seconds.
Event log has enter_ts but no exit_ts — missing recovery criteria or readout-window issue?
Likely cause: Exit condition is not defined (or too strict), or the host reads mid-event and never captures the close-out update.
Quick check: Confirm exit threshold and persistence for recovery; check whether the event record is updated in-place and requires a second read.
Fix: Define explicit exit semantics (threshold + time), and ensure host reads “event close” via IRQ or periodic polling until exit is recorded.
Pass criteria: exit_recorded_rate ≥ X% for injected faults; close_out_latency ≤ X ms after fault removal.
False flags increase at low temperature — threshold drift first, or input leakage first?
Likely cause: Temperature shifts the effective threshold/hysteresis or changes leakage paths that bias the sensed node.
Quick check: Hold the bus in a known stable state and compare measured sense node and threshold crossings at cold vs room conditions.
Fix: Increase margin (hysteresis/persistence) at cold, and validate input-bias assumptions; keep classification tied to stable states.
Pass criteria: false_event_rate ≤ X/hour at cold and room; threshold_crossing_shift ≤ X% between temperatures under the same state.
After moving the monitor tap closer to the connector, CAN FD becomes less stable — check loading or return path first?
Likely cause: The tap introduces unintended loading, or the connector-side location increases susceptibility to local return-path disturbances.
Quick check: Compare stability with tap disconnected vs connected, and A/B the tap location while keeping firmware constants unchanged.
Fix: Enforce “do-no-harm” rules: keep sense path high-impedance, minimize parasitic load, and validate the tap reference continuity.
Pass criteria: With the tap enabled, error_rate increase ≤ X% and link stability ≥ X hours under the same harness and mode.
Production station measures shorter fault-detection latency than the lab — injection method or timestamp baseline?
Likely cause: The production injection edge is steeper/closer to the tap, or timestamps are referenced to different clocks/markers.
Quick check: Align the definition of “t0” (injection start marker) and compare injection topology and the tap distance for lab vs production.
Fix: Standardize injection fixtures and timestamp baseline; report latency as a defined interval (t_detect − t0) with the same t0 marker.
Pass criteria: latency_delta between stations ≤ X ms for the same fault, and measurement repeatability σ ≤ X ms across N runs (N = X placeholder).
Same fault reappears shortly after a clear — recurrence or “clear semantics not clean”?
Likely cause: Clear resets counters but the physical condition persists, or clear does not reset the same fields across ECUs (semantic mismatch).
Quick check: Verify which fields are cleared (totals vs last-N vs “active state”); confirm whether the fault condition is truly removed at clear time.
Fix: Define clear as a transaction with a clear_reason + clear_ts, and differentiate recurrence using time separation and physical-state confirmation.
Pass criteria: post_clear_retrigger within X seconds must be classified as “active-not-removed” unless physical_state_ok is true; semantic mismatch rate = 0.
icnavigator

ICNavigator helps engineers find verified ICs, alternatives, and fast quotes.

Explore
Categories
  • Power Management
  • MCU
  • Automotive ICs
  • Sensors
  • Interface & Transceivers
  • Analog Front-End
Get in Touch
  • Email: hello@icnavigator.com
  • WeChat/WhatsApp: +86-xxxx

© 2025 ICNavigator. All rights reserved.