การพัฒนาซอฟต์แวร์ควบคุมเครื่องจักรในไทย: คู่มือตรวจรับปี 2026

เมื่อว่าจ้างภายนอกเพื่อ พัฒนาซอฟต์แวร์ควบคุมเครื่องจักร ในประเทศไทย สิ่งที่ตัดสินความสำเร็จไม่ใช่เพียงยี่ห้อ PLC หรือภาษาที่ใช้เขียนโปรแกรม ผู้ว่าจ้างต้องตกลงให้ชัดว่าเครื่องจักรเปลี่ยนสถานะอย่างไร ฟื้นตัวจากความผิดปกติแต่ละแบบอย่างไร ขอบเขตระหว่างระบบความปลอดภัยกับระบบควบคุมอยู่ตรงไหน และจะใช้หลักฐานใดตัดสินการตรวจรับ FAT/SAT บทความนี้รวมการออกแบบซอฟต์แวร์ PLC การออกแบบ state transition การฟื้นตัวจากเหตุผิดปกติ log และเวลา การควบคุมเวอร์ชัน simulation, FAT/SAT ตลอดจนการส่งมอบ source code, license และงานบำรุงรักษาไว้ในกรอบการจัดซื้อเดียว โดยไม่อธิบายซ้ำเรื่องพื้นฐานของโปรแกรม PLC หน้าจอ HMI ตู้ควบคุม หรือการเลือกหุ่นยนต์ แต่เน้น interface และหลักฐานการตรวจรับที่ตรวจสอบย้อนหลังได้

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

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

1. รายการสถานะการเดินเครื่องและ state transition ทั้งหมด
2. เงื่อนไขตรวจจับ พฤติกรรมหยุด และเงื่อนไขกู้คืนสำหรับเหตุผิดปกติแต่ละรายการ
3. ขอบเขตความรับผิดชอบระหว่าง safety function กับ standard control
4. สัญญา interface ระหว่าง PLC หุ่นยนต์ HMI ระบบตรวจสอบ และ MES/ERP
5. รายการ log ฐานเวลา ระยะเวลาเก็บ และวิธีดึงข้อมูล
6. วิธีควบคุมเวอร์ชันที่เชื่อม source, configuration, library และเครื่องจริง
7. test case และหลักฐานของ simulation, FAT และ SAT
8. เงื่อนไขส่งมอบ source code เครื่องมือพัฒนา license และข้อมูลบำรุงรักษา

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

ช่องว่างความเข้าใจห้าประการในการจ้างพัฒนาซอฟต์แวร์ควบคุมเครื่องจักร

คำว่า “อัตโนมัติ” อาจหมายถึงเฉพาะรอบปกติ

โรงงานมักคาดหวังว่าระบบจะรับมือวัสดุหมด คำสั่งซ้ำ การสื่อสารขาดหาย emergency stop ไฟดับ และการกู้คืนงานค้าง แต่ผู้รับจ้างอาจประเมินเฉพาะ nominal cycle จึงต้องแยก “รอบปกติ” ออกจาก “ขอบเขตการใช้งานจริง” และระบุ exception ที่รวมอยู่ในราคา

I/O list ไม่ได้กำหนดพฤติกรรม

ชื่อ sensor และ actuator ไม่ได้บอก debounce, delay, interlock, timeout, retry หรือเงื่อนไข manual operation I/O list จำเป็นแต่ไม่ใช่ข้อกำหนดซอฟต์แวร์ทั้งหมด

ความรับผิดชอบด้าน safety หายไประหว่างสัญญา

แม้บริษัทอื่นออกแบบ safety circuit แต่ standard control ยังต้องรับรู้ safety state ยับยั้งการ restart โดยไม่ตั้งใจ และนำผู้ปฏิบัติงานผ่านขั้นตอนกู้คืน ต้องแยกความรับผิดชอบของ safety function ออกจาก signal, permission และ restart condition ที่ standard PLC ใช้

FAT ผ่านไม่ได้แปลว่าพร้อมผลิต

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

การส่งมอบ source code ไม่ใช่เพียงการส่งไฟล์

แม้เปิด project file ได้ แต่อาจ reproduce ไม่ได้หากขาดเวอร์ชัน IDE, patch, device description, library, license, password และ build procedure เป้าหมายคือบุคคลที่สามที่ได้รับอนุญาตสามารถสร้าง baseline ที่อนุมัติแล้ว อธิบายความแตกต่าง และ restore จาก backup ได้

เริ่มกำหนดความต้องการด้วยตารางขอบเขต

ก่อนเพิ่มรายการฟังก์ชัน ให้ระบุว่าใครเป็นเจ้าของแต่ละด้านของ interface และหลักฐานแบบใดที่ยอมรับ

ในตารางควรมี owner, เงื่อนไขส่ง, acknowledgement, ค่าเริ่มต้น, timeout, retry และพฤติกรรมหลัง power cycle ไม่ใช่เพียง tag name รายละเอียดการออกแบบหน้าจออ่านได้จาก คู่มือพัฒนา HMI สำหรับโรงงานไทย และขอบเขตไฟฟ้าจาก การออกแบบตู้ควบคุมในประเทศไทย ส่วน RFP ซอฟต์แวร์นี้ควรเน้นจุดส่งต่องานและเงื่อนไขตรวจรับ

การออกแบบ state transition: วางสถานะปกติ หยุด ผิดปกติ และกู้คืนบนแผนเดียวกัน

IEC 61131-3:2025 กำหนด syntax และ semantics ของ Structured Text (ST), Ladder Diagram (LD), Function Block Diagram (FBD) รวมถึงองค์ประกอบ Sequential Function Chart (SFC) สำหรับจัดโครงสร้างภายในโปรแกรมและ function block ไม่ว่าจะใช้รูปแบบใด เอกสารจัดซื้อต้องทำให้ตรวจสอบ state model และ transition condition ของเครื่องได้ การระบุชื่อภาษาอย่างเดียวไม่เพียงพอ

ใช้ชื่อสถานะที่ผู้ปฏิบัติงานเข้าใจ

อย่างน้อยควรแยก power-up, pre-check, homing, idle, ready, executing, controlled stop, stopped, fault stop, recovery confirmation และ maintenance เชื่อมชื่อบน HMI, state code ใน log และค่า enumeration ในโปรแกรมให้ใช้คำชุดเดียวกัน

กำหนดสี่คุณลักษณะให้ทุก transition

ทุก transition ต้องมี start condition, completion condition, timeout และปลายทางเมื่อไม่สำเร็จ ตัวอย่างเช่นการเริ่ม transfer อาจต้องมี downstream ready, workpiece present, axis home และ safety permission การมาถึงของ sensor อย่างเดียวอาจไม่พอหากต้อง clamp และอ่าน ID ด้วย ต้องกำหนดว่า timeout แล้ว hold, retract ไปตำแหน่งปลอดภัย, retry หรือยกระดับเป็น fault

กำหนด recovery เป็นขั้นตอนการทำงาน ไม่ใช่ reset bit

แต่ละ alarm ต้องระบุ clear condition การตรวจ residual energy การจัดการ work in process วัสดุทดแทน การตัดสินคุณภาพ และจุด restart การกลับไป step ก่อนหน้าอาจทำให้ชิ้นงานถูก process ซ้ำ ขณะที่การขับออกทั้งหมดอาจสร้าง scrap มาก จึงต้องประเมิน machine state และ product state แยกกัน พร้อมระบุว่าใครตรวจอะไรจึงเริ่มใหม่ได้

ทดสอบไฟดับและสื่อสารขาดหายแยกกัน

กำหนดผลต่อ retained value, ตำแหน่งแกน, result ที่ยังไม่ตอบรับ และ ID ที่กำลัง process หากไฟดับหลังส่ง result แต่ก่อนรับ acknowledgement การ resend ต้องไม่สร้างข้อมูลซ้ำ ขอบเขต autonomous operation ระหว่างเครือข่ายขัดข้องต้องอิง buffer และความเสี่ยงคุณภาพ ไม่ใช่ตัวเลขตายตัวที่ไม่มีเหตุผล

ใช้ abnormal-recovery matrix เป็นแกนของ RFP

ความแตกต่างระหว่างผู้รับจ้างอยู่ที่ exception handling มากกว่าลำดับปกติ เปลี่ยน alarm list ให้เป็น recovery matrix

แปลงทุกแถวเป็น test case หนึ่งรายการขึ้นไป ข้อความว่า “ทดสอบ alarm ทั้งหมด” ไม่สามารถเทียบราคาได้ แต่ input condition และ expected outcome ทำให้เห็น test effort ชัดเจน

ขอบเขตความปลอดภัย: อย่าให้ standard PLC รับ safety function อย่างคลุมเครือ

ISO 13849-1:2023 ครอบคลุม methodology พร้อม requirements, recommendations และ guidance สำหรับการออกแบบและรวม safety-related parts of control systems (SRP/CS) รวมถึงการออกแบบซอฟต์แวร์ บทคัดย่อสาธารณะยังระบุว่ามาตรฐานนี้ไม่ได้กำหนด safety function หรือ required performance level สำหรับ application เฉพาะ ดังนั้นข้อความ “สอดคล้อง ISO 13849-1” เพียงบรรทัดเดียวไม่สามารถกำหนด safety function ของเครื่องได้

หลัง risk assessment และยืนยันมาตรฐานที่ใช้ ให้แยกอย่างน้อยดังนี้

• ขอบเขต safety circuit, safety controller และอุปกรณ์ safety
• safety status และ diagnostics ที่ standard PLC อ่านได้
• ความแตกต่างระหว่าง safety reset กับ alarm reset ปกติ
• เงื่อนไขที่ยับยั้ง automatic restart หลัง safety recovery
• การเคลื่อนที่ ความเร็ว และขอบเขตที่อนุญาตใน manual/maintenance mode
• ผู้จัดทำและผู้อนุมัติ safety validation evidence

หากมี robot cell ให้อ้างอิง การติดตั้งหุ่นยนต์อุตสาหกรรมและ ISO 10218 แล้วกำหนดหลักฐานของ cell status, PLC handshake และ recovery order ในโครงการนี้แทนการอธิบายพื้นฐานหุ่นยนต์ซ้ำ

Interface contract: จาก tag list สู่ข้อกำหนดตามลำดับเวลา

การออกแบบซอฟต์แวร์ PLC ที่ดีต้องตกลงลำดับ interaction หลัง start request อีกฝ่ายตอบ accepted, busy, complete อย่างไร หาก request หายระหว่างทำงานจะยกเลิกหรือทำต่อ ออก request ใหม่ก่อน acknowledge complete ได้หรือไม่ และป้องกัน complete เก่าหลังอีกฝ่าย restart อย่างไร ให้บันทึกเป็น timing diagram หรือ sequence diagram

ชื่อ protocol ไม่รับประกันพฤติกรรม ใช้ test data ชุดเดียวกันทั้งสองฝั่งและเก็บค่าที่ส่ง ค่าที่รับ การทำงานของเครื่อง และผลที่บันทึกไว้ใน test case เดียว

Log และเวลา: กำหนดรายละเอียดที่พอสร้างเหตุการณ์ย้อนหลัง

การเก็บ log มากไม่ได้แปลว่าดีกว่า เป้าหมายคือเชื่อม machine state, operator action, alarm, communication, software release และ workpiece บน timeline เดียว

รูปแบบ log ขั้นต่ำที่ใช้งานได้

• Event timestamp และสถานะของ time source
• machine, station, unit ID
• state ก่อนและหลัง transition
• user หรือ permission role
• alarm occurrence, acknowledgement, clearance
• request/response สำคัญพร้อม correlation ID
• recipe, software และ configuration release
• work ID หรือ production unit ที่ trace ได้
• result และ reason code

หากนาฬิกา PLC, IPC, robot และ server ไม่ตรงกัน ทีมสอบสวนอาจสรุปลำดับเหตุผิด กำหนด synchronization source, diagnostics เมื่อ sync หาย และนโยบายเก็บ UTC เทียบ local time ใน FAT/SAT ให้ตัด time sync โดยตั้งใจและตรวจการแจ้งเตือน ระยะเวลาเก็บต้องอิงความต้องการสอบสวน คุณภาพ storage, privacy และลูกค้า ไม่ควรสร้างระยะมาตรฐานขึ้นเอง

การควบคุมเวอร์ชัน: เชื่อม source, setting, recipe และเครื่องจริงเป็น baseline เดียว

โฟลเดอร์ latest.zip ไม่พิสูจน์ว่า source ตรงกับเครื่อง อย่างน้อยต้องระบุเวอร์ชันของ

• source ของ PLC, HMI, robot และ IPC
• compiler/IDE และ add-on ที่ต้องใช้
• external library และ license
• hardware configuration และ device description
• การตั้งค่า I/O, network และ safety boundary
• ค่าเริ่มต้น recipe/parameter
• baseline ที่อนุมัติใน FAT, SAT และ production

Change request ทุกใบควรเชื่อม purpose, impact, changed files, test scope, rollback และ approval PLCopen เผยแพร่แนวทางด้าน coding rule, library และโครงสร้าง SFC สำหรับ industrial control และเผยแพร่ guideline ด้าน software quality metrics ในปี 2023 ไม่ควรตีความเป็นตัวเลขเดียวที่รับประกันคุณภาพ แต่ควรแปลงเป็นกฎของโครงการด้าน naming, structure, complexity review, reuse และ peer review

คำอธิบายสาธารณะของ IEC 61131-3:2025 ระบุการเพิ่ม UTF-8 string และฟังก์ชันที่เกี่ยวข้อง หากใช้ข้อความหลายภาษา หรือ recipe name ต้องทดสอบ round-trip ผ่าน PLC runtime, HMI, interface และ CSV/database จริง เวอร์ชันมาตรฐานใหม่ไม่ได้แปลว่า controller ที่ติดตั้งรองรับทุก feature โดยอัตโนมัติ

Simulation: ค้นหาช่องว่างของข้อกำหนดก่อนเครื่องเสร็จ

เป้าหมายไม่ใช่สร้างเครื่องเสมือนที่เหมือนจริงทุกด้าน แต่คือทดสอบ state transition, interface และ exception ให้เร็ว แบ่งขอบเขตเป็นสามชั้น

รวมกรณี sensor ไม่มา response ล่าช้า message ซ้ำ ลำดับกลับกัน และ setting เกินช่วง Simulation ไม่สามารถพิสูจน์ mechanical clearance, wiring noise หรือ safety performance จริง จึงไม่แทน FAT/SAT แต่ลดงาน debug ที่หน้างานได้มาก

FAT และ SAT สำหรับซอฟต์แวร์: เปลี่ยน test sheet เป็น evidence package

ขอบเขต FAT

FAT ควรครอบคลุม I/O ที่อนุมัติ state, major cycle, abnormal recovery, role, alarm, communication, log, backup และ restore หากไม่มีชิ้นงานหรือระบบจริง ให้บันทึกตัวแทนและเหตุผลที่ยกไป SAT Freeze release ในทุก case และ rerun case ที่ได้รับผลกระทบหลังแก้ไข

ขอบเขต SAT

SAT ใช้สายจริง plant network ระบบ production ชิ้นงานจริง factory time source ผู้ใช้จริง อุปกรณ์รอบข้าง และ utility ไม่จำเป็นต้องทำ FAT ซ้ำทุกข้อ แต่รายการที่กระทบจากขนส่ง ติดตั้ง หรือเปลี่ยน setting ต้องตรวจใหม่

รูปแบบหลักฐาน

หลักฐานต้องชี้ว่าเป็น case และ release ใด ไม่ใช่เพียงมีคนเห็นวิดีโอ Acceptance criteria ควรรวม recoverability, log completeness และ baseline reproducibility นอกเหนือจาก cycle performance

ใส่ secure development และ maintenance ลงในสัญญา

คำอธิบาย IEC 62443-4-1:2018 ครอบคลุม secure development lifecycle สำหรับผลิตภัณฑ์ IACS เช่น security requirements, secure design/implementation, verification/validation, defect management, patch management และ product end-of-life คำอธิบายเดียวกันระบุว่าข้อกำหนดใช้กับผู้พัฒนาและผู้บำรุงรักษาผลิตภัณฑ์ ไม่ได้ใช้กับ integrator หรือ user โดยตรง จึงไม่ควรบังคับคำรับรองที่ไม่ถูกต้องแก่ผู้สร้างเครื่องทุกโครงการ แต่ให้แปลง control ที่เกี่ยวข้องเป็นข้อกำหนดสัญญา

• ขั้นตอนอนุมัติ authentication, logging และยุติ remote access
• แยก development account กับ production account
• ยืนยันการถอน default password และ temporary account
• จุดติดต่อเรื่อง dependency และ known vulnerability
• priority, mitigation และ corrective release ของ security defect
• pre-patch assessment, backup, rollback และ regression test
• การแจ้ง end-of-life ของผลิตภัณฑ์ อุปกรณ์ และเครื่องมือ

ISA อธิบาย ISA/IEC 62443 ว่าเป็นข้อกำหนดและกระบวนการสำหรับสร้างและรักษา IACS ที่ปลอดภัย โดยเน้น shared responsibility ของ asset owner, product supplier, integrator และ service supplier โรงงานจึงยังต้องรับผิดชอบ asset, account, backup และ change approval ไม่สามารถมอบให้ supplier ทั้งหมด

เงื่อนไขตรวจรับการส่งมอบ source code, license และ maintenance

ตรวจด้วย reproduction test ไม่ใช่เพียง file list

แยก ownership, modification right, reusable supplier library, third-party component และสิทธิ์แต่งตั้งผู้บำรุงรักษารายอื่น การส่ง source ไม่เท่ากับโอน copyright ถอน private key และ personal credential ออกจาก source แล้วส่ง secret ไปยัง vault ที่โรงงานควบคุม

เปรียบเทียบราคาพัฒนาซอฟต์แวร์ควบคุมด้วย effort driver

ราคาเหมารวมก่อนข้อกำหนดชัดจะซ่อนสมมติฐาน ให้แยกตาม

• จำนวน state, station, axis, device และ concurrent motion
• product variant, recipe, changeover และ traceability
• จำนวน interface ของ robot, inspection, MES และความพร้อมของข้อกำหนดอีกฝ่าย
• abnormal scenario, recovery policy, manual/maintenance mode
• ขอบเขต safety และการสนับสนุน validation
• log, audit, user role และภาษา
• simulation, จำนวน FAT/SAT case และการเตรียมชิ้นงานจริง
• เวลาหน้างาน วันหยุด ล่าม เดินทาง และเงื่อนไขรอ
• source, licence, document, training, warranty, maintenance
• การวิเคราะห์เครื่องเก่าและ contingency ของพฤติกรรมที่ยังไม่รู้

แต่ละ driver ต้องระบุ included, excluded, customer-supplied และวิธีเปลี่ยนสัญญาเมื่อสมมติฐานไม่เป็นจริง เปรียบเทียบ effort ที่จัดให้ review, test, document และ handover ไม่ใช่เฉพาะราคารวม

การดำเนินงานในโรงงานไทย: ใส่เงื่อนไขท้องถิ่นไว้ในแผนตรวจรับ

BOI/OSOS รายงานเมื่อเดือนกรกฎาคม 2026 ว่า ช่วงครึ่งแรกของปี 2026 ประเทศไทยมีคำขอส่งเสริมการลงทุนในสาขาเครื่องจักร ระบบอัตโนมัติ และหุ่นยนต์ 82 โครงการ มูลค่าประมาณ 13.1 พันล้านบาท และมีคำขอ 132 โครงการ มูลค่าประมาณ 17.2 พันล้านบาท ภายใต้ Smart and Sustainable Industry สำหรับการปรับปรุงเครื่องจักร เทคโนโลยีดิจิทัล และการรวม automation/robotics ตัวเลขนี้ไม่ได้รับรองสิทธิประโยชน์หรือผลตอบแทนของโครงการใด แต่สะท้อนบริบทการปรับปรุงอุตสาหกรรมต่อเนื่อง

หน้า BOI สำหรับมาตรการ automation ในอุตสาหกรรมยานยนต์อธิบายการนับค่า software ที่เชื่อมกับเครื่องจักรเพื่อควบคุมและสนับสนุนการผลิต แต่หน้าเดียวกันระบุวันปิดรับคำขอในปี 2025 จึงห้ามนำกำหนดเก่ามาอ้างเป็นมาตรการปัจจุบันของปี 2026 ต้องตรวจประกาศ BOI ล่าสุด ประเภทธุรกิจ ช่วงเวลายื่น และเงื่อนไขรับรองกับ BOI หรือผู้เชี่ยวชาญเป็นรายโครงการ

จัดทีมตรวจรับร่วมระหว่างเจ้าของเครื่อง ฝ่ายผลิตและซ่อมบำรุงในไทย local SI ผู้สร้างเครื่อง และ IT/MES ตั้งแต่ kickoff ให้กำหนดภาษาฉบับควบคุม ผู้รับผิดชอบการแปล หน่วย รูปแบบวันที่ งานวันหยุด/กลางคืน อะไหล่ และการอนุมัติ remote access

การเลือกผู้รับจ้าง: ประเมินวิธีตอบคำถาม ไม่ใช่ดูแต่ demo

ส่ง abnormal scenario เดียวกันให้ผู้เสนอราคาทุกราย แล้วเปรียบเทียบว่าออกแบบ ทดสอบ และส่งมอบอย่างไร

1. Review state transition ด้วยเอกสารใด
2. นับกรณีนอก nominal cycle ในราคาอย่างไร
3. ใครตกลง boundary กับ safety control
4. ควบคุม interface change อย่างไร
5. อะไร simulation ได้และไม่ได้
6. จัดแพ็กเกจ FAT/SAT evidence อย่างไร
7. ยืนยัน source ตรงกับเครื่องจริงอย่างไร
8. standard library มีสิทธิ์และเงื่อนไข support อย่างไร
9. วิศวกรคนใหม่ reproduce release จากเอกสารได้หรือไม่
10. ใครรับ notice เรื่อง defect, vulnerability และ EOL

คำตอบที่ดีต้องมี assumption, artifact, exception และ test method ความสามารถในการเปิดเผยประเด็นที่ยังไม่ตัดสินใจตั้งแต่ต้นสำคัญพอ ๆ กับความสามารถเขียนโปรแกรม

Checklist สำหรับ RFP

Requirements และ design

• [ ] Equipment scope, exclusion และ responsibility matrix
• [ ] State list, transition และ timeout
• [ ] Detection, stop, recovery และการจัดการงานค้าง
• [ ] Manual, maintenance, changeover และ permission
• [ ] Boundary ระหว่าง safety กับ standard control
• [ ] Owner และ time sequence ของทุก interface
• [ ] Logging, clock synchronization, retention และ export

Development และ testing

• [ ] Coding rule, review และ release control
• [ ] Simulation scope และ test data
• [ ] FAT/SAT case, equipment, workpiece และ responsibility
• [ ] Nonconformance, change, retest และ conditional acceptance
• [ ] Minimum control สำหรับ secure development และ remote support

Handover และ support

• [ ] Source, setting, toolchain และ licence inventory
• [ ] Release reproduction และ backup restore test
• [ ] IP, modification, third-party maintenance และ secret handling
• [ ] Training, warranty, incident triage และ EOL notice
• [ ] Open-item list และช่องทางปรับปรุงหลังเริ่มผลิต

FAQ เรื่องการว่าจ้างซอฟต์แวร์ควบคุมเครื่องจักร

ควรเริ่มกำหนด requirement ของซอฟต์แวร์เครื่องจักรจากอะไร

เริ่มจาก boundary, operating state, abnormal recovery และ external interface แล้วแปลงแต่ละ state และ boundary เป็น acceptance test สำหรับเครื่องเก่าให้ระบุว่ามี source หรือไม่ release บนเครื่องคืออะไร หยุดเครื่องได้นานแค่ไหน และพฤติกรรมใดที่ยัง reproduce ไม่ได้

เขียนว่า IEC 61131-3 compliant เพียงพอสำหรับการออกแบบซอฟต์แวร์ PLC หรือไม่

ไม่เพียงพอ มาตรฐานให้พื้นฐานร่วมของ syntax, semantics และโครงสร้างภาษา แต่โครงการยังต้องกำหนด state, recovery, naming, library, review, test และ feature ที่ controller รุ่นจริงรองรับ

เครื่องขนาดเล็กต้องออกแบบ state transition หรือไม่

ระดับรายละเอียดเปลี่ยนตามขนาด แต่เครื่องเล็กก็มี power-up, idle, run, stop, fault และ recovery ใช้ตารางแทน diagram ได้ จุดสำคัญคือทำให้เงื่อนไขกู้คืนที่เคยเป็นความเข้าใจโดยนัยสามารถทดสอบได้

เปรียบเทียบค่าจ้างพัฒนาซอฟต์แวร์ควบคุมอย่างไร

เปรียบเทียบ effort driver ของ state, exception, interface, test, onsite work, document, handover และ support ทำเงื่อนไขที่ลูกค้าจัดหาและ exclusion ให้ตรงกัน และกำหนดว่า assumption ใดเปลี่ยนเป็น change order

แบ่งการทดสอบซอฟต์แวร์ระหว่าง FAT และ SAT อย่างไร

Logic, state, exception, communication, log และ restore ที่ทำซ้ำได้ควรทำใน FAT ส่วนสายจริง ชิ้นงานจริง plant network, production system, clock และผลจากการติดตั้งตรวจใน SAT ทั้งสองขั้นต้องมี release ID และ evidence

การส่งมอบ source code ต้องตรวจอะไรบ้าง

นอกจาก source ต้องตรวจ IDE/patch, device definition, dependency, license, build/download procedure, setting, secret transfer และ change history ให้เปิดหรือ build ใน clean environment และเปรียบเทียบกับ approved release บนเครื่อง

จะกำหนด boundary ระหว่าง safety function กับ standard PLC อย่างไร

ใช้ risk assessment และ applicable standard ออกแบบ safety-related scope แล้วกำหนด safety status, reset, restart permission และ diagnostics ที่ standard control เห็นได้ ควรยืนยัน safety function และ required performance ของเครื่องเฉพาะกับผู้เชี่ยวชาญด้าน machinery safety

สรุป: ออกแบบย้อนกลับจากหลักฐานเพื่อให้ได้ซอฟต์แวร์ที่บำรุงรักษาได้

สัญญาพัฒนาซอฟต์แวร์ควบคุมเครื่องจักรที่ดีต้องรวม nominal sequence, state transition, abnormal recovery, safety boundary, interface, log/time, version control, simulation, FAT/SAT และการส่งมอบ source/licence/maintenance ให้เชื่อมทุก requirement กับ test case และ evidence พร้อมตรวจรับ baseline ที่บุคคลที่สามซึ่งได้รับอนุญาต reproduce ได้ วิธีนี้ช่วยลด downtime ยาวและการพึ่งพา programmer คนเดียวได้จริง

หากโครงการซอฟต์แวร์ควบคุมเครื่องจักรในโรงงานไทยยังอยู่ในรูป note กระจัดกระจายและยังไม่มี state model หรือ test sheet TOMAS TECH สามารถช่วยจัด boundary matrix, RFP, FAT/SAT และแพ็กเกจส่งมอบตั้งแต่ก่อนเริ่มพัฒนา ติดต่อผ่าน หน้าสอบถาม TOMAS TECH พร้อมขอบเขตเครื่องจักรและข้อมูลที่มีอยู่ในปัจจุบัน

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

• IEC 61131-3:2025
• ISO 13849-1:2023
• IEC 62443-4-1:2018
• ภาพรวม ISA/IEC 62443
• PLCopen Software Construction Guidelines
• PLCopen Guideline on Software Quality Metrics
• หน้า BOI มาตรการระบบอัตโนมัติ
• BOI/OSOS รายงานการลงทุนครึ่งแรกปี 2026