Availability of the complete service
A responding process does not prove tasks can execute. Database, queues, network, identity, adapters and equipment all contribute. Specify covered failures and which function must survive each. High availability does not eliminate mechanical stops or every common-mode failure.
Measure recovery through detection, leadership transfer, state recovery and operational release. Process startup time omits much of the interruption.
One command authority
Only the authorized instance may command a resource. A network partition can leave two instances believing they are leaders. The design must invalidate the old authority after takeover.
Fencing must reach the actual command boundary. Database election alone is insufficient if the former leader can still write directly to a PLC. The mechanism depends on infrastructure and protocol capabilities.
State before resumption
The replacement instance must distinguish unsent, accepted, executing and completed-but-unconfirmed tasks. Replicating a task list is insufficient if equipment progressed during failure. Query or reconcile execution state.
Synchronous versus asynchronous replication trades latency against possible recent data loss. Specify tolerable loss and physical reconciliation. Do not claim zero loss without architecture-specific evidence.
Worked failover scenario
A sends command 88 and loses connectivity. B takes over after invalidating A. Before repeating 88, B compares acknowledged sequence and load location. Ambiguous evidence remains in reconciliation.
Test shutdown, network isolation and dependency failure separately. Record time to coherent service, duplicates and pending tasks. ABNET WCS availability requirements must be defined and demonstrated for the contracted architecture.
Project verification criteria
- Measure recovery to coherent execution, not just process health.
- Isolate the leader and verify loss of command authority.
- Reconcile in-flight commands before resumption.
Examples describe engineering decisions and test scenarios. Implemented interfaces, limits and features are defined by each project’s scope.