Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

Historian SDK

TABLE OF CONTENTS

Storing Revision Data

Save PDF
Save selected topicSave selected topic and subtopicsSave all topics
Share
Share to emailCopy topic URL

A tag with its VTQs can be considered as a continuous signal of value starting at the VTQ’s timestamp and continuing forward in time until it hits another VTQ of a different time, value, and quality. This is what you usually see with a Historian Client Trend application.

In the following example, there is some analog tag with some original data values A, B, C stored with timestamps tA, tB, and tC accordingly:

Essentially it means that at time tA value A was stored and continued to be A in time until time tB when another value B was stored, which continued to remain B until time tC, when it changed to C. From time tC to the current time, the value of the tag remains equal to C.

If a batch of two original non-streamed  VTQs D and E were stored at times tD and tE between times tA and tC there would be the following trend:

By definition the original VTQs are considered equal so they never overwrite or have any effect on each other. So the tag history can now be interpreted as follows: value A started at tA and continued until time tD when it changed to value D. Value D continued until time tB when it changed by value B and so on.

The equality of original VTQs allows storing them in any sequence, producing always the same final result, because they are maintained within the same – original version of the data.

Sometimes, however, you would like to create another version of the data while keeping the original data intact. In this example, you might want to correct the trend by “removing” value B from the final retrieval result. This can be achieved by performing a revision data operation.

There are several types of revision data operations supported by managed HCAL:

  1. Latest insert, which is similar to storing a single original non-streamed VTQ, except it makes invisible a VTQ of the same timestamp if it was stored there before.
  2. Latest single-point update, which works like a latest insert with a limited time span.
  3. Latest multi-point update, which works like a continuous sequence of latest single-point updates.