機械設計 #51：Interface control — Station間HandshakeをばらばらのBitにしない

I/O listは、Station AにReady、Station BにStartがあることを示せます。しかしReadyが何を意味し、どのPartに属し、誰がClearし、いつまで有効で、Restart後に何が起き、故障を誰が復旧するかは書きません。

InterfaceはSystem間のContractです。

意味 → 所有 → 更新ルール → Validity → Timing → Recovery → Evidence

1. I/O listはWireでありBehaviorではない

AddressとNameは必要ですがSequenceを定義しません。一方のReady=1が「PowerとSafetyが正常」、もう一方が「CarrierとRecipeが準備済み」を意味すると、配線が正しくても統合は失敗します。

2. Signalの前にBoundaryを定義する

Material、Energy、Data、Permission、Command、Resultの所有が変わる場所を決めます。Carrierを誰が持ち、Process resultを誰が持ち、Recoveryを誰が要求できるかを明記します。BoundaryにOwnerがなければ、両Controllerが相手を待ちます。

3. Data itemの最低六属性

Producerは誰がどの条件で値を作るか、Consumerは値がない・無効な時にどう動くか、SemanticsはUnit、Polarity、State、Transactionを含む意味、Update ruleはSet、Change、Hold、Ack、Clear、Validity/QualityはStale、Unknown、Simulated、Failedの表示、Recovery ownerはDiagnose、Reset、Retry、Cancel、Reconcileの担当です。

4. PermissionとCommitmentを分ける

Permissionは実行可能、Commitmentは特定Transactionを受け入れ責任を持った状態です。「BがReady」は「Carrier 123を受け入れた」ではありません。別DataまたはTransaction recordで、前のPartが未完了のまま次を開始しないようにします。

5. Command、State、Resultを一つのBitにしない

Commandは要求、Stateは現在の事実、Resultは結果です。一つのPulseやLatchへ混ぜると、Scan miss、Reconnect、Restartで意味が消えます。OwnerとLifecycleを分けます。

6. CompositionでState machineをレビューする

Station Aが正しくてもBとのStateが合わないことがあります。Waiting、Ready、Requested、Accepted、Executing、Complete、Rejected、Cancelled、Fault、Recoveringを合同でレビューし、無効な組合せを定義します。

7. Transaction identity

Carrier、Part、Recipe、Transaction IDを使い、繰返しSignalを新しいEventと誤解しないようにします。IDの作成、Transfer、Ack、Complete、Reject、Expire、Archiveを決め、TimingだけでIdentityを推測しません。

8. Timing contractとTimeout

Response、Execution、Heartbeat、Timeout、Retry、Escalationを定義します。Worst cycle、Network latency、Operator hold、Utility recovery、Downstream blockageを含めます。Timeoutは意味あるStateとRecovery instructionを作るRequirementです。

9. Stale dataは明らかなLossより危険

消えたSignalは見えますが、前のCarrierのHighが残ると誤動作を許可します。Sequence number、Timestamp、Validity、Quality、Clear/Ackを使い、遅延、重複、順序逆転、部分更新を試験します。

10. RestartとReconnectをReconcileする

Power lossやCommunication reconnect後に、Transactionが未開始、Accepted、Executing、Complete、Rejected、Unknownのどれかを各Stationが判断します。Physical presence、Recipe、Actuator、Safe recoveryと照合し、偶然HighのBitからResumeしません。

11. Cancel、Abort、Reject、Faultを分ける

CancelはCommit前の意図的停止、AbortはAccepted後の中断、RejectはProcess result、Faultは異常とDiagnosis/Recoveryが必要な状態です。意味を分け、Retry、Discard、Inspect、Escalateを正しく選びます。

12. VersioningはInterfaceの一部

Contract revision、Producer/Consumer software、Schema、Feature、Compatibilityを記録します。Field、Polarity、Unit、Timeout、State nameの変更はBreaking changeかもしれません。NegotiationまたはControlled rolloutを使います。

13. PackMLはReference patternであり魔法ではない

PackML/ISA-88はModeとStateの共通語になりますが、Ownership、Transaction、Product data、Safety、Timeout、Recoveryを自動定義しません。実際のBoundaryへ適用し、Compositionを検証します。

14. SafetyとSecurity Boundary

Safety-related、通常Control、認証が必要なCommunicationを分けます。通常Ready BitをSafety proofにしません。Remote command、Change log、Communication loss時のSafe behaviorを管理します。

15. Carrier AからBへの例

AはBがCarrier IDをAckするまでCarrierを所有します。BはSafe receiving、Recipe、Capacityが有効な時だけRequestします。Bは同じIDでAccepted、Executing、Complete、Reject、Faultを返します。ReconnectがAckとResultの間に起きても、両方がIDとPhysical presenceをReconcileし、二つ目を始めません。Normal、Wrong recipe、Duplicate、Stale Ready、Timeout、Power loss、Reconnect、Reject、Abort、Sensor mismatch、RecoveryをTestし、Log、Trace、Operator instructionを保存します。

16. Interface Control Documentの内容

Boundary、Purpose、Scope、用語、Data dictionary、Producer/Consumer、Owner、State/Sequence、Transaction ID、Timing、Timeout、Error、Retry、Cancel、Reject、Fault、Restart、Version、Safety、Security、Test、Evidence、Change process、担当者を含めます。

17. Interface review checklist

[ ] BoundaryとOwnerが明確である。
[ ] 各Itemに意味、Producer、Consumer、Update、Validity、Recovery ownerがある。
[ ] Permission、Command、State、Result、Commitmentを分けた。
[ ] 遅延、Retry、RestartでもTransaction identityが残る。
[ ] TimingとTimeoutが測定可能なRequirementである。
[ ] Stale、Duplicate、Invalid、Out-of-orderを扱う。
[ ] Cancel、Abort、Reject、Fault、Recoveryの意味を分けた。
[ ] VersionとCompatibilityを管理する。
[ ] SafetyとSecurity Boundaryを明記した。
[ ] Normal、Abnormal、Reconnect、RecoveryをAcceptanceした。

まとめ

Station統合はBitの集合ではなく、意味、所有、Transaction、Timing、Validity、Failure、RecoveryのContractです。Coding前に設計し、Compositionで試験し、深夜でも別のTeamが使えるEvidenceを引き渡します。

18. InterfaceのObservability

Transaction ID、State、Transition、Producer、Consumer、Timestamp、Timeout reason、Retry、Recovery actionを記録します。どのStationがCarrierを所有し、どの条件が遷移を止め、Dataが有効だったかをTraceから説明できるようにします。最後のFaultだけを保存せず、その前のSequenceを残します。

19. Interface changeをRehearsalする

Production接続前にSimulator、Spare controller、Controlled dry runで、Normal、Delayed、Duplicate、Missing、Stale、Out-of-orderを試します。Operator instruction、Alarm、Reset permission、Rollbackも確認します。一回のTransfer成功だけではReconnectとRecoveryを証明できません。

20. HandoverとChange control

Interface Control Document、Data dictionary、State diagram、Test trace、Version matrix、Known deviation、Owner contactを保護します。一つのStationを変える時はContractとCompatibilityを分析し、Compositionを試験し、どのAssetへどのRevisionを展開したかを記録します。

Interfaceのレビューでは、信号名だけでなく、失敗時に人が何を見て、どの状態を安全と判断し、誰が次の操作を承認するかを確認します。Dataの意味、版、保管、Audit、Backupも含め、Supplierや別Teamが同じ契約を使える資料にします。

契約の変更、承認、試験、展開、保存を同じRevisionへ結び、運転中の実状態と設計意図を比較できるようにします。

誤ったBit、古いData、未処理のFault、再接続後のUnknownを、単なる通信問題として閉じません。Interfaceの意味、状態、Recovery、責任、証拠を見直し、必要ならChange requestとRegressionを開きます。記録します。

公開参考資料

IEC 61131-3:2025 — Programmable controllers: https://webstore.iec.ch/en/publication/68532
IEC 61512 — Batch control: https://webstore.iec.ch/en/publication/6030

MINATAの技術記事をすべて見る