พัฒนาหน้าจอ HMI: ย้ายสู่ Industrial PC และตรวจรับ FAT/SAT

การพัฒนาหน้าจอ HMI หากพิจารณาบนสมมติฐานว่าจะย้ายจากทัชพาแนลแบบรวมอุปกรณ์เดิมไปสู่ Industrial PC ประเด็นสำคัญไม่ได้อยู่ที่หน้าตาของจอ แต่คือรูปแบบการติดตั้งใช้งาน วิธีเชื่อมโยง PLC tag ระบบ alarm/log runtime การบำรุงรักษา OS การสำรองข้อมูล การแบ่งขอบเขตความรับผิดชอบ และ FAT/SAT โดยเฉพาะสำหรับวิศวกรรมการผลิตและฝ่ายจัดซื้อของโรงงานในไทย หากทำให้ส่วนนี้คลุมเครือตั้งแต่ขั้นตอน RFP ภาระการบำรุงรักษาหลังเริ่มเดินระบบมักจะพึ่งพา vendor มากเกินไป

บทความนี้จะเปรียบเทียบว่า ในการปรับปรุงเครื่องจักรเดิมหรือการติดตั้งไลน์ใหม่ ควรเลือก “HMI/SCADA แบบ Industrial PC” หรือ “คงใช้พาแนลแบบรวมอุปกรณ์” หรือ “thin client + central server” โดยเน้นที่ การกำหนดสเปกเพื่อการติดตั้งใช้งาน การบำรุงรักษา และการตรวจรับงาน

ทั้งนี้ ประเด็นเรื่องการเปลี่ยนหน้าจอ การใช้สี ไอคอน ความชัดเจนในการมองเห็นของ operator และลำดับชั้นด้านต้นทุนซึ่งเป็น แนวคิดด้านการออกแบบหน้าจอ ไม่ใช่ขอบเขตของบทความนี้ หากต้องการอ่านในส่วนนั้น โปรดดูบทความแยกเรื่อง การออกแบบหน้าจอ HMI Touch Panel บทความนี้จะเน้นเฉพาะ สถาปัตยกรรมการติดตั้งใช้งานและการปฏิบัติการบำรุงรักษา เท่านั้น

วัตถุประสงค์และขอบเขต

วัตถุประสงค์ของบทความนี้

เป้าหมายของบทความนี้คือช่วยให้วิศวกรรมการผลิตและฝ่ายจัดซื้อในโรงงานไทย สามารถนำประเด็นต่อไปนี้ไปใช้ในการพิจารณาภายในหรือใส่ลงใน RFP ได้ทันที เมื่อกำลังพิจารณาย้าย HMI ไปสู่ Industrial PC

• ทำให้แกนเปรียบเทียบเพื่อเลือกแนวทางมีความชัดเจน
• แยกขอบเขตความรับผิดชอบที่ควรมอบหมายให้ vendor
• ทำให้เห็นชัดว่า FAT/SAT ต้องตรวจอะไรบ้าง
• กำหนดขั้นตอนการบำรุงรักษา การสำรองข้อมูล และการอัปเดต รวมถึงการควบคุมการเปลี่ยนแปลง
• ออกแบบโครงสร้างที่ไม่พังง่ายเมื่อมีการดัดแปลงในอนาคตหรือขยายหลายภาษา

ขอบเขตที่บทความนี้ครอบคลุม

บทความนี้ครอบคลุมหัวข้อต่อไปนี้

• การติดตั้งใช้งาน HMI runtime บน Industrial PC
• PLC tag mapping
• Alarm, event, history, log
• สิทธิ์ผู้ใช้ การสลับภาษา และบันทึกการปฏิบัติงานในเชิง audit
• OS, license และการจัดการเวอร์ชันของ runtime
• Backup / restore
• พฤติกรรมตอนกู้คืนหลังไฟดับ และตอน PLC offline
• มุมมองการทดสอบ FAT/SAT
• สเปกจัดซื้อ RFP และการแบ่งขอบเขตความรับผิดชอบ

ขอบเขตที่บทความนี้ไม่ครอบคลุม

• แนวคิด UI/UX ทั่วไปของหน้าจอ
• แนวคิด DX แบบนามธรรม
• การออกแบบที่ถือว่า HMI เป็นฟังก์ชันความปลอดภัย

ประเด็นสำคัญมากคือ HMI ไม่ใช่ตัวฟังก์ชันความปลอดภัยโดยตัวมันเอง ฟังก์ชันที่เกี่ยวข้องกับการหยุดเพื่อความปลอดภัย interlock หรือ SIL/PL ต้อง เป็นจริงสมบูรณ์อยู่ที่ฝั่ง safety PLC หรือ safety circuit ก่อน HMI อาจทำหน้าที่แสดงสถานะหรือเป็น interface ให้สั่งงานได้ แต่ไม่ใช่เงื่อนไขที่ทำให้ฟังก์ชันความปลอดภัยสมบูรณ์

อีกทั้ง ISA-101 เป็น กรอบอ้างอิงด้าน lifecycle สำหรับการออกแบบ การติดตั้งใช้งาน และการบริหารจัดการ HMI ไม่ใช่การรับรองผลิตภัณฑ์ ISA-101

ในทำนองเดียวกัน IEC 62443-2-1 เป็นเอกสารที่กล่าวถึง security program ฝั่ง asset owner ไม่ได้หมายความว่าเป็น “การรับรองการันตี” สำหรับผลิตภัณฑ์ใดโดยเฉพาะ IEC 62443-2-1

3 สถาปัตยกรรมของ runtime

แนวทางติดตั้งใช้งาน HMI ควรพิจารณาจากตำแหน่งที่วางความรับผิดชอบในการปฏิบัติการและจุดที่อาจเกิดความขัดข้อง ไม่ใช่ดูเฉพาะตัวซอฟต์แวร์ ด้านล่างนี้คือ 3 รูปแบบที่พบได้บ่อยในภาคการผลิต

1. Panel PC / Panel HMI แบบรวมอุปกรณ์

เป็นโครงสร้างที่ทัชพาแนลและ runtime อยู่รวมกันใน terminal หน้างาน

เหมาะกับกรณี

• การควบคุมแบบปิดอยู่ในเครื่องเดี่ยว
• ต้องการให้แต่ละเครื่องทำงานอิสระจากกัน
• ต้องการแยก network อย่างชัดเจน
• มาตรฐานของ vendor ใช้แบบรวมอุปกรณ์เหมือนกันทั้งระบบ

ข้อดี

• โครงสร้างเข้าใจง่าย
• แยกขอบเขตความรับผิดชอบตามเครื่องจักรได้ชัด
• ลดการพึ่งพา network หรือ server ได้ง่ายกว่า

ข้อควรระวัง

• ต้อง backup และจัดการเวอร์ชันแยกตามแต่ละ terminal
• หากจำนวนหน้าจอหรือความต้องการเก็บข้อมูลเพิ่มขึ้น การจัดการ configuration จะซับซ้อน
• ความสามารถในการทดแทนตอนเปลี่ยนรุ่นมักขึ้นกับ model โดยตรง

2. Industrial PC แบบรัน local

เป็นรูปแบบที่รัน HMI runtime บน Industrial PC ซึ่งติดตั้งใกล้เครื่องจักรหรือไลน์การผลิต แล้วเชื่อมต่อกับจอ monitor หรือ touch display หน้างาน

เหมาะกับกรณี

• ต้องการ monitor ข้ามหลาย PLC และอุปกรณ์รอบข้าง
• มีหน้าจอ log recipe และ report ค่อนข้างมาก
• ต้องการใช้ runtime ฝั่ง Windows หรือใช้ความยืดหยุ่นของระบบ
• ต้องการมาตรฐานเดียวกันด้านอะไหล่บำรุงรักษาและการจัดการ storage

ข้อดี

• รวมหน้าจอ log และปลายทางการเชื่อมต่อไว้ด้วยกันได้ง่าย
• ออกแบบ backup การเปลี่ยน disk และการ deploy image ได้ง่ายกว่า
• รองรับการเพิ่มฟังก์ชันในอนาคตได้ดี

ข้อควรระวัง

• ต้องมีแนวทางดูแล OS, license และการตัดสินใจเรื่อง patch
• ต้องประเมินให้เหมาะกับ hardware และสภาพแวดล้อมหน้างาน
• หากไม่กำหนดขอบเขตความรับผิดชอบให้ชัดตั้งแต่เริ่มต้น จะตัดแยกปัญหาระหว่างฝั่ง PLC และฝั่ง HMI ได้ยากตอน commissioning

3. Thin client / Central server

เป็นรูปแบบที่ฝั่งหน้างานใช้ terminal แบบ thin client หรือ browser-based client ส่วน HMI runtime หรือ visualization platform จะไปรวมอยู่ฝั่ง server ตัวอย่างเช่นแนวคิดแบบ workstation/client หรือการกระจายศูนย์กลางจะมีโครงสร้างต่างกันไปตามผลิตภัณฑ์ Ignition Perspective Workstation

เหมาะกับกรณี

• ต้องการบริหารหลายไลน์บน platform เดียวกัน
• ต้องการรวมการ backup และการจัดการสิทธิ์ไว้ส่วนกลาง
• วางแผนเชื่อม IT/OT หรือขยายหลายไซต์

ข้อดี

• จัดการแบบรวมศูนย์ได้ง่าย
• เวลาต้องเปลี่ยน terminal การกู้คืนมักทำได้ง่ายกว่า
• เหมาะกับการกระจายใช้งานหลาย terminal

ข้อควรระวัง

• พึ่งพา network และ availability ของ server มากขึ้น
• ขอบเขตความรับผิดชอบระหว่าง OT และ IT มักซับซ้อนขึ้น
• หากไม่กำหนด requirement เรื่องการเดินเครื่องต่อแบบ local ไว้ล่วงหน้า การปฏิบัติงานหน้างานตอน server หยุดจะคลุมเครือ

วิธีที่เหมาะที่สุดขึ้นกับการวางความรับผิดชอบของอุปกรณ์

ไม่ได้หมายความว่า “Industrial PC ดีกว่าเสมอ” ในการตัดสินใจจัดซื้อ ควรเลือกวิธีที่ตอบคำถามต่อไปนี้ได้ชัดเจน

• เมื่อไลน์หยุด ใครเป็นผู้กู้ระบบหน้างาน
• PLC สามารถเดินเครื่องแบบอิสระได้หรือไม่
• เมื่อ network ขาด ยังต้องใช้งานต่อได้หรือไม่
• การดัดแปลงในอนาคตจะเป็นรายเครื่องหรือข้ามทั้งโรงงาน
• ผู้รับผิดชอบหลักด้าน backup คือฝ่ายเครื่องจักรหรือฝ่าย IT

การสำรวจหน้างาน

ก่อนตัดสินใจรูปแบบการติดตั้งใช้งาน มีข้อมูลที่ควรเก็บจาก site survey สิ่งที่มักตกหล่นในการพิจารณาบนโต๊ะไม่ใช่เรื่อง performance แต่คือ สภาพการเชื่อมต่อจริงและเส้นทางงานบำรุงรักษา

รายการขั้นต่ำที่ควรตรวจใน site survey

โครงสร้างควบคุม

• ผู้ผลิต PLC, CPU model, firmware
• Communication protocol
• จำนวน tag ที่มีอยู่และพื้นที่เผื่อในอนาคต
• แหล่งที่มาของการกำหนด alarm เดิมอยู่ที่ไหน เช่น ฝั่ง PLC ฝั่ง HMI หรือมีแค่สเปกกระดาษ
• ตำแหน่งที่เก็บ recipe หรือค่าตั้งชนิดงาน

การใช้งาน HMI

• ตำแหน่งติดตั้ง terminal ที่ใช้สั่งงาน
• ภาษาที่ต้องใช้หน้างาน
• ระดับสิทธิ์และ flow การอนุมัติ
• วิธีตรวจสอบ alarm ในแต่ละกะ
• มี daily report หรือ CSV export หรือไม่

โครงสร้างพื้นฐาน

• คุณภาพไฟฟ้า มีไฟตก/ไฟกระชากสั้นหรือไม่
• จำเป็นต้องมี UPS หรือไม่
• Network topology, VLAN และผู้ดูแล
• สามารถเชื่อมต่อเพื่อ remote maintenance ได้หรือไม่
• อุณหภูมิหน้างาน ฝุ่น การสั่นสะเทือน และความร้อนสะสมในตู้

ระบบบำรุงรักษา

• หน่วยงานใดในโรงงานไทยเป็น first response
• ขอบเขตที่สำนักงานใหญ่หรือฝ่าย IT ส่วนกลางเข้ามาเกี่ยวข้อง
• ขอบเขต onsite support ของ vendor
• นโยบายเก็บอะไหล่
• ผู้อนุมัติเมื่อมี software modification

ประเด็นที่มักถูกมองข้ามในโรงงานไทย

• ข้อความ alarm ในภาษาอังกฤษ ภาษาญี่ปุ่น และภาษาไทยตรงกันจริงหรือไม่
• พนักงานกะกลางคืนถูกคาดหวังให้ทำถึงขั้น login OS หรือ restart service หรือไม่
• หลังไฟดับต้อง auto-recovery หรือให้หยุดรอที่หน้าจอยืนยัน
• ทีมซ่อมบำรุงหน้างานควร restore backup เองได้หรือไม่
• ผู้ดูแล network ของโรงงานจะบริหาร OT terminal เหล่านี้เป็นทรัพย์สินแบบ PC หรือไม่

ตาราง requirement

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

ตัวอย่างตาราง requirement

ถ้อยคำกำกวมที่ควรหลีกเลี่ยงในสเปก

• “ใช้ OS เวอร์ชันล่าสุด”
• “มีมาตรการ security ที่เหมาะสม”
• “มี backup อย่างเพียงพอ”
• “แสดงผลรวดเร็ว”
• “รองรับการขยายในอนาคต”

คำเหล่านี้อาจสะดวกตอนเสนอราคา แต่จะทำให้เกิดข้อโต้แย้งเรื่องการตีความใน FAT/SAT และช่วงบำรุงรักษา ทางที่ดีควรระบุให้ชัดว่า ใครจะตรวจอะไร และตรวจอย่างไร

PLC tag และ alarm

ใน HMI แบบ Industrial PC ปัญหาที่พบบ่อยที่สุดมักไม่ได้อยู่ที่ตัวหน้าจอ แต่คือ ความคลาดเคลื่อนของความหมาย tag และ ความคลุมเครือของวิธีใช้งาน alarm

สิ่งที่ควรกำหนดในการออกแบบ PLC tag

แหล่งความรับผิดชอบของ tag

อันดับแรกต้องกำหนดให้ชัดว่า “ใครเป็นผู้ให้นิยามความหมายของค่านี้”

• Tag ที่ฝั่ง PLC เป็นผู้กำหนดหลัก
• Tag ที่ HMI สร้างเพื่อแสดงผลต่อยอด
• Tag ที่ใช้ค่าคำนวณ การแปลงข้อความ หรือการแปลงหน่วยที่อยู่ฝั่ง HMI
• Tag ที่มาจาก master กลางของเครื่องจักร

หากจุดนี้ไม่ชัด เมื่อมีการแก้ PLC อาจเกิดกรณีที่ HMI ยังคงใช้ความหมายเก่าอยู่

การตั้งชื่อและ mapping

ในตาราง tag mapping ควรมีอย่างน้อยดังนี้

การรับมือกับ malformed/stale tag

ในการใช้งานจริง ปัญหาไม่ได้มีแค่ communication loss แบบตรงไปตรงมา แต่ยังมี ข้อมูลผิดรูปแบบ และ ค่าค้างจากอดีต ด้วย

1. malformed tag

• ชนิดข้อมูลไม่ตรง
• ค่าเทียบเท่า NULL ที่ไม่คาดคิด
• ความยาว string เกินกำหนด
• รูปแบบวันที่เสียหาย

2. stale tag

• หลัง PLC หยุด HMI ยังแสดงค่าเดิมค้างต่อไป
• ค่าก่อน reconnect ดูเหมือนเป็นค่าปัจจุบัน
• ไม่มีเวลาอัปเดตล่าสุดให้ operator เห็น จนเข้าใจสถานะผิด

ดังนั้นใน RFP ควรใส่เรื่องต่อไปนี้

• วิธีแสดง communication quality bit
• วิธีจัดการเวลาอัปเดตล่าสุด
• กฎการแสดงผลเมื่อค่าล้าสมัย
• เงื่อนไขที่ห้ามเขียนค่าเมื่อเกิดความผิดปกติ
• พฤติกรรมของหน้าจอเมื่อ PLC offline

ข้อกำหนดการทำงานเมื่อ PLC offline

แม้ PLC จะ offline ก็ควรออกแบบให้ HMI application เองไม่ล่ม และยังสามารถแสดงได้ว่า

• ขณะนี้ communication loss
• เวลาอัปเดตปกติล่าสุด
• อยู่ในสถานะเขียนไม่ได้
• ห้าม ACK หรือจำกัดการ ACK
• local log จะเก็บต่อหรือหยุดเก็บ

ควรหลีกเลี่ยงสภาพ “มองไม่เห็น PLC = HMI ค้าง” แนวคิดทั่วไปเรื่อง runtime และโครงสร้าง visualization ลักษณะนี้มีการอธิบายในเอกสาร vendor เช่นกันในมุม lifecycle ของ tag และการแสดงผล Siemens Engineering Guideline Siemens WinCC Unified Visualizing Processes

สิ่งที่ควรกำหนดในการออกแบบ alarm

บทความนี้จะมอง alarm ในฐานะเรื่องของการติดตั้งใช้งานและการปฏิบัติการ ไม่ใช่การออกแบบหน้าจอ

แหล่งนิยาม alarm

• ประเมินเงื่อนไขใน PLC แล้วแจ้งสถานะไปยัง HMI
• ประเมิน threshold ที่ฝั่ง HMI
• รวมประเมินบน server ชั้นบน

ไม่ใช่ว่าแบบไหนก็ได้ แต่ต้องกำหนดว่า จุดใดเป็นผู้ตัดสินจริง สำหรับ alarm สำคัญที่เกี่ยวข้องกับการหยุดเครื่อง ความรับผิดชอบมักชัดกว่าหากตัดสินที่ฝั่ง PLC ส่วน alarm เสริมเพื่อการแสดงผลหรือ event เพื่อวิเคราะห์ซ่อมบำรุงอาจทำที่ฝั่ง HMI ได้

ความรับผิดชอบของ ACK

อย่างน้อยควรกำหนดสิ่งต่อไปนี้สำหรับการ acknowledge alarm

• ใครมีสิทธิ์ ACK ได้
• ACK เป็นเฉพาะ terminal นั้น หรือใช้ร่วมกันทุก terminal
• สามารถ ACK ได้หรือไม่หากสาเหตุยังไม่ถูกแก้
• เมื่อกลับสู่ปกติจะลบอัตโนมัติหรือเก็บเป็นประวัติ
• จะเก็บ operation log อะไรบ้าง

สิทธิ์และความสามารถในการ audit

• Operator ดูได้อย่างเดียว
• หัวหน้ากะสามารถ ACK ได้
• วิศวกรสามารถ suppress/disable ได้
• เฉพาะผู้ดูแลระบบเปลี่ยน setting ได้

ควรกำหนดการแยก role แบบนี้ผ่าน สิทธิ์การสั่งงานและการบันทึก ไม่ใช่เพียงลักษณะที่มองเห็นบนหน้าจอ

การเลือก PC hardware และ OS

สิ่งสำคัญของการเปลี่ยนไปใช้ Industrial PC ไม่ใช่ “เลือก PC ที่สเปกสูง” แต่คือ ให้เหมาะกับสภาพหน้างานและแนวทางการกู้คืน

แนวคิดในการเลือก hardware

เงื่อนไขติดตั้งในตู้/นอกตู้

• ตำแหน่งติดตั้ง
• การระบายอากาศภายในตู้
• ระยะห่างจากแหล่งกำเนิดความร้อน
• ความสามารถในการบำรุงรักษา filter
• การเดินสาย
• ความใกล้กับแหล่งสั่นสะเทือน

Storage

• ใช้ SSD หรือไม่
• วิธี backup แบบ image
• ขั้นตอนการเปลี่ยน
• ความเข้ากันได้กับเครื่องสำรอง

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

UPS

การตัดสินใจเรื่อง UPS ไม่ควรมองแค่ว่าใช้ป้องกันไฟดับ แต่ควรแยกตามวัตถุประสงค์ต่อไปนี้

• ต้องการป้องกัน OS เสียหายจากไฟตก/ไฟดับสั้น
• ต้องการปิด log อย่างถูกต้อง
• ให้ PLC ควบคุมต่อไปตามปกติ แต่ปกป้องเฉพาะ HMI
• ต้องจัดความสัมพันธ์กับ safety shutdown sequence

กล่าวคือ การถกเรื่อง UPS ไม่ใช่แค่ “ใส่/ไม่ใส่” แต่เป็นเรื่องว่า ต้องการปกป้องอะไรเมื่อสูญเสียไฟฟ้า

สิ่งที่ควรกำหนดในการเลือก OS

• OS edition
• ผู้ถือ local administrator privilege
• อนุญาต auto login หรือไม่
• สิ่งที่ต้อง auto start
• วิธี sync เวลา
• การจำกัดการใช้ USB
• วิธีจัดการ event log
• ผู้ตัดสินใจเรื่อง patch

การอัปเดต OS ไม่ได้แปลว่า “ยิ่งล่าสุดยิ่งปลอดภัยเสมอ” ในสภาพแวดล้อม OT หลักคิดคือ ต้องประเมินภายใต้ change management แล้วจึงตัดสินใจว่าจะอัปเดตหรือไม่ แนวคิดด้าน security management program ของ asset owner สามารถอ้างอิง IEC 62443-2-1 ได้ IEC 62443-2-1

การจัดการข้อมูลที่ผูกกับรุ่นอุปกรณ์

หากจำเป็นต้องระบุรุ่นผู้ผลิต ควรเขียนให้ชัดว่าเป็นข้อมูล เฉพาะรุ่น

ตัวอย่างเช่น สเปกและเงื่อนไขการติดตั้งของ fanless Industrial PC แตกต่างกันไปในแต่ละรุ่น ข้อมูลของ Beckhoff C6525-0060 ก็เป็นข้อมูลเฉพาะรุ่นนั้น Beckhoff C6525-0060

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

รายการตรวจด้านสิ่งแวดล้อม ความร้อน และไฟฟ้า

หากระบุสิ่งต่อไปนี้ไว้ใน RFP และแผนทดสอบ จะใช้งานได้จริงมากขึ้น

• ตำแหน่งวัดอุณหภูมิในตู้
• วิธีตรวจอุณหภูมิ CPU / storage ขณะรับโหลด
• พฤติกรรมของ runtime ตอนสลับไปใช้ UPS
• การตอบสนองหน้าจอหลังเดินเครื่องต่อเนื่องเป็นเวลานาน
• การยืนยันลำดับ recovery ตั้งแต่ไฟหายจนไฟกลับมา
• การยืนยันขั้นตอน restore หลังเปลี่ยน SSD

Security และ lifecycle

Security ของ HMI ไม่ได้ตัดสินจากแค่ “ผลิตภัณฑ์มี certificate หรือไม่” สิ่งสำคัญในหน้างานคือ ใครเปลี่ยนได้ อัปเดตเมื่อไร และย้อนกลับอย่างไร

นิยาม security ผ่านการปฏิบัติการ

IEC 62443-2-1 กล่าวถึง security program ฝั่ง asset owner IEC 62443-2-1

และในคำแนะนำสำหรับ ICS ของ CISA ก็เน้นประเด็นด้านการปฏิบัติการ เช่น การรู้จักทรัพย์สิน การแยก network การควบคุมการเปลี่ยนแปลง การสำรองข้อมูล และความพร้อมในการกู้คืน CISA ICS Recommended Practices

หัวข้อการปฏิบัติการที่ควรกำหนดสำหรับ HMI / Industrial PC

การจัดการ account

• วิธีจัดการ shared account
• ผู้เก็บรักษา administrator password
• อายุการใช้งานของ account สำหรับ vendor maintenance
• ขั้นตอนยกเลิกสิทธิ์เมื่อพนักงานลาออกหรือย้ายงาน

Change management

• ผู้ยื่นขอ patch OS
• สภาพแวดล้อมทดสอบสำหรับ runtime update
• ผู้อนุมัติกรณีแก้ไขฉุกเฉิน
• ขั้นตอน rollback

Backup

• System image
• HMI project file
• Recipe / setting file
• License information
• Log / history data

สิ่งเหล่านี้ไม่ใช่ backup แบบเดียวกัน การแยกตาม วัตถุประสงค์ของการกู้คืน จะใช้งานได้จริงกว่า

หลีกเลี่ยง arbitrary updates

ความผิดพลาดที่พบบ่อยในหน้างานคือ เจ้าหน้าที่ซ่อมบำรุงหรือ IT อัปเดตด้วยความหวังดี แต่สุดท้ายทำให้ runtime หรือ driver ไม่เข้ากัน

ดังนั้นในสเปกควรเขียนไม่ใช่แค่ “ห้ามอัปเดตตามอำเภอใจ” แต่ให้เขียนว่า อนุญาตเฉพาะการอัปเดตที่เป็นไปตาม change management เท่านั้น

การจัดการ lifecycle

• แนวนโยบายย้ายระบบเมื่อ OS หมดระยะ support
• ระยะเวลาที่ตรึงเวอร์ชัน runtime
• เงื่อนไขการ reissue license
• ขั้นตอน apply image ลงเครื่องทดแทน
• ขั้นตอนเปลี่ยนไปยังรุ่น successor

Lifecycle ไม่ได้สิ้นสุดตอนส่งมอบเครื่องจักร สำหรับ HMI บน Industrial PC จะมี timing ของการเปลี่ยน hardware, OS, runtime และ PLC ที่ไม่ตรงกัน จึงต้องกำหนดให้ชัดว่า ใครเป็นผู้ตัดสินใจปรับแก้ และเมื่อเกิด trigger แบบใด

แผน migration

เมื่อย้ายจากพาแนลแบบรวมอุปกรณ์ไปสู่ Industrial PC งานนี้ไม่ได้จบแค่ย้ายหน้าจอ แผน migration ควรมองเป็น 4 ชั้นคือ การเชื่อมต่อ ฟังก์ชัน การบำรุงรักษา และความต่อเนื่องในการเดินเครื่อง

ขั้นตอน migration แบบเป็นลำดับ

1. ทำบัญชีทรัพย์สินของระบบเดิม

• รายการหน้าจอปัจจุบัน
• รายการ tag ที่ใช้งาน
• รายการ alarm
• รายการ recipe / setting
• สิทธิ์ผู้ใช้
• ทรัพยากรด้านภาษา
• วิธี backup เดิม

2. ระบุจุดที่ไม่เข้ากัน

• ความต่างของ communication driver
• ความต่างของชนิด tag
• ความต่างของสเปก alarm history
• ความต่างของ font และการแสดงผลหลายภาษา
• ความต่างของรูปแบบไฟล์ recipe
• ความต่างของโครงสร้าง license

3. ทดสอบแบบขนาน

• ตรวจเฉพาะการเชื่อมต่อ PLC ก่อน
• ตรวจเฉพาะ alarm หลักก่อน
• ตรวจเฉพาะ recovery หลังไฟดับก่อน
• ตรวจเฉพาะปลายทางเก็บ log ก่อน

4. ตัดสินใจรูปแบบการสลับใช้งาน

• สลับทั้งหมดครั้งเดียว
• สลับเป็นรายเครื่อง
• สลับในช่วงหยุดไลน์
• สลับโดยมีช่วงที่ใช้ HMI เดิมควบคู่กัน

จุดที่ migration มักล้มเหลว

ยก tag เดิมมาทั้งชุดโดยไม่ทบทวน

Tag ที่ใช้งานได้ใน HMI เดิม อาจชนกันหรือซ้ำซ้อนเมื่อรวมศูนย์บนระบบ PC ดังนั้นระหว่าง migration ควร normalize tag dictionary ใหม่หนึ่งรอบ เพื่อให้งานขั้นถัดไปจัดการง่ายกว่า

แปลเฉพาะข้อความ alarm แล้วจบ

ในการรองรับหลายภาษา ไม่ควรตรวจเฉพาะข้อความที่แสดง แต่ต้องรวม คำอธิบายสิทธิ์การสั่งงาน ข้อความตอนกู้คืน และบริบทของ error code ด้วย

เลื่อนการทดสอบ backup ไปเป็นขั้นสุดท้าย

สิ่งที่สำคัญที่สุดแต่ถูกเลื่อนบ่อยที่สุดคือ เวลาพังแล้วสามารถกู้กลับได้หรือไม่ ในแผน migration ควรกำหนดแนวทาง recovery ให้ชัดก่อนการยืนยันฟังก์ชันด้วยซ้ำ

แนวคิดที่เกี่ยวข้องกับการติดตั้งใช้งาน software

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

ขอบเขตความรับผิดชอบของ supplier

สิ่งสำคัญที่สุดในการจัดซื้อไม่ใช่แค่การเลือก vendor แต่คือ วิธีเขียนขอบเขตความรับผิดชอบ หากส่วนนี้ไม่ชัด ตอน commissioning จะเกิดการโยนปัญหากันไปมาว่าเป็น “ปัญหา PLC” “ปัญหา HMI” หรือ “ปัญหา network”

รูปแบบการแบ่งความรับผิดชอบที่แนะนำ

HMI vendor

• สร้าง HMI runtime
• ติดตั้งใช้งานหน้าจอ
• ทำ tag mapping
• ตั้งค่า alarm และ history
• ติดตั้งใช้งานสิทธิ์ผู้ใช้
• จัดทำคู่มือ backup / restore
• จัดทำเอกสารเพื่อ FAT

PLC vendor หรือผู้รับผิดชอบระบบควบคุม

• นิยาม PLC variable
• Logic การตัดสิน alarm
• เงื่อนไขอนุญาตให้เขียนค่า
• ยืนยันการเชื่อมต่อสื่อสาร
• ให้ safety สมบูรณ์เมื่อ PLC หยุด

เจ้าของเครื่องจักร / ผู้ใช้งาน

• อนุมัติโครงสร้างสิทธิ์
• อนุมัติข้อความแต่ละภาษา
• ตัดสิน requirement เรื่องการเก็บ log
• ตัดสินนโยบาย patch
• ร่วม SAT และตัดสินใจรับมอบ

ผู้รับผิดชอบ IT/OT infrastructure

• ออกแบบ IP
• ตัดสินใจเรื่อง join domain
• Time synchronization
• นโยบาย remote connection
• บำรุงรักษา server / storage

ประเด็นที่ควรเขียนให้ชัดในการแบ่งความรับผิดชอบ

• ความรับผิดชอบของการแสดงผล HMI เมื่อ PLC offline
• ขอบเขตเมื่อ network ขาด
• ผู้ตัดแยกปัญหาเบื้องต้นเมื่อ OS ขัดข้อง
• ความรับผิดชอบในการ reconfigure เมื่อ license สูญหาย
• ผู้รับผิดชอบอนุมัติความผิดพลาดจากการแปล
• ช่องทางแก้ไข defect ที่พบใน FAT

เอกสารส่งมอบ

ในเงื่อนไขการรับมอบ ควรมีอย่างน้อยดังนี้

• System configuration diagram
• ตาราง tag mapping
• รายการ alarm
• รายการ user role
• คู่มือ backup
• คู่มือ restore
• รายการ version
• ข้อมูลการเก็บรักษา license
• บันทึก FAT
• บันทึก SAT
• เงื่อนไขการส่งมอบ source / project

แม่แบบ RFP

ด้านล่างคือตัวอย่างหัวข้อ RFP ที่ฝ่ายจัดซื้อสามารถหยิบไปใช้ได้ทันที และสามารถกระจายเป็นตารางให้ vendor กรอกตอบกลับได้

1. ภาพรวมโครงการ

• ชื่ออุปกรณ์เป้าหมาย
• ติดตั้งใหม่ / ปรับปรุง / ย้ายตำแหน่ง
• เงื่อนไขการเดินเครื่อง
• ระยะเวลาหยุดเพื่อสลับระบบที่ยอมรับได้
• ภาษาที่ใช้งาน

2. ขอบเขตงานที่ให้เสนอ

• HMI runtime
• Industrial PC หรือ panel
• การตั้งค่าการสื่อสาร
• การติดตั้งใช้งานหน้าจอ
• Alarm / log
• การจัดการผู้ใช้
• FAT/SAT
• การฝึกอบรม
• การบำรุงรักษา

3. รายการที่ต้องระบุในข้อเสนอ

• สถาปัตยกรรมการรันระบบ
• Hardware configuration
• OS configuration
• ชื่อผลิตภัณฑ์ runtime / version
• รูปแบบ license
• วิธีเชื่อมต่อ PLC
• วิธี backup
• วิธี recovery
• ข้อสมมติของ network
• การแบ่งขอบเขตความรับผิดชอบ

4. Functional requirement

• จำนวนและประเภทของหน้าจอ
• วิธีประมาณจำนวน tag
• วิธีนิยาม alarm
• วิธีจัดเก็บ history
• ความต้องการ export เช่น CSV/PDF
• การสลับหลายภาษา
• สิทธิ์ผู้ใช้
• พฤติกรรมเมื่อ PLC offline
• Recovery หลังไฟดับ
• กฎการแสดง malformed/stale tag

5. ข้อกำหนดด้าน security และ operation

• รูปแบบ account
• สิทธิ์ local administrator
• นโยบายการใช้ USB
• Flow การใช้ patch
• Change management
• ความจำเป็นของ audit log
• ความถี่ backup และผู้รับผิดชอบขั้นตอน

6. ผลงานส่งมอบ

• Configuration diagram
• I/O / tag list
• Alarm list
• Screen list
• นิยามสิทธิ์
• Version list
• ขั้นตอน backup / restore
• ขั้นตอนและบันทึก FAT/SAT
• เอกสารฝึกอบรม

7. Format การตอบของ vendor

เพื่อให้เปรียบเทียบได้ง่าย ควรใช้ format เดียวกันแทนการเขียนอิสระ

FAT/SAT test matrix

FAT/SAT ไม่ควรตรวจแค่ว่าหน้าจอขึ้นหรือไม่ แต่ต้อง ตรวจการเดินเครื่อง ความผิดปกติ การกู้คืน สิทธิ์ และการบำรุงรักษา ด้วยวิธีที่วัดและยืนยันได้

มุมมองที่ควรตรวจใน FAT

FAT ดำเนินการก่อนส่งมอบจากโรงงานผู้ผลิต ในสภาพแวดล้อมของ vendor หรือระบบจำลอง หากเป็นไปได้ควรใช้ PLC เครื่องจริง ถ้ายากจึงใช้ simulator หรือ force value

มุมมองที่ควรตรวจใน SAT

SAT ดำเนินการหลังติดตั้งที่หน้างานจริง โดยตรวจภายใต้การ wiring จริง network จริง และสิทธิ์ผู้ใช้จริง ประเด็นที่ FAT มองไม่เห็น เช่น time synchronization การสลับ UPS การแสดงผลหลายภาษา และเส้นทางการทำงานของผู้ใช้งานหน้างาน ควรอยู่ใน SAT

ตัวอย่าง FAT/SAT test matrix

วิธีเขียนเกณฑ์การรับมอบ

ไม่จำเป็นต้องล็อกค่าตัวเลขตายตัวไว้ในบทความหลักเสมอไป แต่สามารถเขียนเกณฑ์รับมอบของแต่ละการทดสอบได้ดังนี้

• ต้องตรงกับสเปกที่ระบุใน RFP
• ต้องไม่ขัดแย้งกับ tag list, alarm list และนิยามสิทธิ์
• การแสดงผลเมื่อเกิดความผิดปกติต้องเป็นไปตามกฎที่ผู้ใช้อนุมัติไว้
• ขั้นตอน backup / restore ต้องทำซ้ำได้จริง
• ต้องไม่เป็นอุปสรรคต่อการเดินเครื่องต่อเนื่องในสภาพแวดล้อมจริง

ต้นทุนและ change control

การย้ายไปใช้ Industrial PC ไม่สามารถตัดสินได้จากราคาเริ่มต้นเพียงอย่างเดียว เพราะความต่างของต้นทุนมักอยู่ที่ ค่าการเปลี่ยนแปลงและค่าบำรุงรักษา มากกว่าค่าติดตั้งเริ่มต้น

วิธีมองโครงสร้างต้นทุน

เนื่องจากมูลค่าเงินจริงต่างกันไปในแต่ละโครงการ ด้านล่างจึงเรียบเรียงเป็นหมวดรายการ

ต้นทุนติดตั้งเริ่มต้น

• ตัวเครื่อง Industrial PC
• Monitor / touch display
• License ของ HMI runtime
• Communication driver หรือ option เพิ่มเติม
• ชั่วโมงงานออกแบบและติดตั้งใช้งาน
• ชั่วโมงงาน FAT/SAT
• ชั่วโมงงานเริ่มเดินระบบหน้างาน

ต้นทุนด้านบำรุงรักษา

• เครื่องสำรอง
• งานรองรับการ reissue license
• สื่อและที่เก็บ backup
• สัญญา onsite maintenance
• การทดสอบซ้ำเมื่อมีการดัดแปลง
• การประเมิน OS update
• การอัปเดตคำแปล

ต้นทุนการเปลี่ยนแปลงในอนาคต

• เพิ่ม PLC tag
• เพิ่มหน้าจอ
• เปลี่ยน role สิทธิ์
• เปลี่ยนวิธีเก็บ log
• รวมเข้ากับ server กลาง
• ย้ายไปยัง PC รุ่นถัดไป

การปฏิบัติจริงของ change control

Change management ไม่ใช่เรื่องขององค์กรขนาดใหญ่เท่านั้น อย่างน้อยหากทำตารางปฏิบัติการดังนี้ไว้ จะช่วยให้หน้างานเสถียรมากขึ้น

คำถามที่ควรถามตอนเปรียบเทียบใบเสนอราคา

• Project file รวมอยู่ในสิ่งส่งมอบหรือไม่
• เงื่อนไขการย้าย license คืออะไร
• ใครเป็นผู้ดำเนินการ restore ไปยังเครื่องทดแทน
• หลัง SAT มีการแก้ไขเล็กน้อยรวมให้กี่ครั้ง
• หากเพิ่ม tag จะคิดราคาอย่างไร

FAQ (5 คำถามแบบเจาะจง)

Q1. หากย้ายจากพาแนลแบบรวมอุปกรณ์ไปเป็น Industrial PC จะทำให้บำรุงรักษาง่ายขึ้นเสมอหรือไม่?

ไม่เสมอไป การใช้ PC ทำให้จัดการ backup และการขยายระบบได้ง่ายขึ้นก็จริง แต่จะเพิ่มภาระเรื่อง OS, license และการควบคุมการอัปเดตด้วย ความสามารถในการบำรุงรักษาจะดีขึ้นก็ต่อเมื่อกำหนดชัดว่าใครดูแลส่วนไหน และ IT/OT เข้ามาเกี่ยวข้องอย่างไร

Q2. สามารถให้ฝั่ง HMI ถือปุ่มหยุดเพื่อความปลอดภัยหรือสถานะ safety release ได้หรือไม่?

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

Q3. การปล่อยให้ OS patch อัปเดตอัตโนมัติเป็นระยะโดยไม่หยุด จะปลอดภัยกว่าหรือไม่?

สำหรับ OT ไม่สามารถสรุปเช่นนั้นได้เสมอไป ควรตัดสินใจภายใต้ change management โดยกำหนดการประเมินผลกระทบ การทดสอบ ขั้นตอนปฏิบัติ และ rollback ก่อนใช้งาน IEC 62443-2-1 CISA ICS Recommended Practices

Q4. ใน FAT ควรตรวจอะไรถึงระดับไหนเพื่อให้ SAT ง่ายขึ้น?

อย่างน้อยควรปิดประเด็นต่อไปนี้ให้จบใน FAT ได้แก่ tag mapping, การเกิด alarm และ ACK, สิทธิ์ผู้ใช้, backup / restore, recovery หลังไฟดับ และพฤติกรรมเมื่อ PLC offline หากไปตรวจสิ่งเหล่านี้เอาใน SAT จะกลายเป็นการใช้เวลาหยุดหน้างานไปค้นหาข้อผิดพลาดพื้นฐาน

Q5. หากต้องรองรับภาษาไทย อังกฤษ และญี่ปุ่น แค่ส่งมอบตารางคำแปลก็เพียงพอหรือไม่?

ไม่เพียงพอ ควรรวมการตรวจไม่ใช่แค่ข้อความ alarm แต่รวมถึงข้อความบนปุ่ม dialog ยืนยัน หน่วย รูปแบบวันที่ ตัวอักษรตกหล่น การตัดบรรทัด ความสามารถในการค้นหา และข้อความที่ปรากฏใน operation log ด้วย การทดสอบสลับภาษาควรทำทั้งใน FAT และ SAT

สรุปและช่องทางติดต่อ

สิ่งที่สำคัญจริง ๆ ในการย้าย HMI ไปสู่ Industrial PC ไม่ใช่ความสวยของหน้าจอ แต่คือ สถาปัตยกรรม การจัดการความหมายของ PLC tag การปฏิบัติการ alarm, OS/license, backup / restore, change management, การแบ่งขอบเขตความรับผิดชอบ และความสามารถในการตรวจยืนยันผ่าน FAT/SAT ทั้งพาแนลแบบรวมอุปกรณ์ Industrial PC และ thin client / central server ต่างก็มีบริบทที่เหมาะสมของตนเอง ไม่มีแบบใดถูกต้องเสมอไป ในมุมของฝ่ายจัดซื้อและวิศวกรรมการผลิต ปัจจัยชี้ขาดไม่ใช่แค่การเปรียบเทียบวิธี แต่คือการเขียนสเปกให้ตอบได้ว่า “เมื่อเกิดปัญหา ใครจะกู้คืนอะไร อย่างไร” โดยเฉพาะในโรงงานไทย หากกำหนดเรื่องหลายภาษา โครงสร้างงานซ่อมบำรุงหน้างาน การกู้คืนหลังไฟดับ ความรับผิดชอบด้าน network และ boundary กับ vendor ให้ชัดก่อน จะช่วยลดการพึ่งพาคนเฉพาะรายหลังเริ่มใช้งานได้มาก

หากกำลังวางแผนปรับปรุงเครื่องจักรหรือโครงการติดตั้งใหม่ และต้องการเดินงานร่วมกันตั้งแต่การจัดทำ RFP สำหรับ HMI / Industrial PC การคัดเลือก vendor การจัดระเบียบขอบเขตความรับผิดชอบ ไปจนถึงการลงรายละเอียดมุมมอง FAT/SAT สามารถปรึกษาได้ตั้งแต่ช่วงร่าง requirement เบื้องต้น เราสามารถช่วยจัดโครงสร้างเปรียบเทียบแนวทางติดตั้งใช้งานให้เหมาะกับสภาพหน้างานจริงได้

https://tomastc.com/th/contact/

Sources

• ISA-101 Standards
• Siemens WinCC Unified Engineering Guideline
• Siemens WinCC Unified Visualizing Processes
• Ignition Perspective Workstation
• Beckhoff C6525-0060
• IEC 62443-2-1
• CISA ICS Recommended Practices