PCB 조립 프로젝트에서 프로토타입 검증 속도를 저하시키는 요인은 무엇입니까?

소개

많은 OEM 팀은 프로토타입 보드가 도착하면 검증이 빠르게 진행될 것이라고 가정합니다.

그것은 합리적인 것 같습니다. 실제 프로젝트에서는 그렇지 않은 경우가 많습니다.

프로토타입 PCB 어셈블리가 일정대로 돌아오더라도 팀이 빌드가 무엇을 증명해야 하는지, BOM에서 변경된 사항 또는 테스트 경로가 사용 가능한 답변을 생성할 준비가 되었는지 여부에 대해 여전히 논쟁을 벌이고 있는 경우 검증에 며칠 또는 심지어 일주일이 걸릴 수 있습니다. 그 시점에서 둔화는 더 이상 조립 리드 타임만의 문제가 아닙니다. 릴리스, 테스트 및 핸드오프 문제가 됩니다.

이것이 이 글의 진짜 질문입니다. 문제는 프로토타입을 얼마나 빨리 제작할 수 있는지 뿐만이 아닙니다. 문제는 보드가 이미 벤치에 놓인 후에도 검증이 여전히 지연되는 이유입니다.

팀이 이미 베어{0}}보드 타이밍을 지나 프로토타입 진행이 여전히 느리게 느껴지는 이유를 이해하려고 노력하고 있다면, 어셈블리만 넘어서 전체 경로를 검토해야 합니다.PCB 조립.

프로토타입 납품과 프로토타입 검증은 동일한 이정표가 아닙니다.

여기서 많은 일정이 잘못 읽혀집니다.

프로토타입 배송은 보드가 제작, 조립 및 수령되었음을 의미합니다. 프로토타입 검증은 팀이 실제로 해당 보드를 사용하여 의도된 기술적 질문에 답하고 다음에 일어날 일을 결정했음을 의미합니다.

그것들은 같은 이정표가 아닙니다.

보드가 제 시간에 도착했지만 여전히 프로젝트를 진행하지 못할 수 있습니다. 전원이 켜질 수 있지만 여전히 중요한 테스트 경로를 지원하지 않습니다. 올바르게 조립될 수 있지만 여전히 대체, 프로그래밍 가정, 인터페이스 동작 또는 실제로 벤치에 있는 개정판에 대해 의구심을 불러일으킵니다. 때로는 하드웨어가 전혀 문제가 되지 않는 경우도 있습니다. 팀은 패스로 간주되는 요소, 허용 가능한 편차로 간주되는 요소, 또 다른 회전을 유발해야 하는 요소에 대해 단순히 동의하지 않습니다.

그렇기 때문에 프로토타입 검증은 배송 전이 아니라 배송 후에 진행되는 경우가 많습니다.

보드는 실제로 검증되기 전에도 구축 가능할 수 있습니다.

일반적으로 확인 속도를 늦추는 요인

팀이 '보드 수신'을 이미 '결정-준비된 하드웨어'를 의미하는 것처럼 처리하면 프로토타입 검증 속도가 느려지는 경향이 있습니다.

일반적으로 그렇지 않습니다.

약한 데이터 핸드오프

일부 프로토타입 빌드는 보드를 제조하는 데 충분한 정보가 포함되어 출시되지만 이를 명확하게 검증할 수 있는 정보는 충분하지 않습니다.

거버(Gerber)와 BOM이 존재할 수 있습니다. 종종 약한 것은 프로그래밍 노트, 조립 의도, 승인된 대체품, 펌웨어 가정, 극성 설명, 통과 기준 및 이 스핀이 실제로 해결해야 할 것이 무엇인지 팀에 알려주는 검증 논리 등 주변의 모든 것입니다.

그러면 즉시 마찰이 발생합니다.

보드가 도착했지만 이를 검증하려는 사람들은 여전히 설명이 필요합니다. 그러면 모든 예상치 못한 행동은 또 다른 해석으로 변합니다. 집회소가 느리다고 해서 프로젝트가 막힌 것은 아니다. 빌드 패키지가 출시될 만큼 완료되었지만 빠른 학습을 지원할 만큼 완료되지 않았기 때문에 차단되었습니다.

늦은 DFM 결과

일부 프로토타입 검증 지연은 전기적 고장으로 인해 발생하지 않습니다. 이는 설계가 이미 너무 멀리 나아간 후에야 명백해지는 제조 가능성 문제로 인해 발생합니다.

설치 공간 불일치, 약한 테스트 지점 액세스-, 피할 수 있는 열 문제 또는 어셈블리 지향 레이아웃 선택으로 인해 보드 제작이 중단되지 않을 수 있습니다. 간헐적인 동작, 납땜 불일치 또는 프로빙의 어려움으로 인해 실제 설계 문제가 모호해지기 시작하면 여전히 검증 속도가 심하게 느려질 수 있습니다.

이것이 프로토타입 작업에서 늦은 DFM 문제에 비용이 많이 드는 이유입니다. 그들은 단지 다음 회전을 지연시키지 않습니다. 또한 현재 스핀의 학습 가치도 감소합니다.

가용성-에 따른 대체

프로토타입 빌드는 파일럿 로트보다 더 많은 소싱 유연성을 견딜 수 있습니다. 그것은 정상입니다.

문제는 대체 부품을 빠르게 선택했지만 검증 논리에 명확하게 적용되지 않을 때 시작됩니다. 그 시점에서 팀은 더 이상 하나의 명확한 가정을 테스트하지 않습니다. 디자인과 소싱 해결 방법을 테스트하고 있습니다.

이러한 구별은 많은 팀이 기대하는 것보다 더 중요합니다.

핀-호환 대체 장치는 시작 동작, 열 응답, 타이밍 마진 또는 신호 특성을 변화시켜 문제를 복잡하게 만들 수 있습니다.- 그러면 팀이 답변하려고 계획한 것과 다른 질문에 답변하려고 하기 때문에 확인 속도가 느려집니다. 프로젝트는 디버깅 연습의 일부, 재{4}}인증 연습의 일부가 됩니다.

빌드 준비보다 뒤처진 테스트 준비

이는 가장 일반적인 숨겨진 병목 현상 중 하나입니다.

실제 검증 경로가 전혀 준비되지 않은 상태에서 보드가 제 시간에 조립될 수 있습니다. 프로그래밍 파일이 계속 이동 중일 수 있습니다. 벤치 설정은 여전히 비공식적일 수 있습니다. 설비가 아직 존재하지 않을 수 있습니다. 기능적 기대는 여전히 모호할 수 있습니다. 통과/실패 논리조차도 빠른 결정을 지원하기에는 너무 느슨할 수 있습니다.

이러한 경우 PCB 조립이 프로젝트 속도를 늦추는 것은 아닙니다. 빌드 완료와 사용 가능한 테스트 실행 사이에는 격차가 있습니다.

AOI-완전한 프로토타입은 자동으로 검증 준비가 된 프로토타입이-아닙니다.

수동 프로빙이 병목 현상을 일으키기 시작합니다.

일부 초기 보드에는 수동 프로빙이 적합합니다.

많은 팀이 예상하는 것보다 훨씬 빠르게 드래그됩니다.

보드의 밀도가 높아지거나 액세스가 더 나빠지거나 단위 수가 소수의 샘플을 넘어 증가하면 수동 검증이 각 보드를 자체적인 소규모 조사로 전환하기 시작합니다. 팀은 여전히 답변을 얻을 수 있지만 더 느리게, 더 많은 반복 확인을 통해, 그리고 누가 프로브를 쥐고 있는지에 대한 의존도가 높아져 답변을 얻을 수 있습니다.

그렇기 때문에 프로토타입 단계에서도 단순한 개발 장치, 더 나은 프로브 액세스 또는 더 구조화된 불러오기 경로가{0}}중요할 수 있습니다. 목표는 전체 생산 장치를 너무 일찍 구축하는 것이 아닙니다. 목표는 피할 수 있는 물리적 접근 문제로 인해 확인 시간을 낭비하지 않는 것입니다.

하나의 빌드가 너무 많은 질문에 답하려고 합니다.

일부 프로토타입 로트는 빌드 범위가 너무 광범위하기 때문에 느리게 진행됩니다.

보드는 하드웨어 기능, 소프트웨어 동작, 전력 안정성, 신호 무결성, 열, 제조 가능성, 현장 동작은 물론 초기 규정 준수 가정까지 한꺼번에 검증할 것으로 예상됩니다. 이론적으로는 효율적으로 들립니다. 실제로 이는 공개 질문 중 어느 것도 깨끗하게 종료되지 않음을 의미합니다.

집중된 프로토타입은 일반적으로 모든 것을 한 번에 해결하려는 빌드보다 빠르게 검증됩니다.

프로토타입 작업에서는 가장 느린 물리적 단계뿐만 아니라 가장 느린 해결되지 않은 질문으로 일정이 진행되는 경우가 많습니다.

OEM 팀이 일반적으로 문제를 잘못 판단하는 경우

가장 흔한 실수는 지연이 여전히 제조에 속한다고 가정하는 것입니다.

때로는 그렇습니다. 종종 그렇지 않습니다.

보드가 이미 벤치에 배치되면 실제 병목 현상은 일반적으로 검증 논리, 개정 제어, 소싱 명확성 및 테스트 순서로 이동합니다. 프로젝트가 여전히 느리게 느껴지지만 빌드가 출시되기 전에 느렸던 것과 같은 이유로 더 이상 느리지 않습니다.

팀은 종종 잘못된 문제에 반응하기 때문에 이러한 구별이 중요합니다. 실제로 필요한 것이 더 엄격한 검증 목표, 더 깔끔한 개정 기준 또는 단순히 더 많은 논의를 생성하는 대신 실제로 결정을 지원할 수 있는 테스트 경로일 때 더 빠른 다음 빌드 빌드를 추진합니다.

팀이 정확히 무엇을 증명해야 했는지에 대해 여전히 논쟁을 벌이고 있다면 이사회는 일정대로 돌아와서 검증하는 데 일주일을 잃을 수 있습니다.

유용한 경계 사례

작은 프로토타입 로트가 자동으로 검증이 빨라야 함을 의미하지는 않습니다.

10-보드 빌드는 각 장치에 해결되지 않은 소싱 변경 사항, 불분명한 테스트 의도 및 혼합된 개정 가정이 있는 경우 천천히 확인할 수 있습니다. 펌웨어 기준이 동시에 이동하고 검증 계획이 충분히 좁혀지지 않은 경우 5{2}}보드 스핀이 지연될 수도 있습니다.

반면, BOM이 더 명확하고, 질문이 더 좁으며, -가져오기 경로가 이미 구조화되어 있으면 다소 큰 로트가 더 빨리 검증될 수 있습니다.

그렇기 때문에 보드 수만으로는 검증 속도를 제대로 예측할 수 없습니다.

검증이 더 빠르게 진행되는 데 도움이 되는 것

프로토타입 검증 시간을 단축하는 것이 목표라면 일반적으로 다음 빌드가 시작되기 전에 가장 큰 개선이 이루어집니다.

검증 질문을 더 일찍 잠그세요

프로토타입은 팀이 이 스핀이 무엇을 증명해야 하는지, 무엇을 증명하지 말아야 하는지를 알 때 더 빠르게 검증됩니다.

소싱 변경 사항을 지속적으로 표시

가용성-에 따른 대체 항목이 사용된 경우 빌드 기록에 명확해야 하며 검증 중에 논의하기 쉬워야 합니다. 숨겨진 소싱 변경으로 인해 학습 속도가 느려집니다.

데이터 패키지를 테스트 경로에 맞춰 정렬

BOM 개정, 어셈블리 출력, 펌웨어 버전, 프로그래밍 가정,{0}}업데이트 체크리스트는 모두 동일한 의도된 기준을 가리켜야 합니다.

보드가 도착하기 전에 테스트 경로를 준비하세요.

프로그래밍, 벤치 설정, 통과 기준 및 간단한 고정 작업은 어셈블리가 이미 준비될 때까지 기다려서는 안 됩니다.

DFM 및 테스트 액세스를 검증 준비 문제로 처리

테스트 액세스가 좋지 않거나 제조 가능성 위험이 여전히 해결되지 않은 경우 보드가 아무리 빨리 구축되더라도 검증이 깨끗하게 유지되는 경우는 거의 없습니다.

관점에서 생각해보면 바로 이것이다.테스트 및 검사프로토타입 단계에서도 유용해집니다.

이것이 현재 환경에서 더 중요한 이유

현재 소싱 환경에서는 가용성-에 따른 대체가 더 일반적이며 리드타임 완화는 카테고리별로 균일하지 않습니다.- 이로 인해 재료 변경 사항이 검증 계획에 명확하게 반영되지 않을 때마다 프로토타입 검증 속도가 느려집니다. 보드는 여전히 정시에 도착할 수 있습니다. 학습 경로는 그렇지 않은 경우가 많습니다.

이것이 바로 프로토타입 검증이 단지 조립 리드 타임의 최종 단계가 아닌 자체 엔지니어링 및 조정 단계로 처리되어야 하는 또 다른 이유입니다.

결론

PCB 조립 프로젝트의 프로토타입 검증은 보드 제작 속도뿐만 아니라 보드 도착 후 발생하는 상황으로 인해 속도가 느려지는 경우가 많습니다.

가장 일반적인 원인은 취약한 데이터 핸드오프, 늦은 DFM 결과, 가용성-에 따른 대체, 열악한 테스트 준비, 수동 조사 마찰, 개정 드리프트, 한 번의 스핀으로 명확하게 답변하기에는 너무 광범위한 검증 목표 등입니다.

이것이 모두 제조상의 문제는 아닙니다. 그 중 다수는 순수한 제조 문제이기 이전에 릴리스, 테스트 및 핸드오프 문제입니다.

이것이 바로 팀이 "프로토타입 전달"을 "검증된 프로토타입"을 의미하는 것처럼 취급하는 것을 중단해야 하는 이유입니다.

벤치 위의 보드만으로는 일정이 단축되지 않습니다. 사용 가능한 확인 경로가 있습니다.

팀이 프로토타입 검증을 단축하려는 경우 실용적인 다음 단계는 빌드를 검토하는 것입니다.PCB 조립,올바른 수준으로 검증 경로를 강화하세요.테스트 및 검사생각하고 다음 프로토타입 범위를 정렬합니다.견적 요청또는 다음 주소로 팀에 직접 문의하세요.info@pcba-china.com.