histsdk/docs/plans/histevents.md

How a HistorianEvent reaches the Historian DB files

Living analysis doc. Traces an event end-to-end: client API → wire → server storage backend (SQL Database vs history Blocks .dat) → read-back.

Evidence base: 2023 R2 aahClientManaged.dll (decompiled ArchestrA.HistorianAccess, HistorianEvent, HistorianEventPropertyType), native aahStorage.exe (string analysis), the recovered gRPC + CloudHistorian contracts, and the histsdk read-side reverse-engineering (CM_EVENT registration + event-row parser).

Status legend: ✅ proven (from binary) · 🔶 strong inference · ❓ open.

---

TL;DR

An event is not a distinct wire message. The client turns each HistorianEvent into a HistorianDataValue of type Event against the built-in CM_EVENT tag, marshals it into a native VTQ, and streams it like any tag value on a dedicated Event connection. Events are batched into an opaque serialized event data packet and delivered (with their own store-and-forward "event snapshot" path). On the server they are persisted into one of two backends, chosen by a server-configured EventStorageMode: a SQL Database, or the history Blocks (.dat) files.

HistorianEvent (Type + typed property bag)
  └─(AddStreamedValue)→ HistorianDataValue{Type=Event, TagKey=CM_EVENT, EventTime, Q=192}
       └─ HistorianEvent.PackToVtq → CCommonArchestraEventValue::PackToVtq (native value blob)
            └─ HISTORIAN_VALUE2 (44B; blob ptr @+33) → HistorianClient.AddHistorianValue → queue
                 └─ flush → EnqueueEventDataPacket{ byte[] SerializedBytes } (batched VTQs)
                      └─ SERVER: aahEventStorage.exe (InSQLEventSystem)
                           per-client event-tag pipeline → recovery-log WAL → backend:
                             • Blocks   → elastic snapshot → frozen → history .dat (Circular/Permanent)
                             • Database → ArchestrAEvents.EventStorage.Contract assembly → SQL (A2ALMDB)
                           → EventReplication (redundant historians)
                 └─ (offline) → store-and-forward → ForwardEventSnapshotBegin/…/End on reconnect
  read-back: Retr.StartEventQuery / SQL provider views (Events, v_AlarmEventHistory2, v_EventSnapshot)

---

1. The HistorianEvent object ✅

Decompiled ArchestrA.HistorianEvent — a structured header plus a typed property bag:

• Header fields: ID/Id (Guid), Type/EventType (string, e.g. "Alarm.Set", "User.Write"), EventTime (DateTime), ReceivedTime, Severity (ushort), Priority (ushort), IsAlarm, IsSilenced, System, Source, Source_Name, Area, Namespace, DisplayText.
• Revision fields: RevisionVersion (ushort), Delete (bool), Update (bool) — events are revisable (see §4 UpdateEventStatus).
• Property bag: AddProperty(name, value, HistorianEventPropertyType, …) with typed overloads. HistorianEventPropertyType (alphabetical enum): Blob, Boolean, Byte, Date, DateTime, Decimal, Double, Duration, Float, Guid, Hex, Int, Integer, Long, Short, String, Time, UnsignedByte, UnsignedInt, UnsignedLong, UnsignedShort, Undefined.

These map onto the wire property-bag the histsdk read parser already decodes (HistorianEventRowProtocol): typemarkers 0x02 Boolean, 0x10 Guid, 0x18 FILETIME, 0x31 Int32, 0x43 UTF-16 string, … — i.e. the write enum and the read typemarkers are two views of the same typed-value format. The event-send serialization is the inverse of that read parser.

---

2. Client send path — an event becomes a streamed VTQ ✅

From decompiled ArchestrA.HistorianAccess (line refs into the decompile):

1. Open an Event connection. HistorianConnectionArgs.ConnectionType = HistorianConnectionType.Event, ReadOnly = false (sample Step10.SendEvents).
2. Default event tag. CreateDefaultEventTag() (:3006) registers tag CM_EVENT / "AnE Event" / TagDataType = Event and stores eventTagHandle. Same CM_EVENT registration histsdk reverse-engineered (RTag2 + EnsT2; tag id 353b8145-5df0-4d46-a253-871aef49b321).
3. Wrap as VTQ. AddStreamedValue(HistorianEvent) (:3123):

   historianDataValue.objValue      = historianEvent;          // header + property bag
   historianDataValue.DataValueType = HistorianDataType.Event;
   historianDataValue.TagKey        = eventTagHandle;          // CM_EVENT
   historianDataValue.StartDateTime = historianEvent.EventTime;
   historianDataValue.OpcQuality    = 192;
   return AddStreamedValue((ConnectionIndex)1, historianDataValue, false, out error); // 1=Event
   

4. Marshal + queue. The private AddStreamedValue (:3173):
   • builds a 44-byte native HISTORIAN_VALUE2 (InitBlockUnaligned(…,0,44)),
   • HistorianAccessUtil.ConvertManagedStructToUnmanagedStruct(value, &HV2, bVersioned…) — its case HistorianDataType.Event (HistorianAccessUtil:89) calls HistorianEvent.PackToVtq(out byte[]) to produce the event value blob, whose pointer is placed at HISTORIAN_VALUE2+33 (freed after send; offset 33 is the value-union pointer used for Event/String types),
   • HistorianClient.AddHistorianValue(client, &HV2, &err) (:3209) queues the VTQ into the native delivery buffer and returns immediately.

So an event uses the same streaming machinery as a process value; only DataValueType (Event) and the target tag (CM_EVENT) differ.

2a. Event value serialization — HistorianEvent.PackToVtq ✅/🔶

HistorianEvent.PackToVtq (HistorianEvent:1392) populates a native CCommonArchestraEventStruct then hands it to the native packer CCommonArchestraEventValue::PackToVtq(…, 192, 192, vtq) (Q=192), associated with the built-in EVENT_TAGID / EVENT_TAGNAME (CTagMetadata.CommonArchestraEvent). The actual byte layout is produced in C++ — not visible in managed code — so pinning exact write bytes needs a wire/IL capture, exactly as the read side did. But the field set + order the managed code writes into the struct is now known:

SetReceivedTime  (uint64 FILETIME, from UniqueTime.GetUniqueFileTime — unique/monotonic)
SetEventType     (wchar* string, e.g. "Alarm.Set")
SetEventTime     (uint64 FILETIME, from EventTime)
SetId            (GUID)
SetRevisionVersion (uint16)
SetIsUpdate      (bool)        ← revision flags
SetIsDelete      (bool)
Namespace        (string, trimmed, non-printable-validated)
…then the typed property bag: Dictionary<string, Tuple<HistorianEventPropertyType, object>>

This matches HistorianEventRowProtocol on read: the property bag is name→(type,value) with the same typed-value encoding (typemarkers 0x02/0x10/0x18/0x31/0x43/…). So a managed event-send serializer is tractable: emit the header struct fields above, then the typed property bag in the read parser's format. The remaining unknown is only the exact native framing offsets — best obtained by capturing one PackToVtq output, then golden-byte testing.

---

3. Event transport / delivery pipeline ✅ (CloudHistorian + gRPC contracts)

Events have a dedicated, batched connection + delivery pipeline, distinct from tag data but structurally parallel:

Stage	Event op	Tag-data analogue
Open connection	OpenEventConnection2 { byte[] ClientInfo } → { byte[] ServerInfo }	OpenConnection
Send batch	EnqueueEventDataPacket { byte[] SerializedBytes }	EnqueueTagDataPacket { byte[] SerializedBytes }
Store-and-forward	ForwardEventSnapshotBegin / ForwardEventSnapshot / ForwardEventSnapshotEnd	ForwardSnapshot…
Revise	UpdateEventStatus	(revision write)

Key point: the event data packet is an opaque serialized byte buffer (SerializedBytes, DataMember d) — the queued event VTQs batched together, exactly the same envelope shape as the tag data packet. On-prem this is what the storage-streaming op (AddStreamValues) carries; in the cloud variant it is EnqueueEventDataPacket.

Validation surfaced via error codes: InvalidAlarmEventPropertyLength=212, AlarmEventPropertyHasNonPrintableChar=214, AlarmEventPropertyHasInvalidSpecialChar=215, AlarmEventPropertyNameIsAReservedName=216 — the server validates alarm/event property names + values on ingest.

Offline → events spool to the store-and-forward cache and replay as event snapshots (ForwardEventSnapshot*) on reconnect — a separate SF stream from tag-data snapshots.

---

4. Revisions / updates ✅

HistorianEvent.Update / .Delete / .RevisionVersion + the contract's UpdateEventStatus op mean events are not write-once: an event can be re-sent to update or delete a previously stored event (e.g. alarm acknowledge/clear), bumping RevisionVersion.

---

5. The storage-backend switch — EventStorageMode ✅

The client reads the server's event-storage backend from HISTORIAN_INFO byte offset 514 (HistorianAccess :5715):

EventStorageMode = (info[514] == -1) ? Unsupported
                 : (info[514] == 0)  ? Database     // SQL Server
                                     : Blocks;       // history .dat blocks

HistorianEventStorageMode ∈ { Database, Blocks, Unsupported }. The destination is a server decision; the client streams the same VTQ regardless.

---

6. Server side — where it lands ✅ (confirmed on the live local install)

The server-side event component is aahEventStorage.exe (service InSQLEventSystem, "AVEVA Historian Event System"; plus aahEventSvc.exe), at …\Wonderware\Historian\x64\aahEventStorage.exe. Its string table maps the full pipeline:

event packets / forwarded snapshots → per-client "event tag pipeline" → batch enqueue
   → Event Storage Recovery Log (WAL; "enqueuing N events to log",
        path SystemParameter EventStorageLogPath = C:\Historian\Data\Logs\EventStorage)
   → persist to the active backend:
        Block Storage  ("Enabled Block Storage for events")  → history .dat blocks
        Database       ("storing N events in database")      → SQL via loaded managed
              assembly ArchestrAEvents.EventStorage.Contract.EventStorageDatabaseConnection
              (e.g. ";Initial Catalog=A2ALMDB;Integrated Security=true;Encrypt=True;…")
   → also fed to EventReplication (aahReplication.exe) for redundant historians

So persistence is pluggable (a loadable connection assembly) and dual-mode, guarded by a recovery log. Which backend is live depends on configuration (the EventStorageMode of §5).

This historian = Block storage (verified)

• C:\Historian\Data\Circular holds 527 .dat history blocks (Permanent empty); the EventStorage recovery log dir exists. aahEventStorage logs "Enabled Block Storage for events".
• SDK-shape alarm/events are present and retrievable: Runtime.dbo.v_AlarmEventHistory2 returns 224 rows over the last 30 days.
• A2ALMDB (the System-Platform alarm DB the connection string references) is not present here — that path is only used when integrated with AVEVA System Platform alarming. Absent it, ArchestrA events land in blocks, exactly as aahStorage.exe advertises ("Stores ArchestrA Event Data", snapshot→block).

The SQL surface is provider-backed views, not physical tables ✅

In Runtime, the rich event objects are views with NULL OBJECT_DEFINITION — i.e. the historian's OLE DB History provider exposes them as virtual/extension tables that read the block store, not stored T-SQL:

• Events, v_EventHistory, v_EventSnapshot, v_EventStringSnapshot, v_AlarmEventHistory2 (columns: EventStampUTC, AlarmState, TagName, Description, Area, Type, Value, Priority, Category, Provider, Operator, DomainName, UserFullName, MilliSec, …) — these are the read-back of the SDK alarm/event property bag.

So SELECT … FROM Events (and v_AlarmEventHistory2) is the provider reading the block store, which is why the handoff could query events even though they live in .dat blocks.

Database-mode physical store

When events ARE stored in SQL (Database mode / A2ALMDB integration), the writer is the loaded ArchestrAEvents.EventStorage.Contract connection assembly doing batched inserts ("storing N events in database", "creating event storage database connection role"). The exact table schema there is the A2ALMDB alarm schema (not present on this box to dump).

Read-back ✅

Uniform regardless of backend: Retr.StartEventQuery → GetNextEventQueryResultBuffer (provider) surfaces events from wherever they were stored — so histsdk ReadEventsAsync is mode-agnostic. Engine filter note: "EventTime filtering can only be specified through StartDateTime and EndDateTime".

6b. Two different "event" subsystems — don't conflate ✅

	Classic event detectors	ArchestrA alarms/events (the SDK path)
What	server-side detectors watching tag conditions	client-streamed HistorianEvent (alarms, user events)
Config/store	Runtime.dbo._EventTag (TagName, DetectorTypeKey, DetectorString, Action*, ScanRate, Edge, Priority)	CM_EVENT / CommonArchestraEvent tag
History	physical BASE TABLE Runtime.dbo.EventHistory (EventLogKey, TagName, DateTime, DetectDateTime, Edge); 30 rows	block store (or A2ALMDB), surfaced via v_AlarmEventHistory2 / v_EventSnapshot
Source	evaluated by the server	sent via AddStreamedValue(HistorianEvent)

AddStreamedValue(HistorianEvent) feeds the right column (ArchestrA alarms/events) — it is not the classic EventHistory detector log.

---

7. Relationship to histsdk

• histsdk implements event reads only (ReadEventsAsync via StartEventQuery); its CM_EVENT EnsT2/RTag2 dance is read-subscription registration.
• Event writing is unimplemented but viable. Chain to replicate: Event-type connection → register CM_EVENT (done) → serialize HistorianEvent (header + typed property bag) into the event-VTQ value blob (inverse of HistorianEventRowProtocol) → batch into an event data packet → stream via AddStreamValues (2023 R2 gRPC: StorageService.AddStreamValues).

---

Open threads

• 🔶 Event value blob: field set/order known (§2a); exact native framing still needs one CCommonArchestraEventValue::PackToVtq output capture + golden-byte test (mirror the read-side HistorianEventRowProtocol reverse-engineering). Now feasible locally — the live historian is installed, so the same instrument-and-capture approach used for reads applies.
• ❓ EnqueueEventDataPacket.SerializedBytes packet framing (header + N event VTQs batched).
• ✅ Database-mode store: server writer is aahEventStorage.exe loading the managed ArchestrAEvents.EventStorage.Contract connection assembly; SQL retrieval surface is the provider-backed Events / v_AlarmEventHistory2 / v_EventSnapshot views (NULL T-SQL def). This box runs Block storage (A2ALMDB absent). A2ALMDB physical schema still un-dumped (needs a System-Platform-integrated box).
• ✅ ArchestraEvent vs CommonArchestraEvent: send path packs CommonArchestraEvent via EVENT_TAGID; both are event-tag schemas in CTagMetadata (the server stores either).
• ❓ UpdateEventStatus wire payload for Update/Delete revisions.
• ❓ EventStorage recovery-log (C:\Historian\Data\Logs\EventStorage) on-disk format (WAL).
• 🔶 Decompile ArchestrAEvents.EventStorage.Contract.dll (managed) for the exact DB insert contract/schema — locate it (not under …\Wonderware\Historian; check GAC / Framework\Bin).

---

Changelog

• Rev 4 (live local install): confirmed server side. aahEventStorage.exe (InSQLEventSystem) is the event store engine — per-client event-tag pipeline → recovery-log WAL → Block storage OR SQL (loadable ArchestrAEvents.EventStorage.Contract assembly) → EventReplication. This box uses Block storage (527 .dat in C:\Historian\Data\Circular; A2ALMDB absent). SQL Events/v_AlarmEventHistory2/v_EventSnapshot are provider-backed views over the blocks (NULL OBJECT_DEFINITION), not physical tables — v_AlarmEventHistory2 (224 rows/30d) is the SDK-event read surface. Distinguished the classic event-detector subsystem (_EventTag → physical EventHistory) from the ArchestrA alarm/event path (the SDK's target).
• Rev 3: event value serialization pinned to native CCommonArchestraEventValue::PackToVtq via managed HistorianEvent.PackToVtq; documented the CCommonArchestraEventStruct field set/order (ReceivedTime, EventType, EventTime, Id, RevisionVersion, IsUpdate/IsDelete, Namespace, typed property bag) and the path to a managed send serializer.
• Rev 2: HistorianEvent structure + HistorianEventPropertyType enum; client marshaling (HISTORIAN_VALUE2 / ConvertManagedStructToUnmanagedStruct / AddHistorianValue); dedicated event pipeline (OpenEventConnection2 / EnqueueEventDataPacket / ForwardEventSnapshot / store-and-forward); revisions (Update/Delete/UpdateEventStatus); Blocks-mode clarified (events = generic VTQ snapshots, no event-specific block code).
• Rev 1: client send path, EventStorageMode switch, Blocks/Database backends, read-back.