การนำ OPC UA FX มาใช้: RFP และ FAT/SAT สำหรับโรงงานไทย

การนำ OPC UA FX มาใช้ไม่ควรเริ่มจากรายการรุ่น PLC และสวิตช์ที่ต้องซื้อ โรงงานไทยควรกำหนดขอบเขต Controller-to-Controller (C2C) และ Controller-to-Device (C2D), จุดแบ่งของเครือข่ายที่ใช้ TSN, การเชื่อมต่อกับระบบเดิม, ผู้รับผิดชอบการบำรุงรักษาแบบหลายผู้ขาย และหลักฐานที่ต้องส่งมอบใน FAT/SAT ก่อน บทความนี้ไม่ทบทวนการสร้างเครือข่ายอุตสาหกรรมทั่วไป แต่เน้นการจัดซื้อ: เขียน RFP อย่างไร ทดลอง PoC 90 วันอย่างไร และตัดสินใจ GO หรือ HOLD ด้วยหลักฐานอย่างไร

ข้อสรุป: จัดซื้อ “สัญญาการเชื่อมต่อที่ตรวจพิสูจน์ได้” ไม่ใช่คำว่า OPC UA Ready

OPC UA FX ไม่ใช่ชื่อใหม่ของการอ่าน Tag จาก PLC ด้วย OPC UA Client/Server แบบทั่วไป และไม่ได้เกิดขึ้นเพียงเพราะ Gateway ส่งค่าจาก PLC เป็น JSON ผ่าน MQTT เท่านั้น OPC UA FX เป็นชุดข้อกำหนดหลายส่วนที่ขยาย OPC UA สู่การทำงานร่วมกันระดับภาคสนาม ครอบคลุม Information Model, วงจรการสร้าง–เฝ้าติดตาม–ยุติ Connection, Network, Offline Engineering และ Profile

ดังนั้น RFP ที่เขียนเพียง “รองรับ OPC UA” จะทำให้เทียบข้อเสนอไม่ได้ ผู้เสนอราคาต้องระบุ UAFX Profile, Facet, Conformance Unit และเวอร์ชันข้อกำหนดที่ใช้งานจริง รวมถึง Communication Model, รุ่นและ Firmware ที่เคยทดสอบ ตลอดจนฟังก์ชันที่ไม่รองรับหรืออยู่ใน Roadmap การผ่าน C2C ไม่ใช่หลักฐานว่า C2D พร้อม และผล PlugFest ไม่ใช่การรับรองผลิตภัณฑ์เชิงพาณิชย์ทุกตัว

สิ่งส่งมอบขั้นต่ำควรมีห้ารายการ:

1. Connection Matrix แยก C2C/C2D และ Mapping ของ AutomationComponent, Asset, FunctionalEntity
2. แบบขอบเขต Network ที่รวม VLAN, QoS, Time Synchronization, Redundancy และส่วนที่ไม่ใช่ TSN
3. Test Case FAT/SAT หลายผู้ขายที่ทำซ้ำได้ พร้อม Configuration, Raw Log และผลทดสอบ
4. Ownership สำหรับวิเคราะห์ปัญหาขั้นแรก, ต่ออายุ Certificate, อัปเดต Firmware, Escalation และเปลี่ยนอะไหล่
5. Scorecard PoC 90 วันที่มีเงื่อนไข GO/HOLD และรายการความเสี่ยงก่อนขยายผล

สถานะเดือนกันยายน 2026: PlugFest เป็นหลักฐานสำคัญ แต่ไม่ใช่หลักฐานความพร้อมของทุกผลิตภัณฑ์

OPC Foundation รายงานว่า PlugFest OPC UA FX จัดที่ Festo ประเทศเยอรมนี ระหว่างวันที่ 7–10 กันยายน 2026 เป็นเวลาสี่วัน มีผู้เข้าร่วม 28 คนจาก 16 บริษัท Controller หลายผู้ขายควบคุมเครื่องจักรเสมือนที่ประกอบเป็นสายการผลิต และสามารถสร้างหรือยุติ C2C Connection ตามคำสั่งได้ Prototype ของ I/O, Drive และ Field Device อื่นถูกเชื่อมกับ Controller แม่ผ่าน C2D รายงานระบุว่าเส้นทาง C2C/C2D ที่ทดสอบในงานสำเร็จทั้งหมด อีกทั้งมีการทดสอบ UDP Multicast, Priority-based QoS ด้วย VLAN Tagging และ gPTP Time Synchronization ระหว่าง Implementation ต่างกัน ผลงานนี้เตรียมไปสู่ Demo Wall ที่ SPS วันที่ 24–26 พฤศจิกายน 2026

นี่คือความคืบหน้าที่มีความหมาย แต่ขอบเขตของข้อสรุปคือ “เส้นทางและ Implementation ที่ทดสอบในงานประสบผลสำเร็จ” เท่านั้น ไม่ได้พิสูจน์ผลิตภัณฑ์ทุกรุ่น Firmware ทุกเวอร์ชัน สวิตช์ทุกยี่ห้อ เครือข่ายเดิมในโรงงานไทย หรือระบบบริการหลังการขาย โดยเฉพาะ C2D ซึ่งประกาศกล่าวถึง I/O และ Drive ในบริบท Prototype ต้องแยก Demo/Prototype ออกจาก Profile ที่ Release อย่างเป็นทางการของรุ่นที่จะซื้อ

เมื่อ 27 กรกฎาคม 2026 มี Maintenance Release v1.00.04 ที่อัปเดต Part 81 และ Part 84 การเปลี่ยนแปลงที่ประกาศรวมถึงการ Link Asset กับ FunctionalEntity, รองรับหลาย GDS Address, ระบุ DataSetReader/DataSetWriter เพิ่มเติม และกำหนด Communication Interval ได้ดีขึ้น ส่วน Part 84 เพิ่ม Conformance Unit ที่เกี่ยวข้อง นี่เป็นสัญญาณเชิงบวก แต่ผู้ขายยังต้องเปิดเผยขอบเขตที่ Implement จริง ข้อจำกัด แผนอัปเดต และ Compatibility ของแต่ละรุ่น

แปลง OPC UA FX Part 80–84 เป็นคำถามใน RFP

ใน Part 81 v1.00.04 นั้น AutomationComponent ไม่ใช่เพียงชื่อเรียกกล่อง PLC ส่วน Asset แทนสิ่งทางกายภาพหรือเชิงตรรกะ FunctionalEntity แทนฟังก์ชันพร้อม Input/Output/Configuration และ ConnectionManager เกี่ยวข้องกับการสร้าง เฝ้าติดตาม และปิด Connection ให้ผู้ขายทำ Mapping เครื่องบรรจุ Conveyor เครื่องตรวจสอบ Remote I/O และ Drive ของจริงลงในโมเดลเหล่านี้ พร้อมอธิบายวิธีตรวจ Compatibility เมื่อเปลี่ยนอุปกรณ์

ก่อนออก PO ต้องตรวจฐานข้อมูล Profile ของ OPC Foundation อีกครั้ง อย่าแปลง Scope ระดับ Series ให้เป็นคำรับรองสำหรับทุกรุ่นโดยอัตโนมัติ ผูกคำตอบกับ Model, Hardware Revision, Firmware, Library และฟังก์ชันที่ใช้จริง แยก Formal Release, Limited Release, Evaluation, Implementation สำหรับ PlugFest และ Future Roadmap เป็นคนละช่อง

อย่าถือว่า OPC UA FX เท่ากับ Client/Server หรือ MQTT Forwarding

ทั้งสามมีประโยชน์แต่แก้ปัญหาคนละแบบ OPC UA Client/Server เหมาะกับ Client ที่เข้าถึง Data หรือ Method ใน Address Space ของ Server ส่วน MQTT เหมาะกับ Lightweight Messaging ผ่าน Broker ขณะที่ OPC UA FX จัดการความหมายและพฤติกรรม Connection ให้ Automation Component ต่างผู้ขายทำงานร่วมกัน

ถ้า Gateway อ่าน Tag จาก PLC A แปลงเป็น JSON แล้ว Publish ไป MQTT นั่นอาจเป็น IIoT Architecture ที่ดี แต่ยังไม่ใช่หลักฐาน UAFX C2C/C2D เช่นเดียวกับ PLC สองตัวแลกค่าผ่าน Client/Server ได้ ก็ไม่ได้แปลว่า Implement UAFX Information Model, Profile และ Connection Lifecycle แล้ว แบบ Architecture ทุกฉบับต้องระบุ Communication Model และทำเครื่องหมายส่วนที่ทดสอบเป็น OPC UA FX อย่างชัดเจน

แยก C2C และ C2D เป็นคนละหน่วยรับมอบ

C2C: ตรวจ Functional Connection ระหว่างเครื่องและ Cell

C2C ต้องแสดงว่า Production Permission, State และข้อมูล Interlock ถูก Mapping ไปยัง Input/Output ของ FunctionalEntity ระหว่าง Controller ต่างผู้ขายอย่างไร ต้องแยก Safety Function ออกจาก Standard Control ตั้งแต่ต้น คำว่า UAFX Capable ไม่ใช่เหตุผลเพียงพอที่จะเปลี่ยน Safety Fieldbus หรือวงจร Hardwired ที่ผ่านการรับรอง

FAT ควรทดสอบการ Restart ของแต่ละฝั่ง, Connection Definition ไม่ตรงกัน, Descriptor เก่า, Time Sync หาย, Publisher หยุด, Subscriber ช้า, Certificate หมดอายุ และเปลี่ยน Network Path บันทึก Error ที่ ConnectionManager แสดง State หลังความผิดปกติ และความเสี่ยงที่ Operator จะเข้าใจผิดว่า “Connected”

C2D: ตรวจความพร้อมเชิงพาณิชย์ทีละรุ่น

C2D ขยายไปยัง I/O, Drive และ Field Device แต่รายงาน PlugFest เดือนกันยายน 2026 ใช้บริบท Prototype จึงไม่สามารถรับรองสถานะผลิตภัณฑ์ที่เสนอในโครงการได้ RFP ต้องขอ Model, Hardware Revision, Firmware, Profile/Facet, สถานะจำหน่ายอย่างเป็นทางการ, Certification, ประเทศที่ Support และระยะ Maintenance

PoC ต้องทดสอบการเปลี่ยนอุปกรณ์ ไม่ใช่เพียง Cyclic Communication เมื่ออุปกรณ์เสีย ให้ตรวจ Asset Identity และ Compatibility, ผู้อนุมัติ ConfigurationData และวิธี Reject รุ่นผิดหรือ Firmware เก่า งานนี้เชื่อมกับหน้าที่ฝ่ายซ่อมบำรุงโดยตรง จึงปิดประเด็นไม่ได้ด้วยภาพจาก Lab ของ SIer เท่านั้น

ขอบเขต OPC UA FX TSN ต้องมาจาก Requirement

OPC UA FX เกี่ยวข้องกับ TSN แต่ไม่จำเป็นต้องทำ TSN ทั้งโรงงาน เริ่มจาก Requirement ด้าน Cycle, Latency, Jitter, Concurrent Traffic, Availability, Time Accuracy และพฤติกรรมเมื่อเกิด Fault แล้วจึงกำหนด Network Function ในส่วนที่ต้องใช้

PlugFest ทดสอบ UDP Multicast, QoS ตาม Priority ด้วย VLAN Tag และ gPTP ระหว่าง Implementation ต่างกัน ซึ่งเหมาะเป็น Candidate Test ใน RFP แต่สวิตช์ที่รองรับ TSN เพียงตัวเดียวไม่ทำให้ Performance แบบ End-to-end เกิดขึ้น ต้องทดสอบ Endpoint, Switch, Time Grandmaster, VLAN, Queue, Management Tool และส่วน non-TSN เป็น Route เดียวกัน

ยิ่งขยาย TSN มาก ยิ่งมี Configuration ที่ต้องรับผิดชอบร่วมกัน สัญญาต้องระบุ Owner ของ Grandmaster, VLAN, QoS, Diagnostic และ Firmware Compatibility ระหว่าง PLC Vendor, Switch Vendor, SIer และทีม IT/OT ของโรงงาน คำกล่าวว่า Conform กับมาตรฐานไม่เท่ากับผล FAT/SAT แบบ End-to-end

ขอบเขตบทความเพื่อไม่แย่ง Keyword กับบทความเดิม

บทความเดิมช่วยวางพื้นฐาน Network, มาตรฐานในไทย และบทบาท Edge ส่วนบทความนี้ใช้สำหรับเขียน OPC UA FX RFP และรับมอบระบบด้วยหลักฐาน

12 คำถามที่ต้องมีใน OPC UA FX RFP

คำว่า “Planned Support” อยู่ในข้อเสนอได้ แต่ต้องแยกจาก Feature ปัจจุบัน แยก GA, Limited Release, Evaluation, Prototype และ Roadmap ถ้าฟังก์ชันอนาคตจำเป็นต่อ Production ต้องมีทางเลือกสำรองและเงื่อนไขในสัญญา

ใช้ Certification และ PlugFest ให้ถูกความหมาย

โปรแกรม Certification ของ OPC Foundation ตรวจข้อกำหนด Operability ขั้นต่ำ เช่น Specification Compliance, Interoperability, Robustness, Usability และ Resource Efficiency ผลิตภัณฑ์ที่ทดสอบโดย Accredited Lab เป็นหลักฐานที่มีน้ำหนัก แต่ SDK ไม่สามารถ Certified โดยตรง เพราะ Application ของลูกค้ายังต้องกำหนด Address Space, Data Handling และ Security แม้ใช้ SDK ที่มี Certified Reference Implementation ตัว Application ก็ยังต้องทดสอบเองเพื่อเป็น Certified Product

ตรวจว่ารายการ Certification ครอบคลุม Product, Version และ Profile ที่จะใช้จริงด้วย Compliance Corner เดือนกันยายน 2026 แจ้งว่าการรองรับ Certification สำหรับ OPC UA 1.03 จะสิ้นสุดปลายปี 2026 และ Vendor ควรมุ่งสู่ 1.05 ไม่ได้หมายความว่าระบบ 1.03 ที่ติดตั้งอยู่จะหยุดทำงาน แต่ RFP ใหม่ควรถาม Upgrade Roadmap และ Support ในช่วงที่ต้องอยู่ร่วมกัน

PlugFest ใช้ค้นหาปัญหาระหว่าง Implementation, Certification ประเมิน Product Scope ตามโปรแกรม และ FAT/SAT รับมอบ Configuration จริงของโรงงาน ทั้งสามอย่างเสริมกันและแทนกันไม่ได้

Multi-vendor FAT: ล็อก Combination, Configuration และ Evidence

FAT ต้องสร้าง Record ที่ทำซ้ำได้ ไม่ใช่รูปไฟเขียวสองจุด Bill of Test ต้องระบุ Controller, I/O/Drive, Switch, Time Source, ConnectionManager, Engineering Tool, Certificate, Configuration File และ Traffic Generator

ทดสอบอย่างน้อย:

• Establish, Monitor, Planned Close และ Abnormal Loss ของ C2C
• Discovery, Compatibility, Replacement และ Reject รุ่น/Firmware ผิดของ C2D
• UDP Multicast Join/Leave, หลาย Subscriber และป้องกันการรับโดยไม่ตั้งใจ
• VLAN/QoS ตรงและไม่ตรงกันภายใต้ Traffic ปกติและ Traffic แข่งขัน
• gPTP Sync, เปลี่ยน Grandmaster, Loss และ Recovery
• ต่ออายุ/หมดอายุ Certificate, Trust List ไม่ตรง และสิทธิ์ไม่พอ
• Descriptor/OfflineEngineering Version ไม่ตรง, Reapply และ Rollback
• Log Export, Correlation และความสม่ำเสมอเมื่อทดสอบซ้ำ

อย่านำ Performance จาก Catalog มาใส่เป็นผลรับมอบ ต้องเก็บ Message Size, จำนวน Publisher/Subscriber, Cycle, Load, Switch Setting, Measurement Point และ Time Source พร้อมผลทุกครั้ง Threshold มาจาก Requirement โรงงาน ไม่สร้าง Effect Rate, Cost Saving หรือ Payback โดยไม่มีข้อมูล

Multi-vendor SAT: เปลี่ยนสภาพจริงของโรงงานไทยเป็นหลักฐาน

SAT ต้องรวมไฟฟ้า สาย ตู้ VLAN เดิม ระบบเวลา สิทธิ์ ผู้ดูแล Laptop และการส่งกะ เปลี่ยน Simulator ใน FAT เป็นอุปกรณ์จริงและทดสอบซ้ำ ทีมซ่อมบำรุงไทยต้อง Export หลักฐานและวิเคราะห์ปัญหาขั้นแรกได้โดยไม่พึ่ง Hidden Vendor Access

1. กู้ Connection เมื่อ Cell Start ไม่ตามลำดับปกติ
2. Restart Controller, Field Device และ Switch แยกกัน
3. สร้าง Traffic แข่งขันที่ Uplink เดิมหรือขอบเขต non-TSN
4. ตัด gPTP ชั่วคราวแล้วตรวจ Alarm, Diagnostic และ Recovery
5. เปลี่ยนอะไหล่แล้วตรวจ Identity, Compatibility และ Configuration
6. ทดสอบ Remote Maintenance ตั้งแต่อนุมัติ Log Session ถึงยุติ
7. ให้พนักงานโรงงานรวม Configuration Snapshot, Packet Capture และ UAFX Log

Open Item ต้องมี Impact, Reproduction, Workaround, Permanent Action, Owner, Due Date และ Retest Condition ไม่ปิดด้วยคำว่า “Minor” ควรกำหนดตั้งแต่ก่อนเซ็นสัญญาว่า Exception ใด Block GO และ Exception ใดรับความเสี่ยงเพื่อเริ่ม Production ได้

กำหนด Evidence Package และ Maintenance Ownership ในสัญญา

Incident หลายผู้ขายชะงักเมื่อทุกบริษัทบอกว่าอุปกรณ์ตัวเองปกติ แต่ไม่มีใครถือหลักฐาน End-to-end ให้กำหนด Package ดังนี้เป็น Deliverable:

• As-built, Model, Serial, Hardware/Firmware/Software Version
• UAFX Profile, Facet และ Conformance Unit Scope
• Definition ของ AutomationComponent, Asset, FunctionalEntity และ Connection
• Snapshot ของ Switch, VLAN/QoS, gPTP, Multicast และ ACL
• Test Input, Expected/Measured Result, Raw Log, Packet Capture และ Time Status
• Owner ของ Certificate/Key, Renewal, Expiry Monitoring และ Revocation
• Open Item, Exception, Workaround, Retest และ Approver
• Backup/Restore, Spare Replacement, Rollback และ Vendor Escalation

Product Vendor รับผิดชอบ Feature/Diagnostic, SIer รับผิดชอบ Integrated Configuration, Plant OT รับผิดชอบ Operation, IT/Security รับผิดชอบ Identity/Certificate/Remote Access และ Procurement รับผิดชอบ Contract Gate จากนั้นอุดช่องว่างด้วยการระบุว่าใครเก็บ Log End-to-end เป็นคนแรก และใครเรียก Incident Meeting ตอนยังไม่ทราบ Root Cause

PoC 90 วันพร้อม Gate GO/HOLD

90 วันเป็นกรอบจำกัด Scope เพื่อการตัดสินใจ ไม่ใช่การรับประกันผลลัพธ์ ให้เลือก C2C หนึ่งคู่, C2D หนึ่ง Branch, อย่างน้อยสอง Vendor และขอบเขต TSN หนึ่งจุด

วันที่ 1–30: DEFINE Requirement และ Evidence

ตกลง Process, Downtime ที่อนุญาต, Safety Boundary, C2C/C2D, Communication Model, Timing/Availability, Network เดิม และ Formal Release ของ Candidate อนุมัติ Profile/CU Response, Asset–FunctionalEntity Map, Ownership, Test Case และ Evidence Format

Gate ไม่ใช่ “อุปกรณ์มาถึงแล้ว” แต่คือทุก Requirement มี Test ID/Owner, Prototype/Roadmap แยกจาก GA และกำหนดหลักฐานสำหรับ GO/HOLD แล้ว ถ้ายังมี Unknown สำคัญให้ HOLD ก่อน Implement

วันที่ 31–60: PROVE C2C/C2D และทดสอบ Fault ที่ขอบเขต TSN

ทดสอบ Connect, Disconnect, Restart, Version Mismatch, Sync Loss, VLAN/QoS Mismatch, Multicast, Certificate และ Replacement ล็อก Bill of Test และเก็บ Raw Evidence ถ้า C2D เป็น Prototype ต้องบันทึกและกำหนดเงื่อนไขย้ายไป Production Product

Gate คือ Mandatory Case ผ่านซ้ำได้, Fail ทุกข้อมี Cause/Owner และรายการที่จะไป SAT ได้รับอนุมัติ การเชื่อมได้ครั้งเดียวไม่ใช่ Gate

วันที่ 61–90: VALIDATE ที่โรงงานและส่งมอบการปฏิบัติงาน

ติดตั้งใน Cell ตัวแทน ใช้ Network, Clock, Access และทีมซ่อมบำรุงจริง พนักงานไทยสาธิตตรวจ Configuration, Export Log, เปลี่ยนอะไหล่ และวิเคราะห์ขั้นแรก ปิด Open Item ด้านสัญญา Support Cybersecurity และ Training

GO ต้องดูมากกว่าผล Technical Case ต้องยืนยัน Supply, Formal Release, Certification Scope, Support Contact, Update Policy, Responsibility และ Residual Risk ของรุ่นจริง HOLD ไม่ใช่ความล้มเหลว แต่อาจหมายถึงรอ C2D Production Release, ปิด Profile Gap, กำหนด TSN Boundary หรือเจรจา Support Agreement พร้อมเงื่อนไขกลับมาพิจารณาใหม่

มาตรการ BOI เป็นประเด็นตรวจสอบ ไม่ใช่การรับประกัน

BOI เผยแพร่มาตรการยกระดับอุตสาหกรรมสู่ Smart and Sustainable Industry หน้าอย่างเป็นทางการกล่าวถึงผู้ลงทุนใหม่และเดิมในกิจการ Group B ที่เข้าเงื่อนไข และระบุเงินลงทุนเพิ่มประสิทธิภาพขั้นต่ำ 1 ล้านบาท ไม่รวมที่ดินและเงินทุนหมุนเวียน พร้อมสิทธิยกเว้นอากรเครื่องจักรและสิทธิภาษีเงินได้นิติบุคคลตามเงื่อนไข รวมถึงเงื่อนไขที่เกี่ยวกับเครื่องจักรเชื่อมโยงอุตสาหกรรม Automation ในประเทศ

บทความ OSOS ของ BOI รายงานครึ่งแรกปี 2026 ว่า Smart and Sustainable Industry มี 132 คำขอ มูลค่าประมาณ 17.2 พันล้านบาท ตัวเลขนี้เป็นคำขอ ไม่ใช่จำนวนโครงการ OPC UA FX, การอนุมัติ, คำแนะนำภาษี หรือผลตอบแทน ต้องตรวจ Announcement ล่าสุด ประเภทกิจการ เวลา รายจ่าย และเอกสารกับ BOI หรือผู้เชี่ยวชาญ อย่าบิด Requirement ทางเทคนิคเพื่อให้ตรงสิทธิประโยชน์

รูปแบบความล้มเหลวที่พบบ่อยและวิธีหลีกเลี่ยง

ซื้อคำว่า “รองรับ OPC UA” เป็นรายการเดียว

Conventional UA, UAFX, PubSub, Client/Server และ MQTT Gateway มักถูกรวมไว้ในราคาเดียว ควรล็อก C2C/C2D, Communication Model, Profile/Facet/CU และ Model ที่แน่นอนไว้ใน Response Matrix

ซื้อ TSN เป็นเพียงป้ายชื่อ

มีการตรวจเฉพาะ Feature ของ Switch แต่ละเลย Endpoint, gPTP และการทำงานของ QoS ต้องทดสอบเส้นทางแบบ End-to-End ภายใต้ Load ที่ประกาศไว้

อ่านผล PlugFest เป็นการรับประกันผลิตภัณฑ์

PlugFest เป็นหลักฐาน Interoperability ที่มีคุณค่า แต่ Version และ Test Case อาจต่างจากโรงงาน ต้องแยกสถานะ Prototype, Demo, GA และ Certified ให้ชัดเจน

มอบความรับผิดชอบทั้งหมดให้ SIer

Integrator ไม่สามารถควบคุม Roadmap หรือ Certification ของ Vendor ทุกเจ้าได้ ต้องแบ่ง Product Ownership, Integration Ownership, Network Ownership, Certificate Ownership และ Operations Ownership พร้อมกำหนดผู้รับผิดชอบ First Response แบบ End-to-End

จบ PoC ด้วย Dashboard Demo

การแสดงค่าปกติไม่ได้พิสูจน์ Maintainability ต้องตั้งใจทดสอบการตัดการเชื่อมต่อ, Restart, Time Desynchronization, Misconfiguration, Component Replacement และ Update พร้อมเก็บหลักฐานทุกครั้ง

FAQ การนำ OPC UA FX มาใช้

OPC UA FX ต่างจาก OPC UA ทั่วไปอย่างไร?

เป็นกรอบหลายส่วนที่ใช้เทคโนโลยี OPC UA เพื่อกำหนด Information Model, Connection, Network, Offline Engineering และ Profile ระดับภาคสนาม ไม่เท่ากับอ่าน Tag หรือ Forward Payload ผ่าน MQTT

OPC UA FX TSN จำเป็นทุกจุดหรือไม่?

ไม่จำเป็นเสมอไป กำหนดจาก Cycle, Latency, Jitter, Time, Load และ Availability แล้วทดสอบ Endpoint, Switch, gPTP และ VLAN/QoS ร่วมกัน

ทดลอง C2C และ C2D ใน PoC เดียวกันได้หรือไม่?

ได้ แต่รับมอบแยกกัน อย่านำผล C2C ไปสรุป C2D ต้องตรวจ Model, Hardware/Firmware, Formal Release, Profile Scope และ Replacement ของ C2D แต่ละตัว

PlugFest กันยายน 2026 พิสูจน์ว่า C2D พร้อมเชิงพาณิชย์แล้วหรือไม่?

ไม่ รายงานยืนยันเส้นทางที่ทดสอบในงานและมีบริบท Prototype ของ I/O/Drive ไม่ได้รับรองความพร้อม การจำหน่าย Certification หรือ Performance ของทุกผลิตภัณฑ์

มี OPC Foundation Certification แล้วไม่ต้อง FAT/SAT ใช่หรือไม่?

ยังต้องทำ Certification เป็นหลักฐานระดับ Product/Profile, PlugFest เป็นการทดลองหลาย Implementation และ FAT/SAT เป็นการรับมอบ Configuration ของโรงงาน ขอบเขตต่างกัน

สิ่งแรกที่ต้องตัดสินใจสำหรับการทำงานร่วมกันของ PLC หลายผู้ขายคืออะไร?

กำหนด Functional Boundary, ความหมายของข้อมูล, Connection Lifecycle, Model และ Version, เงื่อนไข Time/Network และ Failure Ownership ให้ชัดเจน พร้อมระบุวิธี Replacement, Update, Diagnosis และการ Export Evidence

GO ของ PoC 90 วันคืออะไร?

Mandatory C2C/C2D Case ผ่านซ้ำได้ อธิบาย TSN/non-TSN Boundary ได้ ทีม Local เก็บ Log และวิเคราะห์ขั้นแรกได้ และ Risk ด้าน Release, Support, Ownership ยอมรับได้ ห้ามสร้าง ROI หรือ Effect Rate ขึ้นเอง

สรุป: รับมอบ Interoperability ด้วยหลักฐาน ไม่ใช่ชื่อข้อกำหนด

การนำ OPC UA FX มาใช้ที่ดีต้องแยก C2C/C2D ผูก Part 80–84 และ Profile กับรุ่น/เวอร์ชัน และกำหนด TSN Boundary จาก Requirement PlugFest เดือนกันยายน 2026 เป็นหลักฐานที่น่าสนับสนุน แต่ไม่ใช่คำรับรองความพร้อมเชิงพาณิชย์ทั้งหมด ต้องแยก Prototype/Demo ของ C2D จาก Formal Release ทำ RFP ให้ตอบในรูปแบบเดียวกัน ทดสอบ Normal/Fault ที่ FAT/SAT และเก็บ Configuration, Log, Result และ Owner ใน Evidence Package เดียว

TOMAS TECH สามารถช่วยกำหนด OPC UA FX RFP, ขอบเขต C2C/C2D, ออกแบบ Multi-vendor FAT/SAT และสร้าง Gate GO/HOLD สำหรับ PoC 90 วันได้ สามารถ ติดต่อเรา ได้ตั้งแต่ช่วงเปรียบเทียบทางเลือก

แหล่งข้อมูลหลักและทางการ

• OPC Foundation, Field Level Communications Corner – September 2026: https://opcconnect.opcfoundation.org/2026/09/field-level-communications-corner-september-2026/
• OPC UA Part 80: https://reference.opcfoundation.org/specs/OPC-10000-80/4.1
• OPC UA Part 81 v1.00.04: https://reference.opcfoundation.org/specs/OPC-10000-81/4
• OPC Foundation Profile Database: https://profiles.opcfoundation.org/document/25
• OPC Foundation Certification: https://opcfoundation.org/certification/overview-benefits/
• OPC Foundation Compliance Corner – September 2026: https://opcconnect.opcfoundation.org/2026/09/compliance-corner-september-2026/
• Thailand BOI Smart and Sustainable Industry: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
• Thailand BOI OSOS, 1H 2026: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/