Most OPC UA integrations start with variables: read temperatures, write setpoints, subscribe to trends. But OPC UA's information model offers two much richer interaction patterns that separate a real integration from a tag-pump: Methods (callable functions on the server) and the Event model (structured, filterable notifications). The third piece, the Program model (defined in OPC 10000-10), formalizes control of long-running procedures. Together they let clients behave like proper control applications instead of tag browsers.
Methods: Calling Functions on the Server
A Method is a function exposed in the address space, attached to an object, with typed input and output arguments. Examples: StartRecipe(recipeId), AcknowledgeAlarm(conditionId, comment), ResetDevice.
Key properties of the Method model:
- Typed arguments — input/output arguments are defined with data types, so clients can validate before calling.
- Executable / ExecutableOnObject attributes — the server publishes whether the method may be called now and by this client, enabling rights-aware UIs.
- Call semantics — a Call is a request/response: the server executes and returns outputs or a status code. Long-running logic should be modeled as a Program, not a blocking Method.
- Security — method execution is subject to the session's user role; the server must check authorization per method.
Design guidance: expose methods for anything a client should do, not just read. Writing a control bit via a variable write leaves the semantics implicit and un-auditable; a method call with a name, arguments, and a result status is self-documenting and logs cleanly.
The Event Model
Events are asynchronous notifications pushed from server to client through subscriptions. The model is deliberately rich:
- Event types — a class hierarchy rooted at BaseEventType with subtypes for system, device, alarm, and condition events (e.g., ExclusiveLimitAlarmType, SystemEventType). Clients can subscribe to a type and receive all subtypes.
- Structured fields — every event carries standard fields (EventId, Time, SourceNode, Severity, Message) plus type-specific fields (e.g., alarm: ConditionName, ActiveState, AcknowledgeState).
- Server-side filtering — the client defines a WhereClause filter (severity ≥ 500, source node = reactor-1, event type = alarm) and the server only sends matching events — bandwidth is consumed on the server side, not the network.
- Select clauses — the client chooses which fields it wants, keeping payloads small.
Events are the correct mechanism for alarms, diagnostics, operator actions, and any "something happened" information. A well-modeled server turns a SCADA or IIoT client into an event consumer with full alarm semantics instead of a polling loop over status bits.
Programs: Long-Running Procedures
When a call takes minutes or hours (a recipe run, a sequence, a batch phase), the Program model provides the proper abstraction:
- States — a program is always in one of the standard states (Idle, Running, Suspended, Halted, Completed, Aborted) with defined transitions.
- State machine methods — Start, Suspend, Resume, Halt, Reset — standardized names and semantics that any client can drive.
- Events — state transitions and results are reported as events (ProgramStateMachineEventType), including the final result code.
- Auditability — the whole execution history is visible: who started, when, which arguments, what result.
Programs map naturally onto ISA-88 batch phases and equipment procedures — a server exposing batch control as programs gives clients (and auditors) a complete, standard view of what the equipment is doing and why.
Putting It Together
A mature OPC UA server design uses all three patterns:
| Interaction | Model |
|---|---|
| Read/write process data | Variables (with subscriptions for change notification) |
| Operator commands, configuration actions | Methods with typed arguments and result codes |
| Alarms, diagnostics, operator actions, state changes | Events with server-side filtering |
| Long-running sequences, batch phases, robot programs | Programs with standard state machine |
Summary
Variables get data moving, but Methods, Events, and Programs are what make OPC UA a complete control-plane protocol. Expose actions as methods, notifications as typed events, and long-running procedures as programs; then let clients exploit the server's filtering and state semantics. The result is an integration that is self-documenting, auditable, and robust to network interruptions — the difference between connecting systems and integrating them.