-
Notifications
You must be signed in to change notification settings - Fork 27
Point Recs
In Niagara 4, ControlPoints and Histories exist in separate namespaces. There is one object in the station database which represents the current state of the point, (including its current value, actions to command it, and so forth), and a different object to represent its historical log of timestamp/value pairs.
However, in Haystack, a point rec models both of these concepts in one
object. A point rec can have both a cur tag,
which indicates the point has capability for subscription to its real-time
current value, and it can have a his tag, which indicates that a
point is historized with a history log of timestamp/value pairs.
NHaystack handles this mismatch by unifiying the namespaces.
It automatically maps ControlPoints and Histories together
so that only one Haystack rec is generated, with both a cur tag and a
his tag. If only one of the objects is present, then either
the cur tag or this his tag is generated, but not both. Lets
look at a couple of examples showing how this works.
First lets take a simple example of a Niagara station that has two ControlPoints in it , with no History collection for those ControlPoints. The station will look similar to this:
station:|slot:/AHU1/NumericWritable
station:|slot:/AHU1/BooleanWritable
history:/my_station/AuditHistory
history:/my_station/LogHistory
This station will automatically have four point recs: two for the
ControlPoints, and two for the Histories. The first two will have a cur
tag, but no his tag, and the second two will have a his tag but
no cur tag.
{point,cur} station:|slot:/AHU1/NumericWritable
{point,cur} station:|slot:/AHU1/BooleanWritable
{point,his} history:/my_station/AuditHistory
{point,his} history:/my_station/LogHistory
Now lets add a NumericCov extension to the NumericWritable and enable it.
Whenever we make a structural change to a station, by adding or removing a
Component or History, we must invoke an action on the NHaystackService called
rebuildCache. Invoking rebuildCache causes the
NHaystack Server to traverse through the entire station and rebuild
all of its internal data structures, so it can keep track of how everything
in the station is interrelated.
After we invoke rebuildCache, the station will look like this:
{point,cur,his} station:|slot:/AHU1/NumericWritable
{point,cur} station:|slot:/AHU1/BooleanWritable
{point,his} history:/my_station/AuditHistory
{point,his} history:/my_station/LogHistory
---- history:/my_station/NumericWritable
The station still has the same four point recs. However, a his tag has
been added to the NumericWritable point. If a [hisRead][hisRead] on that
point is performed, the NHaystack Server will fetch the timestamp/value pairs
for the associated History. The History for NumericWritable does not have its
own rec created, because it has been unified with the NumericWritable.
By the way, the id tags that are generated for these recs consist of
a single character, either "c" or "h" (which indicates whether the rec comes
from the ComponentSpace or HistorySpace), followed by a ".", and then followed
by a Uri-friendly Base64 encoding of either the slotPath or the historyId.
As a final example from this simple station, lets delete the NumericWritable
and then invoke rebuildCache. The station now looks like this:
{point,cur} station:|slot:/AHU1/BooleanWritable
{point,his} history:/my_station/AuditHistory
{point,his} history:/my_station/LogHistory
{point,his} history:/my_station/NumericWritable
We still have four point recs. However, the first rec is now gone. In its
place we have a point rec for the NumericWritable History. Note that this
rec has a different id than the rec that has disappeared.
Now lets look at a more complex station -- one that is similar to what one often sees on a Niagara Supervisor. A very frequent case for supervisors is that they just import lots of Histories from jaces.
---- station:|slot:/Drivers/NiagaraNetwork/jace1/Histories/Remote_NumericWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace1/Histories/Remote_BooleanWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace2/Histories/Remote_NumericWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace2/Histories/Remote_BooleanWritable
{point,his} history:/supervisor/AuditHistory
{point,his} history:/supervisor/LogHistory
{point,his} history:/jace1/NumericWritable
{point,his} history:/jace1/BooleanWritable
{point,his} history:/jace2/NumericWritable
{point,his} history:/jace2/BooleanWritable
This station has six recs: two for the station's own audit and log Histories,
and four for the imported Histories. Note that the four NiagaraHistoryImport
objects do not have a point associated with them.
Now lets change the station by importing the ControlPoints for the first Jace,
and running rebuildCache. Here is what the station looks like now:
{point,cur,his} station:|slot:/Drivers/NiagaraNetwork/jace1/points/NumericWritable
{point,cur,his} station:|slot:/Drivers/NiagaraNetwork/jace1/points/BooleanWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace1/Histories/Remote_NumericWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace1/Histories/Remote_BooleanWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace2/Histories/Remote_NumericWritable
---- station:|slot:/Drivers/NiagaraNetwork/jace2/Histories/Remote_BooleanWritable
{point,his} history:/supervisor/AuditHistory
{point,his} history:/supervisor/LogHistory
---- history:/jace1/NumericWritable
---- history:/jace1/BooleanWritable
{point,his} history:/jace2/NumericWritable
{point,his} history:/jace2/BooleanWritable
You'll notice that the two Histories from jace1 no longer have their own auto-generated rec. Instead, the two imported ControlPoints know about those Histories, and will export them via [hisRead][hisRead]. NHaystack creates this linkage by analyzing the relationships between imported ControlPoints found under a NiagaraPointDeviceExt, imported NiagaraHistoryImports found under a NiagaraHistoryDeviceExt, and the Histories found in the station's HistorySpace.
If NHaystack creates a [cur][cur] tag, then it will also create a [curStatus][curStatus] tag, and (usually) a [curVal][curVal] tag.
In N4, a Status value is a set of status flags and an associated value,
and at least in theory a given
Status can contain any combination of the flags. However, in the haystack tagging
system, curStatus always only has exactly one value -- one of "ok", "fault",
"down", "disabled", or "unknown".
NHaystack translates from an N4 Status to curStatus by checking the following N4 Status flags in order:
N4 ok maps to `curStatus`:"ok"
N4 disabled maps to `curStatus`:"disabled"
N4 fault maps to `curStatus`:"fault"
N4 down maps to `curStatus`:"down
Anything else (overridden, null, alarm, stale, unackedAlarm) is simply
translated into curStatus:"ok".
NHaystack creates a curVal tag only if curStatus is "ok" and the N4
status is not null. This means that if a point in N4 has the "null" status flag
set, then it will be reported with a curStatus of "ok", but it will simply not
have a curVal.