Система обнаружения пешеходов в автомобиле — это не одна специальная PCB, а сквозная функция ADAS: датчики формируют данные, интерфейсы доставляют их в вычислительный блок, алгоритмы обнаруживают и сопровождают уязвимого участника движения, логика оценивает риск, а автомобильная сеть передает запрос на предупреждение или торможение. Печатная плата поддерживает питание, синхронизацию, передачу и обработку данных, диагностику и тепловой режим, но сама по себе не подтверждает качество распознавания или безопасность автомобиля.
Правильный проект начинается не с выбора Tg или количества слоев, а со сценариев VRU: взрослый или ребенок, пешеход или велосипедист, пересечение или движение вдоль траектории, поворот, задний ход, перекрытие обзора, день или ночь, загрязнение датчика и границы ODD. Затем для каждого сценария назначают владельца требования, измеримый результат, набор конфигураций и уровень проверки.
Для инженера итогом должна быть связанная цепочка «сценарий → данные → аппаратное ограничение → диагностика → испытание → критерий приемки». Для NPI и закупок — сравнимый пакет доказательств, в котором отдельно указаны PCB, PCBA, датчик, ECU, программное обеспечение, автомобиль и конечная оценка системы.
Ключевые выводы
- «PCB для обнаружения пешеходов» не является самостоятельным типом платы или сертификатом; это PCB/PCBA в составе камеры, радара, sensor hub или ADAS ECU.
- Сценарии нужно задавать по типу VRU, движению, перекрытию, освещению, погоде, дорожной геометрии, движению автомобиля и ожидаемой реакции.
- Euro NCAP дает полезную структуру vehicle-level сценариев, но не заменяет ODD, OEM DVP&R, SOTIF-анализ и квалификацию аппаратуры.
- Камера, радар, тепловизор и LiDAR имеют разные сильные стороны и разные систематические ограничения; архитектуру выбирают по сценарию и evidence plan, а не по универсальному рейтингу датчиков.
- Сквозная задержка включает exposure/readout, link, buffering, inference, fusion, decision, vehicle network и actuation. PCB влияет только на часть этого бюджета.
- Целостность кадра требует контроля не только CRC, но и timestamp, frame counter, exposure/gain, SerDes lock, clock, memory, dropped-frame и thermal-throttling states.
- Случайный аппаратный отказ и корректно работающий датчик с недостаточной информацией — разные классы риска и требуют разных мер.
- ASIL не присваивается плате по названию функции. Требования приходят из item definition, HARA, safety concept и распределения на аппаратные и программные элементы.
- AEC-Q100/Q200 относится к квалификации соответствующих компонентов; это не квалификация PCB, PCBA, ECU или автомобиля.
- Производственный тест должен связывать каждый значимый дефект с методом обнаружения, пределом, эталоном и реакцией на отказ.
- Валидация должна быть многоуровневой: bare PCB, PCBA, sensor/ECU bench, replay/SIL/HIL, environmental/EMC, vehicle/track и end-of-line.
- Hardware revision, BOM, sensor, optics, model, dataset, calibration, firmware и test scripts должны образовывать одну контролируемую конфигурацию.
- Цена и срок определяются не только слоями платы, но и SoC/BGA, memory, high-speed links, shields, fixtures, programming, калибровкой, данными приемки и жизненным циклом компонентов.
- HILPCB может изготовить и собрать согласованную PCB/PCBA и выполнить оговоренные проверки, но не заменяет владельца perception stack, functional safety, SOTIF, braking function или vehicle approval.
Содержание
- Что именно называется системой обнаружения пешеходов?
- Какие сценарии VRU нужно зафиксировать?
- Как разделить ответственность по цепочке восприятия?
- Как выбрать камеру, радар, тепловизор или LiDAR?
- Как составить бюджет задержки и качества данных?
- Как проверить целостность изображения и высокоскоростной линии?
- Чем аппаратный отказ отличается от ограничения восприятия?
- Какие требования задать питанию, clock/reset, памяти, теплу и EMC?
- Как обеспечить производимость, сборку и тестопригодность ADAS PCBA?
- Как связать отказ, диагностику и испытание?
- Как построить многоуровневую валидацию?
- Как управлять моделью, калибровкой и конфигурацией?
- Как закрыть прототип, design validation и pilot?
- Как аудировать поставщика и управлять BOM?
- Из чего складываются цена и календарный срок ADAS PCBA?
- Какие входные данные нужны поставщику для точного предложения?
- Где заканчивается область работ HILPCB?
- Практические вопросы
Что именно называется системой обнаружения пешеходов?
Система обнаружения пешеходов — это функция восприятия и реакции, а не отдельная категория печатной платы. Ее аппаратная реализация может быть распределена между камерой, радаром, центральным ADAS ECU, зональным контроллером, vehicle network gateway и тормозным контроллером.
| Уровень | Что делает | Что должно быть доказано |
|---|---|---|
| Датчик | преобразует свет, радиоотражение или тепловое излучение в данные | поле зрения, качество сигнала, синхронизация, загрязнение, температура и диагностируемость |
| Sensor interface | сериализует, передает, принимает и проверяет поток | link margin, bit/frame integrity, latency, recovery и EMC robustness |
| Perception compute | выполняет preprocessing, inference, tracking и fusion | производительность на утвержденной конфигурации, resource margin и fault handling |
| Decision function | оценивает траекторию, риск и требуемую реакцию | timing, confidence/policy, state machine, degraded modes и safety requirements |
| Vehicle network | передает object/risk/brake data между ECU | message integrity, freshness, timeout, bandwidth и fault containment |
| Brake/HMI | предупреждает водителя или формирует тормозное действие | actuator response, arbitration, driver interaction и vehicle-level acceptance |
| PCB/PCBA | физически реализует питание, interconnect, compute, memory, clocks и diagnostics | соответствие утвержденным файлам, процессу, тестам и приемочным данным |
На практике могут существовать camera PCB, radar PCB, compute carrier или центральный ECU. Для более глубокого проектирования камеры используйте руководство по автомобильной камере ADAS, а для радиочастотной части — руководство по radar PCB. Эта статья связывает их на уровне VRU-функции и доказательств.
Какие сценарии VRU нужно зафиксировать?
Сценарий должен описывать не только слово «пешеход», но и геометрию, движение, видимость, среду, состояние автомобиля и ожидаемую реакцию. Без такой матрицы невозможно осмысленно выбрать датчики, собрать dataset, задать latency budget или определить достаточность DVP&R.
Актуальный протокол Euro NCAP AEB/LSS VRU v4.5.1 включает структурированные сценарии с пешеходами, велосипедистами и мотоциклистами: пересечение с ближней и дальней стороны, ребенок из-за препятствия, продольное движение, поворот автомобиля, задний ход, dooring и несколько траекторий мотоциклиста. В нем также фиксируются конфигурации освещения, пути, скорости и измерение реакции. Это полезная исходная таксономия, но не полный перечень условий конкретного ODD.
| Измерение сценария | Примеры значений | Что фиксировать как evidence |
|---|---|---|
| Тип VRU | взрослый, ребенок, велосипедист, мотоциклист, пользователь средства микромобильности | target specification, размер/поза, clothing/reflectivity или применимый surrogate |
| Относительное движение | crossing near/far, longitudinal, stationary, turning, reverse, dooring | пути, скорости, acceleration, time-to-collision и допустимые отклонения |
| Перекрытие обзора | припаркованный автомобиль, инфраструктура, другой VRU, частичный выход из кадра | obstruction geometry, reveal time и доступность каждому датчику |
| Освещение | день, ночь, streetlight, low/high beam, backlight, glare, shadow transition | lux/lighting setup, exposure state, headlamp state и repeatability |
| Среда | дождь, снег, туман, брызги, пыль, загрязнение линзы/radome | severity, deposition method, sensor-health state и cleaning strategy |
| Дорога | прямая, перекресток, поворот, уклон, обочина, сложный фон | map/geometry, lane boundaries, curvature и roadside clutter |
| Автомобиль | скорость, yaw/turn, braking state, load, pitch, reverse | vehicle state log, coordinate frames и timing source |
| Реакция | предупреждение, частичное/полное торможение, suppression, degraded state | trigger condition, response timing, deceleration request и pass/fail rule |
Внутренняя матрица должна добавить условия, которых нет в rating protocol, но которые входят в ODD или foreseeable misuse проекта: необычная одежда, небольшая видимая часть тела, животное рядом с человеком, строительная зона, стекло/отражение, грязный датчик, неверная калибровка, потеря одного sensor channel и переход между режимами.
Для каждой строки назначают три результата: функция должна сработать, функция должна не сработать или поведение определяется безопасным degraded mode. «Максимальная чувствительность» без false-positive policy может вызвать ненужное торможение; поэтому обнаружение и допустимая реакция должны задаваться вместе.
Как разделить ответственность по цепочке восприятия?
Ответственность нужно распределять по требованиям и evidence, а не передавать целиком поставщику одной платы. Один и тот же symptom — например, пропущенный кадр — может возникнуть из-за датчика, SerDes, power transient, memory congestion, software scheduling или logging error.
| Объект | Обычно задает требование | Реализует | Предоставляет evidence | Принимает результат |
|---|---|---|---|---|
| ODD и VRU use cases | OEM/system owner | perception and vehicle teams | scenario catalogue, safety/SOTIF work products | vehicle programme owner |
| Оптика и sensor module | perception/camera owner | Tier 1/module supplier | optical, calibration, environmental and health data | system integration owner |
| Radar/other sensing | sensor-fusion owner | radar/Tier 1 supplier | detection, interface, environmental and diagnostic data | system integration owner |
| PCB/PCBA | hardware design authority | PCB fabricator/EMS по утвержденным файлам | stack-up, inspection, electrical/test and genealogy data | hardware/NPI owner |
| SoC, memory and interfaces | compute architect | hardware and software teams | timing, bandwidth, ECC, thermal and fault-injection results | ECU owner |
| Model and tracking | perception owner | algorithm/software team | dataset, metrics, corner cases, change and regression evidence | function owner |
| Fusion and decision | system architect | system/software team | timing, state-machine, fault and scenario results | safety/function owner |
| Vehicle network and brake | vehicle E/E owner | network/brake teams | communication, arbitration, actuator and vehicle tests | OEM vehicle authority |
| Rating/regulatory approval | OEM/manufacturer of record | cross-functional programme | official vehicle/lab evidence | applicable authority/programme |
Матрица RACI недостаточна, если не указывает deliverable и approval right. Например, EMS может загрузить образ и записать checksum, но не должен самостоятельно менять модель, калибровку или production key. PCB-поставщик может подтвердить параметры изготовленной структуры, но не может принять остаточный риск пропуска пешехода.
Как выбрать камеру, радар, тепловизор или LiDAR?
Датчик выбирают по наблюдаемым свойствам сценария, ограничениям установки и плану доказательств. Универсально лучшего варианта нет. Архитектура может использовать один основной sensor channel, дополняющие датчики или независимо способные каналы; каждое решение меняет failure modes и объем валидации.
| Технология | Сильная сторона | Ограничение, которое нужно проверить | Аппаратные последствия |
|---|---|---|---|
| Видимая камера | текстура, цвет, форма, классификация и lane/context information | darkness, glare, blur, occlusion, contamination, exposure transition | optics, imager, SerDes, high-speed data, calibration, image memory and compute |
| Radar | range/range-rate, работа при части сложных условий видимости | angular/classification resolution, multipath, clutter, radome and mutual interference | RF material/launch, antenna, clock, shielding, calibration and thermal stability |
| Тепловизор | тепловой контраст при слабом видимом освещении | emissivity/background, resolution, cost, lens material, calibration and weather | sensor interface, calibration storage, thermal control and image processing |
| LiDAR | трехмерная геометрия и depth points | contamination, weather interaction, scanning/field coverage, cost and eye-safety ownership | high-speed interface, timing, power, thermal and mechanical alignment |
| Ультразвук | ближняя зона и маневрирование на низкой скорости | дальность, скорость, ветер/поверхность и cross-talk | analog front end, transducer drive, timing and connector/harness control |
Sensor fusion не устраняет ограничения автоматически. Если каждый канал наблюдает разные признаки и общий world model зависит от обоих, отказ одного канала может удалить критическую информацию. Если каналы должны быть независимыми, это нужно доказать раздельными datasets, failure injection, timing и common-cause analysis, а не только наличием двух типов датчиков.
Поставщик PCB не должен выбирать sensor architecture без system requirements. Его полезная роль — проверить, реализуемы ли power rails, interfaces, stack-up, escape, shielding, thermal path, test access и assembly tolerances выбранной архитектуры.
Как составить бюджет задержки и качества данных?
Сквозную задержку нужно разложить на измеримые этапы и привязать к одному времени. Фраза «реакция за несколько миллисекунд» бесполезна, если неизвестно, где начинается и заканчивается измерение, как синхронизированы clocks и какое percentile/worst case принимается.
| Этап | Что измерять | Возможный аппаратный вклад |
|---|---|---|
| Exposure/integration | начало/середина экспозиции, rolling/global shutter behavior | sensor clock, trigger, illumination and power stability |
| Sensor readout | время вывода полного кадра или region of interest | imager mode, lane count, clock and temperature |
| Serialization/link | packetization, propagation, retries/recovery | SerDes configuration, PCB channel, connector/cable and EMC errors |
| Deserialization/DMA | receive buffering, copy and memory placement | receiver, bus arbitration, memory bandwidth and interrupts |
| Preprocessing/inference | resize, ISP, accelerator execution and queueing | SoC load, memory, voltage, clock and thermal throttling |
| Tracking/fusion | association, state update and cross-sensor alignment | timestamp quality, time sync, compute scheduling and data freshness |
| Decision | risk evaluation, suppression and state machine | processor scheduling, watchdog and safety mechanism interaction |
| Vehicle network | message preparation, arbitration, transport and gateway | CAN/Ethernet load, transceiver, clock and timeout behavior |
| Actuation | brake-controller processing and hydraulic/electric response | outside PCB scope of perception ECU; measured at vehicle level |
Одновременно задают data-quality budget:
- разрешение и field of view в установленной геометрии;
- blur, exposure, dynamic range и signal-to-noise в ключевых сценариях;
- frame drop, reordering, duplication и stale-data limits;
- timestamp accuracy, drift, synchronization и coordinate-frame transform;
- link error counters, CRC, packet/frame completeness и recovery time;
- calibration version, valid range и detection of invalid calibration;
- compute load, memory margin и thermal state;
- confidence/quality fields, которые передаются downstream owner.
Лучший способ приемки — один correlation log, содержащий sensor timestamp, receive timestamp, inference start/end, object-list timestamp, decision output, network transmit/receive и actuator response. Без общего timebase локальные «быстрые» измерения нельзя сложить в сквозной бюджет.
Как проверить целостность изображения и высокоскоростной линии?
Корректный электрический линк еще не гарантирует корректный кадр. Нужно доказать одновременно transport integrity, semantic freshness и пригодность изображения для perception function.
| Наблюдение | Возможная причина | Диагностика | Проверка |
|---|---|---|---|
| Нет кадров | rail/reset/clock failure, cable open, SerDes unlock, driver state | power-good, reset reason, lock and link counters | power fault injection, cable interruption, restart test |
| Редкие dropped frames | marginal channel, EMI burst, buffer overflow, scheduling | frame counter, CRC/error counters, DMA/queue telemetry | stress traffic, EMC injection, temperature and load sweep |
| Кадр повторяется | stale buffer, software pipeline stall, timestamp fault | frame ID, source timestamp, watchdog and queue age | forced task stall and recovery verification |
| Изображение темное/пересвечено | exposure/gain, optics, lighting, sensor mode | exposure/gain metadata, histogram, mode and temperature | lighting transitions and configured limits |
| Смаз или геометрическая ошибка | motion, exposure, vibration, rolling shutter, calibration | IMU/vehicle state, exposure time, calibration and feature residuals | vibration/motion rig and vehicle correlation |
| Локальная порча | packet loss, memory corruption, ISP error | line/frame CRC, ECC, error map and dump | link/memory fault injection and golden-frame comparison |
| Данные правдоподобны, но устарели | time-sync loss, buffering, replay or update order | timestamp age, clock status and sequence ID | clock drift, time-source loss and delayed-packet injection |
Для высокоскоростной PCB контролируют не абстрактные «50/100 Ом», а конкретные interfaces, reference stack-up, geometry, insertion/return loss requirement, connector/cable boundary, skew, via/backdrill и manufacturing coupon. Числа берут из chipset/reference design и channel model проекта.
Детальный camera-module review остается в руководстве по автомобильной камере ADAS. Здесь главный критерий — связать электрическую ошибку с потерей, старением или искажением данных, которые видит perception function.
Чем аппаратный отказ отличается от ограничения восприятия?
Аппаратный отказ нарушает ожидаемое поведение элемента; ограничение восприятия может возникнуть при исправной аппаратуре, когда входной информации недостаточно или алгоритм интерпретирует ее неверно. Эти риски пересекаются в vehicle function, но не закрываются одним и тем же тестом.
| Событие | Основной класс проблемы | Типичный owner | Нужное evidence |
|---|---|---|---|
| обрыв питания imager | electrical/electronic fault | hardware/safety owner | diagnostic reaction, fault injection and safe/degraded behavior |
| bit error в link | hardware/channel fault | hardware and interface owners | detection coverage, counter/CRC behavior and recovery |
| memory corruption | hardware/systematic integration fault | compute/hardware/software owners | ECC, scrubbing, fault injection and error containment |
| перегрев и throttling | performance/resource fault | thermal/compute/system owners | thermal map, timing margin and declared degraded state |
| пешеход закрыт автомобилем | perception insufficiency/scenario limitation | perception/SOTIF owner | scenario evidence, reveal-time behavior and residual-risk decision |
| glare или плохой contrast | sensor/perception limitation | optics/perception owner | controlled lighting data and multi-sensor/degraded response |
| незнакомая поза или объект | model/data limitation | dataset/model owner | coverage rationale, targeted data and regression result |
| неверная калибровка после ремонта | lifecycle/configuration fault | service/system owner | calibration detection, service procedure and end-of-line check |
ISO 26262 не дает оснований объявить всю плату «ASIL B/C» только по применению. Safety goals и ASIL определяются на уровне item, после чего требования распределяются на элементы. PCB/PCBA supplier предоставляет evidence только для выделенного scope.
ISO 21448/SOTIF относится к недостаточности предполагаемой функции и foreseeable misuse при отсутствии неисправности. Это также системная работа: dataset, scenario coverage, sensor limitations, algorithm, driver interaction и vehicle behavior не могут быть квалифицированы измерением голой платы.
AEC-Q100/Q200 помогает оценивать квалификацию соответствующих микросхем и пассивных компонентов. Маркировка AEC-Q в BOM не подтверждает layout, solder joint, PCB material, enclosure, software, perception performance или соответствие автомобиля.
Какие требования задать питанию, clock/reset, памяти, теплу и EMC?
Аппаратная спецификация должна исходить из states и failure reactions всей цепочки, а не из типового списка automotive components. Каждый rail, clock, reset и interface получает нормальный режим, worst case, диагностику и критерий recovery.
Питание
- входной диапазон и transients задаются по installation zone и OEM profile;
- power sequence связывается с imager, SerDes, SoC, memory и safety MCU;
- brownout, over/undervoltage, short/open и slow ramp проверяются fault injection;
- power-good и ADC telemetry должны позволять отличить rail fault от software stall;
- worst-case load включает boot, inference peak, interface traffic, heater/illumination и degraded modes;
- PDN target, decoupling и plane strategy подтверждаются simulation/measurement по частотному диапазону проекта.
Clock, reset и time
- определите source, accuracy, jitter, holdover и monitor для каждого критичного clock;
- разделите power-on reset, watchdog reset, software reset и external reset causes;
- сохраните reset reason и last-valid timestamp для анализа поля;
- проверьте потерю time source, drift между sensors и recovery без смешения старых и новых данных;
- не допускайте молчаливого перехода на другой clock без диагностируемого state.
Память и compute
- bandwidth рассчитывается для всех sensor streams, intermediate buffers, logging и update paths;
- ECC/parity, error reporting, memory test и retention задаются по выделенным safety requirements;
- thermal throttling должен иметь видимый state и известное влияние на latency;
- watchdog проверяет не только «CPU жив», но и freshness критической pipeline;
- debug logging не должен менять timing так, что validation build перестает представлять production build.
Тепловой режим и EMC
- temperature profile берется из реального mounting location, enclosure, airflow и vehicle soak;
- junction estimates связываются с workload и power modes, а не только с комнатным bench test;
- shields, chassis contacts, return paths, filters и connector pinout проектируются как система;
- conducted/radiated immunity проверяется одновременно с frame/link/error telemetry;
- pass означает сохранение требуемой функции или корректный declared degraded state, а не только отсутствие reset.
Как обеспечить производимость, сборку и тестопригодность ADAS PCBA?
DFM/DFA/DFT должны защищать контролируемую конструкцию и обеспечивать измеримый производственный тест. Универсальный чек-лист сборщика не заменяет review BGA escape, high-speed channel, shields, camera/radar connectors и programming/calibration flow.
| Область | Что проверить до release | Возвращаемый результат |
|---|---|---|
| Stack-up | material properties, layer function, impedance/loss structures, copper balance and pressed thickness | approved stack-up with tolerances and coupon plan |
| BGA/HDI | escape, via type, aspect ratio, via-in-pad fill/cap, registration and rework access | manufacturability exceptions and approved construction |
| High-speed | reference continuity, launch, via stub, connector breakout, length/skew and test access | channel-risk review and controlled-structure list |
| Power/thermal | planes, current density, thermal vias, copper coins/heatsink interface if used | PDN/thermal assumptions and process constraints |
| Assembly | MSL, paste aperture, BGA/QFN, bottom-terminated parts, shields and selective processes | assembly drawing review and process-risk list |
| Inspection | hidden joints, void-sensitive interfaces, polarity and critical alignment | AOI/X-ray/visual coverage map and acceptance owner |
| Test | rails, clocks, resets, interfaces, memory, programming, sensor emulation and diagnostics | test-point/fixture list and defect-to-test matrix |
| Configuration | hardware ID, BOM revision, firmware/model/calibration compatibility | serialization and release-data mapping |
Если изделие закупается как SMT-сборка, RFQ должен указать, какие inspections обязательны, какие пределы задает customer drawing и какие raw data возвращаются. «AOI + X-ray» без coverage map не доказывает обнаружение конкретного дефекта.
Как связать отказ, диагностику и испытание?
Каждый значимый failure mode должен иметь detection method, acceptance limit, test level и реакцию. Если дефект не обнаруживается на производстве, нужно понять, закрывается ли он design margin, qualification, system diagnostic или остается residual risk.
| Failure mode | Возможный эффект | Detection/telemetry | Где проверять | Реакция |
|---|---|---|---|---|
| open/short rail | sensor/SoC unavailable или нестабильные данные | voltage/current, power-good, reset reason | ICT/FCT and fault injection | inhibit output, degraded state, DTC |
| marginal SerDes channel | intermittent frame corruption | lock, CRC/error counters, frame loss | channel measurement, stress and EMC | retry/reinit or channel isolation |
| clock drift/loss | timestamp error, sensor desynchronization | clock monitor, sync error, age | bench/HIL and environmental | reject stale data, degraded mode |
| memory bit error | corrupt frame/model/object data | ECC/parity and exception logs | memory test and fault injection | correction, containment or reset |
| BGA solder defect | intermittent compute/interface fault | boundary scan/ICT/FCT, X-ray limits | production and thermal/mechanical stress | reject/rework under controlled rule |
| calibration mismatch | geometric/object-position error | version/CRC, plausibility and residual | EOL, service and vehicle test | block release or recalibrate |
| thermal overload | latency increase or shutdown | junction proxy, throttle state, timing | thermal chamber and workload stress | derate/degraded state with DTC |
| wrong firmware/model | unvalidated behavior | signed ID, manifest and compatibility check | programming/EOL and boot | prevent activation and quarantine |
Test coverage нужно считать по согласованному defect universe, а не по количеству станций. SPI, AOI, X-ray, ICT, boundary scan и FCT дополняют друг друга; ни один метод не видит все дефекты. Golden unit также должен иметь revision, calibration state и периодическую проверку, иначе он становится неизвестным эталоном.
Как построить многоуровневую валидацию?
Самый быстрый путь к надежному результату — закрывать риск на самом низком уровне, где его можно однозначно воспроизвести, и подтверждать интеграцию на верхнем. Vehicle test не должен быть первым местом, где ищут marginal rail или dropped frame.
| Уровень | Главный вопрос | Примеры evidence | Чего не доказывает |
|---|---|---|---|
| Bare PCB | изготовлена ли утвержденная структура | dimensions, stack-up, coupon, impedance/loss, electrical test, microsection as specified | assembly, software или perception performance |
| PCBA production | собрана и запрограммирована ли единица без обнаруживаемых defects | SPI/AOI/X-ray/ICT/boundary scan/FCT, programming manifest, serial genealogy | полную environmental или vehicle qualification |
| Sensor/ECU bench | работают ли rails, clocks, interfaces, diagnostics и compute states | power/thermal maps, link margin, memory, fault injection, restart/recovery | полную сцену дороги и vehicle actuation |
| Replay/SIL | как model/logic работает на контролируемых данных | dataset version, expected outputs, metrics, regression and corner cases | sensor physics, link faults and installed geometry |
| HIL/sensor stimulation | как timing, network и state machine реагируют на сценарии и faults | synchronized inputs, logs, fault injection and requirement trace | все optics/weather/road interactions |
| Environmental/EMC | сохраняется ли функция или declared degradation при stress | temperature, vibration, humidity, conducted/radiated tests with telemetry | полную статистику ODD и vehicle behavior |
| Vehicle/track | достигается ли end-to-end response в установленной системе | scenario matrix, paths, timing, warnings/braking and configuration record | все редкие field scenarios без дополнительного coverage plan |
| Production EOL | соответствует ли каждая серийная единица контролируемому baseline | serial, hardware/BOM/software/calibration IDs and pass data | design qualification новой revision |
Euro NCAP protocol применяется на vehicle/track уровне и определяет собственные targets, geometry, lighting, paths и evaluation. Его нельзя использовать как замену PCBA acceptance. И наоборот, идеальный FCT не показывает, распознает ли автомобиль частично закрытого ребенка ночью.
Для общей структуры автомобильных release gates полезно руководство по L2 ADAS и EVT/DVT/PVT для automotive ADAS. В текущем проекте названия gates могут отличаться, но requirement traceability и exit criteria должны сохраняться.
Как управлять моделью, калибровкой и конфигурацией?
Результат ADAS действителен только для записанной комбинации hardware, software, data и test setup. Замена памяти, imager, lens, SerDes, PCB material, model weights или calibration может изменить timing, image quality, thermal behavior или detection performance.
Минимальный configuration manifest включает:
- product/ECU part number и hardware revision;
- PCB fabrication revision, stack-up revision и assembly revision;
- BOM revision, approved manufacturer parts и фактически установленные lot/date codes;
- sensor, lens, filter, radome, cable и connector identifiers;
- bootloader, firmware, drivers, OS/container и safety software versions;
- model architecture/weights identifier и cryptographic checksum;
- training/evaluation dataset releases и применимые scenario subsets;
- calibration set, coordinate transforms, intrinsics/extrinsics и validity status;
- test scripts, stimulus data, instrument/fixture revision и acceptance-limit revision;
- vehicle configuration, mounting position, tire/load state и time source для track evidence.
Изменение проходит impact assessment: что затронуто, какие требования повторно проверяются, какие samples representative и кто принимает deviation. «Form-fit-function equivalent» в закупке недостаточно, если part влияет на timing, optics, RF, thermal или diagnostic behavior.
В производстве serial genealogy должна позволять связать конкретную единицу с BOM, firmware/model/calibration и test result. При field issue это сокращает containment: можно определить затронутые конфигурации, а не отзывать все изделия или предполагать, что проблема только программная.
Как закрыть прототип, design validation и pilot?
Gate закрывается evidence и принятым residual risk, а не фактом изготовления партии. Названия EVT/DVT/PVT могут различаться у OEM и Tier 1; важны representative configuration и exit criteria.
| Gate | Главный вопрос | Минимальные выходы | Нельзя считать закрытым, если |
|---|---|---|---|
| Architecture/concept | сценарии, owners и budgets согласованы? | VRU matrix, responsibility, sensor choice, latency/data budget, safety/SOTIF interfaces | ODD, braking owner или sensor assumptions остаются скрытыми |
| EVT | аппаратная архитектура и диагностика работают? | bring-up, rails/clocks/interfaces, early thermal, link and fault-injection evidence | тестируется provisional stack-up/BOM без плана корреляции |
| DVT | design соответствует требованиям в representative configuration? | DVP&R, environmental/EMC, timing, scenario, diagnostic and regression evidence | model/calibration/hardware не совпадают с release baseline |
| PVT/pilot | процесс стабильно воспроизводит approved design? | process window, fixtures, test correlation, genealogy, yield/failure disposition and operator readiness | golden unit, limits или software load не контролируются |
| Production release | supply, process, change and field loops готовы? | approved BOM/alternates, control plan, data retention, deviation/PCN and CAPA flow | supplier может менять critical item без approval |
Prototype deviation register должен перечислять все отличия: engineering sample sensor, temporary heatsink, hand-modified PCB, alternate memory, debug firmware, disabled security, provisional model или bench-only calibration. Результаты такой единицы полезны, но не автоматически представляют production configuration.
Как аудировать поставщика и управлять BOM?
Поставщика нужно оценивать по способности воспроизвести конкретную конструкцию и вернуть доказательства, а не по общему списку оборудования. Для ADAS ECU особенно важны change control, traceability и test-data correlation.
Доказательства PCB/PCBA поставщика
- утвержденный stack-up с material system, glass/resin construction, thickness и tolerances;
- список controlled impedance/loss structures и coupon/report method;
- DFM/DFA/DFT issues, owner responses и закрытые deviations;
- process flow для HDI/via-in-pad/BGA/shields/coating, если они применяются;
- inspection/test coverage по failure modes, а не только названия станций;
- fixture/software/golden-unit control и correlation procedure;
- serial/lot genealogy, raw-data export, retention и access rights;
- nonconformance, rework, quarantine, CAPA/8D и escape response;
- material/component/site/process/test change-notification rules;
- continuity, backup tooling/data и recovery expectations.
BOM и жизненный цикл
- разделите no-substitute, customer-approved alternate и supplier-proposed alternate;
- проверьте lifecycle, allocation, MOQ/NCNR, authorized channel и date-code policy;
- для SoC, memory, PMIC, SerDes, imager и transceiver определите redesign trigger;
- зафиксируйте firmware/driver/model compatibility для каждого alternate;
- требуйте impact assessment и representative revalidation до использования замены;
- отделите component AEC qualification от пригодности детали в конкретном load/environment;
- согласуйте ownership excess, EOL last-time buy и obsolete inventory.
Аудит документации должен использовать sample evidence по похожему процессу без раскрытия чужих данных: stack-up approval, test report structure, traceability export, nonconformance closure и change workflow. Сертификат системы менеджмента сам по себе не показывает, что RF/high-speed structure или programming manifest данного проекта контролируются правильно.
Из чего складываются цена и календарный срок ADAS PCBA?
Стоимость ADAS PCBA формируют плотность, материалы, компоненты, тест и доказательства; срок — еще и готовность требований. Поздний stack-up или неутвержденная замена SoC может задержать программу сильнее, чем сама fabrication.
| Драйвер | Почему влияет | Как управлять |
|---|---|---|
| HDI, via-in-pad, fine-pitch BGA | дополнительные процессы, registration и inspection | использовать только по escape/channel need и рано согласовать construction |
| High-speed/loss control | material sourcing, coupon, test setup and yield sensitivity | заморозить interface/channel requirements до layout release |
| SoC, memory, PMIC, SerDes и sensors | allocation, lifecycle, MSL, programming and unit cost | ранний AVL/lifecycle review и approved alternate strategy |
| Shields, connectors и mechanical alignment | tooling, assembly sequence and inspection | включить enclosure/shield/connector drawing в DFA review |
| Thermal solution | heatsink/TIM, flatness, torque and test workload | согласовать mechanical stack и representative workload до DVT |
| Programming/model/calibration | secure data handling, station time and configuration control | определить manifest, checksum, retry/scrap and audit flow до PVT |
| ICT/FCT/HIL fixtures | NRE, debug, maintenance and correlation | назначить ownership, acceptance and spare strategy до PO |
| Environmental/EMC/track samples | lab/vehicle availability and repeated configurations | построить sample matrix и DVP&R до заказа партий |
| Traceability/raw data | serialization, storage, export and review effort | собирать только обязательные fields с понятным retention |
Quotes сравнивают на одной базе: одинаковая revision, quantity breaks, approved material/BOM assumptions, included inspections/tests, fixture/NRE, programming/calibration, reports, packaging, Incoterms, lead-time basis, NCNR/excess и change terms. Низкая цена без FCT, raw data или controlled alternates не является эквивалентной ценой.
Какие данные отправить в RFQ на PCB/PCBA для обнаружения пешеходов?
Полный RFQ должен позволить поставщику оценить конструкцию, test scope, data return и ответственность без угадывания safety или perception requirements.
Система и границы
- тип изделия: camera module, radar interface, sensor hub, ADAS ECU или другой узел;
- vehicle/application, installation zone, ODD summary, target SOP и service life;
- функциональная граница PCB/PCBA и внешние owners sensor, algorithm, network, brake and approval;
- allocated hardware requirements, diagnostics, degraded states и acceptance owner;
- список interfaces, data rates/modes, time source и synchronization requirements;
- applicable OEM, safety, SOTIF, EMC, environmental and rating documents с revisions.
PCB и механика
- Gerber/ODB++/IPC-2581 или согласованный fabrication package и netlist;
- schematic, stack-up/constraints, layer functions, impedance/loss table и coupon requirements;
- material properties, copper/finish, HDI/via/backdrill/via-in-pad и special process notes;
- dimensions, tolerances, flatness, connector/sensor/shield/heatsink locations;
- panelization, serialization, marking, cleanliness/coating and packaging requirements;
- customer-controlled structures и deviation approval flow.
BOM и сборка
- BOM/AVL/AML с MPN, no-substitute flags, approved alternates и lifecycle status;
- centroid, assembly drawings, polarity/rotation, MSL/bake/storage and special handling;
- BGA/QFN/bottom-terminated, shields, press-fit, selective solder, coating or bonding rules;
- firmware, bootloader, model and calibration images с IDs/checksums;
- programming/security boundary, access roles, retry, scrap and audit requirements;
- golden sample/reference ownership and maintenance.
Проверка и приемка
- DFM/DFA/DFT report format и response/closure process;
- SPI/AOI/X-ray/ICT/boundary-scan/FCT coverage linked to defects;
- rail, clock, reset, memory, high-speed link, network and diagnostic test requirements;
- sensor stimulus/emulation, calibration and time-correlation scope, если применяется;
- fixture, cable, load, software, instrument and correlation ownership;
- acceptance limits, sampling, raw-data format, retention and review access;
- COC, material/lot, coupon, microsection, inspection, test and genealogy deliverables;
- nonconformance, rework, retest, failure analysis and CAPA/8D rules.
NPI, коммерция и изменения
- EVT/DVT/PVT quantities, configuration, sample split and gate deliverables;
- объемы по ценовым уровням, прогноз потребности, требуемые даты и правила согласованной частичной поставки;
- разовые инженерные затраты, оснастка, fixture, права на software/data/IP и порядок амортизации;
- component sourcing model, authorized channels, NCNR/excess and EOL handling;
- material/component/site/process/equipment/test/software change notice and approval;
- warranty/return analysis, continuity, backup and disaster-recovery expectations;
- условия отгрузки и Incoterms, тип упаковки, moisture control и язык возвращаемой документации.
В ответе поставщика assumptions, exclusions и open technical questions должны быть привязаны к строкам RFQ. До PO закрывают отдельный clarification list по stack-up, BOM, test, programming, evidence и schedule. Это предотвращает ситуацию, когда unit price согласована, а обязательная калибровка или fixture оказалась вне scope.
Что может выполнить HILPCB в таком проекте?
HILPCB может рассмотреть fabrication и assembly package, предложить DFM/DFA/DFT замечания в согласованном объеме, изготовить PCB, собрать PCBA и выполнить утвержденные inspection, programming и test steps. Конкретный stack-up, controlled structures, materials, BGA/HDI process, coating, fixture, reports, traceability и quality deliverables подтверждаются по файлам проекта и quotation.
Для полного sourcing/assembly scope можно запросить комплексную сборку PCBA. В RFQ следует явно разделить approved component channels, alternates, firmware/model/calibration ownership, security data, fixture ownership, acceptance limits и возвращаемые raw data.
HILPCB не определяет ODD, не выбирает safety goals или ASIL, не утверждает SOTIF, не владеет training dataset и perception metrics, не калибрует автомобиль без согласованного scope и не подтверждает AEB/Euro NCAP результат одной платой. Эти обязанности остаются у назначенных system, software, safety, vehicle и approval owners.
Для точной оценки отправьте schematic, fabrication/assembly files, stack-up или channel constraints, BOM/AVL, mechanical drawings, programming/calibration package, defect-to-test expectations, quantities, schedule и требуемые evidence. Чем яснее границы, тем меньше скрытых допущений в цене и сроке.
FAQ по обнаружению пешеходов и ADAS PCB
Существует ли специальная PCB для обнаружения пешеходов?
Нет универсального типа или сертификата с таким названием. Функция может использовать PCB в камере, радаре, sensor hub или ADAS ECU. Требования к плате определяются выбранными датчиками, interfaces, compute, power, installation zone, safety allocation и test plan. Способность изготовить плату не доказывает качество алгоритма распознавания.
Какие сценарии обязательно включить в DVP&R?
Минимум нужно разделить взрослых и детей, crossing/longitudinal/turning/reverse, near/far side, obstruction, day/night и ожидаемую реакцию. Проектный ODD добавляет погоду, загрязнение, glare, road geometry, unusual poses, sensor degradation и transition states. Euro NCAP полезен как базовая vehicle-level структура, но не заменяет полный project scenario catalogue.
Достаточно ли одной камеры для обнаружения пешеходов?
Иногда camera-only архитектура соответствует целевым требованиям, но это нельзя решить универсально. Нужно проверить освещение, blur, occlusion, contamination, range, false-positive policy, compute margin и degraded behavior. Если добавляется radar, thermal или LiDAR, требуется доказать, какую независимую информацию он дает и что происходит при отказе каждого канала.
Радар лучше камеры ночью и в плохую погоду?
Радар часто сохраняет полезные range/range-rate данные при части сложных условий видимости, но имеет собственные ограничения по angular resolution, classification, multipath, clutter, radome и interference. Камера дает богатую семантику, но зависит от изображения. Решение принимают по сценарию, installed performance и combined evidence, а не по общему лозунгу.
Как задать допустимую задержку системы?
Сначала определите измерительные точки: exposure, sensor output, ECU receive, inference, fusion, decision, network и actuator. Затем распределите end-to-end budget между этапами и задайте worst-case/percentile, timebase, operating states и degraded limits. PCB влияет на link, memory, clock, power и thermal timing, но не определяет всю задержку торможения.
CRC кадра достаточно для подтверждения качества данных?
Нет. CRC помогает обнаружить часть транспортных ошибок, но не показывает, что кадр свежий, правильно экспонирован, откалиброван и относится к нужному времени. Нужны frame counter, timestamp age, exposure/gain metadata, SerDes/link counters, memory/ECC state, dropped-frame detection, calibration ID и thermal/compute state.
Какой ASIL имеет плата обнаружения пешеходов?
Плате не присваивают ASIL только по названию применения. ASIL выводится из item definition и HARA, после чего safety requirements распределяются на system, hardware и software. PCB/PCBA реализует выделенные требования и предоставляет согласованное evidence; итоговую functional safety принимает владелец item/safety case.
Чем SOTIF отличается от hardware fault analysis?
Hardware fault analysis рассматривает неисправности элементов и их обнаружение/контроль. SOTIF рассматривает недостаточность предполагаемой функции или foreseeable misuse при исправной аппаратуре, например сложную видимость или неохваченный сценарий. Они встречаются в одной функции ADAS, но требуют разных analyses, datasets, tests и owners.
Подтверждает ли AEC-Q пригодность всей ADAS PCBA?
Нет. AEC-Q100 и AEC-Q200 относятся к квалификации соответствующих категорий компонентов. Они не квалифицируют PCB material, stack-up, solder joints, assembly process, ECU software, perception performance или автомобиль. Component qualification — один вход в более широкий design and validation plan.
Какие производственные тесты нужны ADAS ECU?
Набор зависит от design и defect universe. Обычно комбинируют SPI, AOI, X-ray для скрытых соединений, ICT или boundary scan, programming verification и FCT rails/clocks/interfaces/memory/diagnostics. Критично связать каждый failure mode с detection method и limit; список оборудования без coverage map недостаточен.
Можно ли заменить память, SerDes или PMIC без повторной валидации?
Только после impact assessment и одобрения владельца design. Замена может изменить timing, bandwidth, power sequence, thermal behavior, drivers, diagnostics или EMC. Нужно определить affected requirements и representative regression. Формальная совместимость корпуса и номиналов не доказывает эквивалентность perception system.
Чем vehicle test отличается от PCBA acceptance?
PCBA acceptance подтверждает fabrication/assembly, programming, electrical function и обнаруживаемые manufacturing defects. Vehicle test проверяет installed sensors, perception, network, driver warning/braking и end-to-end response в сценарии. Оба уровня обязательны для своего scope; успешный vehicle demo не заменяет process evidence, а успешный FCT не доказывает распознавание пешехода.
Что закупкам сравнивать кроме цены платы?
Сравнивайте material/stack-up assumptions, BOM channels и alternates, DFM/DFT, inspection/test coverage, fixture/NRE, programming/model/calibration scope, raw data, traceability, change control, EOL/NCNR, failure analysis, packaging и lead-time basis. Quotes должны использовать одну revision и одинаковые inclusions.
Какие файлы ускоряют точный RFQ?
Нужны system/PCB boundary, schematic, fabrication data, stack-up или high-speed constraints, BOM/AVL, assembly/mechanical files, firmware/model/calibration manifest, test and diagnostic requirements, acceptance limits, evidence list, EVT/DVT/PVT quantities и schedule. Открытые вопросы лучше перечислить явно, чтобы поставщик вернул assumptions до PO.
Публичные нормативные ориентиры
- Euro NCAP AEB/LSS VRU Systems Test Protocol v4.5.1: vehicle-level сценарии для пешеходов, велосипедистов и мотоциклистов, включая crossing, obstruction, longitudinal, turning, reverse и lighting configurations.
- Euro NCAP Vulnerable Road User Protection: рамка оценки защиты и активного предотвращения/смягчения столкновений с VRU.
- ISO 26262: functional safety дорожных транспортных средств; применимость частей и требований определяется item, safety lifecycle и allocation.
- ISO 21448: safety of the intended functionality; используется для анализа недостаточности функции и foreseeable misuse, а не как сертификат PCB.
- AEC-Q100 и AEC-Q200: квалификационные требования для соответствующих категорий автомобильных компонентов; не квалификация готовой PCB/PCBA или автомобиля.
Перед release проверьте актуальные редакции, OEM requirements, национальные правила, installation profile, rating protocol и согласованный DVP&R. Перечень ориентиров определяет области проверки, но не является декларацией соответствия конкретного изделия.