Thiết kế điều khiển tuần tự: State, Recovery và PLC FAT

Chất lượng điều khiển tuần tự không thể chỉ được đánh giá bằng việc chương trình Ladder chạy hết chu trình bình thường. Bên mua còn cần biết máy chuyển sang trạng thái nào khi cảm biến không phản hồi, ai có quyền xác nhận và phục hồi, sản xuất được tiếp tục từ đâu, và bằng chứng nào được lưu lại. Bài viết này trình bày cách biến chế độ vận hành, chuyển trạng thái, phục hồi lỗi và phiên bản phần mềm thành ranh giới nghiệm thu PLC FAT/SAT có thể kiểm toán bằng bảng trạng thái và thử nghiệm chèn lỗi.

Vì sao “chạy được chu trình bình thường” chưa phải tiêu chí nghiệm thu

Báo giá máy thường ghi “chương trình PLC”, “trình tự tự động” và “chạy thử” nhưng không định nghĩa chính xác khi nào phần mềm được coi là hoàn thành. Nhà cung cấp trình diễn nạp phôi, khởi động, gia công và lấy phôi ra; bên mua kiểm tra Cycle Time và thành phẩm. Trong sản xuất thực tế vẫn sẽ có thiếu vật liệu, cảm biến không tác động, mất truyền thông, tụt áp khí, dừng giữa chu trình, đổi Recipe hoặc khởi động lại sau mất điện.

Tranh luận khi đó hiếm khi nằm ở cú pháp Ladder mà nằm ở ý nghĩa trạng thái: Khi Hold thì Output nào được duy trì? Restart tiếp tục tại bước gián đoạn hay phải Home? Timeout là cảnh báo hay Fault giữ? Chi tiết dở dang được xem là đạt, loại bỏ hay cách ly? Nếu hợp đồng không xác định, các quyết định sẽ dồn vào giai đoạn Commissioning cuối dự án.

Do đó, nên xác định ranh giới mua hàng bằng các đầu ra có thể rà soát:

Về phạm vi thuê ngoài tổng thể, có thể xem thuê phát triển chương trình PLC tại Thái Lan. Bài này tập trung sâu hơn vào nghiệm thu dừng máy, lỗi và phục hồi.

Dùng IEC 61131-3 và SFC như ngôn ngữ chung

IEC 61131-3:2025 quy định cú pháp và ngữ nghĩa của Structured Text (ST), Ladder Diagram (LD) và Function Block Diagram (FBD) cho bộ điều khiển lập trình. Tiêu chuẩn cũng định nghĩa các phần tử Sequential Function Chart (SFC) để cấu trúc chương trình và Function Block. IEC công bố ngày 22/05/2025, Edition 4.0.

Vấn đề thực tế không phải ngôn ngữ nào “tốt nhất”. LD thường thuận tiện để theo dõi Contact và Interlock; ST có thể diễn đạt kiểm tra dữ liệu và Recipe rõ ràng; SFC làm lộ cấu trúc Step, Transition và Action. PLCopen cũng lưu ý SFC cần ngôn ngữ khác để biểu diễn điều kiện chuyển và hành động, vì vậy không nên coi SFC là ngôn ngữ độc lập giải quyết mọi việc.

Thay vì bắt buộc mọi Module dùng SFC, hãy yêu cầu:

• trạng thái hoặc bước và điều kiện chuyển phải truy vết được;
• Logic Output và quyết định trạng thái không tạo phụ thuộc vòng khó kiểm tra;
• phân biệt Permissive, Process Interlock và quyết định Fault;
• thao tác Manual không âm thầm phá trạng thái Automatic;
• tên State, Signal và Alarm thống nhất giữa tài liệu, Code và HMI;
• Version Diff cho biết phần thay đổi và phạm vi cần Retest.

PLCopen Software Construction Guidelines bao gồm quy tắc lập trình và đặt tên, Library, SFC do’s and don’ts, lập trình hướng đối tượng và Software Quality Metrics. Đây không phải tài liệu thay thế yêu cầu chức năng của bên mua, nhưng là nền tảng hữu ích cho Code Review với nhà cung cấp.

Tách Operating Mode khỏi Machine State

AUTO và MANUAL là Mode; STOPPED, STARTING, RUNNING, HELD và ABORTED là State. Nếu gộp hai khái niệm vào một số nguyên hoặc nhóm Bit ẩn, tổ hợp sẽ nhanh chóng mơ hồ. Manual có thể Idle hoặc Active; Auto có thể Ready, Starting, Running, Holding hoặc Stopping. Hai trục rõ ràng giúp quy định tổ hợp hợp lệ và bị cấm.

Nội dung của bảng Mode

Với mỗi Mode, xác định người được chọn, điều kiện trước khi đổi, lệnh khả dụng, giới hạn chuyển động/Output và State sau khi chọn.

Đây là ví dụ thiết kế, không phải yêu cầu Safety. Cô lập năng lượng nguy hiểm và Safety Function phải được xác định từ Risk Assessment của máy, tách khỏi Logic trình tự thông thường.

Viết trạng thái theo Entry, Active và Exit

Tên trạng thái đơn lẻ không thể thử nghiệm. Mỗi State cần Entry Action, Output và nội dung Monitor khi Active, Normal Transition, Abnormal Transition và Exit Action. ISA đã thông báo xuất bản ISA-TR88.00.02-2022, áp dụng khái niệm ISA-88 cho trạng thái và chế độ của máy tự động, kèm ví dụ về State Model, Procedure, Implementation và Tag Naming. Có thể dùng làm từ vựng chung nhưng không nên sao chép mô hình mà không điều chỉnh cho máy cụ thể.

Tên trên chỉ là ví dụ. Điều cốt lõi là bảng, PLC, HMI và Event Record dùng cùng một ý nghĩa.

Phân biệt Permissive, Process Interlock và Fault

Nhà máy thường gọi cả ba là “Interlock” dù mục đích khác nhau. Điều kiện ngăn Start, điều kiện khóa một Output khi đang Run và sự kiện cần người xử lý không nên tự động dùng cùng cách Latch, Message và Recovery.

Permissive

Permissive là điều kiện tiên quyết để nhận lệnh: đã Home, có vật liệu, máy sau sẵn sàng, Recipe được duyệt hoặc Handshake giữa máy thành công. Nếu thiếu, HMI nên hiển thị lý do “Not Ready” mà không nhất thiết tạo Fault History mới ở mỗi Scan.

Process Interlock trong điều khiển thông thường

Interlock loại này bảo toàn thứ tự hoặc thiết bị, ví dụ cấm gia công trước khi Clamp hoặc cấm Transfer trước khi Axis tới vị trí. Phải quy định khi điều kiện trở lại thì tự Resume hay cần lệnh mới.

Fault

Fault là sự kiện cần phản ứng, xử lý trạng thái sản phẩm hoặc lưu lịch sử. Ghi Code, State khi phát sinh, Input liên quan, Cycle/Part bị ảnh hưởng, thời điểm đầu và thời điểm phục hồi. “Lỗi xi lanh” quá rộng; “đã phát lệnh tiến nhưng tín hiệu giới hạn tiến không ON trước thời hạn giám sát” phản ánh đúng quan sát của PLC mà không vội kết luận van, khí, dây, cảm biến hay cơ cấu hỏng.

Timeout là hành vi, không chỉ là giá trị Timer

Đặc tả Timeout cần điều kiện bắt đầu Monitor, Expected Response, Deadline, quy tắc hoàn tất, State đích, Output Action, Product Action và Retry Policy. Một con số không thể nghiệm thu nếu không thống nhất thời điểm bắt đầu.

Ví dụ tính toán (giả định): Actuator thường phản hồi trong 0,8 giây, biên dao động quan sát 0,3 giây và dự phòng Communication/Scan 0,4 giây. Có thể đặt ban đầu 0,8 + 0,3 + 0,4 = 1,5 giây, sau đó điều chỉnh bằng Log FAT và SAT trên máy thật. 1,5 giây chỉ là giả định minh họa, không phải giá trị khuyến nghị chung.

Duy trì Output sau Timeout có thể làm kẹt nặng hơn, nhưng cắt mọi Output ngay cũng có thể làm rơi phôi hoặc mất trạng thái chất lượng. Nhóm dự án phải phân biệt điều kiện giảm rủi ro của máy với Process Hold để bảo toàn sản phẩm, kết hợp Machine Design, Process Requirement và Risk Assessment.

Đưa Fault Code và HMI vào tiêu chí nghiệm thu

Mỗi Fault Code Record nên có:

• Code duy nhất và thông điệp theo từng ngôn ngữ;
• Mode/State có thể phát sinh;
• điều kiện PLC thực sự quan sát;
• phản ứng Stop/Hold của máy;
• trạng thái của chi tiết bị ảnh hưởng;
• mục Operator/Technician cần kiểm tra;
• Reset Condition và Required Authority;
• có Auto Retry hay không và giới hạn;
• FAT Test ID chứng minh hành vi.

Trong nhà máy đa ngôn ngữ, Code phải dùng chung dù câu chữ được dịch. HMI tiếng Thái và tài liệu bảo trì tiếng Việt, Nhật hoặc Anh vẫn có thể nói về cùng một Event.

Thiết kế Fault Recovery vượt ra ngoài nút “Reset”

Tránh Logic trong đó Reset xóa Bit và lập tức cấp lại Output. Hãy tách phục hồi thành loại bỏ nguyên nhân, Acknowledge, kiểm tra tính nhất quán trạng thái máy, xử lý sản phẩm, chọn Home/Restart Point và phê duyệt Restart.

Phân quyền Recovery

Operator có thể phục hồi thiếu vật liệu đơn giản; Servo Following Error, dữ liệu chất lượng không nhất quán hoặc sự kiện sau khi Protective Device tác động có thể cần Maintenance hay Quality Approval. Liên kết Role trên HMI với Audit Event về người xác nhận, nội dung và thời điểm.

Kiểm soát Work in Process

Máy phục hồi cơ khí không đảm bảo chi tiết dở dang còn đạt. Phải theo dõi công đoạn đã xong, Measurement, Traceability ID, Hold Duration và quyền Rework rồi chuyển sản phẩm sang Resume, Controlled Discharge, Quarantine hoặc Scrap theo Quality Procedure. PLC có thể giữ trạng thái nhưng không nên tự đưa ra phán quyết chất lượng cuối cùng.

Tách trường hợp Power Restoration

Sau mất điện, Volatile Data, Physical Output, Communication Session, Servo Position và State của thiết bị ngoài có thể không còn nhất quán. Phân loại dữ liệu Retain, Initialize và Reconcile, đồng thời định nghĩa Power-up State riêng. Không dùng Normal Fault Reset để che giấu bước đối soát này.

Quản lý Recipe và Software như một Tested Configuration

Cùng PLC Code nhưng Recipe, HMI Setting, Robot Program hoặc Vision Parameter khác có thể cho hành vi khác. Bằng chứng FAT phải ghi đủ Configuration đã thử: PLC, HMI, Robot, Vision, Recipe và Drawing Revision liên quan.

Mỗi cập nhật cần có lý do, người sửa, người duyệt, State/Fault/Product bị ảnh hưởng và Regression Test cần chạy. Online Edit khi Commissioning phải được thu hồi về Controlled Master để lần bảo trì sau không ghi đè sản xuất bằng Backup cũ. Vấn đề chuyển đổi thiết bị hiện hữu được trình bày tại thay thế và Retrofit PLC tại Thái Lan.

Xây dựng PLC FAT từ bảng trạng thái và Fault Injection

FAT không chỉ là Demo sản xuất. Nó phải áp Stimulus có kiểm soát vào từng Requirement liên quan và chứng minh Expected State, Output, Message, Product Status, Log và Recovery.

Các cột của Fault-Injection Matrix

Từ mỗi State, triển khai Normal Transition, thiếu Permissive, Expected Input không đến, Input mất giữa Step, Stop Request, Mode Change, Communication Loss và Power Restart. Ưu tiên theo Risk, khả năng xảy ra, độ khó phát hiện và tác động sản phẩm thay vì thử tổ hợp không giới hạn.

Ví dụ tính toán (giả định): 8 State, mỗi State có 3 lỗi đại diện sẽ tạo 8 × 3 = 24 Case. Lặp toàn bộ trong 3 Mode sẽ thành 72 Case, nhưng Logic dùng chung có thể cho phép Representative Coverage nếu có lý do. Đây chỉ là cách ước lượng Scope, không phải số Case bắt buộc.

Thống nhất phương pháp Inject

Force Input bằng Software, dùng Simulator và ngắt thiết bị thật có độ lặp lại và Risk khác nhau. Trước FAT, thống nhất Signal được mô phỏng, nội dung chỉ kiểm tra được trên máy thật, cách xác nhận đã Clear Force và người được truy cập Test Mode. Nếu Bypass còn trong Production Build, phải có Authorization, hiển thị rõ, Logging và cơ chế kiểm tra gỡ bỏ.

Làm Pass/Fail quan sát được

“Dừng đúng” không phải tiêu chí Pass. Hãy tách Expected State, Output, HMI Code, Product Flag, Event Time và Recovery Role. Nếu bằng chứng chỉ nằm trong Online View của Programmer, bên mua không thể tái kiểm tra. Cần thống nhất Event Export, Trend, Screenshot hoặc Video có thể bàn giao.

Phân chia vai trò FAT và SAT

FAT kiểm tra Panel, PLC, HMI, Simulator và máy lắp tại nhà cung cấp. SAT bổ sung Utility thật, Product thật, máy trước/sau, Network sản xuất, người dùng và Host System. FAT đạt không đồng nghĩa mọi Production Condition đã được kiểm tra.

Mọi điều chỉnh tại SAT phải được ghi như Difference so với FAT-approved Configuration. Nếu gọi Online Change là “tinh chỉnh nhỏ” mà không lưu, chương trình tại Site, Final Backup và Test Result sẽ khác nhau. Về ranh giới mua máy tổng thể, xem mua sắm máy chuyên dụng tại Thái Lan.

Nối Requirement đến Audit Log thành một chuỗi bằng chứng

Test Report không có giá trị lâu dài nếu không chỉ ra Requirement và Software Configuration đã thử. Hãy nối Requirement ID, State Model, Software Version, Test ID, Result, Approval và từ vựng Event trong sản xuất.

Evidence Chain cần trả lời:

1. Requirement được thực hiện ở Mode, State hay Transition nào?
2. Nó nằm trong PLC/HMI/Recipe Configuration nào?
3. FAT/SAT Test nào chứng minh?
4. Kết quả đo và tệp đính kèm là gì?
5. Ai duyệt, khi nào và với điều kiện nào?
6. Có truy cùng ID trong Fault/Recovery Log sản xuất được không?

Traceability giúp chọn Regression Test khi sửa Fault Message, Transition hoặc Recipe Limit. Audit Log không nhằm giám sát nhân viên mà nhằm tái dựng Event, Version và Authorized Recovery Decision. Thời gian lưu và quyền truy cập phải theo Quality/Security Policy của khách hàng.

Tách điều khiển tuần tự thông thường khỏi Functional Safety

Đây là ranh giới quan trọng nhất. Stop Condition, Process Interlock, hiển thị Emergency Stop hay Recovery Routine trong Standard PLC không tự đáp ứng Functional Safety. ISO 12100:2010 đưa ra nguyên tắc và phương pháp Risk Assessment/Risk Reduction cho máy; ISO ghi nhận phiên bản này đã được rà soát và xác nhận năm 2022. ISO 13849-1:2023 đề cập phương pháp thiết kế và tích hợp Safety-related Parts of Control Systems, gồm cả Software.

Vì vậy Hazard, Required Risk Reduction, Safety Function, Required Performance, Architecture, Diagnostic và Validation phải được người có năng lực thực hiện riêng dựa trên tiêu chuẩn áp dụng và Risk Assessment của máy. State Table của Normal Control có thể giúp quản lý máy sau khi Safety Function tác động, nhưng không thay Safety PLC, Safety Circuit hay Safety Function đã Validation.

Purchase Specification phải nêu Responsibility Boundary giữa Standard PLC, Safety PLC/Circuit, Drive Safety Function, Mechanical Safeguard và Operating Procedure. Nếu Standard PLC đọc Safety Status để hiển thị hoặc lưu lịch sử, không được mô tả việc Monitoring đó như chính Safety Function.

Bối cảnh BOI cho đầu tư tự động hóa tại Thái Lan

Thông cáo BOI Thái Lan về nửa đầu năm 2026 ghi nhận 132 hồ sơ Smart and Sustainable Industry với tổng giá trị THB 17,158 tỷ. Đây là số liệu hoạt động nộp hồ sơ, không bảo đảm dự án cụ thể được duyệt hoặc đủ điều kiện.

Biện pháp hiện hành của BOI nêu mức đầu tư tối thiểu THB 1 triệu, không gồm đất và vốn lưu động. Biện pháp cũng mô tả miễn thuế thu nhập doanh nghiệp 3 năm với trần 50% khoản đầu tư đủ điều kiện, hoặc 100% khi ít nhất 30% giá trị máy móc, Automation hoặc Robot liên kết hay hỗ trợ ngành máy móc Automation trong nước. Phạm vi dự án, chi phí hợp lệ, thời điểm và mối liên kết trong nước phải được xác nhận với BOI hoặc chuyên gia. Không nên lập Business Case dựa trên giả định chắc chắn được duyệt.

State Specification, Version Manifest và FAT Record có thể hỗ trợ hồ sơ đầu tư có kỷ luật nhưng không tự động đáp ứng BOI. Hãy tách Technical Acceptance và Incentive Eligibility thành hai luồng công việc với kế hoạch bằng chứng riêng.

Checklist mua hàng và nghiệm thu

Trước khi yêu cầu báo giá

• Xác định ranh giới với Product, Host System và thiết bị liền kề.
• Đính kèm bản nháp Mode/State Model.
• Bao gồm Stop, Hold, Abort, Fault và Recovery, không chỉ Normal Cycle.
• Phân biệt Permissive, Process Interlock và Safety Function.
• Quy định HMI đa ngôn ngữ, Common Fault Code và Event Export.
• Yêu cầu quản lý PLC/HMI/Robot/Recipe Configuration.

Khi Design Review

• Mọi State có Entry, Active và Exit Behavior?
• Normal, Abnormal và Prohibited Transition rõ ràng?
• Mọi Timeout có Start Point và Failure Reaction?
• Reset đã tách khỏi Restart?
• Có Power Restart, Communication Failure và Work in Process?
• Tài liệu có ngăn Normal Control bị hiểu thành Functional Safety?

Trước FAT

• Tạo Fault-Injection Matrix từ State Table đã duyệt.
• Initial Condition, Stimulus và Expected Result quan sát được.
• Kiểm soát Test Force và quyền Bypass.
• Freeze mọi Software/Recipe Version cần thử.
• Xác định Correction, Retest và Conditional Acceptance.
• Thống nhất Evidence Format và Handover Package.

Khi SAT và bàn giao

• Xác minh Timing dưới tải thật và ghi mọi điều chỉnh.
• Thử Host/Adjacent Machine Failure và Recovery.
• Đào tạo từng Role về Recovery và Product Disposition.
• Xác nhận Final Backup đúng Site Version đã thử.
• Ghi Open Item, Temporary Control, Owner và Due Date.
• Có quy trình Review Production Fault Log.

Các lỗi thường gặp và cách sửa

Chỉ mua theo sơ đồ Normal Cycle

Nếu Flowchart chỉ có sản xuất bình thường, hành vi khi bất thường sẽ phụ thuộc vào tiêu chuẩn của nhà cung cấp hoặc phán đoán của từng kỹ sư. Hãy bổ sung Abnormal Transition và Recovery Condition vào State Table, rồi liên kết từng trường hợp với FAT Test ID.

Chấp nhận máy chỉ bằng Review Ladder Program

Code Review quan trọng nhưng không thay thế kết quả quan sát khi chèn Input hoặc Fault. Nghiệm thu phải dựa trên Test Evidence gồm State, HMI Message, Output Behavior, Event Record và Product-quality Flag.

Dùng một Reset cho mọi Fault

Xóa chung các Fault có nguyên nhân, rủi ro và quyền xử lý khác nhau khiến khó truy vết tái diễn và ảnh hưởng đến sản phẩm. Cần quy định Acknowledgement, Cause Removal, Machine Consistency và Restart Approval theo từng Fault Class.

Không đưa thay đổi tại hiện trường trong SAT về bản phát hành được kiểm soát

Nếu Backup bàn giao khác Site Version đang chạy, lần bảo trì sau có thể làm chương trình quay về bản cũ. Hãy ghi Version, Reason, Impact và Retest trong Change Record, sau đó thu lại Approved Final Configuration.

Câu hỏi thường gặp

Điều khiển tuần tự là gì?

Đó là điều khiển chuyển trạng thái và Output theo thứ tự cùng điều kiện đã định. Đặc tả có thể nghiệm thu cần Mode, State, Permissive, Stop, Timeout, Fault, Recovery và Evidence, không chỉ trình tự bình thường.

Nên yêu cầu Ladder Program hay SFC?

Chọn theo Controller, máy, tiêu chuẩn nhà cung cấp và năng lực bảo trì. LD dễ theo Contact; SFC dễ chia sẻ cấu trúc Step/State. Quan trọng hơn là Traceability giữa State Table và Code, Naming, Transition Rule và Testability.

PLC FAT cho State Transition phải kiểm tra gì?

Kiểm tra Normal/Abnormal Transition, Permissive, Timeout, Output Behavior, HMI Code, Product Status, Event Record và Recovery Authority. Cố định Starting Condition và Injection Method, sau đó viết tiêu chí bằng đại lượng quan sát được.

Fault Recovery Sequence nên bắt đầu từ đâu?

Tách Reset khỏi Restart, xác nhận Cause Removal, Machine Consistency, Work-in-process Disposition, Restart Point và Approval Authority. Power/Communication Restoration phải là kịch bản riêng.

PLC FAT có chứng minh Functional Safety của máy không?

Không. FAT có thể xác minh Normal-control Behavior đã quy định nhưng không thay Machinery Risk Assessment hoặc việc Design, Integration và Validation của Safety-related Control Function theo tiêu chuẩn áp dụng.

Ưu đãi BOI cho Automation có được bảo đảm không?

Không. Biện pháp hiện hành có điều kiện về dự án, khoản đầu tư và chi phí; lộ trình áp dụng phụ thuộc dữ kiện cụ thể. Cần xác nhận Eligibility, Calculation và Application Timing với BOI hoặc chuyên gia.

Kết luận

Ranh giới nghiệm thu điều khiển tuần tự phải gồm Mode, State, Transition Guard, Permissive, Timeout, Fault Code, Recovery Authority, Recipe/Software Version và Audit Evidence, không chỉ là Ladder chạy được Normal Cycle. Hãy dẫn xuất Fault-Injection Matrix từ State Table và dùng FAT/SAT để chứng minh State, Output, xử lý sản phẩm, Message, Log và Recovery. Tách Functional Safety khỏi Normal Control và giữ Evidence Chain từ Requirement qua Version, Test đến Approval để thiết bị tiếp tục bảo trì được sau khi sản xuất.

Nếu doanh nghiệp đang chuẩn bị máy mới hoặc cải tạo máy tại Thái Lan nhưng State Table hay Fault Case cho PLC FAT chưa hoàn chỉnh, vẫn có thể trao đổi từ giai đoạn xác định phạm vi. Hãy liên hệ TOMAS TECH để rà soát khoảng trống giữa tài liệu mua hàng, thiết kế của nhà cung cấp và quy trình Recovery thực tế.

Tài liệu tham khảo

• 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 (tài liệu nền năm 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