AIAPC Learning Library

OPC DA, HDA and Alarms & Events: Which Data Task?

Map current values, historical requests and alarm/event notifications to the appropriate OPC Classic information task.

Choose the information task before choosing an interface

OPC Classic separates several information tasks. Data Access, or DA, concerns process data including values, time and quality. Historical Data Access, or HDA, concerns historical time-stamped data and supported queries. Alarms & Events, or A&E, concerns alarm/event information and related states. Supporting one specification does not automatically establish that a product supports the others.

This comparison concerns Classic interfaces. OPC UA uses a different architecture and its own supported services and profiles; the same three tasks should not be treated as proof that Classic and UA connections are interchangeable.

Map three requests to the relevant Classic interface

Original synthetic client acceptance checklist
User request	Interface to investigate	Evidence to obtain
Show the current vessel level with quality and time	DA	Supported data items, current value, quality/status and timestamp behavior
Retrieve the level record from a stated time range	HDA	Historical item support, time range and the supported retrieval behavior
Receive a process alarm/state notification	A&E	Supported event/alarm categories, states and subscription behavior

The interface name is the beginning of the check, not an acceptance result. The actual client and server must support compatible behavior for the requested task.

Use a DA-only counterexample to test the assumption

Suppose a synthetic server exposes a current pressure item through DA. A client can read its current value, quality and timestamp. That successful read does not establish that the server has a historical archive or provides an HDA interface. It also does not show that an A&E subscription is available.

If another application stores those DA readings in its own archive, that archive may make a historical display possible without proving HDA support in the original server. Keep the source of the historical record explicit when documenting a system.

Make a task-based compatibility record

Record the specification, the relevant client and server products and versions, the item or category required, and the expected information behavior. Use the supported interfaces and documentation for the actual system. Do not treat a product family name as a complete list of implemented capabilities.

For current values, check the meaning of quality/status and time information as well as the number.
For history, identify the archive, requested time range and supported retrieval or aggregation behavior.
For alarms/events, identify the event/state task and the supported notification behavior.
Keep connectivity, authorization and useful data interpretation as separate acceptance questions.
Record missing support or unknown behavior explicitly instead of inferring it from another successful connection.

These are information checks, not instructions to weaken DCOM, firewall or authentication settings. Configuration and security handling depend on the real products and authorized environment.

Connect interface selection with communications training

The Classic versus UA guide provides the architecture comparison. Review OPC500 communications training for its published Classic-focused topics. The DCS alarm/event/trend example illustrates why transporting information and interpreting its operating meaning remain distinct tasks.

References and learning scope

Technical definitions are supported by the primary references below. The labelled numerical records, timelines and checklists are original teaching examples for this article. They do not establish site-specific design approval or a new course entitlement.

Browse the process-control learning library for the wider subject guides and course routes.