พัฒนาหน้าจอ HMI สำหรับโรงงานไทย: RFP และการตรวจรับ FAT/SAT

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

บทความนี้จัดทำแนวทางสำหรับผู้จัดการโรงงาน วิศวกรผลิต ซ่อมบำรุงและควบคุม ฝ่ายจัดซื้อ ตลอดจนผู้อนุมัติจากสำนักงานใหญ่ญี่ปุ่น โดยครอบคลุมขอบเขตการออกแบบ HMI ตาราง RFP เอกสารส่งมอบ การเปรียบเทียบผู้รับจ้างอย่างเป็นกลาง FAT/SAT และแบบจำลองภาระงานที่ตรวจสอบที่มาได้ บทความไม่ได้จัดอันดับยี่ห้อ ฟังก์ชันจริงขึ้นอยู่กับรุ่น ใบอนุญาต เวอร์ชันซอฟต์แวร์ โปรโตคอล ฮาร์ดแวร์ และรูปแบบติดตั้ง จึงต้องตรวจสอบความเข้ากันได้ก่อนจัดซื้อ

งานพัฒนาหน้าจอ HMI ครอบคลุมอะไรบ้าง

HMI หรือ Human-Machine Interface คือจุดที่คนมองเห็นสภาพเครื่องจักร ตัดสินใจ และส่งคำสั่งที่ได้รับอนุญาต ดังนั้นงานไม่ได้มีเพียงการวางปุ่มหรือเลือกสี แต่รวมถึงแบบจำลองสถานะ ลำดับชั้นของหน้าจอ ขอบเขตข้อมูลกับ PLC ระบบ Alarm บทบาทผู้ใช้ ภาษา ประวัติ สูตรการผลิต การสำรองและกู้คืน การควบคุมการเปลี่ยนแปลง การฝึกอบรม และการตรวจรับ

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

เหตุใดการคิดตามจำนวนหน้าจอจึงไม่เพียงพอ

โครงการที่มี 20 หน้าจอเท่ากันอาจใช้แรงงานต่างกันมาก โครงการหนึ่งอาจแสดงสถานะพื้นฐาน แต่อีกโครงการมีการเปลี่ยน Recipe, Audit Trail, สามภาษา, Remote Viewing, Trend, สิทธิ์ผู้ใช้ และการกู้คืน จำนวนหน้าจอไม่บอกว่าได้รวมเรื่องต่อไปนี้หรือไม่

• เฉพาะการผลิตปกติ หรือรวม Changeover, Manual, Maintenance และ Abnormal Recovery
• สถานะ Run/Stop เท่านั้น หรือรวม Starting, Waiting, Interlock, Fault และ Recovery Confirmation
• แสดงข้อความ Alarm อย่างเดียว หรือรวมลำดับความสำคัญ สาเหตุ ผลกระทบ วิธีตอบสนอง สิทธิ์รับทราบ และประวัติ
• ผู้รับผิดชอบคำศัพท์หลายภาษา ฟอนต์ การป้อนข้อมูล ความยาวข้อความ และการอนุมัติ
• ผู้รับผิดชอบนิยามแท็ก Scale, Quality, Update Rate และการแสดงค่าเก่าเมื่อสื่อสารขาด
• Source File, Build Procedure, License, Version Control และการทดสอบ Restore

ราคาต่อหน้าจอที่ต่ำจึงไม่ได้หมายความว่าต้นทุนรวมต่ำ ขอบเขตที่หายไปมักกลับมาในรูป Change Order กำหนดการล่าช้า การใช้งานผิด หรือไฟล์โครงการที่กู้คืนไม่ได้

แกนกลางของ RFP คือการสอบกลับจาก Requirement ถึง Test

เอกสารที่มีค่าที่สุดคือสายการสอบกลับดังนี้

สถานการณ์เดินเครื่อง → สถานะอุปกรณ์ → วัตถุบนหน้าจอ → แท็ก PLC → สิทธิ์ → Alarm/Action → หลักฐาน FAT/SAT

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

ตารางขอบเขต HMI ที่ผู้ซื้อต้องกำหนด

RFP ที่ดีต้องแยกข้อมูลที่โรงงานจะให้ งานออกแบบที่ผู้รับจ้างรับผิดชอบ และเอกสารที่ต้องอนุมัติร่วมกัน ตารางต่อไปใช้เป็น Checklist ในการประชุมเริ่มต้นได้

กำหนดสถานะก่อนเลือกสี

HMI ที่ดีต้องทำให้ผู้ปฏิบัติงานรู้ว่าเครื่องอยู่สถานะใด เหตุใดจึงอยู่สถานะนั้น และทำอะไรต่อได้ เริ่มจากการนิยาม Production, Standby, Stopped, Faulted, Startup Preparation, Waiting for Interlock, Manual Intervention, Communication Failure และ Stale Data ตามสถานการณ์จริง

อย่าใช้สีเป็นสัญญาณเพียงอย่างเดียว เพราะแสงสะท้อน คุณภาพจอ ความแตกต่างด้านการมองสี และ Alarm หลายรายการอาจทำให้ตีความผิด ควรใช้สีร่วมกับรูปทรง ป้าย ตำแหน่ง และ Animation ที่ควบคุมไว้ ทำภาวะปกติให้สงบ และเน้นเฉพาะสิ่งที่ต้องลงมือ พร้อมบันทึกกฎไว้ใน HMI Philosophy และ Style Guide

ออกแบบ HMI โรงงานโดยคำนึงถึงถุงมือ ระยะมอง และการกดผิด

พื้นที่ผลิตในไทยอาจมีถุงมือ ความร้อน ฝุ่น แสงสะท้อน การยืนใช้งาน และผู้ใช้หลายภาษา Touch Target ที่เล็ก คำสั่งอันตรายที่อยู่ชิดกัน หรือเงื่อนไขที่ต้อง Scroll จึงจะเห็น อาจผ่านรีวิวบนคอมพิวเตอร์แต่ล้มเหลวหน้างาน ต้องกำหนดขนาดและระยะห่าง การยืนยัน Hold-to-Act หรือการอนุมัติสองขั้นตามความเสี่ยง รวมถึงบทบาทระหว่างคำสั่งบน HMI กับสวิตช์จริง

อย่างไรก็ตาม HMI ไม่ใช่ Safety Function ด้วยตัวเอง Logic และ Validation ด้านความปลอดภัยต้องอยู่ใน Safety System ที่เหมาะสมและได้รับการทบทวนโดยผู้มีคุณสมบัติ HMI ช่วยแสดงสถานะความปลอดภัยได้ แต่ไม่ใช่อุปกรณ์แทน Safety Circuit

ออกแบบ Alarm HMI ให้ผู้ใช้ตอบสนองได้

Alarm ไม่ควรเป็นเพียงรายการข้อความจาก PLC ต้องกำหนดเจ้าของความรับผิดชอบตั้งแต่ความจำเป็น ลำดับความสำคัญ การตอบสนองที่คาดหวัง การนำไปใช้ การทดสอบ การติดตามระหว่างใช้งาน การเปลี่ยนแปลง และประวัติ บทความนี้แปลงสายความรับผิดชอบดังกล่าวให้เป็นข้อกำหนด RFP และการทดสอบรับมอบ

Alarm แต่ละรายการควรมีอย่างน้อย:

• ID ไม่ซ้ำ เงื่อนไขเกิดและคืนสู่ปกติ Delay และ Deadband
• Priority และเหตุผลในการกำหนด
• การตอบสนองที่คาดหวังจาก Operator
• สาเหตุที่เป็นไปได้และจุดที่ต้องตรวจ
• ผลกระทบหากไม่ดำเนินการ
• บทบาทที่ Acknowledge ได้และหลักฐานการรับทราบ
• กฎ Shelving, Suppression และ Maintenance Mode
• ขั้นตอน FAT/SAT สำหรับ Activate, Acknowledge, Return และ History

ถ้าต้องการเพียงบันทึกการเปลี่ยนสถานะให้เป็น Event ถ้าเป็นข้อมูลที่ไม่ต้องตอบสนองให้เป็น Message และสงวน Alarm สำหรับเหตุที่ต้องลงมือภายในเวลาที่เหมาะสม มิฉะนั้น Alarm สำคัญจะหายไปใน Alarm Flood ควรจัดการ Alarm Master แยกจาก Graphic และเก็บเหตุผลการเปลี่ยนพร้อมผู้อนุมัติ

HMI หลายภาษาสำหรับสำนักงานใหญ่ญี่ปุ่นและ Operator ไทย

Localization ไม่ใช่การแทนข้อความก่อนส่งมอบ ป้ายญี่ปุ่นที่สั้นอาจยาวขึ้นมากในภาษาไทยหรืออังกฤษและล้นปุ่ม ตาราง Trend หรือ Popup ต้องทดสอบสระและวรรณยุกต์ไทย เครื่องหมายกำกับเสียงเวียดนาม และคำประสมอังกฤษด้วย Runtime และฟอนต์จริง

Glossary ที่ควบคุมต้องกำหนดคำอนุมัติหนึ่งคำต่อเครื่อง สถานะ และคำสั่ง การอนุมัติควรรวมผู้ที่ใช้เครื่องจริง ไม่ใช่ผู้แปลสำนักงานใหญ่เท่านั้น เอกสารส่งมอบต้องระบุผู้อนุมัติภาษา Workflow การเปลี่ยน Fallback Language วิธี Export/Import String และวิธีนำกลับเข้า Source Control

การตรวจรับหลายภาษาควรประกอบด้วย:

1. เปิดทุกหน้าจอในทุกภาษาและบันทึกข้อความล้น ซ้อน หรือ Key ที่ยังไม่แปล
2. ตรวจการประกอบอักษรไทยและเวียดนาม รวมถึง Search/Input หากอยู่ในขอบเขต
3. ตรวจ Alarm History, Trend, Recipe, Audit Log และ PDF/CSV Export
4. สลับภาษาระหว่างเดินระบบโดยสถานะและค่าที่กรอกไม่เสีย
5. ตรวจว่า Glossary ที่เปลี่ยนถูกกระจายไปยังหน้าจอ Manual และ Training Material ภายใต้เวอร์ชันเดียวกัน

แบ่งความรับผิดชอบ PLC แท็ก และข้อมูลให้ชัด

HMI กับ PLC ทำงานใกล้ชิดกัน แต่ขอบเขตที่คลุมเครือทำให้การวิเคราะห์ปัญหาหยุดชะงัก Tag Dictionary ควรมี Logical Name, PLC Address, Data Type, Unit, Scaling, Read/Write Direction, Update Rate, Quality, Owner และหน้าจอที่ใช้ ต้องแยกค่าที่ HMI คำนวณ Interlock ที่ PLC รับประกัน และ Recipe จากระบบระดับบน

หากรวมการแก้ PLC ให้กำหนด Source Control, Online Change, Rollback, I/O Verification และผลกระทบต่อเครื่องเดิมเป็นขอบเขตแยก อ่านแนวทาง จ้างพัฒนาโปรแกรม PLC ในประเทศไทย และหากเป็นอุปกรณ์เก่าให้ใช้ แนวทางเปลี่ยนและ Retrofit PLC เพื่อวางแผน Compatibility และ Downtime

เมื่อการสื่อสารขาด ห้ามแสดง Last Good Value เหมือนเป็นค่าปัจจุบัน ต้องแยก Stale, Bad Quality และ Disconnected พร้อมกำหนดว่าเมื่อใดต้อง Inhibit Command นี่คือข้อกำหนดเพื่อป้องกันการตัดสินใจผิด ไม่ใช่เรื่องความสวยงาม

เอกสารและไฟล์ที่ต้องส่งมอบ

ระบุรูปแบบ ภาษา ไฟล์ต้นฉบับที่แก้ไขได้ และผู้อนุมัติใน Purchase Scope ไฟล์ PDF อย่างเดียวไม่เพียงพอสำหรับการเปลี่ยนในอนาคต

เปรียบเทียบผู้รับจ้างด้วย RFP ไม่ใช่จัดอันดับยี่ห้อ

ข้อมูลผลิตภัณฑ์จาก Mitsubishi Electric GOT3000, Rockwell Automation FactoryTalk Optix และ Siemens WinCC Unified แสดงตัวอย่างความสามารถ เช่น จอความละเอียดสูง ภาพหลายภาษา Alarm, Version Management, OPC UA, Web Client, Central Deployment และการเชื่อม PLC สิ่งเหล่านี้เป็นตัวอย่าง ไม่ใช่ Requirement สากลหรือการรับประกันว่าทุกรุ่นมี ต้องตรวจรุ่น License, Version, Protocol และ Target Runtime

ในการ Demo ให้ขอดู Communication Loss, Denied Command, ข้อความไทยยาว, Alarm Load และ Restore ไม่ใช่เฉพาะ Overview ที่สวยในสภาวะปกติ

Remote Access และ Cybersecurity ต้องอยู่ใน RFP ตั้งแต่ต้น

เมื่อ HMI เชื่อม Plant Network, Historian, Web Client, Cloud หรือ Remote Support ขอบเขตจะมาถึง IT/OT Boundary แหล่งข้อมูลสาธารณะ CISA สำหรับ ICS ครอบคลุม Defense in Depth, Patch Management, Incident Response, Secure Procurement และ Secure Remote Access RFP ควรกำหนดอย่างน้อย:

• บัญชีรายบุคคลและบทบาท รวมวิธีควบคุม Shared Administrator
• การอนุมัติ Remote Access, Time Limit, MFA และ Session Record
• ทิศทางสื่อสารและ Port ที่อนุญาตระหว่าง HMI, PLC, Historian และระบบบน
• ขั้นตอน USB/File Transfer, Malware Check และ Application Allow-list
• ผู้รับผิดชอบ Patch และ Test Environment ของ OS, Runtime และ Project
• Encryption, Location, Retention และเจ้าของ Recovery ของ Backup
• ผู้ติดต่อเมื่อเกิด Incident การเก็บ Evidence การ Isolate และ Recovery

การอนุญาต Remote Control หรือ View Only ไม่ใช่การตัดสินใจเพื่อความสะดวก ต้องพิจารณา Hazard, Safety Design, ผู้ยืนยันหน้างาน, Latency, Disconnection Behavior และการอนุมัติจากผู้มีคุณสมบัติ

การตรวจรับ FAT/SAT สำหรับ HMI

FAT ตรวจว่าแบบทำงานตามข้อกำหนดใน Development หรือ Pre-shipment Environment ส่วน SAT ตรวจ Solution ที่รวมกับ PLC, Network, Equipment, Account และสภาพหน้างานจริง ต้องกำหนดขอบเขต Test Data, Simulator, Witness, Evidence Format และ Retest Rule ก่อนสั่งซื้อ

กำหนด Abnormal Recovery เป็นเงื่อนไขผ่าน

Demo สภาวะปกติไม่เปิดเผยจุดอ่อน ต้องตรวจการทำเครื่องหมาย Stale Data, พฤติกรรมหลัง Restart, Recipe ที่ค้าง, Ack History และการกู้คืนโดยไม่เกิดคำสั่งอัตโนมัติที่ไม่ปลอดภัย ทุกการทดสอบต้องผ่าน Risk Assessment และวิธีที่อนุมัติ

Backup ไม่ผ่านเพียงเพราะมีไฟล์ ต้องกู้ Software, License, Communication Setting และ Project บน Clean Workstation หรือ VM แล้วทำ Startup, Edit, Build และ Download เมื่อปลอดภัย อย่าปล่อยให้ Recovery ขึ้นกับความจำของวิศวกรคนเดียว

สำหรับการรวมหลักฐาน PLC, HMI, I/O และเครื่องจักร อ่าน แนวทางออกแบบ Sequence Control และ FAT และใช้ Requirement ID เดียวกัน

ตัวอย่างสมมติของภาระงาน ไม่ใช่ราคาตลาด

ไม่มีราคาตลาดสากลสำหรับงาน HMI เพราะขึ้นกับ Tag, Scenario, Alarm Rationalization, ภาษา, Runtime, PLC Interface, Recipe, Report, FAT/SAT, Training, Document และ Source Handover ตัวอย่างต่อไปนี้เป็น สมมติฐานเพื่อวางแผน ไม่ใช่ใบเสนอราคาตลาดหรือราคาของ TOMAS TECH

สมมติหนึ่งไลน์ใหม่ หน้าจอหลัก 12 จอ Popup 8 จอ แท็ก PLC 300 จุด Alarm 60 รายการ สามภาษา ไม่มี Style Guide เดิม ทำ FAT หนึ่งครั้งและ SAT หนึ่งครั้ง

56 คน-วันเป็นเพียงสมมติฐาน สิ่งที่ต้องเปรียบเทียบคือแต่ละผู้เสนอราคารวมงานใด ให้โรงงานรับผิดชอบข้อมูลใด และคิด Retest หรือเวลารอหน้างานอย่างไร การแปลง “20 หน้าจอ” เป็น Work Package ทำให้เห็นความต่างนี้

เมื่อเปลี่ยน Requirement ให้ประเมินผลกระทบต่อ Screen, Tag, Language, Alarm, Document และ Retest ตาม ID การแก้ Label กับการเปลี่ยน State Transition หรือ Permission ไม่ควรถูกมองว่าเป็นงานเท่ากัน

ความเสี่ยงเฉพาะของโครงการในประเทศไทย

การอนุมัติสามฝ่าย: สำนักงานใหญ่ โรงงานไทย และผู้รับจ้าง

ถ้าสำนักงานใหญ่กำหนดนโยบาย โรงงานไทยเป็นผู้ตรวจรับ และผู้รับจ้างเป็นผู้พัฒนา ต้องกำหนด Author, Reviewer และ Approver ในแต่ละ Gate ได้แก่ Requirement, Glossary, Prototype, Alarm, FAT และ SAT ตัวอย่างเช่นสำนักงานใหญ่รับผิดชอบนโยบายเครื่อง Operator รับผิดชอบ Usability วิศวกรควบคุมรับผิดชอบ PLC Boundary และ IT รับผิดชอบ Network/Account

Downtime และข้อจำกัดการทดสอบจริง

ไลน์เดิมไม่สามารถสร้าง Fault ทุกชนิดได้อย่างอิสระ จึงต้องตกลง Shutdown Window, Simulator Substitute, Residual Risk ของ Test ที่ทำไม่ได้ และเงื่อนไข Retest ภายหลัง Online Change ต้องมี Backup, Difference Review, Rollback และ Site Authorization

License และ Maintenance Account

Project อาจทำงานบน PC ผู้พัฒนาแต่ขาด Runtime, Driver, Web Client, Historian หรือ Language License ที่โรงงาน บันทึก Product ID, Quantity, Contract Owner, Renewal, Offline Use และการโอนไปเครื่องทดแทนใน Build/Version Manifest ห้ามให้ Recovery ขึ้นกับ Personal Account ของพนักงานผู้รับจ้างเพียงคนเดียว

การกล่าวถึง BOI แบบมีเงื่อนไข

Investment Promotion Guide ฉบับปัจจุบันของ BOI ไทยระบุกิจการที่เกี่ยวกับเครื่องจักรหรืออุปกรณ์ Automation ซึ่งมี Engineering Design, Automation-System Integration และ Control-System Configuration แต่ไม่ได้หมายความว่าโครงการ HMI รายใดจะได้รับสิทธิ์โดยอัตโนมัติ ต้องพิจารณานิติบุคคล กิจกรรม อุปกรณ์ ช่วงเวลายื่นคำขอ และข้อเท็จจริงอื่นเป็นรายกรณีกับ BOI หรือที่ปรึกษาที่เหมาะสม

ขั้นตอนดำเนินโครงการ HMI

1. สำรวจงานและกำหนด Scenario: รวม Shift, Changeover, Cleaning, Maintenance และ Recovery
2. อนุมัติ HMI Philosophy: ตกลง State, Hierarchy, Color, Component, Command, Alarm และภาษาด้วยตัวอย่าง
3. สร้าง Traceability และ Prototype: เชื่อม Requirement, Tag, Permission, Alarm และ Test ก่อน Implement เต็ม
4. พัฒนาแบบ Iteration: เริ่มจาก Reusable Component และ Representative Scenario พร้อมรีวิวกับผู้ใช้ภาษา
5. ทำ FAT: จำลอง Normal, Abnormal, Communication, Permission, Language และ Recovery
6. ทำ SAT: ใช้ PLC, I/O, Network, Account และสภาพหน้างานจริง
7. Training/Handover: แยก Operator, Maintenance, Admin และ Change Control พร้อมสาธิต Restore
8. Management of Change: เก็บ Requirement ID, Version, Reason, Approval และ Retest Evidence หลัง Startup

FAQ เกี่ยวกับการพัฒนาหน้าจอ HMI

พัฒนาหน้าจอ HMI คือการออกแบบหน้าตาทัชสกรีนเท่านั้นหรือไม่

ไม่ใช่ Layout เป็นเพียงส่วนหนึ่ง ขอบเขตที่สมบูรณ์รวม Scenario, State, PLC Tag, Permission, Alarm, ภาษา, History, Remote Access, Backup, FAT/SAT, Training และ Editable Source

เปรียบเทียบราคาจ้างพัฒนา HMI ด้วยราคาต่อหน้าจอได้หรือไม่

ไม่ควรใช้เพียงอย่างเดียว Tag Behavior, Dynamic Object, Recipe, Report, Alarm, ภาษา, Permission, Communication, Test และ Document ทำให้หน้าจอจำนวนเท่ากันใช้แรงงานต่างกัน ต้องเทียบ Work Package, Assumption, Exclusion, Retest และ On-site Support

ออกแบบ HMI โรงงานควรเริ่มจากอะไร

เริ่มจากผู้ใช้ Operating Scenario, Equipment State, Permitted Command และ Abnormal Action ก่อนเลือกสีหรือ Widget จากนั้นจึงออกแบบ Hierarchy, Navigation, Reusable Object และ Visual Rule

ออกแบบ Alarm HMI ต้องขอเอกสารอะไร

ขอ Alarm Master ที่มี Priority Basis, Cause, Consequence, Operator Response, Acknowledgement Right, Suppression Rule, History, FAT/SAT Step และ Change Record พร้อม Rationalization ว่าทุก Alarm ต้องการ Action จริง

ควรจ้าง PLC Software และ HMI กับบริษัทเดียวกันหรือไม่

บริษัทเดียวอาจลดรอยต่อ แต่ไม่ใช่ข้อบังคับ ถ้าแยกผู้รับจ้าง ต้องกำหนด State Model, Tag Dictionary, Cause & Effect, Version Control, Integration Test และ Troubleshooting Ownership ใน RFP

งานสนับสนุนติดตั้งเครื่องจักรควรเน้น FAT หรือ SAT

ต้องมีทั้งสอง FAT พบข้อผิดพลาดตอนแก้ง่าย ส่วน SAT ตรวจเครื่องจริง Network จริง Account จริง และ Operator จริง ถ้าทำ SAT อย่างเดียว Defect จะไปรวมในช่วง Downtime แต่ FAT อย่างเดียวจะไม่เห็นความต่างของหน้างาน

ใช้ HMI เป็น Safety Function ได้หรือไม่

HMI ช่วยสื่อสารสถานะ แต่ไม่แทน Safety System Logic, Circuit, Stop Function และ Validation ต้องได้รับการตรวจโดยผู้มีคุณสมบัติตามมาตรฐานและ Risk Assessment ที่เกี่ยวข้อง

รับ Source File แล้วถือว่าส่งมอบเสร็จหรือไม่

ยังไม่เสร็จ ต้องมี Software/Version, License, Driver, Communication Setting, Build Instruction, Checksum, Backup และหลักฐาน Clean Restore วิศวกรฝั่งผู้ซื้อควรเปิด Build และแก้ไขเล็กน้อยแบบควบคุมได้

สรุป: ตรวจรับ Operating Interface ไม่ใช่เพียงชุดหน้าจอ

คุณภาพการพัฒนาหน้าจอ HMI ไม่ได้วัดจากความสวยหรือจำนวนจอ ต้องสอบกลับจาก Operating Scenario ไปยัง State, Screen Object, PLC Tag, Permission, Alarm, ภาษา, Restore และ Test Evidence และพิสูจน์ Abnormal Behavior, Localization, Communication Loss, Restart และ Clean Backup Restore ใน FAT/SAT RFP ต้องกำหนด Deliverable, Ownership Boundary, Version, License, Source Ownership และ Change Control เพื่อให้เปรียบเทียบผู้รับจ้างบนฐานเดียวกัน

หากกำลังวางแผน HMI สำหรับโรงงานในไทย แม้ยังไม่มี Screen Inventory หรือ Tag List ที่สมบูรณ์ ก็สามารถเริ่มจากการจัด Scenario หน้างาน ขอบเขต RFP และเกณฑ์ FAT/SAT ได้ ติดต่อ TOMAS TECH ผ่าน หน้าติดต่อภาษาไทย พร้อมข้อมูลเท่าที่มี เช่น ประเภทเครื่อง PLC เดิม ภาษาที่ต้องการ และช่วงเวลา Startup

แหล่งข้อมูลหลัก

• Mitsubishi Electric GOT3000
• Rockwell Automation FactoryTalk Optix
• Siemens WinCC Unified for Industrial Edge
• CISA ICS Recommended Practices
• Thailand BOI Investment Promotion Guide