Thiết kế máy #51: Interface control — Handshake giữa các station không nên là vài bit rời rạc

Station A chuyển phôi cho station B bằng ba tín hiệu:

Ready
Busy
Done

Trên bản vẽ, mọi thứ có vẻ đủ. Nhưng khi chạy thật:

A thấy B Ready nên bắt đầu transfer;
B mất Ready trong một scan vì đổi mode;
A giữ request vì chưa thấy Done;
B không nhận request mới vì vẫn giữ trạng thái Busy;
cả hai cùng chờ bên kia đổi bit.

Không có component nào hỏng. Không có alarm nào giải thích rõ. Hai state machine hợp lệ riêng lẻ nhưng khi ghép lại tạo deadlock.

Vấn đề không nằm ở thiếu thêm một bit. Vấn đề là interface chưa có contract: ai sở hữu dữ liệu, mỗi trạng thái nghĩa là gì, một transaction bắt đầu/kết thúc khi nào, timeout xử lý ra sao và hai bên hòa giải thế nào sau restart.

1. I/O list chỉ mô tả dây, không mô tả behavior

Một interface list thường có:

Signal	Direction	Type	Comment
Ready	B → A	BOOL	B sẵn sàng
Start	A → B	BOOL	Bắt đầu
Done	B → A	BOOL	Hoàn tất

Nhưng “sẵn sàng” có thể nghĩa:

B ở Auto;
B không fault;
vùng nhận trống;
downstream còn chỗ;
đúng recipe;
safety condition phù hợp;
tất cả điều trên tại thời điểm hiện tại;
hoặc B cam kết giữ điều kiện đó trong toàn transaction.

Nếu hai đội hiểu khác nhau, cùng một bảng I/O tạo hai implementation khác nhau.

Interface contract phải mô tả:

boundary;
semantics;
ownership;
state validity;
transaction lifecycle;
timing;
fault/cancel/restart behavior;
version compatibility;
verification evidence.

I/O, fieldbus tag hay API message chỉ là phương tiện truyền contract đó.

2. Xác định boundary trước signal

Boundary có thể nằm:

giữa hai station;
giữa machine và line controller;
giữa PLC và robot;
giữa control và MES;
giữa OEM module và integrator;
giữa standard control và safety-related control;
giữa hai trust zone mạng.

Boundary tốt trả lời:

Chức năng nào nằm phía A, chức năng nào nằm phía B?
Ai quyết định transaction được phép bắt đầu?
Ai chịu trách nhiệm giữ phôi, chất lượng và identity trong transfer?
Khi interface mất, mỗi bên phải giữ hay dừng ở state nào?
Ai phát hiện và thông báo mismatch?
Ai có quyền cancel, abort, reset hoặc reconcile?

Nếu responsibility nằm “ở giữa”, khi lỗi xảy ra hai bên đều có thể nói mình đã làm đúng.

IEC 62264 cung cấp terminology và model cho các domain/interface trong manufacturing operations và enterprise-control integration. Nó giúp đặt đúng tầng và nội dung trao đổi, nhưng không tự động định nghĩa handshake chi tiết giữa hai cơ cấu ở Level 1/2. Phần đó vẫn cần system-specific contract.

3. Mỗi data item cần sáu thuộc tính tối thiểu

Đừng chỉ ghi name/type. Hãy ghi:

Producer

Ai tạo giá trị? Một data item chỉ nên có một source of truth tại một thời điểm.

Consumer

Ai dùng và dùng để quyết định gì? Một signal “để hiển thị” khác signal điều khiển transition.

Semantics

True/false/value nghĩa chính xác là gì, trong mode/state nào?

Update rule

Level, pulse, edge, cyclic data, event message hay request/response? Khi nào producer được thay đổi hoặc clear?

Validity/quality

Giá trị còn hợp lệ bao lâu? Có quality/status/timestamp không? Mất communication thì consumer xử lý last value, unknown hay safe operational fallback nào?

Ownership of recovery

Ai được clear, retry, override hoặc reinitialize? Điều kiện gì?

Ví dụ:

ReceiverAvailable = TRUE nghĩa receiver ở production mode, không có active fault ngăn transfer, vị trí nhận đã được xác nhận trống và receiver chấp nhận một transfer mới. Producer là receiver. Tín hiệu có giá trị khi communication healthy và interface version compatible. TRUE không tự động là safety permission.

Câu này vẫn cần refinement theo machine, nhưng tốt hơn nhiều so với “B ready”.

4. Tách permission khỏi commitment

Một lỗi phổ biến là dùng Ready cho cả hai ý:

B hiện có điều kiện nhận;
B đã nhận và cam kết xử lý request cụ thể.

Hai ý này khác nhau.

Một transaction thường cần các phase:

Available/permission: bên nhận có thể xem xét request.
Request: bên gửi đề nghị transaction với identity/context.
Accepted/acknowledged: bên nhận chấp nhận request cụ thể.
Executing: transfer đang diễn ra.
Physical confirmation: vật/operation đạt checkpoint.
Complete/result: outcome đã xác định.
Consumed/released: hai bên đồng ý transaction có thể đóng và resource được giải phóng.

Không phải giao diện nào cũng cần bảy tín hiệu. Có thể encode bằng state, message hoặc ít bit hơn. Nhưng behavior của các phase phải tồn tại rõ trong contract.

Nếu A bắt đầu chỉ vì B “available” nhưng B chưa commit, một thay đổi mode tức thời có thể làm transaction không còn owner.

5. Command, state và result không nên dùng chung một bit

Start là command hay state? Done là pulse, latched result hay current condition?

Một pattern rõ hơn:

Command/request: điều được yêu cầu.
Acknowledgement: request hợp lệ đã được nhận.
Execution state: đang làm gì.
Result: success, rejected, cancelled, aborted hoặc failed.
Reason/context: tại sao kết quả đó xảy ra.

Command không nên tự trở thành evidence rằng action đã xảy ra. TransferRequest = TRUE không có nghĩa phôi đã chuyển. Done = TRUE cũng chưa chắc bên kia đã consumed result.

Khi result cần tồn tại đến lúc consumer xác nhận, dùng latch/state hoặc transaction record thay pulse ngắn dễ bỏ lỡ.

6. State machine phải review khi composition

Hai state machine có thể được test riêng và đều đạt, nhưng combination vẫn deadlock.

Ví dụ:

A chỉ clear request sau khi thấy B complete.
B chỉ set complete sau khi A clear request.

Mỗi rule nghe hợp lý độc lập, nhưng tạo vòng chờ.

Review composition cần xem:

mọi state có đường tiến hoặc đường thoát không?
có state nào cả hai cùng chờ input do bên kia chỉ phát sau transition không?
request/ack có thể xảy ra đồng thời không?
mất một transition có thể được phát hiện không?
có livelock do retry/reset liên tục không?
priority khi hai request cạnh tranh?
invariant vật lý nào phải luôn đúng?

Một số invariant ví dụ:

cùng một carrier không được cả A và B cùng coi là “free”.
chỉ một bên sở hữu motion trong shared zone tại một thời điểm.
product identity không được đổi giữa accept và complete.
complete không được phát trước physical confirmation.

Sequence diagram và state-transition table thường lộ deadlock tốt hơn prose.

7. Transaction identity: cùng event hay event mới?

Nếu một request được gửi lại sau communication retry, bên nhận phải biết:

đây là duplicate của transaction cũ;
retry của transaction chưa rõ kết quả;
hay request mới.

Sequence number hoặc correlation ID giúp liên kết command, ack, result và event record. Nhưng ID không tự giải quyết duplicate.

Consumer cần behavior idempotent hoặc reconciliation rule:

nếu cùng ID đã complete, trả result cũ thay vì thực hiện lại;
nếu cùng ID đang executing, báo current state;
nếu ID cũ nhưng context khác, reject;
nếu ID mới trong khi resource bận, queue hoặc reject theo contract.

Với interface bit-level, có thể dùng toggle/counter/state pair thay message ID. Chọn pattern nào cũng cần giải quyết “exactly once” mong muốn trong khi network/control thực tế thường chỉ đảm bảo at-most-once hoặc at-least-once ở từng lớp.

8. Timing contract: timeout là một engineering requirement

Timeout không nên là một số chọn vì “1 giây chắc đủ”.

Cần hiểu:

PLC scan/update;
network cycle và jitter;
processing latency;
mechanical action;
sensor response;
buffering;
worst-case mode transition;
retry;
clock uncertainty;
diagnostic objective.

Phân biệt:

response timeout: chờ acknowledge;
execution timeout: chờ physical/process complete;
stale timeout: data quá cũ để dùng;
heartbeat/communication timeout: peer không còn được coi online;
business/process deadline: transaction không còn giá trị.

Timeout phải dẫn đến state xác định: retry, hold, reject, cancel, abort, fault hoặc operator decision. “Timeout → reset tất cả” có thể tạo mất identity hoặc motion bất ngờ.

Timeout operational không tự động là safety function. Nếu timing tham gia risk reduction, nó phải được đưa vào safety-function specification, architecture và validation tương ứng.

9. Stale data nguy hiểm hơn data mất rõ ràng

Khi communication mất, consumer có thể vẫn giữ giá trị cuối:

ReceiverAvailable = TRUE

Nếu không có freshness/quality, A có thể dùng TRUE đã cũ.

Cách xử lý tùy protocol/architecture:

communication quality bit;
watchdog/heartbeat;
timestamp;
sequence counter;
producer state/version;
explicit invalid/unknown;
fail-operational hoặc fail-stop policy.

Không phải luôn clear mọi bit về FALSE. Một số state cần preserve để reconcile. Quan trọng là consumer không nhầm “last known” với “current confirmed”.

Timestamp giữa hai controller cũng cần clock context. Với local deterministic bus, sequence/cycle counter có thể đáng tin hơn wall clock. Với hệ thống phân tán, clock synchronization và uncertainty phải được xem xét.

10. Restart và reconnect cần reconciliation

Sau restart, các khả năng:

A nghĩ transaction đang executing, B nghĩ chưa bắt đầu.
B đã nhận phôi nhưng A mất record.
physical transfer hoàn tất nhưng complete chưa truyền.
request được latched trong output image cũ.
sequence counter reset về zero và trùng ID.

Một startup policy kiểu “clear tất cả bit” có thể xóa evidence nhưng không di chuyển phôi trở lại.

Reconciliation nên dùng:

physical state;
product/carrier identity;
retained transaction state;
peer state/version;
last committed checkpoint;
operator confirmation theo procedure nếu ambiguity không tự giải được.

Các outcome:

resume transaction;
complete/close transaction;
rollback nếu thiết kế cho phép;
quarantine item;
controlled abort và recovery;
escalate manual decision.

Không auto-resume chỉ vì hai PLC online lại. Unexpected restart/recovery risk phải được đánh giá theo machine context.

11. Cancel, abort, reject và fault khác nhau

Reject: request chưa được chấp nhận.
Cancel: dừng request/transaction theo đường bình thường khi điều kiện cho phép.
Abort: thoát bất thường, ưu tiên đưa system về trạng thái kiểm soát.
Fault: condition ngăn behavior yêu cầu hoặc cần diagnostic/recovery.

Contract cần nói:

ai được yêu cầu;
phase nào còn cho phép;
bên kia acknowledge ra sao;
physical item hiện thuộc ai;
resource nào phải release;
result/reason được lưu thế nào;
reset/recovery prerequisite.

Nếu dùng một bit Reset cho mọi tình huống, action có thể xóa alarm nhưng không giải quyết ownership của phôi hoặc transaction.

12. Versioning là một phần của interface

Interface thay đổi theo thời gian:

thêm state;
đổi semantics;
mở rộng enum;
đổi unit/range;
thêm field bắt buộc;
sửa timing;
thay fault behavior.

IEC 62264-2:2026 bổ sung/cập nhật nhiều object model và nêu rõ edition mới không thể đảm bảo backward compatibility với implementation theo edition cũ. Đây là lời nhắc quan trọng: cùng tên standard không đồng nghĩa mọi version interoperable.

Interface contract cần:

interface ID/version;
compatibility matrix;
mandatory/optional field;
unknown enum behavior;
feature negotiation nếu cần;
deprecation/migration plan;
test cho mixed version;
rollback.

Consumer không nên crash hoặc mặc định unsafe behavior khi nhận field/enum mới. Producer không nên giả consumer hiểu semantics mới chỉ vì packet vẫn parse được.

13. PackML là reference pattern, không phải phép màu

ISA-TR88.00.02-2022 mô tả application example của ISA-88 cho machine/unit states. OMAC PackML hướng tới consistent machine behavior và data giữa nhiều nhà cung cấp.

Các pattern này hữu ích cho:

state/mode vocabulary;
transition behavior;
tag convention;
consistent HMI/data;
integration expectation.

Nhưng:

không phải mọi machine đều phải dùng toàn bộ PackML;
đặt tên state giống nhau không đảm bảo custom interface đúng;
PackML state không thay product-transfer contract chi tiết;
operational standardization không thay safety assessment.

Hãy dùng standard/reference model để giảm tùy biến vô ích, rồi vẫn viết system-specific interface contract cho boundary thật.

14. Safety và security boundary

Một bit InterlockOK trong standard PLC không tự thành safety function.

Nếu interface tham gia risk reduction, phải xác định:

safety function;
required behavior;
safe state;
performance/integrity requirement;
architecture/communication;
fault response;
validation.

Standard operational handshake có thể nhận safety status để điều phối, nhưng không được tự tuyên bố đạt safety chỉ vì nó chặn sequence.

Khi interface đi qua Ethernet, gateway, remote service hoặc trust boundary, security review cần xem:

authentication/authorization;
integrity/replay;
availability/DoS;
segmentation;
logging/time;
version/update;
default credential;
recovery.

Operational retry logic không được vô tình khuếch đại lỗi mạng thành command lặp.

15. Ví dụ giả định: transfer carrier A → B

Contract rút gọn

B là source of truth cho khả năng nhận.
A tạo TransferRequest kèm transaction ID và carrier ID.
B chỉ Accept khi identity/context hợp lệ và slot được reserve.
Sau Accept, B cam kết giữ slot trừ khi abort condition được định nghĩa.
A thực hiện transfer và phát physical checkpoint.
B xác nhận carrier present/identity.
B phát result complete.
A acknowledge result; hai bên release transaction.

Failure case

Communication mất sau carrier đã vào B nhưng trước complete.

Không được:

A tự retry physical transfer;
B clear carrier record;
cả hai reset ownership.

Sau reconnect:

trao đổi version và current transaction state;
kiểm tra carrier identity/physical state;
nếu B xác nhận nhận đúng carrier, complete transaction với cùng ID;
nếu ambiguous, hold và chuyển controlled recovery;
record interruption/reconciliation result.

Acceptance evidence

normal transfer;
duplicate request;
delayed ack;
communication loss tại từng phase;
restart A;
restart B;
mismatched carrier ID;
B fault trước/sau accept;
cancel/abort;
version mismatch;
stale availability;
simultaneous competing request nếu architecture cho phép.

Không cần test nguy hiểm trên machine nếu có thể chứng minh bằng simulation/bench. Test method phải phù hợp risk boundary.

16. Interface Control Document nên có gì?

Một ICD/interface register tối thiểu:

scope/boundary;
producer/consumer/owner;
data dictionary và semantics;
units/range/enum;
update/validity/quality;
state/mode applicability;
transaction lifecycle;
state/sequence diagrams;
timing/timeout/retry;
error/reject/cancel/abort;
startup/restart/reconciliation;
version/compatibility;
safety/security classification;
logging/diagnostic;
test vectors và acceptance;
change owner/approval.

Document không cần dài nếu interface đơn giản. Nhưng những quyết định quan trọng không được chỉ nằm trong code của hai PLC.

17. Checklist review

Boundary và responsibility có rõ không?
Mỗi item có một producer/source of truth không?
Semantics có cụ thể hơn tên signal không?
Permission có tách commitment/acceptance không?
Command, execution state và result có tách không?
Transaction có identity/checkpoint/closure không?
Duplicate/lost/delayed/out-of-order có behavior không?
State composition đã kiểm tra deadlock/livelock chưa?
Timing/timeout có budget và action rõ không?
Data validity/freshness/quality có định nghĩa không?
Restart/reconnect có reconciliation theo physical state không?
Reject/cancel/abort/fault có phân biệt không?
Version compatibility và unknown field/enum behavior có rõ không?
Safety-related interface có route riêng không?
Network/trust boundary có security review không?
ICD, diagrams và failure test vectors đã bàn giao chưa?

Kết luận

Handshake tốt không được đo bằng số bit ít hay nhiều. Nó được đo bằng việc hai bên có cùng hiểu một transaction, giữ được ownership, phát hiện ambiguity và phục hồi có kiểm soát sau fault/restart hay không.

Khi interface được thiết kế như một contract với semantics, state, timing, version và test evidence, việc tích hợp không còn phụ thuộc vào “hai programmer tự hiểu nhau”. Đó là nền tảng để nhiều station, nhiều OEM và nhiều thế hệ control cùng vận hành ổn định.

Nguồn tham khảo

IEC 62264-1:2013 — Models and terminology: https://webstore.iec.ch/en/publication/6675
IEC 62264-2:2026 — Object models and relationships: https://webstore.iec.ch/en/publication/75127
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

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