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.
Apply this to your project
- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.
- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.
- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.
Follow an ASP project guide to connect the fundamentals with implementation and acceptance.
Primary references and further reading
Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.