ออกแบบ Sequence Control: State, Recovery และ PLC FAT

คุณภาพของการควบคุมลำดับ (Sequence Control) ไม่ควรวัดจากการที่ Ladder Program เดินรอบการผลิตปกติได้เพียงอย่างเดียว ผู้ซื้อจำเป็นต้องรู้ด้วยว่าเมื่อเซนเซอร์ไม่ตอบสนอง เครื่องจะเปลี่ยนไปอยู่ State ใด ใครมีสิทธิ์รับทราบและกู้คืน จะเริ่มผลิตต่อจากจุดไหน และมีหลักฐานอะไรเหลือไว้ บทความนี้อธิบายวิธีกำหนด Mode, State Transition, Fault Recovery และการควบคุมเวอร์ชันให้เป็นขอบเขตตรวจรับ PLC FAT/SAT โดยใช้ตารางสถานะร่วมกับ Fault Injection

เหตุใด “รอบปกติทำงานได้” จึงยังไม่ใช่เกณฑ์ตรวจรับ

ใบเสนอราคาเครื่องจักรมักระบุ “PLC Program”, “Automatic Sequence” และ “Commissioning” แต่ไม่ได้กำหนดชัดว่าเมื่อใดซอฟต์แวร์จึงถือว่าเสร็จ ผู้ขายสาธิตการป้อนชิ้นงาน เริ่ม เดินกระบวนการ และนำออก ผู้ซื้อดู Cycle Time และคุณภาพชิ้นงานแล้วรับงานเบื้องต้น แต่ในการผลิตจริงย่อมมีวัสดุหมด เซนเซอร์ไม่เข้า การสื่อสารขาด ลมตก เครื่องหยุดกลางรอบ เปลี่ยน Recipe หรือไฟดับแล้วเปิดใหม่

ข้อขัดแย้งที่เกิดขึ้นจึงมักไม่ใช่เรื่องรูปแบบ Ladder แต่เป็นความหมายของ State: เมื่อกด Hold แล้ว Output ใดต้องค้างไว้ เมื่อ Restart จะทำต่อหรือกลับ Home ก่อน Timeout เป็น Warning หรือ Fault แบบค้าง ชิ้นงานที่ยังไม่ครบกระบวนการเป็น Good, Reject หรือ Hold ถ้าไม่ได้ตกลงไว้ในใบสั่งซื้อ คำตอบจะถูกตัดสินหน้างานช่วงปลายโครงการ ซึ่งแก้ไขได้ยากและกระทบกำหนดส่ง

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

หากต้องการภาพรวมเรื่องขอบเขตผู้รับจ้างและสิ่งส่งมอบ อ่านเพิ่มเติมได้ที่ การจ้างพัฒนา PLC Program ในประเทศไทย ส่วนบทความนี้เจาะเฉพาะการตรวจรับการหยุด Fault และ Recovery

ใช้ IEC 61131-3 และ SFC เป็นภาษากลาง

IEC 61131-3:2025 กำหนด Syntax และ Semantics ของ Structured Text (ST), Ladder Diagram (LD) และ Function Block Diagram (FBD) สำหรับ Programmable Controller และกำหนดองค์ประกอบ Sequential Function Chart (SFC) เพื่อจัดโครงสร้างภายใน Program และ Function Block โดย IEC ระบุวันเผยแพร่ 22 พฤษภาคม 2025 และ Edition 4.0

ประเด็นสำคัญไม่ใช่ว่าภาษาใด “ดีที่สุด” LD มักติดตาม Contact และ Interlock ได้สะดวก ST เหมาะกับการตรวจข้อมูลหรือ Recipe ส่วน SFC ช่วยแสดงโครงของ Step, Transition และ Action อย่างไรก็ตาม PLCopen อธิบายว่า SFC ต้องใช้ภาษาอื่นเขียน Transition Condition และ Action จึงไม่ควรถือเป็นภาษาเดี่ยวที่แก้ได้ทุกเรื่อง

แทนที่จะบังคับให้ทุก Module ใช้ SFC ควรกำหนดว่า:

• State หรือ Step และเงื่อนไข Transition ต้องตามรอยได้
• Logic ของ Output กับการตัดสิน State ต้องไม่อ้างอิงกันจนตรวจไม่ได้
• แยก Permissive, Process Interlock และ Fault Decision
• Manual Operation ต้องไม่ทำลาย State ภายในของ Automatic Sequence โดยไม่แจ้ง
• ชื่อ State, Signal และ Alarm ตรงกันในเอกสาร Code และ HMI
• Version Diff ต้องบอกได้ว่าแก้อะไรและต้อง Retest ส่วนใด

PLCopen Software Construction Guidelines ครอบคลุม Coding Rule, Naming, Library, SFC do’s and don’ts, Object-Oriented Programming และ Software Quality Metrics เอกสารเหล่านี้ไม่แทน Functional Specification ของผู้ซื้อ แต่ใช้สร้างเกณฑ์ Code Review ร่วมกับผู้ขายได้

แยก Operating Mode ออกจาก Machine State

AUTO และ MANUAL คือ Mode ส่วน STOPPED, STARTING, RUNNING, HELD และ ABORTED คือ State หากรวมสองแนวคิดไว้ใน Integer เดียวหรือกลุ่ม Bit ที่ไม่อธิบาย เมื่อจำนวน Combination เพิ่มขึ้น ความหมายจะคลุมเครือ Manual ก็มีทั้ง Idle และ Active ส่วน Auto ก็มี Ready, Start, Run, Hold และ Stop การแยกเป็นสองแกนช่วยระบุ Combination ที่อนุญาตและห้ามได้ชัดเจน

สิ่งที่ต้องมีในตาราง Mode

กำหนดผู้มีสิทธิ์เลือก เงื่อนไขก่อนเปลี่ยน คำสั่งที่ใช้ได้ ข้อจำกัดการเคลื่อนที่หรือ Output และ State หลังเลือก Mode

ตารางนี้เป็นตัวอย่างออกแบบ ไม่ใช่ข้อกำหนด Safety การแยกพลังงานอันตรายและ Safety Function ต้องพิจารณาจาก Risk Assessment ของเครื่องแยกจาก Normal Sequence

เขียน State ด้วย Entry, Active และ Exit

ชื่อ State อย่างเดียวทดสอบไม่ได้ แต่ละ State ต้องมี Entry Action, Output และสิ่งที่ Monitor ระหว่าง Active, Normal Transition, Abnormal Transition และ Exit Action ISA รายงานว่า ISA-TR88.00.02-2022 ได้รับการเผยแพร่เพื่อประยุกต์แนวคิด ISA-88 กับ State และ Mode ของเครื่องอัตโนมัติ พร้อมตัวอย่าง State Model, Procedure, Implementation และ Tag Naming เอกสารนี้ใช้สร้างคำศัพท์ร่วมได้ แต่ไม่ควรคัดลอก Model โดยไม่ปรับให้ตรงเครื่อง

ชื่อเหล่านี้เป็นตัวอย่าง สิ่งสำคัญคือ ตาราง PLC HMI และ Event Record ต้องใช้ความหมายเดียวกัน

แยก Permissive, Process Interlock และ Fault

โรงงานมักเรียกทั้งสามอย่างว่า “Interlock” ทั้งที่หน้าที่ต่างกัน เงื่อนไขที่ห้าม Start เงื่อนไขที่ห้าม Output บางตัวระหว่าง Run และเหตุการณ์ที่ต้องให้คนตอบสนอง ไม่ควรใช้ Latch, Message และ Recovery แบบเดียวกันโดยอัตโนมัติ

Permissive

Permissive คือเงื่อนไขก่อนรับคำสั่ง เช่น Home แล้ว มี Material ปลายทางพร้อม Recipe ถูกอนุมัติ หรือ Machine Handshake สำเร็จ เมื่อไม่ครบ HMI ควรแสดงเหตุผล “Not Ready” โดยไม่จำเป็นต้องสร้าง Fault History ใหม่ทุก Scan

Process Interlock ใน Normal Control

Interlock ประเภทนี้รักษาลำดับหรือป้องกันอุปกรณ์ เช่น ไม่เริ่ม Machining ก่อน Clamp หรือไม่ Transfer ก่อน Axis ถึงตำแหน่ง ต้องระบุว่าเมื่อเงื่อนไขกลับมาแล้ว Auto Resume ได้หรือผู้ใช้ต้องสั่งใหม่

Fault

Fault คือเหตุที่ต้องตอบสนอง จัดการสถานะชิ้นงาน หรือเก็บประวัติ ควรบันทึก Code, State ที่เกิด, Input เกี่ยวข้อง, Cycle/Part, เวลาเกิดครั้งแรกและเวลาฟื้นคืน “Cylinder Fault” กว้างเกินไป ข้อความ “หลังสั่ง Forward แล้ว Forward Limit ไม่ ON ภายในเวลาที่กำหนด” แสดงสิ่งที่ PLC สังเกตจริงโดยไม่วินิจฉัยเกินข้อมูล

Timeout ต้องเป็นพฤติกรรม ไม่ใช่แค่ค่าตัวเลข

ข้อกำหนด Timeout ต้องมีจุดเริ่ม Monitor, Expected Response, Deadline, เกณฑ์สำเร็จ, State ปลายทาง, Output Action, Product Action และ Retry Policy ตัวเลขอย่างเดียวทดสอบไม่ได้ถ้าไม่รู้ว่าเริ่มจับเวลาเมื่อใด

ตัวอย่างการคำนวณ (สมมติ): Actuator ตอบสนองปกติ 0.8 วินาที ค่าสูงสุดของความแปรปรวนที่สังเกตได้ 0.3 วินาที และเผื่อ Communication/Scan 0.4 วินาที อาจตั้งค่าเริ่มต้นเป็น 0.8 + 0.3 + 0.4 = 1.5 วินาที แล้วปรับจาก Log ใน FAT และ SAT ค่านี้เป็นเพียงสมมติฐานตัวอย่าง ไม่ใช่ค่ามาตรฐานทั่วไป

การคง Output หลัง Timeout อาจทำให้ติดขัดรุนแรงขึ้น แต่การตัดทุก Output ทันทีอาจทำชิ้นงานหล่นหรือทำลายสถานะคุณภาพ จึงต้องแยก “ภาวะลดความเสี่ยงของเครื่อง” ออกจาก “Process Hold เพื่อรักษาชิ้นงาน” โดยพิจารณาร่วมกับ Machine Design, Process Requirement และ Risk Assessment

ทำให้ Fault Code และข้อความ HMI เป็นส่วนหนึ่งของการตรวจรับ

Fault Code Register ควรมี:

• Code เดียวกันทุกภาษาและข้อความ Localized
• Mode/State ที่เกิดได้
• เงื่อนไขที่ PLC สังเกตจริง
• พฤติกรรม Stop/Hold
• สถานะของชิ้นงานที่ได้รับผล
• รายการที่ Operator หรือ Technician ต้องตรวจ
• Reset Condition และ Required Authority
• มี Auto Retry หรือไม่และจำกัดเท่าใด
• FAT Test ID ที่ใช้พิสูจน์

ในโรงงานหลายภาษา Code ควรเหมือนกันแม้คำแปลต่างกัน HMI ภาษาไทยและเอกสาร Maintenance ภาษาญี่ปุ่นหรืออังกฤษจึงอ้าง Event เดียวกันได้

ออกแบบ Fault Recovery ให้มากกว่า “กด Reset”

หลีกเลี่ยง Logic ที่กด Reset แล้วล้าง Bit พร้อม Start ต่อทันที ควรแบ่งเป็นการเอาสาเหตุออก Acknowledge ตรวจ State ของเครื่อง ตัดสินชิ้นงาน เลือก Home/Restart Point และอนุมัติ Restart

กำหนดสิทธิ์ Recovery

Operator อาจแก้ Material Shortage ได้ แต่ Servo Following Error, ข้อมูลคุณภาพไม่สอดคล้อง หรือเหตุหลัง Protective Device ทำงาน อาจต้อง Maintenance หรือ Quality Approval ผูก Role บน HMI กับ Audit Event ว่าใครยืนยันอะไรเมื่อใด

ควบคุม Work in Process

เครื่องกลับสภาพได้ไม่ได้แปลว่าชิ้นงานกลางทางยังผ่านคุณภาพ ต้องติดตาม Operation ที่ทำแล้ว Measurement, Traceability ID, Hold Duration และสิทธิ์ Rework แล้วจึงเปลี่ยนเป็น Resume, Controlled Discharge, Quarantine หรือ Scrap ตาม Quality Procedure PLC ช่วยถือสถานะได้ แต่ไม่ควรสร้างคำตัดสินคุณภาพขั้นสุดท้ายเอง

แยกกรณี Power Restoration

หลังไฟดับ Volatile Data, Physical Output, Communication Session, Servo Position และ State ของเครื่องอื่นอาจไม่ตรงกัน ต้องจัดกลุ่มข้อมูลที่ Retain, Initialize และ Reconcile พร้อมกำหนด Power-up State โดยเฉพาะ อย่าซ่อนการตรวจนี้ไว้ใน Normal Fault Reset

บริหาร Recipe และ Software เป็น Tested Configuration เดียวกัน

PLC Code เดิมอาจทำงานต่างกันเมื่อ Recipe, HMI Setting, Robot Program หรือ Vision Parameter เปลี่ยน หลักฐาน FAT จึงต้องระบุ Configuration ครบ: PLC, HMI, Robot, Vision, Recipe และ Drawing Revision ที่เกี่ยวข้อง

ทุกการแก้ไขควรบันทึกเหตุผล ผู้แก้ ผู้อนุมัติ State/Fault/Product ที่กระทบ และ Regression Test ที่ต้องทำ การแก้ Online หน้างานต้องกลับเข้าสู่ Controlled Master เพื่อป้องกันการนำ Backup เก่ามาทับในครั้งถัดไป ประเด็นการย้ายระบบเดิมอ่านได้ที่ การเปลี่ยนและ Retrofit PLC ในประเทศไทย

สร้าง PLC FAT จากตาราง State และ Fault Injection

FAT ไม่ควรเป็นเพียง Demo การผลิต แต่ควรใส่ Stimulus ที่ควบคุมได้ให้แต่ละ Requirement แล้วพิสูจน์ Expected State, Output, Message, Product Status, Log และ Recovery

คอลัมน์ของ Fault-Injection Matrix

ขยาย Test Case จากแต่ละ State: Normal Transition, Permissive ไม่ครบ, Expected Input ไม่มา, Input หายกลาง Step, Stop Request, Mode Change, Communication Loss และ Power Restart จัดลำดับตาม Risk, โอกาสเกิด, ความยากในการตรวจพบ และผลต่อ Product แทนการทดสอบ Combination แบบไม่จำกัด

ตัวอย่างการคำนวณ (สมมติ): 8 State แต่ละ State มี Representative Fault 3 แบบ จะได้ 8 × 3 = 24 Cases หากทำครบใน 3 Mode จะเป็น 72 Cases แต่ Logic ร่วมอาจใช้ Representative Coverage ที่มีเหตุผลได้ ตัวเลขนี้เป็นตัวอย่างประเมิน Scope ไม่ใช่จำนวน Test ที่บังคับใช้

ตกลงวิธี Inject

การ Force Input ใน Software, ใช้ Simulator หรือถอดอุปกรณ์จริงมี Repeatability และ Risk ต่างกัน ก่อน FAT ให้ตกลง Signal ที่จำลองได้ สิ่งที่ต้องทดสอบกับเครื่องจริง วิธีตรวจว่า Force ถูก Clear แล้ว และผู้มีสิทธิ์เข้า Test Mode หาก Bypass อยู่ใน Production Build ต้องมี Authorization, การแสดงผลชัดเจน, Logging และวิธีตรวจการยกเลิก

ทำ Pass/Fail ให้สังเกตได้

คำว่า “หยุดถูกต้อง” ไม่ใช่เกณฑ์ Pass ให้แยก Expected State, Output, HMI Code, Product Flag, Event Time และ Recovery Role หากหลักฐานมีเพียง Online View ของ Programmer ผู้ซื้อจะตรวจย้อนหลังไม่ได้ ควรกำหนด Event Export, Trend, Screenshot หรือวิดีโอที่ส่งมอบได้

แบ่งหน้าที่ FAT และ SAT

FAT ตรวจ Panel, PLC, HMI, Simulator และเครื่องที่ประกอบในโรงงานผู้ขาย ส่วน SAT เพิ่ม Utility จริง Product จริง เครื่องต้นทาง/ปลายทาง Network ผู้ใช้และ Host System จริง FAT ผ่านไม่ได้หมายความว่าทุก Production Condition ถูกทดสอบแล้ว

การปรับใน SAT ต้องบันทึกเป็น Difference จาก FAT-approved Configuration หากเรียก Online Change ว่า “ปรับเล็กน้อย” โดยไม่เก็บ Version โปรแกรมหน้างาน Backup สุดท้ายและผล Test จะไม่ตรงกัน สำหรับขอบเขตการจัดซื้อเครื่องโดยรวม ดู การจัดหาเครื่องจักรเฉพาะทางในประเทศไทย

เชื่อม Requirement ถึง Audit Log เป็นสายหลักฐานเดียว

รายงาน Test ที่ไม่บอก Requirement และ Configuration ที่ทดสอบจะใช้ตัดสิน Retest หลังแก้ไขไม่ได้ ต้องเชื่อม Requirement ID, State Model, Software Version, Test ID, Result, Approval และคำศัพท์เดียวกับ Production Event

Evidence Chain ต้องตอบได้ว่า:

1. Requirement ถูกนำไปใช้ใน Mode, State หรือ Transition ใด
2. อยู่ใน PLC/HMI/Recipe Configuration ใด
3. พิสูจน์ด้วย FAT/SAT Test ใด
4. ผลวัดและไฟล์แนบคืออะไร
5. ใครอนุมัติ เมื่อใด และมีเงื่อนไขอะไร
6. ใช้ ID เดียวกันตามรอยใน Fault/Recovery Log ระหว่างผลิตได้หรือไม่

Traceability นี้ช่วยเลือก Regression Test เมื่อแก้ Fault Message, Transition หรือ Recipe Limit Audit Log ไม่ได้มีไว้เฝ้าพนักงาน แต่มีไว้สร้างลำดับ Event, Version และ Authorized Recovery Decision ย้อนหลัง ระยะเวลาเก็บและสิทธิ์เข้าถึงต้องเป็นไปตาม Quality/Security Policy ของลูกค้า

แยก Normal Sequence Control ออกจาก Functional Safety

ขอบเขตนี้สำคัญที่สุด Stop Condition, Process Interlock, Emergency-stop Display หรือ Recovery Routine ใน Standard PLC ไม่ได้ทำให้ผ่าน Functional Safety โดยอัตโนมัติ ISO 12100:2010 ให้หลักการและวิธีการ Risk Assessment/Risk Reduction ของเครื่อง และ ISO ระบุว่ามาตรฐานฉบับนี้ผ่านการ Review และ Confirm ในปี 2022 ส่วน ISO 13849-1:2023 ครอบคลุมวิธีการออกแบบและ Integration ของ Safety-related Parts of Control Systems รวมถึง Software

ดังนั้น Hazard, Required Risk Reduction, Safety Function, Required Performance, Architecture, Diagnostic และ Validation ต้องดำเนินการแยกโดยผู้มีความสามารถตามมาตรฐานที่ใช้และ Risk Assessment ของเครื่อง State Table ใน Normal Control ช่วยจัดการเครื่องหลัง Safety Function ทำงานได้ แต่ไม่แทน Safety PLC, Safety Circuit หรือ Safety Function ที่ผ่าน Validation

Purchase Specification ควรแสดง Responsibility Boundary ระหว่าง Standard PLC, Safety PLC/Circuit, Drive Safety Function, Mechanical Safeguard และ Operating Procedure ถ้า Standard PLC อ่าน Safety Status เพื่อแสดงผลหรือเก็บประวัติ ห้ามอธิบาย Monitoring นั้นว่าเป็นตัว Safety Function

บริบท BOI สำหรับการลงทุน Automation ในประเทศไทย

ประกาศของ Thailand BOI สำหรับครึ่งแรกปี 2026 รายงานคำขอในกลุ่ม Smart and Sustainable Industry จำนวน 132 โครงการ มูลค่ารวม 17.158 พันล้านบาท ตัวเลขนี้สะท้อนกิจกรรมยื่นคำขอ ไม่ใช่การรับรองว่าทุกโครงการได้รับอนุมัติหรือมีสิทธิ์

มาตรการปัจจุบันของ BOI ระบุเงินลงทุนขั้นต่ำ 1 ล้านบาท ไม่รวมค่าที่ดินและทุนหมุนเวียน และอธิบายเส้นทางยกเว้นภาษีเงินได้นิติบุคคล 3 ปี ในวงเงิน 50% ของเงินลงทุนที่เข้าเกณฑ์ หรือ 100% เมื่อมูลค่าเครื่องจักร Automation หรือ Robot อย่างน้อย 30% เชื่อมโยงหรือสนับสนุนอุตสาหกรรมเครื่องจักร Automation ในประเทศ ขอบเขตโครงการ ค่าใช้จ่ายที่เข้าเกณฑ์ เวลาและความเชื่อมโยงต้องยืนยันกับ BOI หรือผู้เชี่ยวชาญ ห้ามวาง Business Case บนสมมติฐานว่าอนุมัติแน่นอน

State Specification, Version Manifest และ FAT Record สนับสนุนแฟ้มการลงทุนที่มีระบบได้ แต่ไม่ได้ทำให้ผ่านเงื่อนไข BOI อัตโนมัติ ควรแยก Technical Acceptance และ Incentive Eligibility พร้อมแผนหลักฐานของแต่ละงาน

Checklist สำหรับจัดซื้อและตรวจรับ

ก่อนขอใบเสนอราคา

• ระบุขอบเขต Product, Host System และเครื่องข้างเคียง
• แนบ Draft Mode/State Model
• รวม Stop, Hold, Abort, Fault และ Recovery ไม่ใช่เฉพาะ Normal Cycle
• แยก Permissive, Process Interlock และ Safety Function
• กำหนด Localized HMI, Common Fault Code และ Event Export
• กำหนดการควบคุม PLC/HMI/Robot/Recipe Configuration

ตอน Design Review

• ทุก State มี Entry, Active และ Exit Behavior หรือไม่
• Normal, Abnormal และ Prohibited Transition ชัดหรือไม่
• Timeout ทุกตัวมี Start Point และ Failure Reaction หรือไม่
• Reset แยกจาก Restart หรือไม่
• ครอบคลุม Power Restart, Communication Failure และ Work in Process หรือไม่
• เอกสารป้องกันการตีความ Normal Control เป็น Functional Safety หรือไม่

ก่อน FAT

• สร้าง Fault-Injection Matrix จาก State Table ที่อนุมัติแล้ว
• Initial Condition, Stimulus และ Expected Result สังเกตได้
• ควบคุมสิทธิ์ Test Force และ Bypass
• Freeze Software/Recipe Version ทุกส่วน
• กำหนด Correction, Retest และ Conditional Acceptance
• ตกลงรูปแบบ Evidence และ Handover Package

ตอน SAT และส่งมอบ

• ตรวจ Timing ภายใต้ Load จริงและบันทึกการเปลี่ยน
• ทดสอบ Host/Adjacent Machine Failure และ Recovery
• ฝึกแต่ละ Role เรื่อง Recovery และ Product Disposition
• ตรวจ Final Backup ตรงกับ Site Version ที่ทดสอบ
• บันทึก Open Item, Temporary Control, Owner และ Due Date
• กำหนดการ Review Production Fault Log

ความผิดพลาดที่พบบ่อยและวิธีแก้

จัดซื้อโดยมีเพียงแผนภาพ Normal Cycle

หาก Flowchart มีเฉพาะการผลิตปกติ พฤติกรรมเมื่อเกิดความผิดปกติจะขึ้นกับมาตรฐานของผู้ขายหรือการตัดสินใจของวิศวกรแต่ละคน ควรเพิ่ม Abnormal Transition และ Recovery Condition ลงใน State Table แล้วเชื่อมแต่ละรายการกับ FAT Test ID

ตัดสินผ่านจากการ Review Ladder Program เพียงอย่างเดียว

Code Review มีความสำคัญ แต่ไม่แทนผลที่สังเกตได้เมื่อฉีด Input หรือ Fault เข้าไป เกณฑ์ตรวจรับควรใช้ Test Evidence ที่ครอบคลุม State, HMI Message, Output Behavior, Event Record และ Product-quality Flag

ใช้ Reset เดียวกับ Fault ทุกประเภท

การล้าง Fault ที่มีสาเหตุ ความเสี่ยง และสิทธิ์ต่างกันด้วย Reset เดียว ทำให้ติดตามการเกิดซ้ำและผลต่อผลิตภัณฑ์ได้ยาก ควรกำหนด Acknowledgement, Cause Removal, Machine Consistency และ Restart Approval แยกตาม Fault Class

ไม่ส่งการแก้ไขหน้างานระหว่าง SAT กลับเข้าสู่รุ่นที่ควบคุม

หาก Backup ที่ส่งมอบไม่ตรงกับ Site Version จริง การบำรุงรักษาครั้งถัดไปอาจทำให้โปรแกรมย้อนกลับ ต้องบันทึก Version, Reason, Impact และ Retest ใน Change Record แล้วเก็บ Approved Final Configuration ใหม่

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

Sequence Control คืออะไร?

คือการควบคุมที่เปลี่ยน State และ Output ตามลำดับและเงื่อนไขที่กำหนด ข้อกำหนดที่ตรวจรับได้ควรรวม Mode, State, Permissive, Stop, Timeout, Fault, Recovery และ Evidence ไม่ใช่เฉพาะ Normal Sequence

ควรระบุ Ladder Program หรือ SFC?

เลือกตาม Controller, เครื่อง, Standard ของผู้ขาย และความสามารถ Maintenance LD เหมาะกับการตาม Contact ส่วน SFC เหมาะกับการมองโครง Step/State สิ่งสำคัญกว่าคือ Traceability ระหว่าง State Table กับ Code, Naming, Transition Rule และ Testability

PLC FAT สำหรับ State Transition ต้องตรวจอะไร?

ตรวจ Normal/Abnormal Transition, Permissive, Timeout, Output Behavior, HMI Code, Product Status, Event Record และ Recovery Authority โดยกำหนด Starting Condition กับ Injection Method แล้วเขียนเกณฑ์เป็นสิ่งที่สังเกตได้

Fault Recovery Sequence ควรเริ่มจากอะไร?

แยก Reset ออกจาก Restart ตรวจ Cause Removal, Machine Consistency, Work-in-process Disposition, Restart Point และ Approval Authority พร้อมแยกกรณีไฟหรือการสื่อสารกลับคืน

PLC FAT ใช้พิสูจน์ Functional Safety ของเครื่องได้หรือไม่?

ไม่ได้ FAT พิสูจน์ Normal-control Behavior ตามขอบเขตได้ แต่ไม่แทน Machinery Risk Assessment หรือการ Design, Integration และ Validation ของ Safety-related Control Function ตามมาตรฐานที่ใช้

สิทธิประโยชน์ BOI สำหรับ Automation รับประกันหรือไม่?

ไม่รับประกัน มาตรการมีเงื่อนไขโครงการ เงินลงทุนและค่าใช้จ่าย เส้นทางที่ใช้ขึ้นกับข้อเท็จจริงของโครงการ ต้องยืนยัน Eligibility, Calculation และ Application Timing กับ BOI หรือผู้เชี่ยวชาญ

สรุป

ขอบเขตตรวจรับ Sequence Control ควรเป็น Mode, State, Transition Guard, Permissive, Timeout, Fault Code, Recovery Authority, Recipe/Software Version และ Audit Evidence ไม่ใช่เพียง Ladder ที่เดิน Normal Cycle ได้ นำ State Table ไปสร้าง Fault-Injection Matrix แล้วใช้ FAT/SAT พิสูจน์ State, Output, Product Treatment, Message, Log และ Recovery แยก Functional Safety ออกจาก Normal Control และรักษา Evidence Chain จาก Requirement ถึง Version, Test และ Approval เพื่อให้เครื่องดูแลต่อได้หลังเริ่มผลิต

หากกำลังวางแผนเครื่องใหม่หรือปรับปรุงเครื่องในประเทศไทย และยังไม่แน่ใจว่าจะเขียน State Table หรือ Fault Case สำหรับ PLC FAT อย่างไร สามารถปรึกษาได้ตั้งแต่ขั้นกำหนดขอบเขต ติดต่อผ่าน TOMAS TECH เพื่อร่วมตรวจช่องว่างระหว่างเอกสารจัดซื้อ แบบของผู้ขาย และขั้นตอน Recovery หน้างาน

แหล่งอ้างอิง

• IEC 61131-3:2025: https://webstore.iec.ch/en/publication/68533
• PLCopen Software Construction Guidelines: https://plcopen.org/software-construction-guidelines
• ISA Standards News Archives: https://www.isa.org/standards-and-publications/isa-standards/news/standards-news-archives
• ISA TR88.00.02 preview (เอกสารพื้นหลังปี 2015): https://www.isa.org/getmedia/300dbd50-d549-41ac-b372-a5e52f32fc97/tr_880002_preview.pdf
• ISO 13849-1:2023: https://www.iso.org/standard/73481.html
• ISO 12100:2010: https://www.iso.org/cms/%20render/live/en/sites/isoorg/contents/data/standard/05/15/51528.html?browse=tc
• Thailand BOI 1H2026: https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&language=en&page=press_releases_detail&topic_id=139075
• Thailand BOI Smart and Sustainable Industry: https://www.boi.go.th/th/smart_sustainable