Database Notes

• KKS is not a unique identifier. IKZ is a unique identifier. SOE table uses IKZ as identifier.
• IKZs are prefixed using the event type code (eg. 0x0002). Mapping table for these codes is specified inside the instance.xml configuration file.
• Signals are either binary or analogue. They can be differentiated using the last part of the IKZ (-1 for analogues and other values for binaries). Since version 1.5 (=15), also value -5 is considered as analogue. Signal types (XQ01, ZQ01) are not enough because there are signal without this type
• Particular signal tables (TAG*) unfortunately contain data for multiple IKZs at once without having them identified using particular IKZ. Luckily they can be differentiated using different EVENT value (which is also contained in the structure of IKZ)
• Parts of the IKZ are used for quick identification of data table, when additional KKS information is not available. Therefore following scheme should be met (pseudocode):

ikz='0x8000.1.12.0[61.1056].1081.-3'; // should result in tag_1_61_1056
parts=ikz.Split(new char[] { '.', '[', ']' }); // split using any of . [ ]
tbl="tag_" + parts[1] + "_" + parts[4] + "_" + parts[5];

• Template information from table bpr_typea are mapped to particular signals using same signal type information and following scheme IKZ-based condition (pseudocode):

ikzPart="." + templateInfo.Id2 + "]." + templateInfo.Id3 + ".";
match=(template.SignalType=signal.SignalType)&&(signal.Ikz.Contains(ikzPart));

• Events (both in SOE and particular TAG* tables) are usually stored when the value changes. However this is not always true as there might be other reasons for storage (such as system restart, operator event or simply the beginning of MOD disk where the data has been stored). Therefore you may often encounter same values one after another. In extreme case there are some binary signal having only zero values. This should be displayed within the UI of the client apps (see Inflex issue id: #1959).
• The timezone is not precisely specified (see Inflex issue id: #1897). For the moment it seems that the time_stamp is some local time with an offset, which causes issues when daylight saving time starts/ends.
• There are records in KKS table pointing to non-existing tables (eg. Sagunto - tag_102_5521_7) - see Inflex issue id: #1970. Historian during startup and db updates check for all such signals and marks them as Invalid. This prevents user for searching for such signal and listing it's data (which would lead to a crash)
• Not all IKZ records which appear in SOE (and possibly in TAG* tables) are contained in the KKS table (see Inflex issue id: #1937). Historian during startup and db updates check for all such signals and creates a virtual (in-memory only) signal marked as Invalid. Therefore the SOE data can be at-lest browsed inside Historian.
• IKZ should be unique. However a situation occured when it wasn't. (see Inflex issue id: #3338). Historian will now start normally, accepting the first signal and ignoring the later ones.
• IKZ ends with a signal type -1 for analogues, -3 for binary. These signals can be shown inside Historian. Signals ending with other values (-5/-7/-8/-12) are marked as inqueryable and Historian "hides" them (see Inflex #2481)

Number of ignored signals is appended to the log during each startup and list of invalid signals (with the reason of invalidity) can be seen on (for the moment) hidden page /Dashboard/StatusInvalidSignals (as of version 2.0.2).