In-Vehicle Networks
Long-cycle design programs where IP, foundry, and ecosystem partnerships execute against tapeout and market windows.
Inside this journey
-
Pre-Discovery
Align the room on outcomes, decision process, and constraints before deeper discovery.
-
Stakeholder Alignment
Confirm decision roles, timeline constraints (OEM freeze date), qualification lead times, and what ‘good’ looks like for each stakeholder.
Alignment Questions
Set the Scene: Your Program in One Line
- In one sentence, describe the vehicle platform or program driving the move from CAN to a zonal Ethernet backbone.
- How far away is your OEM platform freeze date?
- Who on your team owns the architectural decision for network silicon (role/title)?
- Which teams will need to be involved in silicon qualification and sign-off?
- What is the single biggest worry you have right now about this migration?
If Your Network Could Talk — What Would It Tell Us?
- Imagine your current vehicle network could complain — what's the one recurring problem it would name?
- Describe the existing ECU domains and the legacy CAN/CAN FD topology we will be bridging from (number of domains, gateway points, star/linear/bus, etc.).
- Which ECUs are high-risk during migration because they cannot be redesigned quickly or are tied to safety functions?
- Have you observed any intermittent field issues (EMC, latency spikes, sleep-wake failure) that suggest deeper systemic problems? Please describe specific incidents and how often they occur.
- What parts of your current supply base or qualification process have historically caused the most schedule slippage?
When 'Good Enough' Breaks the Program
- If a transceiver or switch fell short on EMC or sleep power after design freeze, what would that realistically force you to do?
- What are your numeric target acceptance criteria today for latency, EMC margins, and sleep-mode current? (If you use ranges, please specify.)
- Which protocol compliance must be proven in qualification (select all that apply) and which standards are mandatory for this program?
- How do you prioritize those signals of success when trade-offs arise (e.g., slightly higher latency vs. significantly lower sleep power)?
- Tell us about a past trade-off decision that later caused pain—what was chosen, why, and what happened?
Who Holds the Keys — Roles, Timelines, and What 'Good' Actually Means
- Who ultimately signs off that silicon is acceptable for production for this program, and what authority do they have to pause the program?
- For each stakeholder (architecture, HW design, EMC lab, procurement), what does ‘good enough’ look like—please list stakeholder and their top 1–2 acceptance criteria.
- What are the qualification lead times you must budget for silicon, and what milestones compress the schedule if accelerated?
- If a stakeholder raises a blocking issue during qual, what is your current escalation path and expected SLAs for resolution?
- Who will own on-site lab access, evaluation fixtures, and coordination with our engineering for validation runs?
What Would a Failed Integration Actually Cost?
- If an errata forced a board redesign after design lock, estimate the program impact in weeks or cost bands.
- How comfortable are you with silicon errata that require board-level workarounds versus a full silicon respin?
- What level of supply continuity commitment do you require from a silicon supplier (lead-time guarantees, lifetime availability, last-time buy terms)?
- Describe any contractual or procurement constraints (approved fab lists, country-of-origin restrictions, long-term supplier policies) that we should know.
- How do you measure acceptable risk for a new silicon family on a decade-long vehicle program?
Show Me the Evidence — Tests, Fixtures, and What Wins Your Confidence
- What specific evaluation-board data or lab reports would make you say, “We can move forward” (EMC plots, sleep current traces, deterministic latency histograms, protocol conformance logs)?
- Which validation gates are mandatory before silicon is allowed into your integration lab (select all that apply)?
- How many physical samples and what test fixture access do you require for your qualification plan (numbers and any special fixtures)?
- Do you require co-located engineering support during evaluation runs (vendor engineer on-site vs. remote support)?
- What format and level of traceability do you require for test evidence (raw logs, summarized reports, DFMEA trace to tests)?
What Would Success Feel Like — Commitments, Timelines, and Next Steps
- If this migration is successful, what tangible changes will you see in 6, 12, and 24 months? Be specific about metrics and program milestones.
- What commercial or supply commitments would you need from us to feel confident moving forward (lead-time guarantees, penalty clauses, errata handling process)?
- Who needs to sign a mutual commitment to proceed (roles/titles), and what would be the minimum set of commitments you expect in that mutual plan?
- What would be the ideal timing and cadence for joint qualification gates and check-ins between our teams?
- What immediate next step would move this from conversation to action for you in the next 14 days?
-
Current State Mapping
Document existing ECU domains, legacy CAN topology, gateway points, and supply or qualification risks that impact migration.
Current State
Quick Snapshot — The Program in One Breath
- What is the program name, platform generation, and OEM you’re working against (short form)?
- How many months until your OEM platform freeze date?
- Who is the primary contact for network architecture decisions (role and team)?
- Which internal teams will be actively involved in device selection and qualification?
- On a scale of urgency, how would you describe this decision?
What Could Blindside Your Project?
- If a single unexpected issue appeared tomorrow (supply shortage, late errata, failing EMC), which one would be most likely to derail your freeze date?
- How often have you experienced late silicon errata or qualification blockers on recent programs, and how long did they typically delay you?
- Which of these supply/qualification risks keeps you up at night? Pick all that apply and briefly tell us why in the next question.
- Tell us a concrete example of a past supply or qualification problem and what it cost you (time, rework, or lost launch).
Map the Reality — Your Current ECU & Network Layout
- How many separate ECU domains (logical groups or vehicle domains) are present today and how many ECUs per domain (approx)?
- Which in-vehicle protocols are currently used across those domains?
- Describe your legacy CAN topology: linear bus, star, multiple bridged sub-buses, or mixed — and where gateway points currently exist.
- Upload or paste (or summarize) the single-page logical topology or point us to the diagram — which nodes are the hardest to change?
- Which ECUs are considered ‘untouchable’ (cannot be redesigned in this program) and must be bridged or adapted?
Where Performance Actually Breaks Down
- Which performance metric has been the toughest to meet in previous migrations: EMC, latency, or sleep-mode power?
- Share a recent test result or real-world symptom that shows the problem (e.g., specific EMC margin misses, latency spikes, or sleep current numbers).
- How often do these issues occur during validation—intermittent, reproducible under certain conditions, or continuous?
- What has been the human or program impact when these performance gaps show up (delayed milestones, extra lab cycles, added BOM, customer escalations)?
- Which board-level or system-level levers have you tried (different transceivers, termination changes, shielding, software rate-limiting)? Please list what helped and what didn’t.
Who Needs to Feel Good About This Decision — And Why
- Thinking beyond the project lead—who are the five stakeholders that must sign off for production adoption?
- For each stakeholder type you selected, what does ‘good’ look like for them? (be specific — metrics, gates, or outcomes)
- Which acceptance metrics are non-negotiable for launch (pick up to three)?
- Who owns silicon qualification and who owns system integration — are these separate teams or a single owner?
- How will you decide between a single-source integrated transceiver/switch solution versus mixed suppliers (trade-offs you care about)?
The Migration Tradeoffs You Haven’t Fully Named
- If keeping every legacy ECU unchanged meant a 12–18 month longer program, would you accept that delay, accelerate redesign, or look for bridging silicon?
- Which of these tradeoffs are you most willing to make to hit the freeze date?
- What performance compromises are absolutely off the table (e.g., cannot exceed X latency, cannot exceed Y sleep current)?
- How would you rank the following priorities for this program (1 highest to 4 lowest)?
- Have you mapped a realistic migration path for ECUs that will remain CAN-based for several years? If so, how many phases and what are the phase criteria?
Supply & Qualification — The Unseen Timeline
- What are your typical lead-times for qualified automotive silicon today (NPI to qualified production) in months?
- Do you require multiple independent silicon sources or is single-source acceptable with long-term supply guarantees?
- Which qualification gates must be cleared before you can commit (select all that apply)?
- Who in your organization is the formal owner for supply continuity conversations and commercial commitments?
- If a vendor offered prioritized allocation or long-term product commitments, what contract or assurance terms would be required to make that meaningful to you?
Evaluation Readiness — Can We Recreate Your Roadblocks in the Lab?
- Do you already have evaluation boards and firmware that represent your topology, or will you need vendor-provided evaluation kits?
- Which of the following tests do you plan to run on evaluation hardware (pick all that apply)?
- Do you have lab access and fixtures for EMC, long-duration sleep testing, and latency profiling, or would you need shared/vendor lab time?
- What data would convince you to adopt our silicon for the program (specific tests, thresholds, or reference scenarios)?
- Who on your team will run the hands-on evaluation and who will interpret the results for decisions?
Compliance & Interoperability — The Gates You Can’t Ignore
- Which standards compliance are mandatory for launch (AUTOSAR conformance, OPEN Alliance test profiles, IEEE PHY standards, ISO requirements)?
- Have you previously failed any compliance test (AUTOSAR, OPEN Alliance, or EMC) during qualification? If yes, what was the failure and how was it resolved?
- How important is backwards compatibility with existing CAN tooling and diagnostics for your long-term support model?
- When bridging CAN to Ethernet, which interoperability scenarios concern you most (message translation latency, diagnostic transparency, security, clocking)?
- If we provided a reference gateway design that preserved diagnostic interfaces and reduced BOM count, how would that change your decision calculus?
Decision Rhythm — Milestones, Owners, and The Real Deadline
- Working backwards from your OEM freeze, what intermediate decision milestones do you need (e.g., eval board signoff, EMC signoff, sample order, supplier contract)?
- Who will be the final approver at freeze (role/title) and what evidence will they require to sign off?
- How flexible is your freeze date if a credible mitigation plan (e.g., phased acceptance, conditional supply commitment) is proposed?
- What internal escalations or review forums must be included for any supplier selection (steering committee, platform board, procurement review)?
- If we propose a joint, time-boxed qualification plan, who should be invited to the kick-off and who will drive weekly execution?
A 90-Day Sprint — What Would Make This Feel Like Progress?
- If we agreed on three concrete deliverables for the next 90 days, what would you want them to be (e.g., evaluation boards in your lab, initial EMC pretest report, supply term sheet)?
- Which of these would make you more confident in a vendor: prioritized silicon allocation, early engineering samples, or collaborative lab time?
- What decision criteria would you use at the end of the 90 days to either continue with a single vendor or open to additional suppliers?
- Who should we schedule as the 90-day sponsor from your side (name/role) and how often should we meet to track progress?
- What would count as a red flag at 90 days that requires pausing the plan or escalating immediately?
-
-
Outcome Discovery
Clarify target network architecture, measurable success signals (EMC, latency, sleep power), and must-have protocol compliance.
Discovery Questions
Painting the Destination — Tell Me the Network You're Aiming For
- In one clear sentence, what is your target in-vehicle network architecture for the upcoming platform?
- Which backbone topology(s) are you considering for the zonal migration?
- What backbone data-rate(s) must be supported at launch?
- How long do you expect this silicon choice to remain in production on this program (design life)?
- Who are the primary decision owners for the network architecture and silicon selection (list roles)?
- What is your OEM platform freeze date and your estimated silicon qualification lead time? (dates or durations)
If This Fails, What Breaks First?
- Imagine we miss a critical performance target post-qualification — what single real-world failure would cause the most damage to your program?
- Which early indicators would show this problem first?
- When would you expect to detect those indicators in your timeline?
- How severe would the business impact be if those indicators required a design rework (choose the closest)
- How would such a failure affect your relationship/commitment with the OEM (tactical and reputational consequences)?
Signals That Let You Sleep — The Non‑Negotiables
- Which single measurable signal, if met, would make you confident enough to commit to design lock?
- For EMC, what acceptance threshold do you require for initial silicon (choose the best fit)?
- State your latency targets by use case — e.g., control loops, gateway forwarding, diagnostics (list µs/ms targets per use case).
- What sleep-mode current or power targets must silicon meet on your reference ECU board?
- Which protocol and software compliance marks are mandatory before sign-off?
- How will you instrument the evaluation board to verify these signals (capture method, tools, and required traceability)?
How You’ll Prove It — Scenarios and Tests That Matter
- Are your current test scenarios reflective of what vehicles will actually face in the field, or are they optimized for lab convenience?
- List the top three real-world scenarios we must validate on our evaluation board to prove the migration path (e.g., ADAS message storm crossing, mixed-rate zonal congestion, cold-start sleep/wake).
- Which test types are highest priority during initial evaluation?
- Do you already have test fixtures, lab time, and measurement setups, or will you need vendor-provided facilities and support?
- What format of evaluation data do you find most actionable?
- Would you require vendor engineers onsite to execute or witness tests?
Bridging the Old Without Burning It Down
- What fragile assumption are you making about coexistence between legacy CAN/ECCUs and the new Ethernet backbone that we should challenge first?
- Which legacy CAN domains must remain functionally identical (no change) during migration?
- Which gateway features are absolute must-haves to enable a phased migration?
- Estimate peak cross-domain traffic and burst patterns we should be prepared to replicate (bytes/s, messages/s, and burst durations).
- What fallback behavior is acceptable if a bridge or gateway encounters overload or partial failure?
What Are You Willing to Trade to Meet the Program?
- If program timing forced a compromise, which would you accept first: lower unit cost, reduced power, or stricter latency — and why?
- What level of errata risk is tolerable (minor errata with workaround vs. requiring silicon fix) for this program?
- How important is a unified transceiver solution (one silicon for CAN, CAN FD, LIN, Ethernet) versus best-in-class per-protocol parts?
- How would a 3-month slip in silicon availability affect program milestones and supplier relationships?
- List any hard BOM, cost, or thermal constraints that will directly influence acceptance of the silicon.
Signatures, Gates, and Who Keeps the Lights On
- What concrete deliverables and evidence will you require to sign the silicon off for ECU production?
- Which formal acceptance gates are mandatory before you approve production silicon?
- Which roles must sign off on those gates (list functional roles rather than names)?
- By what point relative to the OEM freeze date must all gates be complete for you to feel comfortable?
- If a gate fails, describe your preferred escalation and remediation path (stop, workaround, parallel supplier qualification, etc.).
Let’s Map the First 90 Days — Concrete Steps to De‑risk
- If we only had 90 days to prove the migration concept, what single outcome would make you stop worrying?
- Which quick-win activities should we prioritize in that window?
- What owners, lab time, and access (hardware/software) will you commit to support those 90-day activities?
- Do you require NDAs, data sharing agreements, or a purchased evaluation kit to start testing? (select all that apply)
- What measurable deliverable would make the 90-day effort a success (specific tests, pass criteria, and documentation)?
- What cadence and format of checkpoints would you prefer during these first 90 days?
-
Solution Experience
Validate how our transceivers, switches, and gateways deliver the desired migration path using the customer’s scenarios and evaluation-board data.
Experience Meetings
- Solution Experience Kickoff — Current State & Scenarios Confirmation
- Consequence Quantification & Success Metrics Workshop
- Evaluation-Board Data Review — Diagnosis and Proof
- Scenario Validation Lab Session — Proof in Customer Context
- Validation Summary & Decision Meeting — From Proof to Commit
Issues & Enhancements
- Obtain explicit customer acceptance (or list of required re-tests) for each validated scenario.
- Agree dates for lab validation runs and reserve slots in the timeline model.
- Walkthrough of Test Matrix
- Map each evaluation-board result to the validated success signals and label them proven, marginal, or failed.
- Identify critical errata or gaps that must be resolved before silicon qualification and estimate mitigation effort.
- Obtain explicit customer validation on which scenarios are accepted and which require additional lab validation.
- Host to provide annotated result packets (plots, raw data) and a per-test disposition (proven/marginal/failed).
- Customer to mark scenarios they accept as proven and list scenarios requiring re-test or deeper analysis.
- If errata identified, host to propose temporary board-level workarounds and a timeline for silicon fixes or errata notes.
- Lab Setup & Roles
- Produce live measurement proof for top-priority scenarios demonstrating pass/fail vs agreed thresholds.
- Document reproducible test procedures and any immediate mitigations required to meet targets.
- Opening & Objectives
- Host lab to deliver repeatable test scripts and raw logs for each scenario executed in the session.
- Customer to review live results and confirm acceptance or specify re-test conditions within 3 business days.
- If mitigations needed, assign owners to implement temporary workarounds and estimate impact on qualification timeline.
- Executive Summary of Results
- Obtain a clear decision on which devices/scenarios move to formal qualification and which require additional work.
- Agree on updated qualification timeline tied to OEM freeze date and list of owners for each gate.
- Capture commercial or supply actions required to secure parts and test kits for the next phase.
- Produce a Validation Summary Doc listing per-scenario dispositions, evidence links, and acceptance signatures.
- Host to hand off validated test procedures, firmware images, and mitigation notes to the qualification owners.
- Assign supply/commercial owner to confirm evaluation-kit purchases and long-term part availability forecasts.
- Create and agree a single-sentence current-state statement that will guide the experience.
- Surface and quantify the top consequences (schedule, rework, EMC risk) that make this urgent.
- Agree the prioritized customer scenarios and measurable success signals to be validated.
- Confirm availability of evaluation-board data and assign owners for any missing artifacts.
- Customer to provide one-sentence current-state and quantified consequence metrics in writing.
- Share evaluation-board BOM, firmware versions, and raw measurement logs to host 24h before data-review meeting.
- Assign owner to confirm lab access and schedule hands-on validation slot.
- Review Current-state Consequence Inputs
- Finalize numeric success criteria for all prioritized scenarios to frame the proof-of-value tests.
- Lock qualification timeline with dates tied to OEM freeze and identify critical-path items.
- Produce a clear validation checklist that will convert measurement outcomes into go/no-go decisions.
- Host to deliver a metric-mapping spreadsheet linking test names to pass thresholds and measurement methods.
- Customer to confirm acceptable numeric thresholds for each success signal and sign off on the validation checklist.
- Single-sentence Current State
- Run Scenario A (Highest Priority)
- Per-scenario Measurement Review
- Define Measurable Success Signals
- Per-scenario Disposition
- Qualification & Timeline Modeling
- Tie Results Back to Consequences
- Consequence Summary
- Run Scenario B (Interoperability/Gateway)
- Impact on Timeline & Qualification Gates
- Risk-to-Consequence Mapping
- Compare Live Results to Targets
- Migration Scenarios & Acceptance Criteria
- Commercial & Supply Considerations
- Errata & Reproducibility Assessment
- Formal Acceptance Criteria & Next Steps
- Validation Checkpoint — Forced Confirmation
- Capture Required Mitigations
- Validation Criteria Checklist
- Inventory of Evaluation Artefacts
- Next Steps & Owners
- Validation Confirmation
-
Solution Scope
Define devices, evaluation kits, test plans (EMC, latency, sleep power), qualification gates, and owner responsibilities.
Scope Configuration
- Ship multi-protocol evaluation board
- Ship gateway processor evaluation kit
- Provide AUTOSAR-compliant driver package
- Provide unified diagnostic interface firmware
- Deliver PHY/transceiver reference PCB layouts and schematics
- Provide CAN-to-Ethernet gateway reference software
- Deliver EMC mitigation hardware kit and layout fixes
- Provide sleep-mode power optimization firmware
- Supply AEC-Q100 qualified production silicon
- Deliver ISO 26262 functional safety package
- Provide silicon errata and workaround release
- Supply long-term production commitment agreement
Scope Questions
Ship multi-protocol evaluation board
- Do you require an evaluation board that supports multiple in-vehicle protocols on a single PCB (CAN, CAN FD, LIN, FlexRay, Ethernet)?
- Which protocols and data rates must the evaluation board support for your benchmarking?
- How many evaluation boards do you need initially and for how many parallel test benches?
- What evaluation deliverables must be included (assembled board, example harnesses, BOM, build notes, firmware image)?
- Do you need vehicle-level connectors or terminal blocks that match your ECU harnesses?
- Are there mechanical constraints (board form factor, mounting points) or thermal conditions for the evaluation board?
Ship gateway processor evaluation kit
- Will the gateway kit be used for protocol bridging, domain consolidation, or both?
- What CPU/performance class and memory footprint do you need on the evaluation gateway for your use cases?
- Specify the expected I/O mix (number of CAN/CAN FD ports, Ethernet ports, LIN channels, GPIO, diagnostics UARTs).
- Do you require pre-flashed reference gateway software and a CLI/API for test automation?
- What acceptance criteria must the gateway kit meet during evaluation (latency, throughput, message preservation, EMC thresholds)?
- Are you planning hardware-in-the-loop (HIL) or MIL testing that the kit must be compatible with?
Provide AUTOSAR-compliant driver package
- Which AUTOSAR release and stack version must the driver package be compatible with?
- Do you need both source code and prebuilt binaries, or only integration headers and documentation?
- Which MCUs/compilers and build environments must the driver package support (e.g., AUTOSAR OS, toolchain versions)?
- Do you require example integration projects (e.g., sample ECU project, integration notes for RTE and BSW)?
- What level of maintenance and security patch cadence do you expect for the driver package?
- Are there certification or traceability needs (MISRA, code review artifacts, DOORS requirements) for delivered driver code?
Provide unified diagnostic interface firmware
- Which diagnostic protocols must the firmware expose (UDS, OBD, vendor-specific, unified diagnostic API)?
- Do you need the diagnostic interface to integrate with dealer tools or OEM cloud backends?
- What level of debugging/logging verbosity and access control is required in the firmware?
- Should the diagnostic interface support CAN, CAN FD, and Ethernet-based diagnostic transport (DoIP)?
- Do you require attestation, secure boot, and signed diagnostics images as part of the firmware deliverable?
- Are firmware update mechanisms (FOTA via Ethernet or gateway) required in the evaluation phase?
Deliver PHY/transceiver reference PCB layouts and schematics
- Do you need full PCB layout files (e.g., ODB++, Gerber + placement) or only schematics and reference layout guidance?
- Which board stackup, layer count, and impedance constraints does your project use (to tailor reference layouts)?
- Are there existing board-level constraints such as connector locations or automotive enclosures we must accommodate?
- Do you want layout variants optimized for EMC performance, low-power sleep states, or minimal BOM cost?
- Should the reference schematics include recommended decoupling, common-mode choke placement, and termination networks?
- Do you require PCB layout review services with annotated fixes and sign-off from our hardware team?
Provide CAN-to-Ethernet gateway reference software
- Which gateway functions are required: raw bridging, message-based translation, security/firewall, or higher-level application services?
- Do you require support for DoIP, SOME/IP, or other Ethernet diagnostic/application protocols in addition to CAN bridging?
- What latency and throughput SLAs must the reference software meet for your use cases?
- Do you require integration examples for AUTOSAR gateway modules or non-AUTOSAR stacks?
- Should the reference software include security features like message authentication, secure boot verification, or encrypted tunnels?
- Do you want a tested toolchain and CI scripts to run regression tests for gateway functionality?
Deliver EMC mitigation hardware kit and layout fixes
- Have you observed EMC issues in initial testing that necessitate a mitigation kit?
- Which mitigation items should be included: common-mode chokes, ferrites, shielding cans, cable filters, layout patch files, or all of the above?
- Do you require tailored PCB layout fixes (GND pours, trace reroutes) and annotated gerbers for your board revision?
- What EMC standards and test levels must the kit address (e.g., CISPR 25 Class 3, ISO 11452 tests)?
- Are there mechanical or thermal constraints that limit adding shielding or components to your board/enclosure?
- Do you require pre-certification testing support or lab time to validate mitigation effectiveness?
Provide sleep-mode power optimization firmware
- What sleep-mode power target do you need to meet at system level (uA, mW)?
- Which components need sleep coordination (transceivers, PHYs, MCU, gateway) and who controls wake sources?
- Do you require firmware hooks for OEM wake/sleep policies, remote wake, or wake-on-bus diagnostics?
- Should the optimization firmware include measurement scripts and automated power profiling on target hardware?
- Are there safety or latency constraints on wake timing that the firmware must guarantee?
- Do you require source-level deliverables, binary patches, or both for sleep-mode firmware?
Supply AEC-Q100 qualified production silicon
- What production volumes and ramp schedule do you anticipate for the qualified silicon (units per year and start of production date)?
- Which AEC-Q100 grade and temperature range are required for your application?
- Do you require device-specific part numbering, packaging options (WBGA, QFN), or custom assembly considerations?
- What qualification gates must be included (PPAP, AEC-Q100 test report, OEM-specific qualification)?
- Are there supply-chain requirements such as consigned stock, dual-sourcing, or long-lead forecasting?
- What acceptance criteria will you use to sign off production silicon (EMC, power, timing, failure rates)?
Deliver ISO 26262 functional safety package
- What ASIL level(s) must the device and software artifacts support (QM, A, B, C, D)?
- Which artifacts are required: FMEDA, safety manual, safety case, V&V reports, or development process evidence?
- Do you require delivered toolchain qualifications or attestations for development tools used by our team?
- Will your OEM require support for safety audits or co-assessment workshops during qualification?
- Are there specific safety arch constraints such as lock-step cores, HW safety features, or diagnostic coverage targets?
- Do you need continuous safety lifecycle support (safety updates, impact analysis for errata) after handover?
-
Mutual Commit
Agree on commercial terms, supply continuity commitments, errata handling, and formal acceptance criteria for silicon qualification.
Agreement Modules
- Statement of Work (SOW)
- Commercial Terms & Pricing
- Supply Continuity & Long-Term Supply Agreement
- Silicon Qualification Acceptance Criteria
- Errata Handling & Post-Silicon Support Agreement
- Change Control & Engineering Change Order (ECO) Process
- Evaluation Kit Purchase & Loan Terms
- Qualification Test Plan Attachment
- Warranty, Liability & Indemnification
- IP, Firmware & Tooling Escrow
- Purchase Order & Delivery Schedule
- Termination & Exit Conditions
-
Deployment
Operationalize rollout with readiness checks, enablement, and outcome validation.
-
Pre-Deployment Readiness
Confirm evaluation results, test fixtures, lab access, owners, and risk controls required to begin silicon qualification and integration.
Readiness Questions
Quick Pulse: Where Are We Right Now?
- How close are you to starting silicon qualification for this vehicle program?
- Who is the single accountable owner for qualification readiness on your side (name/role/team)?
- Which evaluation hardware and firmware do you already have available?
- What is your OEM platform freeze date (or target design lock)?
- How confident do you feel in the evaluation results so far (EMC, latency, sleep power)?
- What supply or qualification lead-time constraints are already impacting your schedule?
If We Slip a Month, What Breaks First?
- What’s the real cost to your program if silicon qualification is delayed by one production month?
- Which component or activity has the longest lead time that could cause that one-month slip?
- Who on your side is empowered to re-prioritize work to avoid that slip, and have they done so before?
- How does the rest of your organization (platform architects, OEM integrators, program managers) feel about the current schedule pressure?
- What would reduce that schedule risk most effectively (e.g., additional test capacity, faster silicon, alternate supply)?
Are Our Labs Really Ready — or Just Ticking Boxes?
- If you tried a full qualification run next week, what in your lab setup would be most likely to fail first?
- Which of the following lab capabilities are already in-house and validated for this program?
- Do you have the required test fixtures, harnesses, and measurement harness drawings that match your production ECU boards?
- Who controls lab access and booking priorities (name/role), and is remote access available for our engineers?
- Which external test houses or OEM labs will you rely on, and have they certified our measurement methods before?
- Are there any upcoming blackout dates for lab time (OEM audits, certification windows) that could block qualification?
Do the Data Tell a Clear Story — or a Riddle?
- Which single test result would cause you to stop and redesign the board rather than continue qualification?
- Please share the current numerical results or ranges you have for EMC, latency, and sleep-mode power (or attach links to reports).
- Have you defined clear pass/fail gates for each critical metric (EMC margins, latency headroom, sleep current thresholds)?
- Are evaluation boards producing consistent, repeatable results across runs and sites?
- Who independently reviews and signs off the raw data (test engineer, system architect, OEM verifier)?
- Have any silicon errata emerged from evaluation that require board-level workarounds or firmware patches?
Who’s Holding the Integration End — and How Pulled Are They?
- If integration surfaces a protocol or timing incompatibility, what is your escalation path and expected time-to-resolution?
- Which software stacks and middleware have you committed to for this project (AUTOSAR release, OPEN Alliance profiles, proprietary gateways)?
- Are firmware drivers and BSPs for our silicon already integrated into your build and regression pipelines?
- Who are the owners for software integration, test automation, and gateway mapping (names/roles)?
- Do you anticipate needing engineering support from us for firmware bring-up, driver fixes, or lab debugging during the first 90 days?
- If a protocol compliance gap is discovered, what trade-offs are you willing to consider (extra hardware, firmware workaround, relaxed spec)?
How Will We Catch Fires Before They Burn the Schedule?
- Which single risk do you believe has the clearest plan to fail safely (i.e., has no mitigation)?
- Do you maintain a formal risk register for qualification with named mitigations and owners?
- Which mitigation levers are most available to you today (choose all that apply)?
- Do you have a fallback silicon or secondary supplier path if the primary part misses milestones?
- How quickly can your team implement a board-level workaround if an errata demands it (days, weeks)?
- What level of commercial or supply commitment from us would materially reduce your program risk (e.g., allocation, buffer stock, long‑term supply agreement)?
If We Could Agree Right Now, What Would You Ask For?
- What are the three non-negotiable deliverables you need from us before you’ll greenlight a qualification kickoff?
- Which milestones would you expect in the first 90 days after kickoff?
- What documentation and artifacts must be in place for you to trust our parts (e.g., datasheets, AEC-Q reports, known errata list, test-method descriptions)?
- What cadence and format of status updates do you want from us (weekly written, weekly call, dashboard access)?
- Are there any contractual, procurement, or compliance blockers we should resolve before qualification begins?
- What would make you feel emotionally confident that this program will hit the OEM freeze date?
-
Deployment Enablement
Schedule qualification runs, integration sprints, supply milestones, and escalation paths with clear owners and timelines.
-
Validation Checklist
Verify EMC, AUTOSAR/OPEN Alliance compliance, sleep-mode power, and latency targets; document any required board-level workarounds.
Validation Questions
Quick Orientation: Your Program in One Line
- What is the program name, OEM platform, and target platform-freeze (OEM freeze) date?
- Who is the primary decision owner for network architecture and who signs the final silicon qualification?
- Which vehicle domains and legacy buses must be supported on this program?
- What is the hard production start or silicon qualification deadline you’re working toward?
- Which single metric will make leadership say 'we made the right choice' for this network design?
If You Could Snap Your Fingers, What Would This Architecture Fix?
- If you could wave a wand and eliminate one persistent network problem on this program, what would it be?
- Which current limitation of transceivers, switches, or gateways causes the most schedule anxiety for your team?
- Which of these outcomes feels most urgent to avoid: missed OEM freeze, failed EMC, missed latency spec, or unacceptable sleep power?
- How does this problem show up politically across stakeholders—who is most vocal, and who quietly tolerates the risk?
- Tell us about a past decision on a similar program that looked good on paper but caused problems later—what happened?
Where Risk Hides in Plain Sight
- Which single qualification or supply risk do you believe people are underestimating for this program?
- Which long‑lead or single‑sourced components are on your risk register today?
- Have you previously accepted silicon errata with board‑level workarounds? Tell us the most impactful example and how it felt to manage.
- How mature are your contingency plans if a device fails qualification—do you have parallel suppliers, redesign budgets, or timeline buffers?
- On a scale from 1–5, how comfortable are you with accepting board‑level workarounds to meet schedule (1 = never, 5 = regularly)?
Mapping Your Current Reality — Show Me the Network
- If I opened your architecture diagram today, what single thing would surprise me about how legacy and Ethernet domains are bridged?
- Please describe the ECU domains, gateway points, and any existing zonal switch locations we must integrate with.
- Which ECUs are fixed (cannot be changed before production), and which are candidates for redesign or replacement?
- What are typical bus lengths, topology (daisy, star, multi-drop), and termination practices for your CAN domains?
- How many gateway translation points do you expect between CAN domains and the zonal Ethernet backbone?
What Does 'Good' Actually Look Like for Everyone?
- Which stakeholder groups have the most divergent definitions of success for this program?
- For each stakeholder, what are the measurable acceptance criteria we must meet (EMC margins, latency numbers, sleep current targets, protocol compliance)?
- What are the non‑negotiable protocol compliance requirements (AUTOSAR stack versions, OPEN Alliance PHY profiles, CAN FD timing, etc.)?
- How will success be signed off—functional signoff, lab report thresholds, supplier qualification board sign‑off, or OEM final acceptance?
- Which timeline constraints (OEM freeze, market launch) feel most at risk today and why?
Can We Honestly Deliver That on Your Board?
- What kinds of board‑level workarounds would you accept to preserve program timing, and which would you categorically reject?
- Do you require that any silicon errata be resolved in silicon before production, or will you accept documented mitigations?
- How much PCB redesign schedule and budget is realistically available for workaround integration?
- Are there thermal, mechanical, or EMC constraints on board layout that we must accommodate (e.g., restricted stacking, CAN stub limits)?
- Who owns board-level fixes during qualification—your engineering team, the Tier‑1, or a co-engineering model?
Testing, Labs, and the Evidence That Closes Deals
- If we could deliver one lab result tomorrow that would remove doubt, which single test would you want to see (EMC margin, sleep current, latency under load, AUTOSAR interoperability)?
- Which tests must run in your lab versus tests you’ll accept from vendor or third‑party labs?
- What are your pass/fail thresholds for EMC, latency (max jitter/RTT), and sleep-mode power (µA or mW)? Please be specific.
- Do you require AUTOSAR conformance reports or OPEN Alliance PHY compliance certificates as part of qualification?
- What level of access can we expect to your lab, fixtures, or testbeds during evaluation (remote access, on-site support, data sharing)?
Commitments That Keep Programs Alive
- Which supplier commitment would change everything for you—firm lifetime supply, documented errata policy, price stability, or something else?
- What supply continuity mechanisms do you expect (dual sourcing, long lead buys, managed safety stock)?
- How should we handle silicon errata notifications and mitigations—advance notice, shared mitigation plans, compensation, or replacement?
- What commercial acceptance gates are mandatory before you move to production (NRE, qualification signoff, PPAP, other)?
- What escalation path or program governance structure do you require for unresolved technical issues?
Next Steps — What Would Make This Conversation Useful?
- If we stopped after this discovery, what would you regret not having captured or agreed upon?
- Which follow‑up deliverables would be most valuable: evaluation kit, tailored test plan, joint lab run, or detailed commercial term draft?
- Who needs to attend the next technical deep‑dive to make decisions (names and roles)?
- What is your preferred timeline to receive an evaluation board and initial test data?
- How would you prefer us to track progress and share artifacts—a shared workspace (preferred), weekly call, or formal milestones in a project plan?
- Anything else—technical, political, or emotional—that we didn’t ask but should know to help you succeed?
-
-
Success
Confirm production readiness, capture lessons learned, and maintain a shared channel for long-term issues and enhancements.
Success Reviews
- Production Readiness Review
- Project Retrospective — Lessons Learned
- Support & Long-term Escalation Alignment
- Enhancement Roadmap & Change Control
- Supply Continuity & Long-term Risk Review
Issues & Enhancements
- Deliver a written change-control policy including notification windows and required qualification steps.
- Agree and document escalation flows, severity definitions, and SLA targets.
- Define telemetry and monitoring responsibilities to enable proactive detection.
- Provision shared collaboration channel and invite defined stakeholders with role mappings.
- Publish an escalation matrix with names, contact methods, and SLA targets.
- Create a runbook for triage of field issues including initial data to collect and test fixtures to run.
- Schedule quarterly support reviews and annual SLA revalidation meetings.
- Product Roadmap Review
- Align on a shared multi-year roadmap that maps to customer platform freeze cycles.
- Establish a formal change-control and notification process with minimum lead times and impact assessment templates.
- Agree on prioritization criteria for customer-requested enhancements and a governance cadence.
- Capture and prioritize customer enhancement requests into the supplier's roadmap tracker.
- Introductions & Objectives
- Produce an impact-assessment template for customers to use when evaluating silicon revisions.
- Schedule the recurring roadmap governance meeting and invite cross-functional stakeholders.
- Current Supply Position & Forecast
- Secure an agreed supply forecast and commit to notification windows for lifecycle events.
- Document contingency plans and triggers for activating alternate sourcing.
- Ensure quality and traceability requirements are aligned with OEM/Tier-1 expectations.
- Deliver a rolling 24-month supply forecast and a 3-5 year planning outlook to the customer.
- Produce a contingency sourcing plan including alternate fabs or last-time-buy options with owners.
- Add agreed lifecycle and EOL notification clauses into the commercial agreement.
- Schedule an annual supply continuity review aligned to OEM platform freeze milestones.
- Validate that all critical qualification metrics meet agreed production acceptance criteria.
- Document and prioritize remaining open issues and assign owners with deadlines.
- Obtain formal readiness signoff or a clearly staged path to signoff with milestones.
- Confirm supply handoff timeline and manufacturing readiness assumptions.
- Publish final qualification report with pass/fail status per acceptance gate and distribute to stakeholders.
- Owner-assigned closure plan for each open errata or test failure with target close dates.
- Confirm first-article and production ramp dates with manufacturing and update project timeline.
- Create production signoff artifact template to capture signatures and criteria.
- Project Timeline Recap
- Produce a prioritized lessons-learned register covering technical and process items.
- Agree on specific process or artifact changes (checklists, templates, test plans) to prevent repeat issues.
- Assign owners and timelines to implement and verify each improvement.
- Create and circulate a formal Lessons Learned document with prioritized items and owners.
- Update qualification and production checklists to include newly identified test cases or signoff criteria.
- Initiate a short project to implement tooling or template changes (owner & due date).
- Schedule a verification checkpoint to confirm changes reduced the identified risk in the next program phase.
- Support Model Overview
- Establish a single shared communications channel with access control and usage rules.
- Shared Communication Channels
- Lifecycle & Obsolescence Policy
- Customer Enhancement Priorities
- What Went Well
- Summary of Qualification Results
- Escalation Paths & SLA Triggers
- Open Issues & Errata Status
- Contingency & Alternate Sourcing
- What Could Be Improved
- Change Control Process
- Impact Assessment & Qualification Plan
- Technical Root Causes & Mitigations
- Quality, Traceability & Change Notifications
- Manufacturing & Supply Readiness
- Monitoring, Telemetry & Alerting
- Contractual Commitments & Reviews
- Periodic Review Cadence
- Acceptance Gates & Signoff
- Process & Tooling Improvements