вступ
Багато команд OEM припускають, що після надходження прототипів плат перевірка пройде швидко.
Це звучить розумно. У реальних проектах це часто не так.
Прототип збірки друкованої плати може повернутися за розкладом і все одно втратити дні або навіть тиждень на перевірку, якщо команда все ще сперечається про те, що збірка мала довести, що змінилося в BOM або чи готовий тестовий шлях дати придатну відповідь. На цьому етапі уповільнення більше не пов’язане лише з часом складання. Це стає проблемою випуску, тестування та передачі.
Це справжнє питання, яке стоїть за цією статтею. Питання полягає не лише в тому, наскільки швидко можна створити прототип. Питання полягає в тому, чому перевірка все ще зупиняється після того, як дошки вже знаходяться на лаві підсудних.
Якщо ваша команда вже вийшла за рамки-часу «голої дошки» й зараз намагається зрозуміти, чому прогрес прототипу все ще виглядає повільно, це те, що потрібно подивитися не лише на складання й переглянути повний шляхЗбірка друкованої плати.
Доставка прототипу та перевірка прототипу – це не одне й те саме
Саме тут багато розкладів тлумачаться неправильно.
Доставка прототипу означає, що плати виготовлено, зібрано та отримано. Перевірка прототипу означає, що команда фактично використовувала ці дошки, щоб відповісти на передбачуване технічне запитання та вирішити, що буде далі.
Це не та сама віха.
Комісія може прибути вчасно і все одно не просунути проект вперед. Він може ввімкнутися, але все ще не підтримувати тестовий шлях, який має значення. Він може бути зібраний правильно, але все одно викликає сумніви щодо замінників, програмних припущень, поведінки інтерфейсу або того, яка версія справді є на лавці. Іноді проблема зовсім не в апаратному забезпеченні. Команда просто не погоджується щодо того, що вважається пропуском, що вважається прийнятним відхиленням, а що має спровокувати повторне обертання.
Ось чому перевірка прототипу часто проскакує після доставки, а не до неї.
Дошку можна побудувати до того, як її справді можна буде перевірити.
Що зазвичай уповільнює перевірку
Перевірка прототипу зазвичай сповільнюється, коли команда розглядає «отримані плати» так, ніби це вже означає «апаратне-готове рішення».
Зазвичай це не так.
Слабка передача даних
Деякі збірки прототипів випускаються з достатньою інформацією для виготовлення плати, але недостатньою для її перевірки.
Гербери та BOM можуть бути присутніми. Часто слабшим є все, що їх оточує: нотатки щодо програмування, наміри складання, затверджені альтернативи, припущення щодо вбудованого програмного забезпечення, виноски щодо полярності, критерії проходження та логіка перевірки, яка повідомляє команді, що насправді має вирішити ця обертання.
Це негайно створює тертя.
Дошки надходять, але люди, які намагаються перевірити їх, усе ще потребують роз’яснень. Тоді кожна несподівана поведінка перетворюється на черговий раунд інтерпретації. Проект не заблоковано через повільну роботу монтажного цеху. Його заблоковано, оскільки пакет збірки достатньо повний для випуску, але недостатньо повний для підтримки швидкого навчання.
Пізні знахідки DFM
Деякі затримки верифікації прототипу не спричинені несправністю електрики. Вони викликані проблемами технологічності, які стають очевидними лише після того, як дизайн вже просунувся занадто далеко.
Невідповідність габаритів, слабкий доступ до тестової-точки, термічна проблема, якої можна уникнути, або вибір макета,-орієнтованого на збірку, можуть не зупинити створення плати. Це все одно може сильно уповільнювати перевірку, коли переривчаста поведінка, неузгодженість пайки або труднощі зондування починають закривати справжнє питання про дизайн.
Ось чому пізні випуски DFM дорогі в роботі прототипу. Вони не просто відкладають наступне обертання. Вони також зменшують цінність навчання поточного обертання.
Доступність{0}}замін
Збірка прототипу може терпіти більшу гнучкість пошуку, ніж пілотна партія. Це нормально.
Проблеми починаються, коли замінні частини вибираються швидко, але не враховуються чітко в логіці перевірки. На цьому етапі команда більше не перевіряє одне чисте припущення. Він тестує дизайн і обхідний шлях пошуку.
Ця відмінність має більше значення, ніж очікують багато команд.
Альтернативний-сумісний контакт може змінити поведінку запуску, теплову реакцію, часові запаси або характеристики сигналу настільки, щоб ускладнити-запуск. Потім перевірка сповільнюється, оскільки команда намагається відповісти на інше запитання, ніж вона планувала. Проект частково стає вправою з усунення помилок, частково вправою з пере-перекваліфікації.
Тест готовності, що відстає від готовності збірки
Це одне з найпоширеніших прихованих вузьких місць.
Плата може бути зібрана вчасно, а сам шлях перевірки ще не готовий. Файли програмування можуть усе ще переміщуватися. Установка лавки все ще може бути неофіційною. Світильників може ще не бути. Функціональні очікування все ще можуть бути розпливчастими. Навіть логіка «пройшов/не пройшов» може бути занадто слабкою для підтримки швидких рішень.
У цих випадках збірка друкованої плати не сповільнила проект. Розрив знаходиться між завершенням збірки та придатним для використання виконанням тесту.
Повний-прототип AOI не є автоматично-готовим прототипом для перевірки.
Ручне зондування починає ставати вузьким місцем
Ручне зондування підходить для деяких дуже ранніх плат.
Це стає перешкодою набагато швидше, ніж очікують багато команд.
Коли дошка стає щільнішою, доступ стає гіршим або кількість одиниць перевищує кілька зразків, ручна перевірка починає перетворювати кожну дошку на окреме маленьке дослідження. Команда все ще може отримувати відповіді, але вона отримує їх повільніше, з більшою кількістю повторних перевірок і з більшою залежністю від того, хто тримає зонд.
Ось чому прості інструменти розробки, кращий доступ до зонда або більш структурований шлях-виведення можуть мати значення навіть на етапах прототипу. Мета полягає не в тому, щоб побудувати повноцінне виробниче обладнання занадто рано. Мета полягає в тому, щоб припинити витрачати час перевірки на проблеми фізичного доступу, яких можна уникнути.
Одна збірка намагається відповісти на забагато питань
Деякі партії прототипів просуваються повільно, тому що обсяг збірки просто занадто широкий.
Очікується, що плата одночасно перевірить роботу апаратного забезпечення, поведінку програмного забезпечення, стабільність живлення, цілісність сигналу, термічні характеристики, технологічність, поведінку в робочих умовах і, можливо, навіть перші припущення щодо відповідності. Теоретично це звучить ефективно. На практиці це означає, що жодне з відкритих питань не закривається чітко.
Цілеспрямований прототип зазвичай перевіряється швидше, ніж збірка, яка намагається вирішити все за один прохід.
У роботі над прототипом графік часто рухається з найповільнішим невирішеним питанням, а не лише з найповільнішим фізичним кроком.
Де команди OEM зазвичай неправильно оцінюють проблему
Найпоширенішою помилкою є припущення, що затримка все ще належить виробництву.
Іноді це так. Часто це не так.
Коли плати вже готові, справжнє вузьке місце зазвичай зміщується в логіку перевірки, контроль версій, ясність джерела та послідовність тестування. Проект все ще здається повільним, але він більше не повільний з тієї ж причини, з якої був повільним до випуску збірки.
Ця відмінність має значення, тому що команди часто реагують не на ту проблему. Вони наполягають на швидшій-комплектації наступного ходу, коли їм справді потрібна точніша мета перевірки, точніша базова лінія перегляду або тестовий шлях, який може фактично підтримувати рішення, а не просто викликати додаткові обговорення.
Правління може повернутися за розкладом і все одно втратити тиждень на перевірку, якщо команда все ще сперечається про те, що саме вона мала довести.
Корисний граничний випадок
Невелика партія прототипу не означає автоматично, що перевірка має бути швидкою.
Десять -збірок плат все ще може перевірятися повільно, якщо кожен блок несе невирішені зміни джерела, нечіткі наміри тестування та змішані припущення версії. Обертання п’яти-плат також може затягнути, якщо базова лінія мікропрограми рухається одночасно, а план перевірки ніколи не був достатньо звужений.
З іншого боку, дещо більший лот може перевірятися швидше, якщо специфікація є чистішою, питання вужчим і шлях-доведення вже структурований.
Ось чому сама лише кількість дощок є поганим прогнозом швидкості верифікації.
Що допомагає перевірці рухатися швидше
Якщо мета полягає в тому, щоб скоротити перевірку прототипу, найбільші покращення зазвичай вносяться до початку наступної збірки.
Заблокуйте питання перевірки раніше
Прототип перевіряється швидше, коли команда знає, що це обертання має довести, і що не менш важливо, що воно не повинно доводити.
Тримайте видимими зміни джерел
Якщо використовувалися-заміни, керовані доступністю, вони мають бути очевидними в записі збірки та легкими для обговорення під час перевірки. Приховані зміни джерел сповільнюють навчання.
Вирівняйте пакет даних із тестовим шляхом
Ревізія специфікації, результати складання, версія мікропрограми, програмні припущення та контрольний-перелік перевірки мають вказувати на ту саму заплановану базову лінію.
Підготуйте тестовий шлях до того, як дошки прибудуть
Програмування, налаштування стенда, критерії проходження та будь-яка проста робота з пристосуваннями не повинні чекати, поки збірки вже будуть у руках.
Розглядайте DFM і тестовий доступ як проблеми готовності до перевірки
Якщо тестовий доступ поганий або ризики технологічності все ще не вирішені, перевірка рідко залишатиметься чистою, незалежно від того, наскільки швидко були створені плати.
Це саме те, де мислиться в термінахТестування та перевіркастає корисним навіть на стадії прототипу.
Чому це важливіше в нинішніх умовах
У поточному середовищі постачальників більш поширеними є-заміни, пов’язані з доступністю, а-залишок часу нерівномірний для різних категорій. Це сповільнює перевірку прототипу щоразу, коли суттєві зміни не відображаються чітко в плані перевірки. Дошка ще може прибути вчасно. Шлях навчання часто цього не робить.
Це ще одна причина, чому перевірку прототипу слід розглядати як власну стадію проектування та координації, а не лише як кінцеву частину процесу складання.
Висновок
Перевірка прототипу в проектах складання друкованих плат часто сповільнюється тим, що відбувається після надходження плат, а не тільки тим, як швидко вони були виготовлені.
Найпоширенішими причинами є слабка передача даних, пізні висновки DFM, доступність-підстановок, низька готовність до тестування, тертя ручного зондування, відхилення при перегляді та цілі перевірки, які є надто широкими, щоб отримати однозначну відповідь.
Це не всі виробничі проблеми. Багато з них є проблемами випуску, тестування та передачі, перш ніж вони є чисто виробничими проблемами.
Ось чому команди повинні припинити розглядати «доставлений прототип» як «перевірений прототип».
Самі по собі дошки на лавці не скорочують графік. Користний шлях перевірки робить.
Якщо ваша команда намагається скоротити перевірку прототипу, практичним наступним кроком є перевірка збірки на відповідністьдрукована плата,збільшити шлях перевірки з правильним рівнемТестування та перевіркамислення, а потім вирівняйте наступний прототипЗапит на цінуабо зв’яжіться з командою безпосередньо за адресоюinfo@pcba-china.com.
Поширені запитання
Яка різниця між доставкою прототипу та перевіркою прототипу?
Доставка прототипу означає, що плати зібрано та отримано. Перевірка прототипу означає, що команда використала ці дошки, щоб відповісти на передбачуване технічне запитання та вирішити, що буде далі.
Чому прототип плати може бути доставлений вчасно, але все ще повільно перевіряється?
Оскільки уповільнення часто зміщується від виробництва до логіки перевірки, чіткості специфікації, невизначеності-деталей заміни, готовності до тестування, контролю переглядів і перехресного-функціонального узгодження.
Чи швидше складання прототипу автоматично означає швидшу перевірку?
Ні. Швидше складання допомагає, лише якщо шлях перевірки вже достатньо зрозумілий для ефективного використання попереднього обладнання.
Яка одна з найбільш забутих причин затримки підтвердження?
Поширеною причиною, яку не враховують, є те, що пакет збірки був достатньо повним для випуску, але недостатньо повним для його перевірки після надходження плат.
