บอร์ด IoT อุตสาหกรรม (เกตเวย์ โหนดเซ็นเซอร์ คอนโทรลเลอร์เอดจ์) มักจะยังไม่ถือว่าเสร็จสมบูรณ์เมื่อบัดกรีชิ้นส่วนชิ้นสุดท้ายแล้ว ตัวบอร์ดจะกลายเป็นผลิตภัณฑ์ก็ต่อเมื่อมีการโหลดเฟิร์มแวร์ และขั้นตอนนั้นมักเป็นจุดที่อ่อนแอที่สุดในห่วงโซ่การตรวจสอบย้อนกลับ บทความนี้กล่าวถึงวิธีที่การติดตามโดยใช้ MES สามารถทำให้การโปรแกรมเฟิร์มแวร์กลายเป็นขั้นตอนของกระบวนการที่มีการบันทึกและตรวจสอบได้ แทนที่จะเป็นขั้นตอนที่ไม่เป็นทางการ
เหตุใดการควบคุมเวอร์ชันเฟิร์มแวร์จึงล้มเหลวบนสายการผลิต
ในการประกอบแบบปริมาณน้อยและความหลากหลายสูงอาจมีการสร้างแผงวงจรดีไซน์เดียวกันหลายครั้งภายในหนึ่งปี แต่ละครั้งอาจใช้เฟิร์มแวร์เวอร์ชันต่างกัน และคำสั่งซื้อเดียวอาจถูกแบ่งออกเป็นหลายรูปแบบการปรับเทียบหรือการกำหนดค่า โหมดความล้มเหลวที่พบบ่อยได้แก่:
มีเฟิร์มแวร์หลายเวอร์ชันผสมกันในล็อตเดียวการเปลี่ยนแปลงทางวิศวกรรมมีการปรับจาก v1.4 เป็น v1.5 ในระหว่างการสั่งซื้อ และบอร์ดที่ถูกโปรแกรมก่อนและหลังการเปลี่ยนแปลงไม่ได้ถูกแยกออกจากกัน
ไฟล์รูปภาพที่ล้าสมัยผู้ปฏิบัติงานโหลดไฟล์โปรแกรมจากโฟลเดอร์ภายในเครื่องซึ่งไม่เคยได้รับการอัปเดต
ความพยายามในการลองใหม่ที่ไม่ได้ถูกบันทึกบอร์ดล้มเหลวในการโปรแกรมสองครั้ง ผ่านในการลองครั้งที่สาม และไม่มีสิ่งใดในบันทึกที่แสดงให้เห็นถึงเรื่องนี้
ไม่มีความเชื่อมโยงระหว่างบอร์ดทางกายภาพกับการออกเฟิร์มแวร์รุ่นใดรุ่นหนึ่งหลายสัปดาห์ต่อมา ไม่มีใครสามารถบอกได้ว่าหน่วยภาคสนามได้รับภาพใด
ผลลัพธ์ปรากฏให้เห็นในภาคสนาม มีบอร์ดสองแผ่นที่ดูเหมือนกันทุกประการแต่มีพฤติกรรมต่างกัน: แผ่นหนึ่งรายงานข้อมูลเซนเซอร์ในช่วงเวลาที่ต่างออกไป อีกแผ่นจัดการกับการหมดเวลาในการสื่อสารแตกต่างกัน และความขัดข้องที่เกี่ยวกับเฟิร์มแวร์ก็ยากจะแยกออกจากความขัดข้องของฮาร์ดแวร์ หากไม่มีบันทึกแยกตามแต่ละบอร์ด การสืบหาสาเหตุจะกลายเป็นการตั้งข้อสงสัยกว้างไปทั่วทั้งล็อต
การผูกเวอร์ชันเฟิร์มแวร์เข้ากับหมายเลขซีเรียลบอร์ดในระบบ MES
ฐานคือรหัประบุเฉพาะบนบอร์ดแต่ละแผ่น ในMES อัจฉริยะพร้อมการตรวจสอบย้อนกลับด้วย UID และการมาร์คด้วยเลเซอร์แต่ละ PCBA จะได้รับ UID ที่มีการมาร์กด้วยเลเซอร์ ซึ่งกลายเป็นคีย์ที่ระเบียนในภายหลังทุกรายการจะเชื่อมโยงถึง สำหรับเฟิร์มแวร์ ระเบียน MES ควรเชื่อมโยงสิ่งต่อไปนี้เข้าด้วยกัน:
UID/SN ของบอร์ด(คีย์หลัก)
ตัวระบุอิมเมจเฟิร์มแวร์(ชื่อไฟล์ สตริงเวอร์ชัน และโดยหลักแล้ว ควรมีค่าเช็คซัมของอิมเมจที่ปล่อยออกมา)
การประทับเวลาการเขียนโปรแกรม
ID สถานีโปรแกรม
ผลลัพธ์:จำนวนผ่าน ล้มเหลว และลองใหม่
ตัวระบุผู้ปฏิบัติงานหรือกระบวนการผลิต
การเลือกออกแบบที่มีประโยชน์มากที่สุดคือการควบคุมสูตรแทนที่ให้พนักงานปฏิบัติงานเป็นผู้เลือกไฟล์ ใบสั่งงานจะระบุเฟิร์มแวร์เวอร์ชันที่ได้รับอนุมัติไว้เป็นพารามิเตอร์ที่ถูกควบคุม สถานีจะโหลดตามที่ใบสั่งงานระบุ และ MES จะบันทึกว่ามีการโหลดอะไรจริง เมื่อทั้งสองอย่างไม่ตรงกัน บอร์ดจะถูกตั้งสถานะเป็นผิดปกติแทนที่จะปล่อยผ่านไปอย่างเงียบ ๆ ส่วนจะบังคับใช้เป็นอินเตอร์ล็อกแบบแข็งหรือเพียงบันทึกเป็นข้อยกเว้นนั้น เป็นการตัดสินใจในระดับโครงการ
ค่าเช็กซัมมีความสำคัญมากกว่าป้ายเวอร์ชัน สตริงเวอร์ชันถูกพิมพ์โดยมนุษย์ ในขณะที่ค่าเช็กซัมถูกคำนวณจากไฟล์ ดังนั้นจึงสามารถยืนยันได้ว่าภาพที่อยู่ในสายส่งตรงกับภาพที่ลูกค้าได้ปล่อยออกมา
บันทึกการลองซ้ำและความล้มเหลว ไม่ใช่แค่ความสำเร็จ
การใช้เพียงแฟล็กผ่าน/ไม่ผ่านจะซ่อนข้อมูลเกี่ยวกับกระบวนการ การบันทึกจำนวนครั้งที่พยายามใหม่จะแยกแยะสามสถานการณ์ที่ดูเหมือนเหมือนกันในรายงานผลผลิตออกจากกันได้
ความสำเร็จในการทำครั้งแรกปกติ
ส่งผ่านหลังจากลองใหม่อีกครั้งอาจเป็นการเชื่อมต่อที่ไม่สมบูรณ์ ปัญหาสัมผัสของขั้วต่อ หรือปัญหากับรางจ่ายไฟที่ควรตรวจสอบอีกครั้ง
ล้มเหลวหลังจากลองซ้ำตามจำนวนที่อนุญาตแล้วมีการจัดประชุมเพื่อการวินิจฉัย ไม่ใช่เพื่อแก้ไขงานอย่างสะเปะสะปะ
บอร์ดที่ต้องพยายามโปรแกรมหลายครั้งจึงจะสำเร็จถือเป็นสัญญาณ มันอาจบ่งชี้ถึงปัญหาการสัมผัสที่อินเทอร์เฟซการโปรแกรม ปัญหารอยบัดกรีใกล้ขาพินสำหรับการโปรแกรม หรือปัญหาด้านแหล่งจ่ายไฟบนบอร์ด การบันทึกปัญหานี้ไว้จะทำให้วิศวกรมีข้อมูลสำหรับวิเคราะห์ก่อนที่บอร์ดจะไปถึงมือลูกค้า
การเชื่อมโยงข้อมูลการโปรแกรมเข้ากับการทดสอบการทำงาน (FCT)
การเขียนโปรแกรมและการทดสอบการทำงานควรอ่านจากบันทึกบอร์ดเดียวกัน เมื่อสถานี FCT สแกน UID ระบบ MES สามารถยืนยันได้ว่า:
คณะกรรมการมีประวัติการเขียนโปรแกรมที่ประสบความสำเร็จ, และ
เวอร์ชันเฟิร์มแวร์ที่บันทึกไว้ตรงตามข้อกำหนดในใบสั่งงาน.
หากการตรวจสอบอย่างใดอย่างหนึ่งล้มเหลว บอร์ดจะไม่ดำเนินการต่อไป ซึ่งช่วยป้องกันช่องโหว่ที่พบบ่อยซึ่งบอร์ดที่ยังไม่ได้โปรแกรมหรือโปรแกรมผิด ถูกทดสอบกับเงื่อนไขที่ไม่ถูกต้อง หรือข้ามขั้นตอนบางอย่างไปอย่างสิ้นเชิง
การแยกแบตช์เมื่ออัตราความล้มเหลวของการเขียนโปรแกรมเบี่ยงเบน
ข้อมูลการเขียนโปรแกรมยังทำงานเป็นเครื่องมือตรวจสอบกระบวนการด้วย กรอบการทำงานสำหรับตอบสนองต่ออัตราความล้มเหลวที่ผิดปกติ:
กำหนดค่าพื้นฐานสำหรับผลิตภัณฑ์จากรุ่นเริ่มต้น ร่วมกับลูกค้า
ตั้งค่าทริกเกอร์การรีวิวเช่น การเพิ่มขึ้นของความล้มเหลวในการลองครั้งแรกหรือการลองใหม่ภายในช่วงเวลาที่กำหนด
เก็บรักษาวัสดุที่ได้รับผลกระทบโดยใช้ UID และเวลาเช็กอินของสถานี ระบุว่าแผงวงจรใดผ่านสถานี ช่วงเวลา หรือล็อตของชิ้นส่วนที่มีปัญหา และกักกันเฉพาะแผงวงจรเหล่านั้นแทนที่จะกักกันทั้งคำสั่งซื้อทั้งหมด
ตรวจสอบโดยใช้การหาความสัมพันธ์เปรียบเทียบบอร์ดที่ไม่ผ่านกับบันทึกของสถานี ฟิกซ์เจอร์ การผ่านเตารีโฟลว์ หรือบันทึกกระบวนการบัดกรี และข้อมูลล็อตของคอมโพเนนต์.
ตัวอย่างเชิงอธิบาย (สมมุติ)สมมติว่าจำนวนครั้งที่ต้องลองใหม่เพิ่มขึ้นสำหรับบอร์ดที่ถูกโปรแกรมบนสถานีใดสถานีหนึ่งหลังจากมีการเปลี่ยนอุปกรณ์ยึดเนื้องาน เนื่องจากแต่ละระเบียนมีรหัสสถานีและการประทับเวลา บอร์ดที่ได้รับผลกระทบจึงสามารถถูกแยกออกมาและตรวจสอบอุปกรณ์ยึดเนื้องานได้ โดยไม่ต้องกักบอร์ดที่ถูกโปรแกรมจากสถานีอื่น ตัวเลขไม่ใช่ประเด็นสำคัญ ประเด็นคือความสามารถในการกำหนดขอบเขตของการกักบอร์ด
เมื่อมีการเชื่อมโยงระเบียนกระบวนการต้นน้ำ เช่น3D SPIและ3D AOIผลลัพธ์หรือการตรวจสอบด้วยเอ็กซเรย์สำหรับโพรงอากาศใน BGA/QFNกลุ่มความล้มเหลวของการเขียนโปรแกรมสามารถนำมาตรวจสอบไขว้กับข้อมูลเหล่านั้น เพื่อแยกแยะสาเหตุที่เกี่ยวข้องกับการบัดกรีออกจากสาเหตุที่มาจากเฟิร์มแวร์หรือเครื่องมือได้ ทั้งนี้ขึ้นอยู่กับว่าบันทึกเหล่านั้นถูกผูกกับ UID เดียวกันภายในการกำหนดค่า MES ของโครงการหรือไม่
ลูกค้าจะใช้บันทึกเหล่านี้อย่างไรในการตรวจสอบเฟิร์มแวร์ภาคสนาม
การตรวจสอบย้อนกลับให้ผลตอบแทนหลังการจัดส่ง ด้วยบันทึกต่อ UID ลูกค้าสามารถ:
ยืนยันลำดับสายวิวัฒนาการของเฟิร์มแวร์ของหน่วยภาคสนามเมื่อระบุหมายเลขประจำเครื่องแล้ว ให้ตรวจสอบว่าโหลดรูปภาพและเวอร์ชันใดที่โรงงานและเมื่อใด
กำหนดขอบเขตปัญหาที่เกี่ยวข้องกับเฟิร์มแวร์หากพบข้อบกพร่องในรุ่นที่ระบุ ให้ระบุหมายเลขซีเรียลใดที่จัดส่งมาพร้อมกับรุ่นนั้นและหมายเลขใดที่ไม่ได้จัดส่ง แทนการเรียกคืนหรือแฟลชใหม่ทั้งผลิตภัณฑ์ทั้งหมด
กระทบยอดกับข้อมูลอุปกรณ์ที่ปรับใช้งานแล้วเปรียบเทียบเวอร์ชันที่บันทึกจากโรงงานกับเวอร์ชันที่รายงานโดยอุปกรณ์ที่ใช้งานอยู่ หากไม่ตรงกันแสดงว่าอาจมีการอัปเดตภาคสนามหรือมีความคลาดเคลื่อนจากฝั่งโรงงานที่ควรสืบสวน
สนับสนุนงานเอกสารภายในและเอกสารตามข้อกำหนดของหน่วยงานกำกับดูแลลูกค้าในอุตสาหกรรมและลูกค้าที่ใช้ผลิตภัณฑ์เชื่อมต่อเครือข่ายมีความจำเป็นมากขึ้นเรื่อย ๆ ที่ต้องแสดงให้เห็นถึงการควบคุมที่มีต่อที่มาของซอฟต์แวร์และเฟิร์มแวร์ กรอบมาตรฐานอย่างเช่น IPC-1782 (การตรวจสอบย้อนกลับสำหรับผลิตภัณฑ์อิเล็กทรอนิกส์) ได้ให้โครงสร้างอ้างอิงว่าสถิติหรือระเบียนการผลิตควรจัดเก็บข้อมูลใดบ้าง
ข้อจำกัดในการตีความ: สิ่งเหล่านี้คือบันทึกการผลิตที่สร้างขึ้นโดยการควบคุมกระบวนการพวกมันใช้สำหรับบันทึกว่าโหลดอะไรและเมื่อใด พวกมันไม่สามารถใช้ทดแทนการจัดการเผยแพร่เฟิร์มแวร์หรือการตรวจสอบความปลอดภัยของลูกค้าเองได้
ช่องติดตามความสามารถในการตรวจสอบย้อนกลับของการเขียนเฟิร์มแวร์ที่แนะนำ
ใช้รายการนี้เป็นจุดเริ่มต้นเมื่อกำหนดความต้องการสำหรับโครงการ
การระบุคณะกรรมการและคำสั่งซื้อหมายเลข UID/ซีเรียลของบอร์ด หมายเลขชิ้นส่วนและรุ่นของ PCBA ใบสั่งงานหรือหมายเลขล็อต
กิจกรรมเฟิร์มแวร์และการเขียนโปรแกรมชื่อไฟล์อิมเมจเฟิร์มแวร์ สตริงเวอร์ชัน ตรวจสอบหรือแฮชของอิมเมจ เวอร์ชันบูตโหลดเดอร์และตัวระบุไฟล์การตั้งค่า/พารามิเตอร์ (หากโหลดแยกต่างหาก) วันที่และเวลาในการโปรแกรม รหัสสถานีและรหัสฟิกซ์เจอร์ ตัวระบุเครื่องมือหรือตัวเชื่อมต่อที่ใช้โปรแกรม ผลลัพธ์ (ผ่าน/ไม่ผ่าน) จำนวนความพยายาม และรหัสหรือข้อความความล้มเหลว (หากมีการบันทึก)
การเชื่อมโยงและการควบคุมการเปลี่ยนแปลงผลการตรวจสอบการจับคู่เวอร์ชัน (เวอร์ชันที่โหลดเทียบกับข้อกำหนดในใบสั่งงาน), ผลการทดสอบการทำงานและเวลาแสตมป์, ลิงก์ไปยังบันทึกการตรวจสอบต้นทาง (SPI/AOI, X-Ray) หากมี, การตัดสินใจจัดการสำหรับบอร์ดที่ถูกกักหรือผ่านการซ่อมแซม, อ้างอิงการอนุมัติการปล่อยรูปภาพโดยลูกค้า และอ้างอิงการควบคุมการเปลี่ยนแปลงเมื่อเวอร์ชันเฟิร์มแวร์มีการเปลี่ยนแปลงระหว่างการผลิตในใบสั่งงานเดียวกัน
ขั้นตอนถัดไป: ขอการประเมินข้อกำหนดการตรวจสอบย้อนกลับ
หากบอร์ด IoT ของคุณถูกโปรแกรมระหว่างการประกอบ คำถามในทางปฏิบัติคือ ระบบการควบคุมคุณภาพและกระบวนการสนับสนุนภาคสนามของคุณต้องการใช้ฟิลด์ใดในบรรดาฟิลด์เหล่านี้จริงๆส่งโปรเจกต์ของคุณ(BOM, ไฟล์แอสเซมบลี, กระบวนการปล่อยเฟิร์มแวร์ และข้อกำหนดการตรวจสอบใด ๆ) ไปยัง PCBCart เพื่อประเมินข้อกำหนดด้านการตรวจสอบย้อนกลับ ทีมวิศวกรรมของเราจะตรวจสอบว่าการเขียนโปรแกรม การทดสอบ และบันทึก MES สามารถกำหนดค่าให้สอดคล้องกับผลิตภัณฑ์ของคุณได้อย่างไร และยืนยันสิ่งที่สามารถรองรับได้ก่อนเริ่มการผลิต
แหล่งข้อมูลที่เป็นประโยชน์
•การติดตามวงจรชีวิตบอร์ดอินเทอร์เฟซ ATE ด้วยระบบ MES: ประวัติรอบการทดสอบและการซ่อมแซม
•การตรวจสอบย้อนกลับตั้งแต่ซิลิกอนจนถึงระบบ: การใช้งาน MES ในการผลิตด้านวิทยาศาสตร์ชีวภาพ
•ยุทธศาสตร์การเคลือบป้องกันสำหรับบอร์ดเกตเวย์ IoT อุตสาหกรรมในสภาพแวดล้อมที่รุนแรง
•การตรวจสอบฟองอากาศ BGA ด้วยเอกซเรย์สำหรับโมดูลกำลังในอุตสาหกรรม
