ระบบบันทึกอุณหภูมิและความชื้นอัตโนมัติในโรงงานไทย: คู่มือ RFP และ FAT/SAT

เกริ่นนำ: กราฟเพียงอย่างเดียวไม่สามารถตอบว่า “ล็อตใดได้รับผลกระทบ”

วันหนึ่ง ฝ่ายประกันคุณภาพสอบถามมาว่า “เกิดการเบี่ยงเบนอุณหภูมิในห้องควบคุมอุณหภูมิและความชื้น แล้วล็อตสินค้าใดได้รับผลกระทบบ้าง?” ในโรงงานส่วนใหญ่ มักคิดว่าการแสดงกราฟข้อมูลอุณหภูมิและความชื้นตามเวลาเป็นการ “ควบคุม” แล้ว แต่ความจริง กราฟเพียงอย่างเดียวไม่สามารถอธิบายได้อย่างแม่นยำว่า “ล็อตใด ในช่วงเวลาใด ถูกเบี่ยงเบนมากน้อยเพียงใด” การอัตโนมัติบันทึกข้อมูลจึงไม่ใช่แค่ “การมองเห็น” หรือ PoC (การพิสูจน์แนวคิด) เท่านั้น แต่ต้องออกแบบ “ระบบบันทึกข้อมูล” ที่สามารถให้บุคคลที่สามตรวจสอบและอธิบายด้วยหลักฐานย้อนหลังได้

กลุ่มเป้าหมายและเส้นแบ่งระหว่าง “การควบคุม” กับ “การเฝ้าระวัง”

บทความนี้มุ่งเป้าไปที่ผู้นำฝ่ายจัดซื้อ ประกันคุณภาพ และวิศวกรรมในโรงงานไทยและญี่ปุ่น โดยเฉพาะผู้ที่กำลังพิจารณา “การอัตโนมัติบันทึกอุณหภูมิและความชื้น” และต้องรับผิดชอบต่อการตรวจสอบในอนาคต การรับมือกับเคลม และการพิสูจน์คุณภาพสินค้า สิ่งที่กล่าวถึงในที่นี้ไม่ใช่ “การควบคุม” หรือ “การเฝ้าระวัง” อุณหภูมิและความชื้น แต่คือ “การอัตโนมัติบันทึกข้อมูล” โดยเน้นที่การออกแบบและการดำเนินงานของระบบบันทึกข้อมูลที่ “อธิบายย้อนหลังได้” ไม่ใช่แค่การเฝ้าระวังแบบเรียลไทม์หรือแจ้งเตือนเท่านั้น

จุดเริ่มต้นของการออกแบบบันทึก: “ต้องตอบคำถามคุณภาพอะไรบ้าง”

การออกแบบระบบอัตโนมัติบันทึกอุณหภูมิและความชื้น ควรเริ่มจาก “ต้องตอบคำถามด้านคุณภาพอะไรบ้าง” ตัวอย่างเช่น

• “ล็อตนี้ถูกสัมผัสกับอุณหภูมินอกช่วงที่กำหนดนานกี่นาที?”
• “เมื่อเกิดการเบี่ยงเบน ใครเป็นผู้ดำเนินการแก้ไขและดำเนินการอย่างไร?”
• “ข้อมูลนี้ได้มาจากเซนเซอร์ใด อยู่ในสถานะการสอบเทียบใด?”

การออกแบบต้องสามารถอธิบายย้อนหลังโดยอ้างอิง “บันทึกข้อมูล” ได้ ไม่ใช่แค่แสดงกราฟหรือค่าตัวเลขเท่านั้น แต่ต้องสามารถติดตาม “บริบท” และ “ที่มา” ของบันทึกข้อมูลได้ด้วย

สคีมาขั้นต่ำของการบันทึก: ควรบันทึกอะไรบ้าง

สำหรับการอัตโนมัติบันทึกอุณหภูมิและความชื้น รายการข้อมูลขั้นต่ำที่จำเป็นต้องบันทึก (สคีมา) มีดังนี้ หากขาดรายการเหล่านี้ จะไม่สามารถอธิบายหรือผ่านการตรวจสอบย้อนหลังได้

• รหัสเซนเซอร์ต้นทาง: ได้ข้อมูลจากเซนเซอร์ใด
• รหัสอุปกรณ์/โซน: ห้อง อุปกรณ์ หรือพื้นที่ใด
• ค่าที่วัดได้/หน่วย: อุณหภูมิ ความชื้น และหน่วย
• เวลาบันทึกต้นทาง: เวลาที่เซนเซอร์บันทึก
• เวลารับข้อมูล: เวลาที่ระบบได้รับข้อมูล
• สถานะ/รหัสคุณภาพ: สถานะผิดปกติ การสอบเทียบหมดอายุ ค่าผิดปกติ ฯลฯ
• สถานะการสอบเทียบ/เวอร์ชัน: หมายเลขใบรับรองสอบเทียบหรือวันหมดอายุ ณ เวลาบันทึก
• เวอร์ชันเกณฑ์ควบคุมที่ใช้: ควรประเมินตามมาตรฐานใด (เช่น เวอร์ชัน SOP)
• ลิงก์ล็อต/ใบสั่งงาน: เชื่อมโยงกับล็อตสินค้า/ใบสั่งงานใด
• รหัสแจ้งเตือน/การดำเนินการ: รหัสแจ้งเตือนหรือบันทึกการดำเนินการเมื่อเกิดการเบี่ยงเบน
• รหัสการนำเข้าข้อมูล: ตัวระบุการประมวลผลนำเข้าข้อมูล (เพื่อป้องกันการส่งซ้ำ/ข้อมูลซ้ำซ้อน)

สคีมานี้สอดคล้องกับข้อกำหนดข้อมูลประวัติของ OPC UA (OPC Foundation Historical Timestamps, StatusCode, Original Values) และแนวคิดด้าน Data Integrity ของ FDA เอกสาร 10 ด้วย

ตัวอย่างบันทึก: ตารางตัวอย่างเมื่อเกิดเหตุการณ์เบี่ยงเบน

ด้านล่างคือตัวอย่างบันทึกเมื่อเกิดการเบี่ยงเบนอุณหภูมิในห้องควบคุมอุณหภูมิและความชื้น ค่าต่าง ๆ และรหัสเป็นตัวอย่างสมมติ เพื่ออธิบายเท่านั้น ไม่ใช่เกณฑ์หรือค่ามาตรฐานสากล

ดังตัวอย่าง จะเห็นว่ามีการบันทึกรหัสแจ้งเตือนเมื่อเกิดการเบี่ยงเบน รหัสการดำเนินการ ข้อมูลสอบเทียบ เวอร์ชันเกณฑ์ควบคุม และการเชื่อมโยงกับล็อต/ใบสั่งงาน ทำให้สามารถอธิบายย้อนหลังได้ว่า “ล็อตใด เจอการเบี่ยงเบนใด และมีการดำเนินการอย่างไร”

ตำแหน่งติดตั้งเซนเซอร์และสายโซ่สอบเทียบ: ความเป็นจริงของ NIST Traceability

ข้อควรพิจารณาในการติดตั้งเซนเซอร์

ตำแหน่งติดตั้งเซนเซอร์ต้องพิจารณาตามความเสี่ยงของสินค้าและกระบวนการ เช่น ในห้องควบคุมอุณหภูมิและความชื้น อาจแนะนำให้ติดตั้งหลายจุด เช่น “ใกล้ตัวสินค้า” “จุดที่อุณหภูมิเปลี่ยนแปลงมากที่สุด” “ระบบอิสระจากเซนเซอร์ควบคุมหลัก” เป็นต้น (Vaisala การอภิปราย Temperature Mapping) ในโรงงานไทย ควรตรวจสอบค่าที่วัดได้บริเวณทางเข้า-ออก ช่องลมเย็น ผนังติดภายนอก ฯลฯ และต้องบันทึกเหตุผลการเลือกจุดติดตั้งแต่ละโซน

สายโซ่สอบเทียบและ NIST Traceability

การสอบเทียบเซนเซอร์อาจต้องการความสามารถในการตรวจสอบย้อนกลับไปยังมาตรฐานแห่งชาติ เช่น NIST (สถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา) อย่างไรก็ตาม การตรวจสอบย้อนกลับของ NIST เองไม่ได้หมายถึง “ใบรับรองเชื่อมโยงโดยตรงกับ NIST” แต่หมายถึง “สายโซ่ของการสอบเทียบ (chain) ได้รับการบันทึกเป็นเอกสาร” ซึ่งเป็นสาระสำคัญ (การสอบกลับได้ทางมาตรวิทยาของ NIST) ในขั้นตอนการออกแบบ ควรตรวจสอบขอบเขตการวัด, ความไม่แน่นอน, เนื้อหาในใบรับรอง, หมายเลขใบรับรอง และวันหมดอายุของผู้ให้บริการสอบเทียบที่ใช้ในประเทศไทย พร้อมทั้งกำหนดวิธีการบันทึกข้อมูลเหล่านี้ไว้ล่วงหน้า

โซนในโรงงานไทยและความแตกต่างด้านการใช้งานตามภูมิอากาศ

โรงงานในไทยต้องตรวจสอบสภาพฝน-แล้ง การไหลเวียนของอากาศภายนอก และเงื่อนไขการเดินเครื่องปรับอากาศในแต่ละจุดติดตั้ง ในแต่ละโซนจะมีจุดเสี่ยงต่างกัน เช่น “ผนังติดภายนอก” “พื้นที่ร้อนชื้นสูง” “ใต้เครื่องปรับอากาศ” ฯลฯ ไม่ควรนำแบบโรงงานญี่ปุ่นมาใช้ตรง ๆ แต่ต้องออกแบบโซนโดยคำนึงถึงภูมิอากาศ โครงสร้างอาคาร และการใช้งานจริงในไทย

สถาปัตยกรรมระบบ: ตั้งแต่เซนเซอร์ถึงการบันทึกและรีวิว

ระบบอัตโนมัติบันทึกอุณหภูมิและความชื้น ไม่ใช่แค่เซนเซอร์กับกราฟแสดงผลเท่านั้น ต้องมีโครงสร้างหลายชั้นดังนี้

1. เซนเซอร์/ดาต้าล็อกเกอร์

จัดการตำแหน่งติดตั้ง สถานะการสอบเทียบ บันทึกค่าที่วัดและเวลาบันทึก

1. เกตเวย์

รวบรวมข้อมูลจากเซนเซอร์ จัดการความผิดปกติของการสื่อสาร การคัดกรองข้อมูลซ้ำ การซิงค์เวลา

1. ฮิสโตเรียน (ฐานข้อมูลบันทึก)

เก็บบันทึกทั้งหมดพร้อมสคีมา รองรับการค้นหาและรีวิวย้อนหลัง

1. หน้าจอรีวิว

ค้นหาบันทึก ดูบันทึกการแจ้งเตือนและการดำเนินการ เรียกดูใบรับรองสอบเทียบ ฯลฯ มี UI ที่เหมาะกับฝ่ายตรวจสอบ/ประกันคุณภาพ

1. เชื่อมต่อ QMS/MES

เชื่อมโยงกับล็อต ใบสั่งงาน และบันทึกการจัดการเบี่ยงเบน เพื่อบริหารจัดการบันทึกคุณภาพแบบรวมศูนย์

ข้อจำกัดของ OPC UA และการรับประกันเมตาดาต้า

สเปค Historical Access ของ OPC UA ได้กำหนดวิธีการจัดการกับไทม์แสตมป์, สถานะโค้ด, ค่าต้นฉบับ และประวัติการเปลี่ยนแปลง (OPC UA Historical Timestamps, StatusCode, Original Values) อย่างไรก็ตาม ไม่ได้รับประกันว่าเมทาดาทาทั้งหมดจะถูกจัดการโดยอัตโนมัติ ตัวอย่างเช่น หมายเลขใบรับรองการสอบเทียบ, รหัสล็อต หรือรหัสแอคชันต่าง ๆ จะไม่สามารถรับประกันได้ด้วย OPC UA เพียงอย่างเดียว หากไม่ได้สร้างระบบที่บันทึกและเชื่อมโยงข้อมูลเหล่านี้อย่างชัดเจนตั้งแต่ขั้นตอนการออกแบบระบบ

ไทม์โซน, ไทม์สแตมป์, และความคลาดเคลื่อนของนาฬิกา

การจัดการเวลาต้นทาง/เวลาระบบ

ต้องบันทึกทั้ง “เวลาต้นทาง” ที่เซนเซอร์บันทึก และ “เวลารับข้อมูล” ที่เกตเวย์หรือฮิสโตเรียนบันทึกเสมอ เพราะในความเป็นจริง มักเกิดกรณีที่ “เวลาวัดจริง” กับ “เวลาบันทึก” ไม่ตรงกัน เช่น ความล่าช้าเครือข่าย การบัฟเฟอร์ ข้อผิดพลาดของนาฬิกาเซนเซอร์ (Clock Drift) หรือการส่งข้อมูลล่าช้าเนื่องจากการขาดการเชื่อมต่อชั่วคราว (OPC UA Historical Timestamps)

การระบุไทม์โซนอย่างชัดเจน

ในโรงงานไทย การบันทึกควรใช้เวลาไทย (UTC+7) เป็นหลัก แต่หากเซิร์ฟเวอร์หรือคลาวด์ทำงานด้วยเวลาอื่น เช่น เวลาญี่ปุ่น (UTC+9) หรือ UTC จำเป็นต้องระบุไทม์โซนในไทม์สแตมป์อย่างชัดเจน หากไม่ระบุ จะไม่สามารถอธิบายย้อนหลังได้อย่างถูกต้องว่า “เกิดการเบี่ยงเบนเมื่อใด” หรือ “ล็อตใดได้รับผลกระทบ”

การจัดการ Clock Drift และการส่งข้อมูลล่าช้า

หากนาฬิกาของเซนเซอร์หรือเกตเวย์คลาดเคลื่อน ความน่าเชื่อถือของบันทึกจะลดลง จึงต้องมีการซิงค์เวลาสม่ำเสมอ (เช่น NTP) ตรวจจับและบันทึก Clock Drift รวมถึงบันทึกทั้ง “เวลาวัดจริง” และ “เวลารับข้อมูล” เมื่อเกิดการส่งข้อมูลล่าช้า ตั้งแต่ขั้นตอนออกแบบ

จุดตรวจสอบหลักในการรีวิวการออกแบบ

• สคีมาบันทึกข้อมูลเพียงพอต่อการตอบคำถามด้านคุณภาพย้อนหลังหรือไม่?
• การบันทึก/อ้างอิงใบรับรองสอบเทียบและเวอร์ชันเกณฑ์ควบคุมทำได้ง่ายหรือไม่?
• การเชื่อมโยงกับล็อตและใบสั่งงานเป็นอัตโนมัติหรือไม่?
• การจัดการไทม์สแตมป์ ไทม์โซน และ Clock Drift เพียงพอหรือไม่?
• การออกแบบครอบคลุมข้อจำกัดของ OPC UA หรือโปรโตคอลอื่น ๆ หรือไม่?
• การติดตั้งและการใช้งานสะท้อนความเสี่ยงเฉพาะของโซนและภูมิอากาศในโรงงานไทยหรือไม่?

(โปรดติดตามตอนต่อไปใน PART B)

ข้อมูลที่ขาดหายและกลยุทธ์การเติมข้อมูลย้อนหลัง

ในการทำให้งานบันทึกอุณหภูมิและความชื้นเป็นอัตโนมัติ ความเสี่ยงของข้อมูลที่ขาดหาย (missing data) เป็นสิ่งที่หลีกเลี่ยงไม่ได้ ในโรงงาน สาเหตุที่ทำให้ข้อมูลขาดหายมีได้หลากหลาย เช่น ปัญหาเครือข่าย อุปกรณ์เซ็นเซอร์เสีย หรือปัญหาไฟฟ้า เพื่อให้มั่นใจในความสมบูรณ์ของบันทึก จำเป็นต้องออกแบบแนวทางรับมือกับข้อมูลที่ขาดหายให้ชัดเจน และเลือกวิธีปฏิบัติให้เหมาะสมกับกระบวนการและความเสี่ยงของผลิตภัณฑ์

หากตัวบันทึกข้อมูลสามารถเก็บค่าที่วัดได้ในช่วงที่เครือข่ายขัดข้อง และส่งข้อมูลเหล่านั้นหลังจากระบบกลับมาทำงาน จะช่วยลดกรณีข้อมูลขาดหายได้ อย่างไรก็ตาม ตามข้อกำหนดของ OPC UA Historical Access เพียงอย่างเดียว ข้อมูลที่มาถึงภายหลังจะไม่ได้ถูกระบุว่าเป็น “แบ็คฟิล” โดยอัตโนมัติ ข้อมูลที่ถูกนำเข้าครั้งแรกแบบกลุ่มด้วยเวลาต้นทางในอดีต อาจไม่มีการสร้างบันทึกการเปลี่ยนแปลง (ดู OPC Foundation historical updates and original values) ดังนั้นจึงควรกำหนดให้มีการบันทึกเวลาที่วัดจริง เวลาที่รับข้อมูล ธงแสดงการมาถึงล่าช้าหรือการส่งซ้ำที่เฉพาะเจาะจงของแอปพลิเคชัน และรหัสเหตุการณ์ต้นทาง พร้อมตรวจสอบให้แน่ใจว่าข้อมูลเหล่านี้ยังคงแสดงและส่งออกได้หลังจากระบบฟื้นตัวจากการขัดข้องของการสื่อสาร

ในทางกลับกัน หากอุปกรณ์หรือระบบในพื้นที่ไม่มีบัฟเฟอร์ในตัว ข้อมูลในช่วงที่เครือข่ายขาดจะไม่สามารถเรียกคืนได้จริง และจะเหลือเป็น “ช่องว่าง (gap)” ในบันทึก ในกรณีนี้ การบันทึกช่วงที่ขาดข้อมูลอย่างชัดเจน (เช่น การใส่ธง “No Data” หรือเว้นว่างพร้อมระบุเหตุผล) เป็นสิ่งจำเป็นสำหรับการตรวจสอบหรือการตัดสินคุณภาพในอนาคต การไม่ปกปิดข้อมูลที่ขาดหาย แต่ระบุข้อเท็จจริงและช่วงเวลาที่ขาดข้อมูลไว้อย่างถูกต้อง จะช่วยรักษาความน่าเชื่อถือในการประเมินความเสี่ยงของกระบวนการและการตัดสินล็อต

ความแตกต่างระหว่างค่าที่ใช้ไม่ได้ ข้อมูลขาดหาย ค่าประมาณ และข้อมูลดิบ พร้อมหลักฐานจาก OPC UA

ในการทำให้งานบันทึกอุณหภูมิและความชื้นเป็นอัตโนมัติ ไม่ใช่แค่การรวบรวมค่าเท่านั้น แต่ต้องแยกแยะให้ชัดเจนว่า “ค่าเหล่านั้นคืออะไร” ในโมเดลข้อมูลประวัติของ OPC UA จะมีการกำหนด “StatusCode” ให้กับแต่ละจุดข้อมูล เพื่อบันทึกความถูกต้องและที่มาของค่า (OPC Foundation historical StatusCode)

• ค่าไม่ถูกต้อง (Invalid): ค่าที่ตรวจพบว่าผิดปกติ เช่น ความผิดปกติของเซนเซอร์ จะไม่ถูกนำมาใช้ในการประเมินคุณภาพ และจะถูกจัดการเป็นค่าไม่ถูกต้องพร้อมระบุสาเหตุ หากใช้ StatusCode เช่น Bad ของ OPC UA ต้องตรวจสอบว่าอุปกรณ์ใดและเงื่อนไขใดที่กำหนดค่านี้
• ข้อมูลขาดหาย (No Data): ช่วงเวลาที่ไม่มีค่าที่วัดได้จริง จะไม่เติมข้อมูลราวกับว่ามีค่าอยู่ การออกแบบต้องแยกแยะระหว่างการตอบกลับ NoData ขณะอ่านข้อมูล กับเหตุการณ์ข้อมูลขาดหายที่แอปพลิเคชันบันทึกไว้
• ค่าคำนวณ (Interpolated): ค่าที่ประมาณจากค่าก่อนหน้าและหลังจากนั้น ต้องแยกจากค่าที่วัดจริง ใน ReadAtTime ของ OPC UA มีข้อกำหนดให้แสดง Interpolated ใน InfoBits เมื่อเป็นค่าคำนวณ (ดู OPC Foundation raw vs interpolated readings)
• ข้อมูลดิบ (Raw): หากมีค่าที่บันทึกไว้ตรงกับเวลาที่ระบุ ใน ReadAtTime เดียวกันจะระบุ Raw ใน InfoBits ข้อมูลดิบ (Raw) และข้อมูลดี (Good) มีความหมายต่างกัน ดังนั้นไม่ควรสรุปว่าข้อมูลดิบต้องเป็น Good เสมอไป

การแยกแยะนี้สำคัญมากในการทบทวนบันทึกย้อนหลัง การสืบหาสาเหตุเมื่อเกิดความผิดปกติ หรือการพิสูจน์ความสอดคล้องกับมาตรฐาน ตัวอย่างเช่น หากเกิดการเบี่ยงเบนของอุณหภูมิหรือความชื้นในกระบวนการ การตัดสินใจของฝ่ายคุณภาพหรือการจัดการล็อตจะเปลี่ยนไปอย่างมาก ขึ้นอยู่กับว่าค่านั้นเป็น “ข้อมูลดิบ” หรือ “ค่าประมาณ”

การจำลองสถานการณ์ขาดเครือข่ายและบัฟเฟอร์ในพื้นที่

ความทนทานของการบันทึกข้อมูลในช่วงที่เครือข่ายขาดเป็นจุดสำคัญในการประเมินการออกแบบระบบ ตัวอย่างเช่น ในบางระบบอย่าง Vaisala viewLinc เซ็นเซอร์หรือยูนิตในพื้นที่สามารถเก็บข้อมูลไว้ภายในในช่วงที่เครือข่ายล่ม และอัปโหลดข้อมูลไปยังเซิร์ฟเวอร์โดยอัตโนมัติเมื่อเครือข่ายกลับมา (Vaisala viewLinc official product) กรณีนี้จะลดช่องว่างของข้อมูลให้น้อยที่สุดและคงความต่อเนื่องของบันทึก

อย่างไรก็ตาม ไม่ใช่ทุกระบบจะรับประกันฟังก์ชันนี้ ก่อนนำมาใช้งานจริง ควรทดสอบโดยจำลองสถานการณ์ขาดเครือข่าย เพื่อดูพฤติกรรมของระบบ หากไม่มีบัฟเฟอร์ในพื้นที่และข้อมูลช่วงขาดเครือข่ายสูญหายทั้งหมด ควรบันทึกช่องว่างอย่างชัดเจนในบันทึก และไม่ควรเติมค่าประมาณหรือคาดเดาย้อนหลังเพื่อความปลอดภัยในการบริหารความเสี่ยง เพราะการพึ่งพาค่าประมาณอาจทำให้มองข้ามความผิดปกติหรือเหตุการณ์เบี่ยงเบนที่เกิดขึ้นจริง

บันทึกต้นฉบับ การแก้ไข ผู้ปฏิบัติงาน/เหตุผล และร่องรอยการตรวจสอบ

สำหรับการบันทึกอุณหภูมิและความชื้น ต้องกำหนดข้อกำหนดในการรักษาข้อมูลต้นฉบับและการติดตามการแก้ไข OPC UA Historical Access กำหนดกลไกสำหรับจัดการค่าที่เปลี่ยนแปลง ค่าต้นฉบับ และข้อมูลการเปลี่ยนแปลง แต่การนำไปใช้และการจัดเก็บประวัติและเหตุการณ์ตรวจสอบต้องตรวจสอบกับผลิตภัณฑ์และการตั้งค่าที่เลือกใช้ โดยเฉพาะอย่างยิ่ง การนำเข้าข้อมูลแบบกลุ่มครั้งแรกที่มีเวลาต้นทางในอดีต อาจไม่มีการสร้างบันทึกการเปลี่ยนแปลง (ดู OPC Foundation historical updates and original values) ดังนั้นจึงควรบันทึกค่าก่อนและหลังการแก้ไข ผู้รับผิดชอบ เวลา และเหตุผลไว้ในแอปพลิเคชัน และทดสอบว่าสามารถนำไปประกอบใหม่หลังการส่งออกได้หรือไม่

ตัวอย่างเช่น หากเจ้าหน้าที่ในพื้นที่เปลี่ยนเซ็นเซอร์หรือสอบเทียบแล้วแก้ไขข้อมูล ต้องบันทึกว่าใคร แก้ไขเมื่อไร ค่าใด และด้วยเหตุผลอะไร พร้อมเก็บเป็นร่องรอยการตรวจสอบ (audit trail) เพื่อรองรับการตรวจสอบคุณภาพหรือความต้องการด้านการตรวจสอบย้อนกลับในอนาคต การบันทึกเหตุผลในการแก้ไขไม่ใช่แค่บันทึกการกระทำ แต่เป็นหลักฐานสำหรับประเมินความเสี่ยงของกระบวนการและผลกระทบต่อคุณภาพของผลิตภัณฑ์

นอกจากนี้ แม้จะมีการแก้ไขหรือเพิ่มเติมข้อมูล ก็ไม่ควรลบข้อมูลต้นฉบับทิ้ง แต่ควรจัดการข้อมูลก่อนและหลังแก้ไข รวมถึงเหตุผลไว้ในที่เดียว เพื่อให้สามารถตรวจพบการปลอมแปลงหรือความผิดพลาดได้แต่เนิ่นๆ และรับผิดชอบต่อการอธิบายระหว่างการตรวจสอบ

การตั้งค่าขีดจำกัดแจ้งเตือน การจัดการเวอร์ชัน การอนุมัติ การแก้ไขปัญหา และการปิดงาน

ในการจัดการแจ้งเตือนกรณีอุณหภูมิหรือความชื้นเบี่ยงเบน การตั้งค่าขีดจำกัด (threshold) และการจัดการเวอร์ชันเป็นสิ่งสำคัญ โดยต้องตั้งค่าขีดจำกัดให้เหมาะสมกับแต่ละกระบวนการหรือผลิตภัณฑ์ และบันทึกประวัติการเปลี่ยนแปลง เพื่อให้ทราบว่าในแต่ละช่วงเวลาใช้เกณฑ์ใด

เมื่อเกิดแจ้งเตือน ต้องแยกให้ชัดเจนระหว่าง “การอนุมัติ (acknowledgement)” “การแก้ไขปัญหา (corrective action)” และ “การปิดงาน (closure)” ในโมเดลแจ้งเตือนของ OPC UA เมื่อเกิดแจ้งเตือน ผู้ปฏิบัติงานสามารถดำเนินการ “อนุมัติ” และบันทึกไว้ได้ (OPC Foundation alarm acknowledge method) อย่างไรก็ตาม การอนุมัติเป็นเพียงการบันทึกว่ารับทราบแล้ว ส่วนการแก้ไขปัญหาจริง (เช่น การตรวจสอบหน้างานหรือปรับแต่งอุปกรณ์) ต้องจัดการแยกต่างหาก

การบันทึกการแก้ไขปัญหาควรระบุผู้ดำเนินการ รายละเอียดการดำเนินการ วันที่และเวลา วิเคราะห์สาเหตุหลัก และมาตรการป้องกันการเกิดซ้ำ การจัดการข้อมูลเหล่านี้ในที่เดียว และให้ฝ่ายคุณภาพหรือผู้รับผิดชอบดำเนินการ “ปิดงาน (close)” จะช่วยให้การจัดการแจ้งเตือนมีความชัดเจน การผสมผสานข้อมูลเวอร์ชันของขีดจำกัด จะช่วยให้สามารถทบทวนย้อนหลังได้อย่างถูกต้องว่าแจ้งเตือนเกิดขึ้นภายใต้เกณฑ์ใดและมีการดำเนินการอย่างไร

การส่งต่อระหว่างกะ

ในโรงงานที่ดำเนินการ 24 ชั่วโมง การจัดการแจ้งเตือนหรือการทบทวนบันทึกมักต้องส่งต่อระหว่างกะ ตัวอย่างเช่น หากเกิดแจ้งเตือนในกะกลางคืนแต่ไม่สามารถดำเนินการได้ ต้องส่งต่อให้กะกลางวัน ในระบบบันทึกอัตโนมัติ ควรแสดงสถานะ “ยังไม่เสร็จสิ้น” ของแจ้งเตือนหรือการแก้ไขปัญหาอย่างชัดเจน และมีระบบส่งต่อให้ผู้รับผิดชอบในกะถัดไปอย่างแน่นอน

ตัวอย่างเช่น หากไม่มีการดำเนินการภายในเวลาที่กำหนดหลังแจ้งเตือน ระบบควรแจ้งเตือนอัตโนมัติไปยังผู้บริหาร หรือแสดงรายการแจ้งเตือนที่ยังไม่ดำเนินการในช่วงเปลี่ยนกะ ฟังก์ชันการส่งต่อและการออกแบบการใช้งานเหล่านี้มีผลโดยตรงต่อการลดความเสี่ยงด้านคุณภาพ ในการออกแบบระบบ ควรตรวจสอบว่าสามารถตั้งกฎการส่งต่อได้ยืดหยุ่นตามสภาพการทำงานและกำลังคนในพื้นที่หรือไม่

“`

+——————-+——————-+——————-+

| ประเภทบันทึก | ตัวอย่าง | OPC UA Status |

+——————-+——————-+——————-+

| ข้อมูลดิบ | 23.5°C, 55%RH | Good |

| ค่าที่ใช้ไม่ได้ | เซ็นเซอร์เสีย | Bad |

| ข้อมูลขาดหาย | เครือข่ายขาด | No Data |

| ค่าประมาณ | ค่าคำนวณระหว่าง 2 จุด | Interpolated |

+——————-+——————-+——————-+

“`

กรณีเบี่ยงเบนความชื้นระหว่างการผลิตและการทับซ้อนของขอบเขตล็อต

ตัวอย่างการใช้งานจริง เช่น ในระหว่างการผลิตผลิตภัณฑ์หนึ่ง หากความชื้นเกินขีดจำกัดชั่วคราว สมมติว่าการผลิตล็อต A เสร็จสิ้น และเริ่มผลิตล็อต B ทันที แล้วเกิดความชื้นเบี่ยงเบนในช่วงเปลี่ยนล็อต กรณีนี้ช่วงเบี่ยงเบนจะทับซ้อนขอบเขตของทั้งสองล็อต จึงต้องระบุให้ชัดเจนว่าล็อตใดได้รับผลกระทบบ้าง

ตามนโยบายฝ่ายคุณภาพที่เน้นความปลอดภัย มักจะ “พัก (hold)” ล็อตทั้งหมดที่อยู่ในช่วงเบี่ยงเบน และดำเนินการประเมินคุณภาพหรือทดสอบซ้ำเพิ่มเติม ก่อนตัดสินใจ “ปล่อย (release)” สิ่งสำคัญคือ ความน่าเชื่อถือของการตัดสินใจขึ้นอยู่กับว่าบันทึกในช่วงเบี่ยงเบนเป็น “ข้อมูลดิบ” หรือมี “ค่าประมาณ” หรือ “ข้อมูลขาดหาย” ปะปนอยู่ ตัวอย่างเช่น หากในช่วงเบี่ยงเบนเกิดเครือข่ายขาดและมีข้อมูลขาดหาย จะต้องใช้มาตรการพักล็อตที่เข้มงวดมากขึ้น

ในสถานการณ์เช่นนี้ ความสมบูรณ์และความชัดเจนของที่มาบันทึกจะเป็นหลักฐานสำคัญในการตัดสินคุณภาพ หากบันทึกในช่วงเบี่ยงเบนเป็น “ข้อมูลดิบ” ต่อเนื่องกับช่วงเวลา จะต่างจากกรณีที่มีค่าประมาณหรือข้อมูลขาดหายปะปน ซึ่งจะส่งผลต่อการตัดสินใจปล่อยล็อตและความรับผิดชอบในการชี้แจงต่อลูกค้า

บทบาทความปลอดภัย การเข้าถึงระยะไกลของซัพพลายเออร์ การสำรอง/กู้คืน การทดสอบนำเข้า/ส่งออก และระยะเวลาการเก็บรักษา

ในระบบอัตโนมัติสำหรับบันทึกอุณหภูมิและความชื้น ต้องกำหนดสิทธิ์การเข้าถึง การตรวจสอบสัญญาณเตือน การแก้ไข การเปลี่ยนแปลงการตั้งค่า และการสำรองข้อมูลตามหน้าที่งาน OPC UA มีระบบเกี่ยวกับบทบาทและการตรวจสอบ แต่การที่เซิร์ฟเวอร์จะนำกลไกบทบาทมาใช้ทั้งหมดหรือบางส่วนขึ้นอยู่กับแต่ละผลิตภัณฑ์ และการจัดเก็บเหตุการณ์ตรวจสอบลงดิสก์ก็ไม่ได้รับประกันตามข้อกำหนด (ดู OPC Foundation OPC UA security model) ต้องตรวจสอบการอนุญาตและปฏิเสธการดำเนินการต่าง ๆ ด้วยบัญชีทดสอบของฝ่ายปฏิบัติการ คุณภาพ บำรุงรักษา และ IT/OT รวมถึงกำหนดเงื่อนไขการรับรองสำหรับที่จัดเก็บบันทึกตรวจสอบ ระยะเวลาการเก็บ สำรองข้อมูล และการตรวจจับการแก้ไข

หากจำเป็นต้องให้ซัพพลายเออร์เข้าถึงระยะไกล ควรจำกัดขอบเขตและสิทธิ์การเข้าถึง พร้อมบันทึก log การเข้าถึงทุกครั้ง การบันทึกการดำเนินการระหว่างการบำรุงรักษาระยะไกลก็ควรเก็บเป็นส่วนหนึ่งของร่องรอยการตรวจสอบ

ฟังก์ชันสำรองข้อมูลและกู้คืน (backup/restore) เป็นสิ่งจำเป็นเพื่อรักษาบันทึกในกรณีเกิดปัญหา ควรมีการสำรองข้อมูลเป็นประจำ และหลังการกู้คืนควรตรวจสอบความสมบูรณ์ของข้อมูล (เช่น การทดสอบนำเข้าข้อมูลที่ส่งออกไว้) เพื่อป้องกันความเสี่ยงจากการสูญหายของข้อมูล ฟังก์ชันส่งออกข้อมูล (export) เช่น เป็นไฟล์ CSV หรือ PDF สำหรับการตรวจสอบภายนอกหรือส่งให้ลูกค้า ก็ควรระบุที่มาของข้อมูล (ข้อมูลดิบ/ค่าประมาณ/ช่วงขาดข้อมูล) อย่างชัดเจน

ระยะเวลาการเก็บรักษาบันทึกจะกำหนดตามความต้องการของลูกค้า ความเสี่ยงของกระบวนการหรือผลิตภัณฑ์แต่ละประเภท ตัวอย่างเช่น ในอุตสาหกรรมยา หรือชิ้นส่วนที่ต้องการความน่าเชื่อถือสูง อาจต้องเก็บข้อมูลหลายปี แต่ไม่ได้มีข้อบังคับทางกฎหมายเหมือนกันทุกอุตสาหกรรม การกำหนดระยะเวลาการเก็บรักษาควรพิจารณาจากวงจรชีวิตผลิตภัณฑ์ สัญญากับลูกค้า และนโยบายคุณภาพภายใน และใช้ฟังก์ชันลบอัตโนมัติหรือเก็บถาวรในระบบเพื่อสมดุลภาระงานและความเสี่ยง

ใน PART C ถัดไป จะเจาะลึกประเด็นปัญหาหน้างานขณะนำไปใช้จริง จุดออกแบบที่เหมาะสมกับความเสี่ยงของกระบวนการ/ผลิตภัณฑ์ และตัวอย่างการปฏิบัติจริงในการทบทวนและตรวจสอบ

เทมเพลตข้อกำหนด RFP: 12 คำถามเชิงปฏิบัติ

เมื่อพิจารณาการนำระบบบันทึกอุณหภูมิและความชื้นอัตโนมัติมาใช้ ใน RFP (คำขอข้อเสนอ) ควรระบุข้อกำหนดที่เป็นรูปธรรมจากมุมมองการปฏิบัติงานจริง การตรวจสอบ และการประกันคุณภาพ ไม่ใช่เพียงแค่สเปกหรือความสวยงามของแดชบอร์ด ตัวอย่างคำถามเชิงปฏิบัติ 12 ข้อด้านล่างนี้คือสิ่งที่ควรสอบถามผู้ขายเพื่อรับประกันความสมบูรณ์ของข้อมูลและลดความเสี่ยงในโรงงาน

1. วิธีการและความแม่นยำในการบันทึก timestamp ของข้อมูล

　ใช้เวลาท้องถิ่นของเซนเซอร์ เวลาของเซิร์ฟเวอร์ หรือ timestamp ของ OPC UA (เอกสาร 1)? หากเกิดความคลาดเคลื่อนของเวลา มีวิธีแก้ไขและบันทึกอย่างไร

1. วิธีการจัดการประวัติการเปลี่ยนแปลงข้อมูลและร่องรอยการตรวจสอบ

　เมื่อมีการแก้ไข ลบ หรือป้อนข้อมูลใหม่ มีระบบบันทึกว่าใคร เมื่อไร ทำไม และเปลี่ยนแปลงอย่างไร และสามารถตรวจสอบย้อนหลังได้หรือไม่ (เอกสาร 3)

1. ขั้นตอนการจัดการเมื่อเกิดค่าผิดปกติหรือสัญญาณเตือน (Alarm)

　มีการแจ้งเตือนเมื่อเกิด Alarm วิธีการยืนยัน (acknowledge) Alarm และบันทึกว่าใครตอบสนองเมื่อไรอย่างไร (6)

1. การปกป้องข้อมูลเมื่อเซนเซอร์หรือเครือข่ายขาดการเชื่อมต่อ

　หากเซนเซอร์หรือเครือข่ายขาดช่วงชั่วคราว มีวิธีบันทึกและกู้คืนข้อมูลที่ขาดหายหรือมาช้าอย่างไร

1. การแยกแยะและบันทึกข้อมูลที่ล่าช้าหรือข้อมูลที่อยู่ในบัฟเฟอร์

　เมื่อเซนเซอร์เชื่อมต่อใหม่ มีแฟล็กเฉพาะของแอปพลิเคชันแยกข้อมูลที่มาล่าช้าออกจากค่าปัจจุบันหรือไม่ และตรวจสอบ StatusCode ด้านคุณภาพของค่าแยกต่างหากได้หรือไม่ (เอกสาร 2)

1. ประวัติการสอบเทียบ (Calibration) และการปฏิเสธค่าที่สอบเทียบผิดปกติ

　มีระบบจัดการประวัติการสอบเทียบ และหากค่าที่สอบเทียบอยู่นอกขอบเขตที่กำหนด ระบบสามารถปฏิเสธหรือแจ้งเตือนอัตโนมัติได้หรือไม่

1. ประวัติการเปลี่ยนแปลงค่า Threshold (Alarm) และการย้อนกลับ (Rollback)

　มีการบันทึกว่าใครเปลี่ยน threshold เมื่อไร ทำไม และมีขั้นตอนการคืนค่าหากตั้งค่าผิด

1. การสร้างรายงาน CSV/PDF ใหม่และการรับประกันความสมบูรณ์

　เมื่อสร้างรายงานใหม่จากข้อมูลเดิมเพื่อการตรวจสอบหรือการสืบย้อนล็อต สามารถรับประกันว่าตรงกับข้อมูลต้นฉบับหรือไม่

1. ฟังก์ชันค้นหาและดึงข้อมูลตามล็อตหรือผลิตภัณฑ์

　สามารถดึงข้อมูลอุณหภูมิและความชื้นที่เกี่ยวข้องกับล็อตการผลิตหรือผลิตภัณฑ์เฉพาะได้อย่างรวดเร็วหรือไม่

1. ความสอดคล้องของข้อมูลเมื่อเกิดปัญหาระบบหรือรีสตาร์ท

　หลังจากระบบหรือเครือข่ายขัดข้องและกู้คืนแล้ว มีการออกแบบเพื่อป้องกันข้อมูลขาดหายหรือซ้ำซ้อนหรือไม่

1. การจัดการสิทธิ์ผู้ใช้และบันทึกการใช้งาน

　มีบันทึกละเอียดว่าใครทำอะไร และมีการจำกัดสิทธิ์ตามบทบาทหรือไม่

1. การรับประกัน Metrological Traceability

　มีวิธีจัดการใบรับรองการสอบเทียบและโซ่การสอบกลับของเซนเซอร์อย่างไร (เอกสาร 9)

คำถามเหล่านี้เป็นข้อกำหนดที่จำเป็นสำหรับการสร้าง “บันทึกที่สมบูรณ์และตรวจสอบย้อนหลังได้” ไม่ใช่แค่ “การเฝ้าระวังอุณหภูมิและความชื้น” เท่านั้น ควรเปรียบเทียบคำตอบของผู้ขายกับความเสี่ยงและข้อกำหนดการตรวจสอบของโรงงานอย่างรอบคอบ

การเปรียบเทียบข้อเสนอผู้ขาย: การประเมินด้วยชุดข้อมูลตัวอย่างและเดโม

ผู้ขายหลายรายมักเน้นดีไซน์แดชบอร์ดหรือความสวยงามของกราฟ แต่ความสมบูรณ์ของข้อมูลและการจัดการปัญหาในระหว่างปฏิบัติงานจริงไม่สามารถตัดสินได้จากรูปลักษณ์เท่านั้น ในการเปรียบเทียบหลังได้รับ RFP การทดสอบดังต่อไปนี้จะมีประสิทธิภาพ

การทดสอบด้วยชุดข้อมูลตัวอย่าง

• นำเข้าข้อมูลดิบจากเซนเซอร์อุณหภูมิและความชื้นจริง (รวมทั้งข้อมูลขาดหาย ค่าผิดปกติ ข้อมูลล่าช้า) ลงในระบบของแต่ละผู้ขาย แล้วทดสอบการบันทึกและสร้างรายงาน
• จำลองสถานการณ์ตัดการเชื่อมต่อเซนเซอร์ ความคลาดเคลื่อนของเวลา การเกิดและกู้คืน Alarm เพื่อเปรียบเทียบวิธีบันทึก แสดงผล และร่องรอยการตรวจสอบ

การทดสอบปฏิบัติจริงในสภาพแวดล้อมเดโม

• ให้ผู้ขายสาธิตการดำเนินการตั้งแต่เกิด Alarm การตอบสนอง การแก้ไขข้อมูล และการสร้างรายงานใหม่ เพื่อประเมินความง่ายในการใช้งาน ร่องรอยการตรวจสอบ และความสอดคล้องของข้อมูล
• ทดสอบการเปลี่ยนสิทธิ์ผู้ใช้ และการกระทำผิดพลาดหรือจงใจผิด เพื่อดูพฤติกรรมของระบบ

การทดสอบเหล่านี้จะช่วยให้เห็นว่าระบบสามารถรับประกัน “ความสมบูรณ์และตรวจสอบได้ของข้อมูล” ไม่ใช่แค่ “การเฝ้าระวัง” เท่านั้น ดูรายละเอียดเพิ่มเติมได้ที่ “จุดสำคัญในการเลือกระบบเฝ้าระวังอุณหภูมิและความชื้น (โรงงานไทย 2026)“

กรณีทดสอบ FAT/SAT รายละเอียด

ในการนำระบบเข้าติดตั้งจริง การออกแบบกรณีทดสอบ FAT (Factory Acceptance Test) และ SAT (Site Acceptance Test) ที่ครอบคลุมความเสี่ยงในโรงงานและทดสอบกับอุปกรณ์จริงเป็นสิ่งจำเป็น

1. การตัดและเชื่อมต่อเซนเซอร์ใหม่

• ตัดและเชื่อมต่อเซนเซอร์ทางกายภาพ แล้วตรวจสอบว่าช่วงข้อมูลขาดหาย แฟล็กข้อมูลมาล่าช้า เวลาที่วัดจริง และเวลาที่ระบบรับข้อมูลยังคงถูกบันทึกหลังฟื้นการเชื่อมต่อ

2. ความคลาดเคลื่อนและการแก้ไข timestamp

• ตั้งเวลาเซนเซอร์ให้คลาดเคลื่อน แล้วตรวจสอบความสอดคล้องกับ timestamp ของเซิร์ฟเวอร์และการบันทึกประวัติการแก้ไข (เอกสาร 1)

3. การจัดการข้อมูลล่าช้า/ข้อมูลบัฟเฟอร์

• ทดสอบว่าค่าที่ได้รับหลังเครือข่ายล่มถูกบันทึกและค้นหาเป็นข้อมูลมาล่าช้าได้หรือไม่ และตรวจสอบการแยกค่าดิบออกจากค่าที่คำนวณแทรกต่างหาก (เอกสาร 12)

4. การเกิดและยืนยัน Alarm (Acknowledge)

• ทดสอบการเกิด Alarm เมื่อเกิน threshold การยืนยันโดยผู้ใช้ และการบันทึกประวัติ (6)

5. การเปลี่ยนแปลงค่าบันทึกและร่องรอยการตรวจสอบ

• ทดสอบการแก้ไข/ลบค่าบันทึก และตรวจสอบว่ามีร่องรอยการเปลี่ยนแปลงก่อน-หลัง ผู้รับผิดชอบ เหตุผล และเวลา

6. การปฏิเสธค่าการสอบเทียบที่ผิดปกติ

• ป้อนค่าการสอบเทียบที่อยู่นอกขอบเขตที่กำหนด และตรวจสอบว่าระบบปฏิเสธหรือแจ้งเตือนอัตโนมัติ

7. ความสอดคล้องของข้อมูลหลังเครือข่ายขัดข้อง/กู้คืน

• บังคับหยุดและรีสตาร์ทเซิร์ฟเวอร์หรือเครือข่าย ตรวจสอบว่าข้อมูลไม่ขาดหายหรือซ้ำซ้อน

8. การสร้างรายงาน CSV/PDF ใหม่และการค้นหาตามล็อต

• สร้างรายงานใหม่ตามช่วงเวลาหรือล็อต และตรวจสอบว่าตรงกับข้อมูลต้นฉบับและสามารถใช้ในการตรวจสอบได้

9. การเปลี่ยน threshold และ rollback

• เปลี่ยน threshold แล้วคืนค่ากลับ พร้อมตรวจสอบประวัติการเปลี่ยนแปลง

10. การจัดการสิทธิ์ผู้ใช้และบันทึกการใช้งาน

• ตรวจสอบว่าการจำกัดสิทธิ์ตามบทบาททำงานถูกต้อง และมีบันทึกการใช้งานครบถ้วน

(รูปที่ 3: รายการกรณีทดสอบหลักของระบบบันทึกอุณหภูมิและความชื้นอัตโนมัติที่ควรตรวจสอบใน FAT/SAT)

ควรดำเนินการทดสอบเหล่านี้อย่างครบถ้วน และให้ฝ่ายปฏิบัติการ ประกันคุณภาพ และ IT ตรวจสอบร่วมกันว่าระบบสามารถบันทึก ตรวจสอบ และสร้างรายงานซ้ำได้อย่างสมบูรณ์ ดูรายละเอียดกลไกการบันทึกข้อมูลได้ที่ “จุดสำคัญในการบันทึกข้อมูลเครื่องมือวัด (โรงงานไทย 2026)“

การกำหนด Ownership/RACI และการจัดการการเปลี่ยนแปลง การสอบเทียบ/เปลี่ยนเซนเซอร์ การอัปเดต threshold และ rollback

การกำหนด Ownership/RACI ให้ชัดเจน

การดำเนินงานระบบบันทึกอุณหภูมิและความชื้นอัตโนมัติเกี่ยวข้องกับหลายฝ่าย เช่น ฝ่ายปฏิบัติการ ประกันคุณภาพ IT และซ่อมบำรุง ควรใช้ RACI (Responsible, Accountable, Consulted, Informed) เพื่อแบ่งหน้าที่ดังนี้

• Responsible (ผู้รับผิดชอบโดยตรง): ตรวจสอบประจำวัน ตอบสนอง Alarm (ฝ่ายปฏิบัติการ)
• Accountable (ผู้รับผิดชอบสูงสุด): ความสมบูรณ์ของบันทึกและการตรวจสอบ (ฝ่ายประกันคุณภาพ)
• Consulted (ที่ปรึกษา): การตั้งค่าระบบ การแก้ไขปัญหา (ฝ่าย IT/ซ่อมบำรุง)
• Informed (ผู้รับทราบ): ผู้บริหารและผู้ตรวจสอบ

การจัดการการเปลี่ยนแปลง การสอบเทียบ และการเปลี่ยนเซนเซอร์

• การบันทึกการสอบเทียบ/เปลี่ยนเซนเซอร์: จัดการประวัติการสอบเทียบและเปลี่ยนเซนเซอร์ในระบบเดียว พร้อมแนบใบรับรองและข้อมูล traceability (เอกสาร 9)
• การอัปเดต threshold และ rollback: ทุกการเปลี่ยน threshold ต้องมีประวัติ และสามารถคืนค่าทันทีหากตั้งค่าผิด

การจัดการการเปลี่ยนแปลงระหว่างการใช้งาน

• เมื่อมีการเปลี่ยนแปลงการตั้งค่าระบบหรืออัปเดตซอฟต์แวร์ ต้องบันทึกรายละเอียดการเปลี่ยนแปลง ผู้รับผิดชอบ เหตุผล และเวลา พร้อมมีขั้นตอนอนุมัติก่อนดำเนินการ

เฟสการนำเข้า เกณฑ์การรับมอบ และจุดที่ควรตรวจสอบกับซัพพลายเออร์

เฟสการนำเข้า

1. นิยามข้อกำหนด/จัดทำ RFP: ระบุความเสี่ยงและข้อกำหนดการตรวจสอบของโรงงานให้ชัดเจน
2. คัดเลือกผู้ขาย/ทดสอบเดโม: เปรียบเทียบด้วยข้อมูลตัวอย่างและเดโมจริง
3. FAT/SAT: ทดสอบด้วยกรณีทดสอบรายละเอียด
4. ขยายสู่หน้างาน/ฝึกอบรม: ฝึกอบรมการใช้งานและจัดทำคู่มือปฏิบัติ
5. เริ่มใช้งานจริง/ตรวจสอบการดำเนินงาน: ตรวจสอบและทบทวนบันทึกเป็นระยะ

เกณฑ์การรับมอบ (Acceptance Criteria)

• ผ่านทุกกรณีทดสอบ FAT/SAT
• รับประกันความสมบูรณ์ของบันทึก ร่องรอยการตรวจสอบ และการสร้างรายงานซ้ำ
• ข้อมูลมีความสอดคล้องในทุกสถานการณ์ เช่น การสอบเทียบ การเปลี่ยน threshold การกู้คืนจากปัญหา
• การจัดการสิทธิ์ผู้ใช้และบันทึกการใช้งานถูกต้อง

จุดที่ควรตรวจสอบกับซัพพลายเออร์

• ระบบสนับสนุนและขั้นตอนการกู้คืนเมื่อเกิดปัญหาระบบ
• วิธีการจัดการใบรับรองการสอบเทียบและ traceability
• การจัดการการเปลี่ยนแปลงและแจ้งล่วงหน้าก่อนอัปเดตซอฟต์แวร์
• ระบบสำรองข้อมูลและการปกป้องข้อมูลระยะยาว

ข้อมูล Data Dictionary และเงื่อนไขขอบเขตที่ควรกำหนดก่อนนำเข้า

หากมีแผนจะเชื่อมโยงข้อมูลไปยังขั้นตอนถัดไป ควรแยกนิยามรหัสระบุจุดวัด (ID) ที่ไม่เปลี่ยนแปลงออกจากชื่อแสดงผล เช่น แม้จะเปลี่ยนชื่อห้องเก็บสินค้าเพื่อปรับปรุงหน้างาน แต่ต้องเก็บประวัติการเชื่อมโยงระหว่างรหัสอุปกรณ์ รหัสโซน และรหัสเซนเซอร์ เพื่อไม่ให้ข้อมูลเก่าแสดงเป็นจุดวัดคนละจุด เมื่อเปลี่ยนเซนเซอร์ใหม่หลังวันที่กำหนด ต้องเปลี่ยนไปใช้รหัสเซนเซอร์ใหม่ และแสดงขอบเขตการเปลี่ยนในลำดับเวลาเดียวกันกับโซน ควรแยกค่าที่เป็นผลการวัดจริงออกจากค่าที่คำนวณเพื่อแสดงผลบนหน้าจอ หากไม่กำหนด dictionary เหล่านี้ให้ผู้ขายตั้งแต่ต้น อาจเกิดความแตกต่างของรหัสและหน่วยระหว่างผู้ขายแต่ละราย ทำให้รวมผลการค้นหาตามล็อตไม่ได้ในภายหลัง

จุดกำเนิดของบันทึกต้องชัดเจน เช่น เซนเซอร์มีเวลาวัดเอง หรือ datalogger กำหนดเวลาตอนรับข้อมูล หรือ gateway เป็นผู้บันทึก เวลาที่แสดงในช่องเดียวกันอาจมีความหมายต่างกัน เพื่อเชื่อมโยงกับเวลาที่ล็อตอยู่ในพื้นที่ ต้องระบุวิธีการซิงค์นาฬิกา ความแม่นยำ วิธีตรวจสอบความคลาดเคลื่อน และวิธีจัดการช่วงเวลาที่พบความคลาดเคลื่อนในข้อกำหนด OPC UA มี timestamp ของ source และ server แต่เครื่องแต่ละรุ่นอาจไม่ได้บันทึกทั้งสองแบบ ควรเก็บตัวอย่างบันทึกของโครงสร้างที่เลือกใน FAT และตรวจสอบว่า timestamp ใดแสดงเหตุการณ์วัดจริง

การเชื่อมโยงกับล็อตต้องไม่ตัดสินจาก “อยู่ในนาทีเดียวกัน” เท่านั้น ต้องตรวจสอบว่าสามารถบันทึกเหตุการณ์นำเข้า-นำออก ใส่-นำออกจากเครื่อง หรือหยุด-เริ่มคำสั่งงานเป็น event ได้หรือไม่ หากขาดเวลาขอบเขต จะไม่สามารถจำกัดผลกระทบได้ ฝ่ายประกันคุณภาพควรกำหนดขอบเขตสมมติที่ปลอดภัย และมีขั้นตอนตรวจสอบกับบันทึกหน้างานภายหลัง เพื่อป้องกันระบบตัดสินผิดว่าปลอดภัย ข้อมูลผลการวัดและ event ของล็อตอาจอยู่คนละระบบ ดังนั้นต้องสามารถย้อนกลับไปยังบันทึกต้นทางได้ทั้งสองฝั่ง ไม่ใช่แค่ดูผ่านหน้าจอ

การบันทึกหลักฐานการรับมอบ

ในคู่มือทดสอบ FAT ควรบันทึกไม่เพียงแค่ขั้นตอนและผลลัพธ์ที่คาดหวัง แต่รวมถึงโครงสร้างที่ใช้ทดสอบ เช่น รุ่นและเฟิร์มแวร์ของเซนเซอร์ รุ่น gateway และ server การตั้งค่าเวลา วิธีเชื่อมต่อ สิทธิ์ของบัญชีทดสอบ และเวอร์ชันของ threshold แม้จะเป็นการทดสอบ “ตัดเครือข่าย” เหมือนกัน แต่ผลลัพธ์จะแตกต่างกันหากตัดระหว่างเซนเซอร์กับ gateway หรือ gateway กับ server การบันทึกเพียงภาพหน้าจออาจไม่เพียงพอ ควรเก็บ event ID ของการทดสอบ ไฟล์ export และ log การใช้งานเป็นชุดเดียวกัน

ใน SAT จะทดสอบกับอาคารและการปฏิบัติงานจริง ตรวจสอบว่าเซนเซอร์ติดตั้งตรงตำแหน่งที่กำหนด ชื่ออุปกรณ์ตรงกับที่แสดงบนหน้าจอ และการเปลี่ยนกะปกติไม่มีการละเลย alarm เมื่อเกิดปัญหาการสื่อสาร ให้จำลองว่าหน้างานรับรู้ความผิดปกติอย่างไร ส่งข้อมูลอะไรให้ผู้รับผิดชอบกู้คืน และใครเป็นผู้ตรวจสอบช่วงเวลาขาดข้อมูลในภายหลัง การรับมอบต้องไม่จบแค่ “มีค่าขึ้นบนหน้าจอ” แต่ต้องสามารถให้ผู้รับผิดชอบคนละคนสร้างข้อมูลใหม่จากล็อตและช่วงเวลาที่กำหนด พร้อมข้อมูลต้นฉบับ ค่าผิดปกติ การตอบสนอง และสถานะการสอบเทียบ

หลังเริ่มใช้งานจริง การถอดจุดวัดเพื่อสอบเทียบ การเปลี่ยนเซนเซอร์ หรือการเปลี่ยน threshold จะเปลี่ยนบริบทของบันทึก ควรระบุเหตุผล ผู้อนุมัติ เวลาที่มีผล อุปกรณ์/ผลิตภัณฑ์ที่ได้รับผลกระทบ การตั้งค่าก่อน-หลัง และขั้นตอนกู้คืนในแบบฟอร์มการเปลี่ยนแปลง แม้จะมีร่องรอยในซอฟต์แวร์ แต่หากไม่เชื่อมโยงกับบันทึกกระดาษของหน้างาน ห่วงโซ่การอธิบายจะขาด ควรกำหนดในคู่มือว่าแต่ละฝ่าย (ประกันคุณภาพ ซ่อมบำรุง IT/OT ผลิต) ต้องเก็บบันทึกอะไร และทดสอบเป็นระยะว่าสามารถติดตามเหตุการณ์จริงย้อนหลังได้หรือไม่

FAQ (คำถามที่พบบ่อย)

Q1. ระบบเฝ้าระวังอุณหภูมิและความชื้น กับระบบบันทึกอัตโนมัติต่างกันอย่างไร?

A. ระบบเฝ้าระวังเน้นการดูสถานะปัจจุบันแบบเรียลไทม์ ส่วนระบบบันทึกอัตโนมัติจะบันทึก “ใคร-เมื่อไร-อย่างไร” ในการบันทึก แก้ไข และตอบสนอง พร้อมร่องรอยการตรวจสอบที่สมบูรณ์ สามารถตรวจสอบและพิสูจน์ย้อนหลังได้ ซึ่งเป็นความแตกต่างหลัก

Q2. จำเป็นต้องปฏิบัติตามข้อกำหนด Data Integrity ของ FDA หรือไม่?

A. ข้อกำหนด Data Integrity ของ FDA ที่อ้างถึงใช้กับ CGMP ของยาในสหรัฐฯ เท่านั้น กฎหมาย สัญญา หรือข้อกำหนดลูกค้าควรตรวจสอบตามผลิตภัณฑ์และคู่ค้า แนวคิดร่องรอยการตรวจสอบที่นำเสนอในที่นี้ ไม่ใช่ข้อบังคับทางกฎหมายสำหรับโรงงานไทยทั่วไป

Q3. เมื่อสอบเทียบหรือเปลี่ยนเซนเซอร์ จะรับประกันความสอดคล้องของบันทึกได้อย่างไร?

A. การจัดการประวัติการสอบเทียบและเปลี่ยนเซนเซอร์ในระบบเดียว พร้อมแนบใบรับรองและข้อมูล traceability (เอกสาร 9) จะช่วยพิสูจน์ความถูกต้องของบันทึกในการตรวจสอบ

Q4. หากเกิดการแก้ไขข้อมูลหรือการกระทำผิดพลาด จะตรวจพบได้อย่างไร?

A. ทุกการเปลี่ยนแปลง/ลบข้อมูลต้องบันทึกผู้รับผิดชอบ เหตุผล และเวลาเป็นร่องรอยการตรวจสอบ สามารถตรวจสอบและติดตามย้อนหลังได้ (เอกสาร 3)

Q5. หากเกิดปัญหาระบบหรือเครือข่ายขัดข้อง ข้อมูลจะเป็นอย่างไร?

A. หากอุปกรณ์ที่ใช้มีฟังก์ชันบันทึกข้อมูลในเครื่องและส่งซ้ำเมื่อเชื่อมต่อใหม่ จะสามารถแยกข้อมูลล่าช้าได้ หากไม่มีฟังก์ชันนี้ ต้องแสดงช่วงข้อมูลขาดหายอย่างชัดเจนและไม่เติมค่าคาดเดา ควรทดสอบกับอุปกรณ์จริงและโครงสร้างเครือข่ายจริงใน FAT/SAT

สรุปและติดต่อสอบถามกับ TOMAS TECH

การเลือกและนำระบบบันทึกอุณหภูมิและความชื้นอัตโนมัติมาใช้ในโรงงานยุคใหม่ ต้องเปลี่ยนจาก “การเฝ้าระวัง” สู่ “การบันทึกที่สมบูรณ์และตรวจสอบได้” เพื่อรองรับความเสี่ยงและการตรวจสอบคุณภาพ การกำหนดข้อกำหนดเชิงปฏิบัติใน RFP และการเปรียบเทียบข้อเสนอด้วยข้อมูลตัวอย่างและเดโมจริงเป็นสิ่งจำเป็น

หากต้องการปรึกษากับ TOMAS TECH กรุณาแจ้งกระบวนการที่ต้องการควบคุม เซนเซอร์ที่ใช้อยู่ ตัวอย่างบันทึก และข้อมูลล็อตที่เกี่ยวข้อง รวมถึงช่วงเวลาที่คาดว่าจะจัดซื้อ เพื่อช่วยจัดระเบียบข้อกำหนดและประเด็นการเชื่อมต่อ/การปฏิบัติงานที่ควรตรวจสอบ

สอบถามรายละเอียด นัดสำรวจหน้างาน หรือขอเดโม ได้ที่ แบบฟอร์มติดต่อ TOMAS TECH

เอกสารอ้างอิง

1. https://reference.opcfoundation.org/specs/OPC-10000-11/4.5
2. https://reference.opcfoundation.org/specs/OPC-10000-11/6
3. https://reference.opcfoundation.org/specs/OPC-10000-11/4.4
4. https://reference.opcfoundation.org/specs/OPC-10000-9/5.7.3
5. https://www.vaisala.com/en/products/software/viewlinc
6. https://docs.vaisala.com/r/M212315EN-C/en-US/GUID-E738FA55-CB57-4BE6-8331-C811E10AB988/GUID-46424254-8FC3-4883-AEA9-2946CD88252F/GUID-8A1D9588-D668-45FD-8662-C7F01317869A
7. https://www.vaisala.com/sites/default/files/documents/viewLinc-Continuous-Monitoring-System-Brochure-B211555EN.pdf
8. https://www.vaisala.com/en/blog/2023-07/temperature-mapping-study-design-duration-intervals
9. https://www.nist.gov/metrology/metrological-traceability
10. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers
11. https://reference.opcfoundation.org/specs/OPC-10000-2/4
12. https://reference.opcfoundation.org/specs/OPC-10000-11/6.5.5.2