Thiết kế máy #52: State machine — Đừng để toàn bộ hành vi của máy nằm trong một biến StepNo

Trong nhiều chương trình PLC, sequence được điều khiển bằng một biến số:

StepNo = 0, 10, 20, 30...

Khi máy chạy bình thường, cách này có vẻ gọn. Nhưng sau vài năm:

step 120 được thêm để xử lý model mới;
step 125 là hotfix khi sensor chậm;
step 127 chỉ chạy sau recovery;
một coil bị ghi ở cả step 90 và fault routine;
khi mất điện, StepNo được retain nhưng cơ cấu đã trôi;
không ai dám xóa step 240 vì “hình như có dùng”.

Vấn đề không phải dùng số nguyên. Vấn đề là behavior contract đã biến mất trong code.

State machine tốt giúp tách mode, state, transition, action và invariant; nhờ đó người thiết kế có thể trả lời: máy đang ở đâu, vì sao được chuyển, output do ai sở hữu và làm thế nào phục hồi khi state logic không còn khớp state vật lý.

1. StepNo không sai — StepNo không có contract mới sai

Một integer có thể là implementation hợp lệ nếu:

mỗi giá trị có tên và semantics;
transition được kiểm soát;
invalid value có behavior;
output ownership rõ;
state được quan sát/ghi log;
requirement và test trace được.

Ngược lại, dùng framework state machine đẹp vẫn có thể sai nếu guard mơ hồ, transition ẩn trong nhiều task hoặc output bị ghi đè.

Mục tiêu không phải thay mọi CASE StepNo bằng thư viện phức tạp. Mục tiêu là làm behavior có thể hiểu, kiểm chứng và bảo trì.

2. Tách mode, state và step

Ba khái niệm thường bị trộn.

Mode

Mode xác định cách machine/unit được điều khiển và tập behavior được phép: production/automatic, manual, maintenance, setup hoặc mode được định nghĩa theo application.

Mode không chỉ là label trên HMI. Nó ảnh hưởng:

quyền command;
transition được phép;
speed/energy behavior;
active sequence;
diagnostic;
recovery;
safety-related function nếu architecture có liên quan.

State

State mô tả condition hành vi ổn định đủ để quyết định reaction với event. Ví dụ Idle, Starting, Execute, Holding, Held, Stopping, Stopped, Aborting, Aborted, Completing, Complete — nếu mô hình ứng dụng chọn dùng những state đó.

Step

Step thường là một bước chi tiết trong procedure: kẹp, nâng, chuyển, đặt. Nhiều step có thể nằm trong state Execute. Một step không nhất thiết là machine state cấp cao.

Nếu mọi step cơ khí, mode và fault đều nhét vào một enum, model nhanh chóng trở thành mê cung.

ISA-TR88.00.02-2022 và OMAC PackML cung cấp reference pattern cho machine/unit states và modes. Chúng hữu ích để chuẩn hóa vocabulary, nhưng không bắt buộc mọi máy phải dùng nguyên model hoặc cùng danh sách state.

3. Một state phải trả lời được sáu câu

Mỗi state nên có definition:

Purpose: state tồn tại để làm gì?
Entry condition: hệ thống biết đã vào state bằng gì?
Invariant: điều gì phải luôn đúng khi ở state?
Permitted events/commands: input nào có ý nghĩa?
Outputs/actions: state sở hữu output hoặc activity nào?
Exit/transition: điều kiện nào cho phép rời state?

Ví dụ giả định:

Held: process đã dừng có kiểm soát tại checkpoint được định nghĩa; product identity và ownership được giữ; motion command của production sequence không được phát; resume chỉ được chấp nhận khi hold cause clear, required conditions valid và operator/system authorization phù hợp.

Definition này tốt hơn State = 40 // held.

4. Invariant quan trọng hơn tên state

Tên Idle không chứng minh máy thực sự idle.

Invariant có thể gồm:

không có automatic motion command active;
không có transaction chưa sở hữu;
gripper/product state đã xác định;
recipe đã load nhưng chưa execute;
shared zone không bị hai unit cùng reserve;
actuator command và feedback không mâu thuẫn quá duration cho phép.

Invariant giúp:

phát hiện state corruption;
viết alarm/diagnostic;
xác định recovery;
xây test negative;
review concurrency;
quyết định state có thể retain không.

Ngoài invariant, hãy định nghĩa forbidden states:

clamp open trong khi axis moving qua vùng cần giữ;
product present nhưng ownership = none;
Automatic mode và Maintenance command cùng active;
Complete nhưng quality result chưa có;
Execute trong khi interface version incompatible.

Happy path chỉ chứng minh máy có thể chạy. Forbidden-state review giúp chứng minh nó không rơi vào combination không mong muốn.

5. Transition là một contract

Một transition không chỉ là:

IF SensorA THEN StepNo := 20;

Nó cần:

Source và target

Từ state nào sang state nào? Có transition global không?

Trigger

Event/command/time condition nào khởi phát?

Guard

Điều kiện nào phải đúng tại thời điểm transition?

Action

Điều gì thực hiện khi chuyển? Update ownership, capture data, clear timer, phát command?

Priority

Nếu nhiều transition cùng true, transition nào thắng và tại sao?

Invalid-event behavior

Nếu event đến ở state không phù hợp: ignore, reject, log, alarm hay escalate?

Ví dụ:

From Ready to Executing on StartRequest, guarded by valid recipe, interface accepted, no active blocking fault và resource reserved; action tạo transaction context và capture baseline; nếu request lặp cùng ID thì trả current state, không tạo execution mới.

Transition contract này nối trực tiếp với interface control của bài #51.

6. Priority ẩn là nguồn lỗi khó thấy

Trong PLC scan, thứ tự code có thể trở thành priority không được công bố:

IF Start THEN State := Execute;
IF Stop THEN State := Stopping;
IF Fault THEN State := Aborting;

Nếu Start, Stop và Fault cùng true, giá trị cuối phụ thuộc order. Người đọc có thể nghĩ Fault có priority cao nhất, nhưng một routine khác có thể ghi lại state sau đó.

Hãy:

định nghĩa priority ở model;
chỉ cho một nơi commit transition;
log event bị supersede;
test simultaneous event;
tránh nhiều task/routine cùng ghi state.

Priority thường theo machine context, không có bảng universal. Safety reaction không nên dựa vào operational-state priority nếu nó thuộc safety-related control path.

7. Entry, do và exit action phải rõ

Một action có thể:

chạy một lần khi entry;
chạy cyclic trong state;
chạy một lần khi exit;
thuộc transition cụ thể.

Nếu không tách, một lệnh “khởi tạo” có thể được gửi mỗi scan, hoặc output bị clear sớm.

Entry action

reset timer;
capture transaction;
initialize local variables;
phát command edge nếu contract yêu cầu.

Do activity

maintain output;
monitor guard/invariant;
update progress;
check timeout.

Exit action

release resource;
archive result;
clear state-owned command.

Output ownership nên rõ:

Output	Owner state/component	Default	Override path
Transfer command	Transfer sequence	OFF	Abort handler
Clamp command	Fixture controller	defined by local state	Safe reaction route
HMI state	State manager	current state	none

Nhiều routine ghi cùng coil là dấu hiệu ownership bị phá vỡ.

8. State hierarchy giúp giảm explosion

Nếu mọi combination thành một state phẳng:

AutoExecuting;
AutoHolding;
ManualIdle;
ManualFaulted;
MaintenanceFaulted;
SetupWaiting…

Số state tăng nhanh.

Hierarchical state machine cho phép state con thừa hưởng behavior:

Operational
Idle
Starting
Execute
Holding
Stopped
StoppedNormal
Aborted
Faulted
Recoverable
RequiresIntervention

Nhưng hierarchy cũng cần semantics:

event được xử lý ở state con hay cha?
entry/exit order?
invariant của cha có luôn áp dụng?
history state có dùng không?
resume trở lại state con nào?

Đừng dùng hierarchy chỉ để vẽ đẹp. Nó phải làm ownership và transition rõ hơn.

9. Concurrency: hai sequence chạy song song cần coordination

Máy có thể đồng thời:

xử lý product;
prepare next material;
communicate với upstream;
log data;
monitor utility.

Orthogonal/concurrent regions hữu ích, nhưng tạo race:

hai region cùng yêu cầu một actuator;
region A complete trước nhưng region B fault;
stop command đến khi một region đang transition;
one region restart, region khác retain;
result aggregation không rõ.

Thiết kế cần:

resource ownership;
synchronization point;
join/merge semantics;
fault propagation;
overall state calculation;
cancellation token/transaction context;
timeout per region và overall.

Nếu concurrency không cần thiết, sequence tuần tự dễ kiểm chứng hơn. Đừng tạo parallel branch chỉ vì PLC có thể chạy.

10. Mode change là transition có điều kiện

Không nên:

Mode := HMI_ModeSelection;

Mode request khác mode active.

Một mode-change lifecycle:

request;
authorization;
current-state compatibility;
controlled stop/transition nếu cần;
resource/command cleanup;
entry condition cho mode mới;
active acknowledgement.

Các câu hỏi:

đổi Auto → Manual khi axis đang chạy thì sao?
Maintenance mode có yêu cầu key/role/procedure?
request remote và local đồng thời?
mode giữ sau power cycle hay default?
interface peer có được thông báo?
product đang dở xử lý ra sao?

Mode management có thể liên quan safety function. Khi đó applicable safety architecture và validation quyết định, không phải enum trong standard PLC.

11. Fault, stop, hold, abort và complete khác nhau

Stop

Đưa hoạt động về state dừng theo process bình thường.

Hold

Tạm dừng có khả năng resume từ checkpoint được thiết kế.

Abort

Thoát bất thường; có thể mất khả năng resume và cần recovery.

Fault

Condition ngăn function hoặc vi phạm expectation, có diagnostic/reaction.

Complete

Procedure đạt outcome dự kiến và result/context sẵn sàng đóng.

Nếu tất cả đi về StepNo = 0, máy mất:

product ownership;
checkpoint;
nguyên nhân;
action đã thực hiện;
khả năng resume;
evidence.

Reset không nên là “xóa mọi trạng thái”. Reset acknowledge/clear condition nào, prerequisites gì và target state nào phải được định nghĩa.

12. Startup/restart: state logic phải reconcile với state vật lý

Sau mất nguồn:

biến state có thể retain;
actuator khí có thể đổi vị trí;
servo mất absolute context;
phôi vẫn nằm trong gripper;
peer PLC đã restart khác thời điểm;
transaction chưa complete.

Ba pattern nguy hiểm:

luôn về Idle;
luôn resume retained step;
auto-home mọi cơ cấu.

Không pattern nào đúng universal.

Startup nên:

xác định boot reason;
kiểm tra configuration/version;
thu thập physical feedback;
xác định product/resource/interface state;
so với retained logical context;
phân loại consistent, recoverable ambiguity hoặc unknown;
chọn initialization/recovery path được thiết kế;
yêu cầu authorization phù hợp trước motion/resume.

Unexpected-start risk phải đi theo risk assessment và applicable machinery-safety requirements. Bài viết không cung cấp generic auto-resume logic.

13. State observability là một requirement

Nếu state chỉ tồn tại trong biến nội bộ không log, troubleshooting dựa vào đoán.

Nên expose phù hợp:

active mode/state/substate;
last transition;
transition timestamp/cycle;
trigger và guard chưa đạt;
active transaction/product;
elapsed/timeout margin;
fault/hold reason;
recovery prerequisite;
state model/interface version.

Đừng hiển thị hàng trăm bit raw cho operator. HMI cần câu trả lời theo task:

máy đang làm gì?
chờ điều kiện nào?
ai sở hữu action tiếp theo?
điều gì ngăn transition?
recovery nào được phép?

Event record nên phân biệt command, transition request, transition accepted/rejected và state entered.

14. IEC 61131-3:2025 giúp implementation, không thay architecture

IEC 61131-3:2025 Edition 4 định nghĩa syntax/semantics của Structured Text, Ladder Diagram, Function Block Diagram và các element Sequential Function Chart (SFC).

SFC có thể biểu diễn step, transition và action rõ hơn code integer. ST/FB có thể triển khai hierarchical state manager tốt. Nhưng language choice không tự giải quyết:

requirement thiếu;
transition ambiguity;
output ownership;
race/concurrency;
unsafe recovery;
incomplete test.

Một programme “IEC 61131-3 compliant” nói về language, không chứng minh machine behavior đúng hoặc đạt safety integrity.

15. IEC 61512/ISA-88 và PackML dùng thế nào?

IEC 61512-1:2026 tập trung batch và related procedure-oriented manufacturing, với separation giữa recipe procedural elements và equipment procedural elements. Một số nguyên tắc procedural/equipment separation và state reference hữu ích, nhưng phải giữ đúng scope.

ISA-TR88.00.02-2022 cung cấp implementation example cho automated machine states/modes. OMAC PackML thúc đẩy behavior/data nhất quán.

Chúng giúp:

vocabulary chung;
giảm custom state model;
HMI/data thống nhất;
integration dễ hơn.

Nhưng model chuẩn phải được tailoring:

function máy;
lifecycle/mode;
safety/control architecture;
product flow;
interface;
recovery.

Không thêm state chỉ để “đủ chuẩn” nếu không có semantics và test.

16. Ví dụ giả định: pick–transfer–place

Behavior hierarchy

Stopped
Idle
Executing
Acquire
Transfer
Place
Verify
Holding
Held
Completing
Complete
Aborting
Aborted

Invariant

Một product chỉ có một owner.
Motion qua transfer zone chỉ khi zone reservation valid.
Gripper release chỉ trong Place và position/receiver condition đạt.
Complete chỉ sau presence/quality result được xác nhận.

Transition ví dụ

Transfer → Place

Trigger: target position reached.
Guard: receiver accepted transaction, identity matches, place zone reserved.
Action: transfer ownership checkpoint; initialize place timeout.
Invalid: nếu receiver revoke trước checkpoint, transition sang Holding/Aborting theo defined policy.

Fault case

Mất feedback product trong Transfer.

Không nhảy về Idle. State manager:

giữ transaction context;
stop/reaction theo thiết kế;
record last confirmed checkpoint;
xác định physical ambiguity;
chuyển Aborting/Recovery-required;
chỉ cho recovery procedure phù hợp.

Restart case

Retained state = Transfer nhưng axis feedback ở vị trí khác và product presence unknown. Reconciliation kết luận ambiguous; machine không auto-resume, chuyển controlled recovery.

17. Verification matrix

Requirement	Model element	Implementation	Test
Không release trước place condition	Invariant + guard	Place transition	Negative boundary test
Stop request được xử lý từ Execute	Global transition	State manager	Stop tại mọi substate
Duplicate start không tạo cycle mới	Invalid-event rule	Command handler	Repeated command
Restart không auto-resume khi ambiguous	Reconciliation	Startup manager	Power-cycle state matrix

Test nên gồm:

every state/transition;
guard true/false boundary;
simultaneous events/priority;
invalid command;
timeout;
sensor disagreement;
mode change;
hold/stop/abort;
restart ở mỗi critical phase;
interface loss/reconnect;
retained/non-retained data;
output ownership;
forbidden-state monitoring.

Transition coverage 100% chưa đủ nếu guard combination và physical boundary không được test.

18. Checklist review

Mode/state/step có tách không?
State có purpose, entry, invariant, event, output và exit không?
Forbidden states đã định nghĩa chưa?
Transition có source/target/trigger/guard/action/priority không?
Invalid event có behavior không?
Entry/do/exit action có rõ không?
Mỗi output có owner duy nhất không?
Hierarchy có semantics event/entry/exit/history không?
Concurrent region có resource ownership và synchronization không?
Mode request có lifecycle, không ghi thẳng active mode không?
Stop/hold/abort/fault/complete có phân biệt không?
Reset/recovery có target và prerequisites không?
Restart có physical reconciliation không?
State/transition/guard có đủ observability không?
Language/framework có bị dùng thay architecture/safety assessment không?
Requirement → model → code → test có trace không?

Kết luận

State machine không chỉ là kỹ thuật tổ chức code. Nó là bản mô tả hành vi của máy: state nào tồn tại, invariant nào phải giữ, event nào được chấp nhận và hệ thống phải làm gì khi logic không còn khớp vật lý.

Khi mode, state, transition và output ownership có contract, sequence dễ review, test và phục hồi hơn. Khi mọi thứ chỉ nằm trong StepNo, machine có thể chạy hôm nay nhưng chi phí hiểu và thay đổi sẽ tăng ở mỗi lần bảo trì sau đó.

Nguồn tham khảo

IEC 61131-3:2025 — Programmable-controller languages: https://webstore.iec.ch/en/publication/68533
ISA-TR88.00.02-2022 — Machine and Unit States: https://www.isa.org/products/isa-tr88-00-02-2022-machine-and-unit-states-an-imp
OMAC PackML: https://www.omac.org/packml
IEC 61512-1:2026 — Batch-control models and terminology: https://webstore.iec.ch/en/publication/75287
ISO/IEC/IEEE 15288:2023 — System life cycle processes: https://www.iso.org/standard/81702.html

Xem tất cả bài viết kỹ thuật MINATA