ในโรงงานที่ไทย มีการติดตั้งเซนเซอร์เพิ่มแล้ว หน้าจอแสดงอุณหภูมิและแรงดันได้ตามปกติ แต่พอถึงการตรวจสอบคุณภาพ กลับถูกถามว่า “ช่วยอธิบายช่วง 30 นาทีที่ค่าขาดหายไประหว่างการให้ความร้อนของล็อตนี้หน่อย” แล้วไม่มีใครตอบได้ ในการทำมาตรการป้องกันข้อมูลเซนเซอร์ขาดหาย สิ่งที่ชี้ขาดไม่ใช่แค่ว่าสื่อสารได้หรือไม่ แต่คือ นับบันทึกที่คาดว่าจะต้องมีได้หรือไม่ ระบุสาเหตุที่ขาดหายได้หรือไม่ และตรวจสอบบันทึกหลังการกู้คืนได้หรือไม่ บทความนี้จะไม่โฟกัสที่ชนิดของเซนเซอร์หรือเส้นทางดึงค่าจาก PLC แต่จะโฟกัสที่สเปกความต้องการตอนสั่งซื้อและการทดสอบรับมอบในโรงงาน
ก่อนเขียน “ห้ามขาดหายแม้แต่รายการเดียว” ลงในสัญญา ต้องกำหนดก่อนว่าอะไรคือสิ่งที่ขาดหาย
อุปกรณ์ที่เก็บค่าอุณหภูมิทุก 1 วินาที กับอุปกรณ์ที่ส่งแจ้งเฉพาะตอนค่ามีการเปลี่ยนแปลง ไม่ควรถูกประเมินด้วยมาตรฐานเดียวกันว่า “1 วินาทีได้ 1 รายการ” สำหรับแบบแรก ถ้าไม่มีบันทึกในช่วงเวลาที่ควรมีระหว่างการผลิต ก็ถือเป็นผู้ต้องสงสัยว่าเกิดการขาดหาย สำหรับแบบหลัง ช่วงที่ค่าไม่เปลี่ยนแล้วไม่มีบันทึกถือว่าปกติ จึงต้องใช้การสังเกตแบบอื่น เช่น ลำดับเลขของข้อความ สถานะเซสชันการสื่อสาร หรือการตรวจสอบสัญญาณมีชีวิตเป็นระยะ การประเมินแบบละเลยวิธีวัด แล้วสรุปว่า “ยิ่งรับได้เยอะยิ่งดี” จะทำให้ระบบที่ส่งซ้ำข้อมูลได้คะแนนดีกว่าที่ควร
เริ่มจากการเขียนลงทะเบียนข้อมูลว่า “ข้อมูลแต่ละชุดควรมีเมื่อไรและควรมีจำนวนเท่าไร” เป็นบันทึกหลัก: แบบคาบคงที่, แบบเมื่อมีการเปลี่ยนแปลง, แบบตามเหตุการณ์ของเครื่องจักร, หรือแบบกรอกมือ จะนับช่วงหยุดเครื่องออกจากตัวหารหรือไม่ จะให้เวลาเริ่มเดินเครื่อง ล้างไลน์ หรือเปลี่ยนรุ่นสินค้าเป็นคนละหมวดหรือไม่ จะตัดสินการขาดหายแบบทันทีในจังหวะเฝ้าดูแบบเรียลไทม์ หรือจะรอข้อมูลมาช้าแล้วค่อยปิดสถานะเป็นข้อยุติ สิ่งเหล่านี้ไม่ใช่แค่ค่าตั้งต้นของระบบ แต่เป็นเงื่อนไขทางธุรกิจที่ฝ่ายคุณภาพและหน้างานต้องตกลงร่วมกัน
ตัวอย่างเช่น ถ้ากำหนดว่า “ระหว่างเดินเครื่องให้อ่านอุณหภูมิทุก 10 วินาที” หนึ่งชั่วโมงควรมี 360 รายการ ถ้าระบบรับได้เพียง 342 รายการ ความครบถ้วนแบบรายงานทันทีคือ 342÷360＝95% อย่างไรก็ตาม 18 รายการอาจยังค้างอยู่ที่อุปกรณ์เอจและอาจมาถึงครบภายหลัง ถ้าบันทึกแยก “ความครบถ้วน ณ เวลารายงาน” ออกจาก “ความครบถ้วน ณ เวลาสรุป” จะไม่สับสนระหว่างการสื่อสารขาดตอนกับการสูญหายถาวร ตัวเลขนี้เป็นเพียงตัวอย่างเพื่ออธิบาย ไม่ใช่ค่าเกณฑ์ผ่านสำหรับทุกโรงงาน
แยกจุดที่ข้อมูลเซนเซอร์หายออกเป็น 6 ขั้นตอน
ถึงแม้เส้นทางจากเซนเซอร์ถึงแดชบอร์ดจะดูเหมือนทางเดียว แต่จริง ๆ แล้วมีจุดเสียหลายจุด ได้แก่ วัดไม่สำเร็จ, PLC หรือเครื่องบันทึกวัดได้แต่เกตเวย์อ่านตก, เกตเวย์รับแล้วแต่เขียนลงบัฟเฟอร์ไม่ได้, มีในบัฟเฟอร์แต่ส่งออกไม่ได้, ส่งแล้วแต่ฝั่งรับปฏิเสธ, บันทึกไว้แล้วแต่ไม่แสดงบนหน้ารวมผล ขั้นสุดท้ายถ้าข้อมูลดิบมีอยู่จริง ก็ไม่ใช่การขาดหายของข้อมูล แต่เป็นปัญหาการแสดงผลหรือการค้นหา ถ้านำทุกขั้นตอนมารวมเป็น “อัตราขาดหาย” เดียว จะไม่รู้ว่าควรให้ใครแก้ไข
บันทึกหนึ่งรายการอย่างน้อยต้องมี ID สำหรับระบุอุปกรณ์/แท็ก ค่าและหน่วย เวลาในการวัด เวลาในการรับ สถานะคุณภาพ และคีย์สำหรับระบุเหตุการณ์ต้นทาง ถ้าอุปกรณ์สามารถออกเลขลำดับได้ก็ควรบันทึกไว้ เพื่อใช้ตัดสินซ้ำซ้อนเมื่อมีการส่งซ้ำเข้ามาพร้อมเลขเดิม สำหรับอุปกรณ์ที่ไม่สามารถออกเลขลำดับได้ ก็ไม่ได้แปลว่าการใช้แค่ Source ID กับเวลาที่วัดจะรับประกันความเป็นเอกลักษณ์ได้เสมอ เพราะภายในหนึ่งคาบอาจมีหลายเหตุการณ์เกิดขึ้น คีย์ที่เหมาะสมต้องตัดสินจากสเปกของอุปกรณ์และชนิดข้อมูลเป้าหมาย
DataValue ของ OPC UA นอกจากค่าข้อมูลแล้ว ยังรองรับ StatusCode และเวลา และเมื่อมีการทิ้งการแจ้งเตือนจากคิวของรายการที่เฝ้าดู ตามเงื่อนไขก็มีสเปกให้แจ้งผ่าน Overflow bit ดังนั้นฝั่งรับไม่ควรเก็บแค่ค่าแล้วทิ้งข้อมูลคุณภาพ อย่างไรก็ดี การไม่มี Overflow ไม่ได้พิสูจน์ว่าตั้งแต่เซนเซอร์ถึงที่เก็บสุดท้ายไม่มีข้อมูลหาย เพราะยังมีจุดเสียอื่นทั้งก่อนและหลังคิวเฝ้าดูอยู่ตามเส้นทาง จึงควรเก็บตัวนับและบันทึกเหตุการณ์แต่ละขอบเขตเพื่อจำกัดตำแหน่งปัญหา เอกสาร OPC UA DataValue และสเปกคิวของ MonitoredItem คือจุดเริ่มต้นของการตรวจสอบนี้
วัดความครบถ้วนของข้อมูล ความหน่วง และคุณภาพแยกกัน
ในการประเมินราคามาตรการป้องกันข้อมูลหาย การมีเพียงบรรทัดเดียวว่า “ความพร้อมใช้งาน 99.9%” ยังตัดสินไม่ได้ อัตราการทำงานของอุปกรณ์ ความเชื่อมต่อของเครือข่าย และความครบถ้วนของบันทึกเทียบกับช่วงเวลาที่คาดหวัง เป็นคนละเรื่องกัน ฝั่งผู้สั่งซื้อควรกำหนด 4 ค่า ต่อหนึ่งแท็กดังนี้
- ความครบถ้วนชั่วคราว: จำนวนบันทึกที่ถูกต้องและไม่ซ้ำที่มาถึงภายในเส้นตายการสังเกต ÷ จำนวนที่คาดว่าจะมี ใช้ดูว่านำไปใช้ในหน้าหน้างานได้ทันทีหรือไม่
- ความครบถ้วนขั้นสุดท้าย: จำนวนบันทึกที่ถูกต้องและไม่ซ้ำที่ตรวจสอบได้หลังช่วงผ่อนผันการกู้คืน ÷ จำนวนที่คาดว่าจะมี ใช้ดูว่านำไปใช้เป็นหลักฐานคุณภาพและการตรวจสอบได้หรือไม่
- ความหน่วงขาเข้า: เวลาในการรับ − เวลาในการวัด ควรดูทั้งค่ากลางและด้านหางของการกระจาย ไม่ใช่ดูแค่มัธยฐาน เพื่อเช็กว่าทันต่อการแจ้งเตือนหรือการตัดสินใจหรือไม่
- อัตราคุณภาพ: จำนวนแยกตาม Good, Uncertain, Bad, Estimated, และแก้ไขด้วยมือ ใช้ดูว่าแม้มีตัวเลขแล้ว จะเชื่อถือได้แค่ไหน
ถ้ากำหนด “บันทึกที่ถูกต้องและไม่ซ้ำ” ไม่ชัดเจน ค่า Bad หรือข้อมูลที่ส่งซ้ำแบบซ้ำกันอาจถูกนับรวมในตัวเศษได้ ข้อมูลที่เติมช่องว่างของช่วงขาดหายด้วยการประมาณมีประโยชน์ต่อการวิเคราะห์ แต่ไม่ควรถูกแปลงให้กลายเป็นค่าที่วัดจริง ต้องเก็บข้อมูลดิบ ค่าประมาณ และค่าที่แก้ด้วยมือแยกกัน พร้อมแฟลกคุณภาพและประวัติการตรวจสอบ ระบบ Historian เองก็เก็บค่าข้อมูล คุณภาพ และเวลาเป็นชุด และจำนวนรายการที่เก็บขึ้นอยู่กับโหมดการบันทึกหรือ deadband แม้บนหน้าจอเส้นกราฟจะต่อเนื่อง แต่ไม่ได้แปลว่าบันทึกดิบมีอยู่ทุกช่วงเวลา เอกสาร คำอธิบาย Tag Historian ของ Ignition ช่วยทำให้ความแตกต่างนี้ชัดเจน
ตัวอย่างการคำนวณ: ถ้าทำงาน 8 ชั่วโมงด้วยคาบ 10 วินาที จำนวนที่คาดไว้คือ 2,880 รายการ เมื่อถึงเส้นตายมีข้อมูลเข้ามา 2,840 รายการ ในจำนวนนั้น 10 รายการเป็นรายการซ้ำ และ 5 รายการมีคุณภาพ Bad ถ้าสัญญาไม่นับ Bad จำนวนรายการที่ใช้ได้คือ 2,825 รายการ และความครบถ้วนชั่วคราวประมาณ 98.09% ถ้าต่อมามีข้อมูลเข้ามาอีก 40 รายการ และในนั้น 6 รายการเป็นการส่งซ้ำของเหตุการณ์เดิม จำนวนที่เพิ่มจริงคือ 34 รายการ จำนวนรายการที่ใช้ได้ขั้นสุดท้ายคือ 2,859 รายการ คิดเป็นความครบถ้วนขั้นสุดท้ายประมาณ 99.27% จะนำตัวเลขไหนไปใช้ในสัญญาก็ต้องตัดสินตามการใช้งานต่างกัน เช่น บันทึกประกันคุณภาพกับการวิเคราะห์แนวโน้มพลังงาน อาจไม่ยอมรับเงื่อนไขเดียวกัน
ออกแบบเวลาให้แยก “เวลาที่วัด” กับ “เวลาที่มาถึง”
ถ้าต้องการเรียงข้อมูลที่มาช้าให้ถูกต้อง ต้องเก็บทั้งเวลาในการวัดและเวลาในการรับ ถ้าเกตเวย์รู้แค่ว่าอ่านจากเซนเซอร์ตอนไหน ก็อย่าอ้างว่าเป็นเวลาในการวัด ให้ระบุชัดว่าเป็น “เวลาเกตเวย์สังเกต” แทน แหล่งที่มาของนาฬิกา วิธีซิงก์ โซนเวลา ค่าความคลาดเคลื่อนที่ยอมรับได้ และวิธีจัดการเมื่อซิงก์ล้มเหลว ควรถูกใส่ไว้ในทะเบียนแท็ก หากโรงงานในไทยและสำนักงานใหญ่ญี่ปุ่นดูหน้าจอร่วมกัน ควรแปลงเวลาที่เก็บให้เป็นมาตรฐานเดียว เช่น UTC แล้วค่อยแสดงผลตามเวลาท้องถิ่นของแต่ละพื้นที่ จะช่วยเทียบกันได้ง่ายขึ้น แต่ก่อนจะบังคับเปลี่ยนเวลาของอุปกรณ์เดิม ต้องตรวจผลกระทบกับฝั่งควบคุมก่อน
ถ้า timestamp มีความละเอียดแค่ 1 วินาที ก็ไม่สามารถถกกันเรื่องลำดับก่อนหลังของเหตุการณ์ที่ห่างกัน 100 มิลลิวินาทีได้ ในทางกลับกัน ระบบเฝ้าระวังอุณหภูมิที่ใช้แค่ระดับวินาที อาจไม่จำเป็นต้องลงทุนโครงสร้างส่งเวลาแพง ๆ แบบไม่เลือกใช้ กำหนดความละเอียดที่ต้องการจากคำถามในกระบวนการ เช่น “ตรวจสอบลำดับก่อนหลังของการหยุดฉุกเฉิน”, “พิสูจน์เวลาคงอุณหภูมิในกระบวนการฆ่าเชื้อ”, “เชื่อมค่าตรวจสอบเข้ากับล็อตสินค้า” แต่ละกรณีต้องการข้อมูลเวลาและความหน่วงที่รับได้ต่างกัน การออกแบบซิงก์เวลาโดยตรงเป็นอีกหัวข้อหนึ่ง แต่บทความนี้จะนำที่มาของเวลาไปผูกกับการตัดสินข้อมูลหายและการทดสอบรับมอบ
เมื่อบันทึกมาถึงปลายทางช้ากว่าปกติ สิ่งสำคัญคือห้ามเขียนเวลาในการวัดเดิมทิ้งไป เวลาที่ส่งซ้ำสำเร็จต้องคงอยู่ในช่องเวลาในการรับ ถ้าโครงสร้างทำให้ตามได้ว่า “วัดตอน 14:00 ถึงตอน 14:37” ก็จะยังถือว่าเป็นบันทึกของกระบวนการช่วง 14:00 น. ได้ พร้อมกันนั้นก็อธิบายข้อเท็จจริงได้ด้วยว่าในช่วง 37 นาทีดังกล่าวยังไม่อยู่บนหน้าจอรายงานเร็ว การใช้แค่ส่วนต่างของสองเวลาอย่างเดียวไม่พอแยก clock drift ออกจากความหน่วงสื่อสาร จึงต้องมีการบันทึกสถานะการซิงก์ด้วย
ออกแบบบัฟเฟอร์เอจให้ครบถึงขั้นแผนกู้คืน ไม่ใช่แค่ความจุ
เมื่อเห็นข้อเสนอที่เขียนว่า “แม้เน็ตหลุดก็ยังบันทึกได้” ควรถามให้ครบว่าบันทึกที่ไหน นานกี่ชั่วโมง กี่รายการ เรียงตามลำดับใด และถ้าดิสก์เต็มจะทิ้งอะไร บัฟเฟอร์ที่มีแต่หน่วยความจำชั่วคราวอาจหายเมื่อรีสตาร์ต ถ้าเก็บลงดิสก์ก็ยังต้องพิจารณาเรื่องความจุ อายุการเขียน สิทธิ์เข้าถึง การเข้ารหัส วิธีคืนค่าข้อมูลเมื่อเสียหาย และพฤติกรรมตอนดับไฟ การส่งแท็กที่มีลำดับความสำคัญก่อนจะทำให้แท็กความสำคัญต่ำล่าช้าออกไป จึงต้องระบุลำดับความสำคัญด้วย
รูปแบบประเมินความจุขั้นต่ำคือ “ขนาดบันทึกเฉลี่ย × จำนวนรายการต่อวินาที × เวลาที่ต้องเก็บ” เช่น ถ้า 1 รายการมีขนาด 200 ไบต์ มี 50 รายการต่อวินาที และต้องเก็บ 24 ชั่วโมง จะใช้พื้นที่ดิบ 864MB แต่ในการใช้งานจริงยังมีดัชนี รูปแบบไฟล์ journal พื้นที่สำรอง และข้อมูลใหม่ที่เข้ามาระหว่างกู้คืนเพิ่มเติม ดังนั้นห้ามนำตัวเลขนี้ไปเป็นความจุจริงของดิสก์ตรง ๆ ต้องปรับประมาณจากปริมาณเขียนจริงและแบนด์วิดท์การกู้คืน แม้จะเก็บได้ครบ 24 ชั่วโมง แต่ถ้าระบายออกได้ด้วยความเร็วเท่ากับอัตราเข้าปกติเท่านั้น ความค้างก็จะไม่หาย ควรคำนวณเวลาที่จะตามทันด้วยกำลังประมวลผลสุทธิหลังหักอัตราข้อมูลไหลเข้าปกติออกจากแบนด์วิดท์กู้คืน
เอกสารของ AWS IoT Greengrass Stream Manager มีการตั้งค่าการคงอยู่ของสตรีม ขนาดหรือระยะเวลาการเก็บ และพฤติกรรมเมื่อขาดการเชื่อมต่อ เป็นต้น นี่เป็นตัวอย่างของความสามารถที่มีในผลิตภัณฑ์ แต่ไม่ได้แปลว่าใช้ที่ไหนก็จะกู้คืนครบทุกรายการโดยอัตโนมัติ ต้องทดสอบทั้งค่าตั้งต้น สตรีมเป้าหมาย ความสามารถในการรับของปลายทาง และความเสียหายของอุปกรณ์เอจด้วย สามารถใช้อ้างอิงจากเอกสาร Stream Manager ของ AWS ในตารางเปรียบเทียบได้
ตอนส่งซ้ำ ต้องแยก “อย่างน้อยหนึ่งครั้ง” ออกจาก “ไม่ซ้ำ”
เมื่อเครือข่ายเชื่อมต่อกลับมา ฝั่งส่งมักจะส่งข้อมูลเดิมซ้ำ ซึ่งเป็นพฤติกรรมปกติ ถ้าฝั่งรับยังไม่ส่งคำตอบหลังบันทึกสำเร็จ แต่การสื่อสารตัดไป ฝั่งส่งจะไม่รู้ว่าข้อมูลนั้นถูกบันทึกแล้วหรือไม่ จึงส่งซ้ำ ดังนั้น ต่อให้เรียกวิธีส่งว่า “exactly once” ก็ยังไม่อาจยืนยันได้ว่าตั้งแต่การวัดของเซนเซอร์จนถึงตารางวิเคราะห์สุดท้ายไม่มีข้อมูลซ้ำ ต้องกำหนดให้ชัดว่า ณ ขอบเขตไหนจะส่ง acknowledgment กลับมา จะถือว่าอะไรเป็นเหตุการณ์เดียวกันด้วยคีย์ใด และจะจัดการอย่างไรเมื่อการส่งซ้ำมาถึงสลับลำดับ
การกำจัดข้อมูลซ้ำควรให้ความสำคัญกับ Event ID และเวอร์ชัน ถ้าเป็นคีย์เดียวกันและเนื้อหาเดียวกันก็ไม่นับซ้ำ ถ้าเป็นคีย์เดียวกันแต่ค่าต่างกัน ห้ามเขียนทับเงียบ ๆ แต่ให้แยกเป็นข้อขัดแย้งและแจ้งผู้รับผิดชอบ ถ้ารองรับการแก้ไข ให้เก็บค่าเดิม ค่าแก้ไข เหตุผล ผู้ดำเนินการ และเวลาไว้ในประวัติด้วย รวมถึงต้องกำหนดวิธีคำนวณใหม่ของผลสรุปตามช่วงเวลา เพราะถ้าค่ามาช้าหลังเส้นตาย ค่าเฉลี่ย ค่าสูงสุด หรือจำนวนครั้งที่เบี่ยงเบนอาจเปลี่ยนได้
ถ้าเซนเซอร์ไม่ออก Event ID ต้องตรวจว่าที่อ่านค่ามา เกตเวย์สามารถออกเลขลำดับถาวรให้ได้หรือไม่ ถ้ารีสตาร์ตแล้วเลขกลับไปเริ่มที่ 1 ต้องจับคู่กับ ID การบูตหรืออย่างอื่นด้วย ถ้าใช้แค่ค่าเซนเซอร์กับเวลาเป็นคีย์ อาจเข้าใจผิดว่าค่าที่เหมือนกันต่อเนื่องเป็นข้อมูลซ้ำ ทั้งที่จริงเป็นการวัดปกติที่เกิดขึ้นหลายรอบ เรื่องนี้ไม่ควรจบด้วยประโยคสั้น ๆ ในสเปกซอฟต์แวร์ แต่ควรทำเป็นกรณีทดสอบจากข้อมูลตัวอย่างในขั้นรับมอบ
เขียน RFP ด้วย “สัญญาข้อมูล” ก่อนชื่อผลิตภัณฑ์
ในเอกสารขอเสนอราคา (RFP) ถ้าเขียนแค่ว่า “ต้องการติดตั้งแพลตฟอร์ม IoT” ผู้เสนอแต่ละรายจะตีความบนสมมติฐานต่างกัน ควรส่งร่างทะเบียนแท็ก สถานการณ์ความเสียหาย สูตรตัดสิน และขอบเขตรับผิดชอบให้เป็นฐานเปรียบเทียบ เริ่มจากจำกัดขอบเขตไว้ที่ 1 ไลน์และไม่กี่แท็ก แล้วแนบรายการต่อไปนี้เป็นตาราง
- ขอบเขตและการใช้งาน: ฝั่งผู้สั่งซื้อระบุ ID เครื่องจักร แท็ก หน่วย กระบวนการ การเชื่อมกับล็อต และใครใช้ข้อมูลเพื่ออะไร ฝั่งผู้เสนอระบุขอบเขตที่รองรับได้และสิ่งที่ต้องแก้ไขเพิ่ม
- เหตุการณ์ที่คาดหวัง: ฝั่งผู้สั่งซื้อระบุว่าเป็นคาบคงที่หรือเมื่อมีการเปลี่ยนแปลง ปฏิทินการเดินเครื่อง และวิธีคำนวณจำนวนที่คาดไว้ ฝั่งผู้เสนอระบุวิธีเก็บจริงและข้อจำกัด
- เวลาและคุณภาพ: ฝั่งผู้สั่งซื้อระบุแหล่งกำเนิดเวลา การซิงก์ Bad/Uncertain และการจัดการกับค่าประมาณ/แก้มือ ฝั่งผู้เสนอระบุรายการที่เก็บและเส้นทางการส่งต่อ
- ความเสียหายและการกู้คืน: ฝั่งผู้สั่งซื้อระบุเวลาที่คาดว่าจะเจอ เช่น เน็ตหลุด รีสตาร์ต ดิสก์เต็ม ปลายทางหยุด ฝั่งผู้เสนอระบุความจุบัฟเฟอร์ ลำดับการทิ้ง และเวลาที่จะตามทัน
- เกณฑ์รับมอบ: ฝั่งผู้สั่งซื้อระบุเงื่อนไขความครบถ้วนชั่วคราว/ขั้นสุดท้าย ความหน่วง ข้อมูลซ้ำ และบันทึกตรวจสอบ ฝั่งผู้เสนอระบุขั้นตอน FAT/SAT และรูปแบบหลักฐาน
- ความรับผิดชอบการปฏิบัติการ: ฝั่งผู้สั่งซื้อระบุผู้รับแจ้งเตือน เส้นตายการแก้ไข และผู้อนุมัติการเปลี่ยนแปลง ฝั่งผู้เสนอระบุรายการเฝ้าระวัง ขอบเขตบำรุงรักษา และค่าใช้จ่าย
ก่อนเก็บข้อเสนอ ควรตกลงกันให้ชัดว่า “จำนวนที่คาดหวัง” จะนับเทียบกับอะไร เช่น ถ้าใช้ตัวหาร 24 ชั่วโมงรวมช่วงหยุดกลางคืน กับตัวหารเฉพาะช่วงเดินเครื่อง 8 ชั่วโมง ระบบเดียวกันก็จะดูเหมือนมีความครบถ้วนต่างกัน ถ้าปล่อยให้ผู้ขายกำหนดเอง จะเทียบตัวเลขกันไม่ได้ ควรใส่สูตรตัดสินพร้อมตัวอย่างคำนวณในภาคผนวก เพื่อให้ฝั่งปฏิบัติทำผลซ้ำได้เหมือนกัน
การประเมินราคาควรแบ่งไม่ใช่แค่เซนเซอร์ เดินสาย เกตเวย์ สื่อสาร จัดเก็บ แดชบอร์ด และบำรุงรักษา แต่ต้องให้ระบุชั่วโมงที่ใช้กับการทดสอบความผิดพลาดและการจัดทำสัญญาข้อมูลด้วย เพราะถ้าตัดส่วนหลังออก ข้อเสนอที่ราคาถูกอาจกลายเป็นความเสี่ยงที่ภายหลังถูกอ้างว่า “การขาดหายอยู่นอกสเปก” หากต้องการจัดระเบียบเส้นทางเชื่อมต่อกับอุปกรณ์เดิมหรือประมาณจำนวนแท็กก่อน สามารถดูที่4 เส้นทางการเก็บข้อมูล PLC ส่วนเกณฑ์รับมอบในบทความนี้จะนำไปใช้หลังจากเลือกเส้นทางนั้นแล้ว
ใน FAT ต้องเก็บหลักฐานตอน “พัง” มากกว่าตอน “ปกติ”
สร้างข้อมูลแม่แบบการทดสอบก่อน
ก่อนเริ่ม FAT ควรล็อกข้อมูลอินพุตที่จะใช้ทดสอบในรูปแบบที่แก้ไขยาก เช่น CSV และบันทึกหมายเลขตั้งค่าของอุปกรณ์ทดสอบกับฐานเวลาให้เรียบร้อย เพราะการนับแค่ฝั่งรับไม่พอจะรู้ว่าฝั่งอินพุตเกิดตามแผนหรือไม่ ถ้าเป็นการทดสอบแบบคาบคงที่ ให้สร้างรายการช่องเวลาโดยแยกตาม ID เครื่องจักรและแท็ก ถ้าเป็นแบบแจ้งเมื่อมีการเปลี่ยนแปลง ให้สร้างลำดับการเปลี่ยนค่าและรายการเหตุการณ์ที่ต้องส่ง การเตรียมข้อมูลต้นฉบับของอินพุต บันทึกการรับของเอจ และการส่งออกจากปลายทางสุดท้ายให้เชื่อมด้วยคีย์เดียวกัน จะช่วยระบุตำแหน่งที่ข้อมูลหายได้ทีละขอบเขต
ถ้าระหว่างทดสอบมีคนสั่งงานด้วยมือ ต้องบันทึกการกระทำนั้นเป็นเหตุการณ์พร้อมเวลาเช่นกัน เพราะเวลาที่บอกว่า “ควรตัดการเชื่อมต่อแล้ว” กับเวลาที่อุปกรณ์เครือข่ายตัดจริงอาจไม่ตรงกัน ซึ่งจะทำให้การคำนวณจำนวนที่คาดไว้เปลี่ยนไป ถ้าทดสอบการขาดการซิงก์เวลา ไม่ควรเอานาฬิกาบนผนังมาเป็นตัวเทียบว่าถูกผิด แต่ให้ใช้เลขลำดับที่เพิ่มขึ้นอย่างเดียวจากเครื่องทดสอบเป็นแกนหลักในการเทียบจำนวน ถ้าจำเป็นต้องตีความเวลาใหม่หลังซ่อมแล้ว ต้องกำหนดกฎการปรับไว้ล่วงหน้า
การตัดสินผ่าน/ไม่ผ่านไม่ควรใช้คะแนนรวมเพียงก้อนเดียว ตัวอย่างเช่น “ตัดการเชื่อมต่อ 20 นาที แต่เหตุการณ์ดิบยังครบทุกรายการ และเปอร์เซนไทล์ที่ 95 ของความหน่วงหลังฟื้นตัวเกินข้อกำหนด” แบบนี้ความครบถ้วนถือว่าผ่าน แต่ความหน่วงไม่ผ่าน หรือกรณี “ข้อมูลมาครบทุกชิ้นแต่บางส่วนถูกนับซ้ำ” การส่งถือว่าผ่าน แต่การสรุปผลไม่ผ่าน ถ้าแยกการประเมินเป็นฟังก์ชัน ความครบถ้วน ความหน่วง คุณภาพ และการตรวจสอบเป็นคนละช่อง จะเห็นชัดว่าต้องแก้ตรงไหน
ใน FAT (Factory Acceptance Test) แค่มีกราฟขึ้นบนเดโมหน้าเว็บยังไม่ควรถูกนับว่าผ่าน ควรกำหนดค่าขาเข้าและเวลาให้ตายตัว แล้วตัดการสื่อสารของเกตเวย์ สร้างเหตุการณ์ตามจำนวนที่กำหนด จากนั้นหลังฟื้นตัวให้เทียบข้อมูลดิบกับข้อมูลที่บันทึกไว้ ตรวจให้ได้ว่ารายการที่หายจริงกับรายการที่มาช้าแล้วกู้คืน แยกจากกันได้ ถ้าเป็นไปได้ ให้ทำหลักฐาน 3 จุดพร้อมกัน คือ เครื่องมือจำลองอินพุตเซนเซอร์, บันทึกที่ทางเข้าเกตเวย์, และการส่งออกฝั่งรับ
ในใบรายงาน FAT ควรระบุ ID การทดสอบ, ค่าตั้งต้น, จำนวนอินพุต, เวลาเริ่ม/จบความเสียหาย, ผลที่คาดหวัง, จำนวนที่วัดได้จริง, จำนวนข้อมูลซ้ำ, สถานะคุณภาพ, การกระจายความหน่วง, ที่เก็บบันทึก และผู้ตัดสิน การเขียนว่า “ตัด 20 นาทีแล้วกราฟสุดท้ายต่อกันได้” หลักฐานยังอ่อนเกินไป ต้องแสดงให้ได้ว่าในช่องเวลาที่คาดหวัง 20 นาทีมีทั้งหมดกี่รายการ ในจำนวนนั้นมาถึงเมื่อไรบ้าง มีเท่าไรที่ถูกตัดออกเพราะซ้ำ และมีกี่รายการที่ไม่เคยมาถึงเลย
ความเสียหายที่ควรทดสอบอย่างน้อย ได้แก่ เน็ตเวิร์กชั้นบนหลุด, เซิร์ฟเวอร์รับหยุด, เกตเวย์รีสตาร์ต, บัฟเฟอร์ใกล้เต็ม, ซิงก์นาฬิกาล้มเหลว, อินพุตที่มีคุณภาพ Bad, การส่งซ้ำของเหตุการณ์เดียวกัน, และลำดับข้อมูลสลับกัน ถ้าโครงสร้างอุปกรณ์เอื้อ อาจเพิ่มคิว overflow ฝั่ง PLC, การเชื่อมต่อไร้สายที่ขาด ๆ หาย ๆ, และไฟตกชั่วขณะด้วย ระหว่างทดสอบห้ามกระทบการควบคุมจริง จึงควรแยกว่าช่วงไหนทดสอบในสภาพจำลองปลอดภัย และช่วงไหนทำในหน้างานได้
ใน SAT ต้องตรวจให้ครบทั้งเวลาในโรงงาน ไฟ และกะการทำงาน
เอกสารส่งมอบต้องเผื่อการเปลี่ยนหลังรับมอบ
ตอนส่งมอบ ควรทำรายการไม่ใช่แค่ค่าตั้งต้นสุดท้าย แต่รวมถึงว่าการตั้งค่าใดมีผลต่อการตัดสินข้อมูลหายบ้าง การเพิ่มแท็ก การเปลี่ยนคาบเก็บ การเปลี่ยนเซนเซอร์ การอัปเดตเฟิร์มแวร์ของเกตเวย์ การเปลี่ยนปลายทางส่งข้อมูล และการอัปเดตปฏิทินการเดินเครื่องของโรงงาน ล้วนเปลี่ยนจำนวนที่คาดไว้หรือเกณฑ์ความหน่วงได้ทั้งหมด ควรทำขั้นตอนปฏิบัติให้ชัดว่าใครต้องยื่นคำขอ ใครอนุมัติ และหลังเปลี่ยนแล้วต้องทดสอบอะไรซ้ำบ้าง เมื่อรูปแบบบันทึกตอน FAT เปลี่ยนไปเพราะอัปเดตซอฟต์แวร์ ต้องตรวจซ้ำว่าเครื่องมือจับคู่ข้อมูลและหลักฐานตรวจสอบยังใช้งานได้หรือไม่
การจัดการบันทึกที่ยังไม่ส่งออกในบัฟเฟอร์หลังสลับไปเครื่องสำรองก็สำคัญ ต้องกำหนดล่วงหน้าว่าดึงออกจากดิสก์ของเครื่องเสียได้หรือไม่ ถ้าไม่ได้จะยืนยันช่วงที่ขาดหายอย่างไร ถ้าเครื่องสำรองเริ่มส่งด้วย ID เครื่องจักรเดิม อาจชนกับเหตุการณ์ที่มาช้าจากเครื่องเก่าหรือเหตุการณ์ใหม่ ควรเก็บตัวระบุของอินสแตนซ์อุปกรณ์ วันเวลาที่เปลี่ยนเครื่อง และกฎการตัดข้อมูลซ้ำไว้ในเอกสารส่งมอบ ถ้าทดสอบถึงจุดนี้แล้ว จึงถือว่าเริ่มพร้อมย้ายจาก PoC ครั้งเดียวไปสู่การใช้งานต่อเนื่อง
SAT (Site Acceptance Test) ไม่พอถ้าทำซ้ำแค่ FAT ต้องรวมสภาพจริงของเครือข่าย การจัดวางตู้คอนโทรล การมีหรือไม่มี UPS การหยุดเดินเครื่องตอนกลางคืน การส่งงานเปลี่ยนกะ และเวลาที่หน้าจอในไทยกับสำนักงานใหญ่แสดงไม่ตรงกัน ต้องแชร์เวลาทดสอบกับฝ่ายผลิตและซ่อมบำรุง และกำหนดขอบเขตความปลอดภัยว่าจุดไหนอนุญาตให้ใส่ความผิดปกติได้ ถ้าไม่สามารถทดสอบการตัดการเชื่อมต่อบนไลน์จริงได้ ให้ใช้เส้นทางทดสอบแทน และบันทึกไว้ในเอกสารรับมอบว่าส่วนไหนไม่สามารถพิสูจน์บนของจริงได้
ถ้าคุณภาพสัญญาณไร้สายเปลี่ยนไปตามช่วงเวลาในวันหรือจากตำแหน่งรถลำเลียง แค่เดโมสั้น ๆ ตัดสินอะไรไม่ได้ ควรกำหนดช่วงสังเกตอย่างน้อยให้ครอบคลุมการเดินรอบหนึ่งของกระบวนการและการเปลี่ยนกะ แล้วตรวจให้ได้ว่าแจ้งเตือนข้อมูลหายส่งถึงใคร และใครเป็นคนแยกสาเหตุชั้นต้น ต้องดูว่าฝ่ายซ่อมบำรุง คุณภาพ วิศวกรรมการผลิต และ IT สามารถแยก “เซนเซอร์เสีย”, “ข้อมูลช้า”, และ “การแสดงผลช้า” บนหน้าจอเดียวกันได้หรือไม่ ระบบที่ทุกครั้งต้องขอให้ผู้ขายดึง log ถึงจะรู้สาเหตุ มักจะถูกปล่อยค้างคาเมื่อเริ่มใช้งานจริง
ค่าเกณฑ์ผ่านไม่ควรเป็นค่าเหมารวมอย่าง “99.9%” แต่ต้องกำหนดตามการใช้งานและสถานการณ์เสียหายแต่ละแบบ ค่าที่ใช้แจ้งเตือนอุณหภูมิสูงต้องมีความหน่วงสั้นถึงจะมีความหมาย ในทางกลับกัน การวิเคราะห์พลังงานรายเดือนอาจยอมให้ช้าบ้างได้ แต่เน้นความครบถ้วนขั้นสุดท้าย สำหรับบันทึกคุณภาพที่สำคัญ บางครั้งข้อกำหนดคือห้ามซ่อนการขาดหาย และต้องแสดงให้เห็นชัดว่า “ช่วงนี้วัดไม่ได้” ค่าที่ตกลงไว้ใน RFP ต้องถูกตรวจใน SAT และถ้าไม่ผ่าน ต้องบันทึกเงื่อนไขการทดสอบซ้ำและการใช้งานชั่วคราว
หลังเริ่มเดินระบบ ต้องเชื่อม “จำนวนที่หาย” ไปสู่การแก้ไข
หลังติดตั้งแล้ว การใส่แค่อัตราขาดหายในแดชบอร์ดรายวันไม่พอจะทำให้ดีขึ้น ควรรวมรายละเอียดของอุปกรณ์เป้าหมาย แท็ก เวลาเริ่ม/จบ จำนวนที่คาดไว้ จำนวนที่กู้คืนได้ จำนวนที่กู้คืนไม่ได้ จำนวนที่คุณภาพ Bad และขอบเขตแรกที่ผิดปกติไว้ใน ticket เดียว ผู้รับผิดชอบจะได้ตัดสินใจว่าจะไปดูฝั่งเซนเซอร์และคอนโทรล ฝั่งเครือข่าย OT ฝั่งเอจ ฝั่งคลาวด์ หรือฝั่งแอป หากข้อมูลที่กู้คืนไม่ได้ส่งผลต่อการตัดสินคุณภาพ ต้องผูกเข้ากับกระบวนการธุรกิจ เช่น กักล็อต ตรวจเพิ่ม หรือขออนุมัติข้อเบี่ยงเบน
รายสัปดาห์ควรดูไม่ใช่แค่จำนวนสาเหตุ แต่รวมถึงจำนวนครั้งที่เกิดซ้ำและเวลาที่ใช้กู้คืน ถ้าเตือนว่าบัฟเฟอร์เริ่มเกินขีดจำกัดบ่อยขึ้น แต่ยังไม่เกิดข้อมูลหาย คนมักจะปล่อยทิ้งจนกว่าจะเจอการตัดการเชื่อมต่อนาน ๆ ครั้งถัดไปแล้วข้อมูลสูญหาย การซิงก์นาฬิกาที่ล้มเหลวก็เช่นกัน ช่วงที่ยังเห็นค่าข้อมูลอยู่มักไม่ถูกสังเกต จึงควรเอาสถานะความน่าเชื่อถือของเวลาเข้าเป็นรายการเฝ้าระวังด้วย เมื่อมีการเปลี่ยนค่า setting ต้องบันทึกก่อนและหลังการเปลี่ยนว่า คาบ sampling, deadband, ความยาวคิว และระยะเวลาการเก็บ ส่งผลต่อจำนวนที่คาดไว้และสูตรตัดสินอย่างไร
สำหรับโรงงานที่กำลังเชื่อมข้อมูลเข้ากับล็อตสินค้า ต่อให้มีแต่ข้อมูลเซนเซอร์ครบ ก็ยังถือว่ายังไม่เป็น traceability สมบูรณ์ การออกแบบให้เชื่อม ID ของวัตถุดิบ กระบวนการ เครื่องจักร การตรวจสอบ และการส่งมอบ มีรายละเอียดอยู่ในต้นทุนและแนวทางการสร้างระบบ Traceability ส่วนมาตรการป้องกันข้อมูลหายในบทความนี้ คือการทำให้บันทึกเงื่อนไขเครื่องจักรและกระบวนการในสายเชื่อมโยงนั้นเชื่อถือได้
เปรียบเทียบใบเสนอราคาโดยพิจารณาเขตความรับผิดชอบและ “งานหลังจากข้อมูลหายไป”
ราคาเสนอของมาตรการรับมือข้อมูลขาดหาย หากเปรียบเทียบกันเพียงราคาต่อหน่วยของอุปกรณ์อย่างเดียว จะตัดสินผิดได้ แม้จะใช้เกตเวย์รุ่นเดียวกัน ต้นทุนการดำเนินงานก็จะแตกต่างกันไปตามว่าใครเป็นผู้เปลี่ยนเซนเซอร์ ใครเป็นผู้อนุมัติการแก้ไขแท็กของ PLC ใครเป็นผู้ตรวจสอบปัญหาเครือข่าย และใครเป็นผู้ป้อนข้อมูลย้อนหลังกลับเข้าไปใหม่ ฝั่งผู้ว่าจ้างต้องกำหนดจุดรับแจ้งปัญหาขั้นแรกและผู้รับมือขั้นที่สองสำหรับความขัดข้องทั้งหกขั้น แล้วให้แต่ละบริษัทเสนอค่าบำรุงรักษาภายใต้เงื่อนไขเดียวกัน แม้จะระบุเพียงว่า “ซัพพอร์ต 24 ชั่วโมง” ก็ไม่ได้หมายความว่าจะครอบคลุมถึงการยืนยันช่วงข้อมูลขาดหายที่ฝ่ายคุณภาพต้องใช้ หรือการแยกผลกระทบต่อแต่ละล็อตด้วยเสมอไป
สิ่งที่ควรตรวจสอบเป็นพิเศษคือขั้นตอนปฏิบัติจริงตั้งแต่ตรวจพบความขัดข้องจนถึงการกู้คืน หากมีการแจ้งเตือน ใครจะเป็นผู้บันทึกล็อกไว้ หากหน้างานรีสตาร์ตอุปกรณ์แล้ว ยังสามารถรักษาบัฟเฟอร์ที่ยังไม่ถูกส่งได้หรือไม่ สามารถกู้คืนข้อมูลเก่าจากอุปกรณ์ที่เปลี่ยนใหม่ได้หรือไม่ หากกู้คืนไม่ได้ จะยืนยันว่าข้อมูลขาดหายแล้วส่งต่อให้ฝ่ายคุณภาพในรูปแบบใด ในกรณีที่เกิดความขัดข้องช่วงวันหยุด บางครั้งเพื่อเร่งการกู้คืนก็อาจเผลอลบหลักฐานทิ้งไปได้ จึงควรจัดทำขั้นตอนสั้น ๆ สำหรับการเก็บล็อกก่อนรีสตาร์ต การบันทึกจำนวนบัฟเฟอร์คงเหลือ และการแชร์เวลาที่เกิดความขัดข้อง เพื่อให้ผู้รับผิดชอบในแต่ละกะสามารถปฏิบัติได้
หากแนบสถานการณ์ค่าใช้จ่ายไว้ 2 แบบในคำขอใบเสนอราคา จะช่วยให้เปรียบเทียบได้ง่ายขึ้น แบบหนึ่งคือการใช้งานปกติ ซึ่งรวมการเพิ่มแท็ก การตรวจเช็กประจำเดือน การสำรองการตั้งค่า และการตรวจทานรายงาน อีกแบบคือการรับมือเหตุขัดข้อง ซึ่งรวมการส่งข้อมูลซ้ำหลังการสื่อสารขาดหาย การแยกบันทึกที่เสียหาย การตรวจสอบเทียบกับข้อมูลต้นทาง การคำนวณใหม่ และการรายงานเพื่อการตรวจสอบ หากมีข้อเสนอที่สมมติว่างานหลังเกิดเหตุเป็นบริการฟรี อาจเกิดปัญหาการตีความขอบเขตงานเมื่อเกิดเหตุขัดข้องจริง จึงควรเปรียบเทียบไม่ใช่แค่ขนาดของค่าใช้จ่าย แต่รวมถึงผู้รับผิดชอบในการดำเนินงานและรูปแบบของผลลัพธ์ด้วย
การขยายไลน์ในอนาคตก็ควรประเมินด้วยวิธีเดียวกัน แม้ไลน์เริ่มต้นเพียง 1 ไลน์อาจตรวจเทียบด้วยแรงงานคนได้ แต่เมื่อเพิ่มเป็น 10 ไลน์ อาจต้องมีผู้รับผิดชอบเฉพาะสำหรับการตรวจเช็กข้อมูลขาดหายทุกเช้า หากจะทำให้เป็นอัตโนมัติ ควรตรวจสอบว่าระบบมาตรฐานของผู้เสนอสามารถรองรับได้ถึงระดับใด ตั้งแต่การสร้างจำนวนงานตามแผน การตรวจเทียบซ้ำหลังข้อมูลมาถึงล่าช้า การออกทิกเก็ต ไปจนถึงรายงานประจำวัน หากต้องส่งข้อมูลการพักล็อตไปยัง MES หรือระบบคุณภาพที่มีอยู่เดิม ควรกำหนดเขตความรับผิดชอบของการเชื่อมต่อแยกต่างหากในอีกบรรทัดหนึ่ง เมื่อทำให้จุดนี้ชัดเจนแล้ว จะสามารถเปรียบเทียบได้ไม่ใช่แค่ราคาของแพลตฟอร์มเก็บข้อมูล แต่เป็นต้นทุนรวมในการรักษาบันทึกคุณภาพด้วย
การเริ่มนำไปใช้แบบค่อยเป็นค่อยไป｜จากการวัดจริงของอุปกรณ์หนึ่งเครื่องไปสู่การขยายใช้ทั้งสาย
เป้าหมายแรกควรเลือกเป็นอุปกรณ์ที่เมื่อเกิดความผิดปกติแล้วจำเป็นต้องมีคำอธิบายจากบันทึก และสามารถทดสอบได้อย่างปลอดภัย แทนที่จะเชื่อมต่อเครื่องวัดอุณหภูมิทั้งหมดพร้อมกัน ควรเริ่มจากกระบวนการให้ความร้อนหนึ่งขั้นตอน และสัญญาณจำนวนน้อยที่เกี่ยวข้องกับขั้นตอนนั้น เช่น อุณหภูมิ ความดัน สถานะการเดินเครื่อง และจุดเริ่มต้น/สิ้นสุดล็อต วิธีนี้จะช่วยไล่หาสาเหตุของข้อมูลที่ขาดหายได้ง่ายกว่า กำหนดเงื่อนไขที่ฝ่ายคุณภาพใช้หนึ่งข้อ และเงื่อนไขที่หน้างานใช้หนึ่งข้อ พร้อมระบุเป็นคำพูดให้ชัดว่าการตัดสินใจแต่ละฝ่ายต้องใช้ค่าภายในกี่นาที หากเพิ่มจำนวนสัญญาณก่อน จะตามการกำหนดจำนวนงานที่คาดหวังและการตีความสถานะคุณภาพไม่ทัน และจะเหลือเพียงกองค่าข้อมูลเท่านั้น
ในการสังเกตช่วงแรก ให้เดินคู่ขนานกับเครื่องมือวัดที่มีอยู่และบันทึกกระดาษ เพื่อยืนยันว่าข้อมูลออกมาอย่างไรตลอดหนึ่งกระบวนการต่อเนื่อง หารือกับหน้างานเกี่ยวกับกฎการตัดรอบการหยุดตามแผนออกจากตัวหาร วิธีจัดการค่าระหว่างการล้างเครื่อง และว่าหลังเปลี่ยนชนิดสินค้าแล้วความหมายของแท็กจะไม่เปลี่ยนไปหรือไม่ สมุดทะเบียนแท็กที่สร้างขึ้นในขั้นนี้ไม่ใช่แค่ตารางที่อยู่เท่านั้น ต้องทำให้ค้นหาจากบรรทัดเดียวได้ว่า มีรหัสอุปกรณ์ ตำแหน่งติดตั้งเซ็นเซอร์ หน่วย ช่วงค่าปกติ คาบการวัด เงื่อนไขแจ้งเตือนเมื่อมีการเปลี่ยนแปลง แหล่งที่มาของเวลา ความหมายของแฟลกคุณภาพ ผู้รับผิดชอบงานบำรุงรักษา และวัตถุประสงค์การใช้งาน เมื่อต้องเพิ่มอุปกรณ์ภายหลัง ให้คัดลอกสมุดทะเบียนนี้แล้วตรวจดูความแตกต่าง จะช่วยไม่ให้ความผิดพลาดเดิมขยายไปยังระบบอื่น
ในขั้นถัดไปให้ทดสอบการขาดการสื่อสารและการรีสตาร์ต แล้วตรวจสอบแบบสามจุดว่ามีกี่รายการเข้าไปที่เอดจ์และกี่รายการไปถึงที่จัดเก็บปลายทาง ก่อนใส่เหตุขัดข้อง ต้องยืนยันก่อนว่าความแตกต่างในสภาวะปกติเป็นศูนย์ หากทดสอบตัดการเชื่อมต่อทั้งที่จำนวนข้อมูลในสภาวะปกติยังไม่ตรงกันอยู่แล้ว ข้อมูลที่ขาดหายใหม่จะปนกับความผิดพลาดในการตั้งค่าที่มีอยู่เดิม ระหว่างการทดสอบ ห้ามเขียนค่ากลับเข้าไปในระบบควบคุม และต้องตรวจสอบกับผู้ผลิตอุปกรณ์ถึงภาระการอ่านและข้อจำกัดด้านความปลอดภัย หลังทดสอบเสร็จ ต้องดูด้วยว่าจำนวนข้อมูลค้างในบัฟเฟอร์กลับไปเท่าเดิมหรือไม่ แม้ภายนอกจะเหมือนว่าข้อมูลส่งครบทุกชิ้นแล้ว แต่ถ้าคิวส่งซ้ำยังคงค้างอยู่ ก็มีความเป็นไปได้ว่าเหตุขัดข้องครั้งถัดไปจะใช้ความจุจนหมด
ก่อนขยายไปยังสายอื่น ต้องเปรียบเทียบให้แน่ชัดว่าสภาวะของอุปกรณ์เครื่องแรกกับเครื่องที่สองเหมือนกันจริงหรือไม่ ไม่ใช่ดูแค่รุ่น PLC เท่านั้น แต่ยังต้องดูเฟิร์มแวร์ ความแม่นยำของเซ็นเซอร์ เส้นทางเครือข่าย รูปแบบการหยุดของเครื่อง การป้องกันไฟฟ้า และผู้รับผิดชอบงานซ่อมบำรุงที่อาจแตกต่างกัน สิ่งที่ทำเป็นเทมเพลตได้คือกรอบของสัญญาข้อมูลและแบบฟอร์มทดสอบ ไม่ควรก๊อปปี้จำนวนงานที่คาดหวังหรือเกณฑ์ผ่าน/ไม่ผ่านแบบเดียวกันทั้งหมด ให้บันทึกข้อยกเว้นของแต่ละไลน์ไว้ในสมุดทะเบียน และในการสรุปรวมทั้งระบบ ให้แสดงเฉพาะตัวชี้วัดที่เปรียบเทียบกันได้บนกราฟเดียว การวางลำดับการนำไปใช้ในแบบนี้จะช่วยแก้ข้อบกพร่องที่พบใน PoC ก่อนที่จะถูกส่งต่อไปยังอุปกรณ์ถัดไป
กำหนดร่วมกับฝ่ายคุณภาพว่าจะเก็บหลักฐานไว้นานเท่าใด และใช้วิธีแก้ไขอย่างไร
ในการดำเนินงานหลังจากตรวจพบข้อมูลขาดหาย ประเด็นสำคัญคือจะเก็บข้อมูลดิบไว้นานแค่ไหน หากเก็บไว้เฉพาะค่าที่สรุปแสดงบนแดชบอร์ด แล้วลบระเบียนรับเข้าต้นฉบับในเวลาอันสั้น เมื่อมีการตรวจสอบภายหลังจะยืนยันไม่ได้ว่า “ขาดจริง” หรือ “มาถึงทีหลัง” กันแน่ ในทางกลับกัน การเก็บข้อมูลความถี่สูงของทุกแท็กไว้ไม่มีกำหนดจะทำให้ต้นทุนสูงขึ้น ควรแยกพิจารณาระยะเวลาที่จำเป็นสำหรับเป็นบันทึกคุณภาพของผลิตภัณฑ์เป้าหมาย ข้อกำหนดการตรวจสอบภายใน สัญญากับลูกค้า และระยะเวลาจัดเก็บเพื่อวัตถุประสงค์การวิเคราะห์ แล้วออกแบบที่เก็บของระเบียนต้นฉบับและผลสรุปขึ้นมา โดยระยะเวลาจัดเก็บตามกฎหมายหรือสเปกของลูกค้าจะแตกต่างกันไปตามอุตสาหกรรมและผลิตภัณฑ์ จึงไม่กำหนดจำนวนปีแบบเดียวกันในที่นี้
ต้องกำหนดด้วยว่ารับข้อมูลที่มาถึงภายหลังได้ถึงเมื่อไร ตัวอย่างเช่น หากใช้งานแบบสรุปรายวันและต้องสรุปให้เป็นทางการในเช้าวันถัดไป ก็อาจตั้งให้ระเบียนที่มาถึงก่อนเวลานั้นถูกคำนวณใหม่โดยอัตโนมัติ และหลังจากปิดยอดแล้วให้ต้องยื่นคำขอแก้ไข อย่างไรก็ตาม เส้นตัดนี้เป็นเพียงตัวอย่างการทำงาน และในกระบวนการที่ใช้ตัดสินคุณภาพอาจต้องใช้ขั้นตอนที่เข้มงวดกว่านี้ เมื่อจะเปลี่ยนค่าที่สรุปแล้ว ต้องไม่ลบค่าต้นฉบับ แต่ให้เก็บเป็นชุดเดียวกันทั้งก่อนและหลังการเปลี่ยน เหตุผลในการเปลี่ยน ผู้อนุมัติ และเอกสารสรุปที่คำนวณใหม่ หากเปลี่ยนเฉพาะผลสรุป จะขัดแย้งกับหน้าจอแจ้งเตือนในขณะนั้นและรายงานที่ส่งให้ลูกค้า ต้องใส่เลขเวอร์ชันให้รายงาน และติดตามได้ว่าตัดสินใจใดด้วยเวอร์ชันไหน
ในแฟลกคุณภาพ ควรให้มีระดับรายละเอียดเพียงพอสำหรับแยกสาเหตุที่ต้องแยกในการทำงาน เช่น “การสื่อสารขาดตอน” “เซ็นเซอร์เสีย” “อยู่นอกช่วงวัด” “ไม่ทราบสถานะการซิงก์นาฬิกา” “ค่าที่ประมาณขึ้น” และ “แก้ไขด้วยมือ” อย่างไรก็ตาม ต้องไม่เอารหัสคุณภาพเฉพาะของผลิตภัณฑ์ไปแทนความหมายแบบเดียวกันทั่วทั้งองค์กรโดยตรง PLC, เซิร์ฟเวอร์ OPC UA, เกตเวย์, ฮิสโทเรียน และ MES อาจใช้คำเดียวกันแต่มีความหมายต่างกันได้ ให้สร้างตารางแปลงรหัส เก็บรหัสต้นทางไว้ด้วย และห้ามตีความค่าที่แปลงไม่ได้ให้เป็น Good เองโดยพลการ ในการทดสอบรับเข้า ควรใส่รหัสที่ไม่รู้จักสักหนึ่งรายการ แล้วตรวจดูว่าการบันทึกและการแจ้งเตือนจะเป็นอย่างไร
รายงานเหตุขัดข้องไม่ได้มีไว้เพื่อใช้เอาผิดเพียงอย่างเดียว แต่ยังเป็นข้อมูลตั้งต้นสำหรับการเปลี่ยนแบบครั้งถัดไปด้วย แทนที่จะเปลี่ยนแท็กที่มีข้อมูลขาดหายบ่อยให้เป็นความถี่สูงขึ้นโดยไม่มีเงื่อนไข ให้ทบทวนว่าจำเป็นต้องใช้สัญญาณดิบจริงหรือไม่ ช่วงเวลาที่ใช้ตรวจจับเหมาะสมแล้วหรือยัง หรือความจุบัฟเฟอร์และแบนด์วิดท์ในการส่งไม่เพียงพอ หากเกิดข้อมูลขาดหายช่วงเดิมเป็นประจำทุกเดือนครั้งละไม่กี่นาที ก็อาจเป็นไปได้ว่าการหยุดเครื่องตามรอบหรือการบำรุงรักษาเครือข่ายยังไม่ได้สะท้อนในตัวหารอย่างถูกต้อง เมื่อจะเปลี่ยนสูตรการตัดสินใจโดยอ้างอิงข้อมูลการใช้งาน ต้องระบุให้ชัดว่าจะนำสูตรใหม่ไปใช้ย้อนหลังกับช่วงเวลาที่ผ่านมาหรือไม่ และอย่าผสมตัวเลขก่อนและหลังเข้าด้วยกันโดยไม่บอกกล่าว
เพื่อไม่ให้การตรวจสอบความสอดคล้องในแต่ละวันต้องพึ่งพาแค่ประสบการณ์ของผู้รับผิดชอบเพียงอย่างเดียว เราจึงกำหนดขั้นตอนตรวจยืนยันตอนเช้าไว้ด้วย โดยสร้างจำนวนรายการที่คาดไว้ของวันก่อนหน้าจากผลการเดินเครื่องจริง แล้วนำไปเทียบกับบันทึกเฉพาะที่มาถึงแล้ว จากนั้นสรุปช่วงที่ขาดหายแยกตามแต่ละเครื่องจักร ในจุดนั้นให้แยกจำนวนที่ยังคงค้างอยู่ในบัฟเฟอร์ออกจากจำนวนที่ส่งถึงปลายทางจัดเก็บแล้ว พร้อมแสดงกำหนดเวลารอข้อมูลที่มาถึงล่าช้า ค่าที่อยู่ก่อนครบกำหนดให้ถือเป็นแบบชั่วคราว ส่วนค่าที่ยังไม่มาถึงแม้พ้นกำหนดแล้วให้ถือว่ายังไม่กู้คืน และให้แจ้งไปยังหน้างานเฉพาะช่วงที่กระทบต่อการตัดสินคุณภาพเป็นหลัก เมื่อการส่งซ้ำเสร็จแล้ว ให้ตรวจเทียบใหม่ด้วยเงื่อนไขเดิม และบันทึกทั้งส่วนต่างจากครั้งก่อนกับผลการตัดสิน วิธีนี้จะช่วยหลีกเลี่ยงกรณีที่แม้ผู้รับผิดชอบจะเปลี่ยนเวร แต่กลับเกิดเหตุว่าเมื่อวานรายงานว่าเป็นข้อมูลขาดหาย พอวันนี้ข้อมูลนั้นก็หายไปโดยไม่มีคำอธิบายใด ๆ
นอกจากนี้ยังต้องทำให้สามารถสังเกตได้ด้วยว่าตัวกระบวนการตรวจเทียบเองหยุดทำงานหรือไม่ เพราะถ้าอาศัยเพียงสัญญาณเตือนเรื่องข้อมูลขาดหาย อาจทำให้เข้าใจผิดว่าวันที่งานตรวจเทียบล้มเหลวและไม่ได้มีการนับอะไรเลยเป็นวันปกติได้ จึงต้องเฝ้าติดตามเวลาที่รันครั้งล่าสุด จำนวนเครื่องจักรที่อยู่ในขอบเขต จำนวนรายการที่คาดไว้ที่ประมวลผลแล้ว และจำนวนแท็กที่ล้มเหลว และในวันที่รันไม่ได้ให้ระบุไว้ชัดเจนในรายงานประจำวัน เมื่อระบบกลับมาปกติแล้วให้ประมวลผลวันนั้นใหม่ โดยใช้เวอร์ชันของปฏิทินการเดินเครื่องและการตั้งค่าแท็ก ณ เวลานั้นเพื่อจำลองสูตรการตัดสินให้เหมือนเดิม หากนำการตั้งค่าปัจจุบันไปนับย้อนอดีต จะเสี่ยงที่ช่วงหยุดแผนหรือการเปลี่ยนรอบการเก็บข้อมูลจะไม่ถูกสะท้อน ทำให้มีเพียงตัวเลขที่เปลี่ยนไปเท่านั้น ดังนั้นการเก็บประวัติการตั้งค่าที่จำเป็นไว้คู่กับบันทึกต้นฉบับ จึงเป็นพื้นฐานของการจัดการข้อมูลขาดหายที่สามารถอธิบายย้อนหลังได้
FAQ｜คำถามที่พบบ่อยเกี่ยวกับการทำมาตรการข้อมูลเซนเซอร์ขาดหาย
ถ้าข้อมูลเซนเซอร์ขาดหาย ควรเติมด้วยการประมาณค่าเลยไหม?
ขึ้นอยู่กับการใช้งาน สำหรับการแสดงแนวโน้มอุณหภูมิ การประมาณค่าอาจมีประโยชน์ แต่สำหรับการประกันคุณภาพหรือหลักฐานสัญญาณเตือน ไม่ควรเอาค่าประมาณมาอ้างเป็นค่าที่วัดจริง ควรเก็บช่วงที่ขาดหายไว้เหมือนเดิม และติดแฟลกคุณภาพแบบ “Estimated” พร้อมวิธีคำนวณ แยกเส้นกราฟสำหรับดูหน้าจอออกจากบันทึกต้นฉบับสำหรับการตรวจสอบ
ถ้าเพิ่มระดับ MQTT QoS จะทำให้ปัญหาข้อมูลขาดหายหมดไปไหม?
ไม่ใช่ QoS กำหนดพฤติกรรมการส่งข้อมูลในช่วงการสื่อสารบางส่วน แต่ไม่ได้รับประกันค่าที่วัดไม่ได้จากเซนเซอร์ ค่าที่ตกก่อนเข้าถึงเกตเวย์ หรือค่าที่ถูกตกหล่นจากการสรุปผลหลังรับมาแล้ว จำเป็นต้องทดสอบการยืนยันรับ การคงข้อมูล การส่งซ้ำ การตัดข้อมูลซ้ำ และการตรวจสอบแต่ละช่วงตามขอบเขตที่ต้องการ เวลาจะเปรียบเทียบความสามารถของ MQTT ให้ดูที่สเปก OASIS MQTT 5.0 และตรวจสอบขอบเขตการทำงานของผลิตภัณฑ์แยกต่างหาก
ควรตั้งเป้าอัตราขาดหายไว้ที่กี่เปอร์เซ็นต์?
ตั้งค่าตายตัวไม่ได้ ค่าที่เหมาะสมขึ้นกับคาบบันทึก ปฏิทินการเดินเครื่อง เวลากู้คืนที่ยอมรับได้ และผลกระทบต่อการตัดสินคุณภาพ ควรเริ่มจากวัดค่าพื้นฐานของหนึ่งกระบวนการ แยกความครบถ้วนแบบรายงานเร็วกับแบบสรุปสุดท้าย และแยกช่วงขาดหายสำคัญออกจากการนับจำนวนทั่ว ๆ ไป ต่อให้ค่าเฉลี่ย 99.9% ถ้ามีช่วงสำคัญ 10 นาทีหายไปทั้งช่วง ก็อาจไม่ผ่านในทางปฏิบัติ
RFP, FAT และ SAT จำเป็นไหมสำหรับ PoC ขนาดเล็ก?
ไม่จำเป็นต้องมีเอกสารยาวหลายสิบหน้า แต่การมีสูตรคำนวณจำนวนที่คาดหวัง แหล่งที่มาของ timestamp การทดสอบการตัดการเชื่อมต่อ กฎตัดสินข้อมูลซ้ำ และเงื่อนไขผ่าน/ไม่ผ่าน อยู่ในใบทดสอบแผ่นเดียว มีประโยชน์มาก ถ้าตรวจเงื่อนไขเหล่านี้ตั้งแต่ PoC จะเปรียบเทียบราคาขยายระบบในอนาคตได้ง่ายกว่า ถ้าไม่ใส่ไว้ จะเหลือผลลัพธ์ว่า “กราฟขึ้นแล้ว แต่ขอบเขตความรับผิดชอบของข้อมูลหายยังไม่ชัด”
สรุป｜รับมอบสิ่งที่อธิบายได้ ไม่ใช่แค่สิ่งที่มองเห็นค่าได้
การป้องกันข้อมูลเซนเซอร์ขาดหายของโรงงานจะกลายเป็นงานที่ใช้ได้จริง เมื่อก่อนหรือหลังเลือกเซนเซอร์และคลาวด์ มีการนิยาม “บันทึกที่คาดหวัง” ไว้ชัดเจน แยกบันทึกแบบคาบคงที่กับแบบเมื่อมีการเปลี่ยนแปลง เก็บเวลาในการวัด เวลาในการรับ คุณภาพ และ Event ID และวัดความครบถ้วนชั่วคราวกับความครบถ้วนขั้นสุดท้ายแยกกัน ออกแบบไม่ใช่แค่ความจุบัฟเฟอร์ แต่รวมแบนด์วิดท์กู้คืนและการตัดข้อมูลซ้ำด้วย ตรวจสูตรตัดสินจาก RFP ให้เป็นหลักฐานรูปแบบเดียวกันใน FAT และ SAT ถ้าเดินตามลำดับนี้ จะเปลี่ยนจากการเฝ้าระวังที่เห็นแค่ตัวเลข มาเป็นการปฏิบัติการที่อธิบายได้ว่าหายเพราะอะไรและกระทบตรงไหน
หากต้องการเริ่มจากโรงงานที่ไทยซึ่งมีอุปกรณ์เดิมอยู่แล้ว และอยากพิจารณาตั้งแต่ทะเบียนแท็กไปจนถึงเงื่อนไขทดสอบตอนสัญญาณหลุด กรุณาแนบไลน์ที่ต้องการและประเภทการใช้งานของบันทึกที่ต้องการ แล้วติดต่อ TOMAS TECH ได้ที่นี่ แม้ในขั้นที่ยังไม่สรุปโครงสร้างหรือผลิตภัณฑ์ เราก็ช่วยจัดเกณฑ์รับมอบไปด้วยกันได้
