![\"A](\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-context.svg\")
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 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.
\n\nKey properties of the Method model:
\n\nDesign 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.
\n\nEvents are asynchronous notifications pushed from server to client through subscriptions. The model is deliberately rich:
\n\nEvents 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.
\n\nWhen a call takes minutes or hours (a recipe run, a sequence, a batch phase), the Program model provides the proper abstraction:
\n\nPrograms 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.
\n\nA mature OPC UA server design uses all three patterns:
\n\n| 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 |
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.
Follow an ASP project guide to connect the fundamentals with implementation and acceptance.
![\"Engineering](\"https://wiki.aspotomasyon.com/assets/diagrams/opc-solutions-review.svg\")
Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.
","markdown":"# OPC UA Methods, Programs and Event Model\n\n> Most OPC UA integrations start with variables: read temperatures, write setpoints, subscribe to trends.\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/opc-ua-methods-programs-events\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: OPC Solutions\n- Published: 2026-08-11 · Updated: 2026-09-13\n- Reading time: 4 min · Language: English\n\nMost 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.\n\n\n\n*A conceptual OPC UA client/server path. Application certificates establish application trust; user authorization controls what a connected user may do.*\n\n## Methods: Calling Functions on the Server\n\nA 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*.\n\nKey properties of the Method model:\n\n- **Typed arguments** — input/output arguments are defined with data types, so clients can validate before calling.\n- **Executable / ExecutableOnObject attributes** — the server publishes whether the method may be called now and by this client, enabling rights-aware UIs.\n- **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.\n- **Security** — method execution is subject to the session's user role; the server must check authorization per method.\n\nDesign 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.\n\n## The Event Model\n\nEvents are asynchronous notifications pushed from server to client through subscriptions. The model is deliberately rich:\n\n- **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.\n- **Structured fields** — every event carries standard fields (EventId, Time, SourceNode, Severity, Message) plus type-specific fields (e.g., alarm: ConditionName, ActiveState, AcknowledgeState).\n- **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.\n- **Select clauses** — the client chooses which fields it wants, keeping payloads small.\n\nEvents 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.\n\n## Programs: Long-Running Procedures\n\nWhen a call takes minutes or hours (a recipe run, a sequence, a batch phase), the **Program model** provides the proper abstraction:\n\n- **States** — a program is always in one of the standard states (Idle, Running, Suspended, Halted, Completed, Aborted) with defined transitions.\n- **State machine methods** — Start, Suspend, Resume, Halt, Reset — standardized names and semantics that any client can drive.\n- **Events** — state transitions and results are reported as events (ProgramStateMachineEventType), including the final result code.\n- **Auditability** — the whole execution history is visible: who started, when, which arguments, what result.\n\nPrograms 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.\n\n## Putting It Together\n\nA mature OPC UA server design uses all three patterns:\n\n| Interaction | Model |\n| --- | --- |\n| Read/write process data | Variables (with subscriptions for change notification) |\n| Operator commands, configuration actions | Methods with typed arguments and result codes |\n| Alarms, diagnostics, operator actions, state changes | Events with server-side filtering |\n| Long-running sequences, batch phases, robot programs | Programs with standard state machine |\n\n## Summary\n\nVariables 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.\n\n## Apply this to your project\n\n- Record the endpoint, supported security policies, application identity, certificate expiry, and user permissions.\n- Verify the value, engineering unit, StatusCode, and source timestamp together at the receiving application.\n- Test disconnection and recovery with representative subscriptions; preserve evidence of any data gaps or repeated values.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n\n\n*Engineering review sequence: Discover → Authenticate → Subscribe → Recover. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OPC Foundation — OPC UA Part 4: Services](https://reference.opcfoundation.org/specs/OPC-10000-4/)\n- [OPC Foundation — OPC UA Part 2: Security Model](https://reference.opcfoundation.org/specs/OPC-10000-2/)\n\n---\n\nCite 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).\n","headings":[{"id":"methods-calling-functions-on-the-server","title":"Methods: Calling Functions on the Server"},{"id":"the-event-model","title":"The Event Model"},{"id":"programs-long-running-procedures","title":"Programs: Long-Running Procedures"},{"id":"putting-it-together","title":"Putting It Together"},{"id":"summary","title":"Summary"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OPC Foundation — OPC UA Part 4: Services","url":"https://reference.opcfoundation.org/specs/OPC-10000-4/"},{"name":"OPC Foundation — OPC UA Part 2: Security Model","url":"https://reference.opcfoundation.org/specs/OPC-10000-2/"}],"related":[{"slug":"opc-ua-testing-interoperability","title":"OPC UA Testing and Interoperability Tools (UaExpert, CTT)","summary":"OPC UA's promise is interoperability: any certified client can talk to any certified server.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-testing-interoperability","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-testing-interoperability.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-testing-interoperability","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":836,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-testing-interoperability-00e5656d2d19.png"},{"slug":"ics-security-awareness-training","title":"ICS Security Awareness and Training Programs","summary":"In industrial security, the human is both the weakest link and the first line of defense: the operator who notices a USB stick that should not be there, the…","category":{"slug":"industrial-cybersecurity","name":"Industrial Cybersecurity"},"url":"https://wiki.aspotomasyon.com/article/ics-security-awareness-training","markdown_url":"https://wiki.aspotomasyon.com/article/ics-security-awareness-training.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/ics-security-awareness-training","published":"2026-08-11T13:05:24+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":4,"word_count":832,"image":"https://wiki.aspotomasyon.com/assets/social/ics-security-awareness-training-dbbe2629a46c.png"},{"slug":"opc-ua-information-model-design","title":"Designing OPC UA Information Models","summary":"The OPC UA information model is what makes OPC UA far more than a data transport.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-information-model-design","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-information-model-design.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-information-model-design","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":965,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-information-model-design-ce767593b5d6.png"},{"slug":"opc-ua-companion-specifications","title":"OPC UA Companion Specifications — Industry-Specific Information Models","summary":"OPC UA Companion Specifications define standardized information models for specific industries and application domains.","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-companion-specifications","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-companion-specifications.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-companion-specifications","published":"2026-05-13T11:58:29+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":1095,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-companion-specifications-40cb237797f5.png"}],"citation":"ASP OTOMASYON. OPC UA Methods, Programs and Event Model. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/opc-ua-methods-programs-events"}}