# OPC UA Methods, Programs and Event Model > Most OPC UA integrations start with variables: read temperatures, write setpoints, subscribe to trends. - Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-methods-programs-events - Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki) - Category: OPC Solutions - Published: 2026-08-11 · Updated: 2026-09-13 - Reading time: 4 min · Language: English 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. ![A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg) *A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.* ## 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](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance. ![Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg) *Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.* ## 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. - [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/) - [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/) --- Cite the canonical article: https://wiki.aspotomasyon.com/article/opc-ua-methods-programs-events (OPC UA Methods, Programs and Event Model, ASP OTOMASYON, updated 2026-09-13).