Server App Configuration

All server application configuration is stored within the App_Data subfolder. Particular files are described below.

Internal processes, actions and simple error messages are logged into file commonlog.txt within the App_Data folder.

More detailed error messages are logged into the errorlog.txt within the App_Data folder.

Both files should be handy during the start up troubleshooting. They are in no way intended to store information about regular user access (for this purpose you may see the Apache access log file). There may also arise errors at the web server level. These errors will not be stored within the application error log files (as the requestest probably have not yet reached the app). This kind of errors may be found at Apache error log file. For more info see Troubleshooting section.

In order to perfrom all required tasks, the application should be able to:

• read all data in it's own folder (incl. App_Data, assets, etc.
• be able to create new subfolders and files under App_Data\packages
• be able to create new subfolders and files under App_Data\profiles
• be able to overwrite files in App_Data\signals
• be able to read & delete files in App_Data\startup (as of ver. 10)
• be able to create & read & delete files in App_Data\calculations (as of ver. 11)
• be able to create/rewrite files App_Data\*

These requirements can be simply met by executing:

sudo chown -R www-data:www-data /var/www/poweranalyzer
sudo chmod -R u+rwx /var/www/poweranalyzer

This file specifies the columns that are presented in client applications in the overview page. Crucial issues:

The order of columns should be preserved within the UI of client applications

• id attribute should be column-unique. Since version 1.5 (=15) - at certain situations, for example when there are more signals than the SignalTimeline screen can handle, the signals are ordered using this property before the list of signals is truncated.
• name of the column, usually is presented to the users
• color - hexadecimal specification of column (resp. events in the column) colors (eg. #ffffff for white or #000000 for black)
• type attribute may have one of following values:
  • Joint - special system column used for aggregation in client apps (eg. color stripes on the global scrollbar). This column is not directly presented to the users
  • Regular - regular column containing events from signals with type specified by one or more event codes
  • Sink - column aggregating signal events of types that are not specified in regular columns (simply said - all the other events)
• selectionColor - used only in conjunction with the Joint column type. Specifies the color of highlighted part of scrollbar in client app.
• Event codes (element event, attribute code) are the binding point between the column data and database records. Only the events having the same event code/type (see event_types section of the instance.xml configuration).

Important aspect of visualizing aggregated number of events by one color is the appropriate scale. The scale transforms the original number of events (0...) into fixed scale (0-255). The scale is specified independently for particular columns and granularities (attribute granularity) and purpose (attribute purpose with values overview and timeline). For the moment only the type linear is available.

The linear scale works as follows:

1. If the value is below minCap return 0
2. If the value is above maxCap return 255
3. Otherwise we know, that the value is between minCap and maxCap, therefore we can calculate the ratio R (0..1) by (val - minCap) / (maxCap - minCap)
   1. If the ratio is above 0, return minOutput + R * (255 - minOutput), otherwise return 0
   2. Therefore the minCap value may be used to ignore certain number of events, while maxCap allows us to ignore the differences in the number of events above certain number. The minOutput attribute create a visual gap between "There's no event at all" and "There's a small amout of events".

<?xml version="1.0" encoding="utf-8" ?>
<columns xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="columns.xsd">
  <column name="JOINT_INDEX" color="#daa810" selectionColor="#5810da" id="0" type="Joint">
    <scale type="linear" minCap="0" maxCap="50" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="500" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="10000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="100000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="1000000" minOutput="20" granularity="week" />
  </column>

  <column name="T" color="#016dc3" id="1" type="Regular">
    <scale type="linear" minCap="0" maxCap="10" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="100" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="1000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="20000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="200000" minOutput="20" granularity="week" />
    <event code="T" />
  </column>

  <column name="W" color="#c39c01" id="2" type="Regular">
    <scale type="linear" minCap="0" maxCap="10" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="100" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="1000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="20000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="200000" minOutput="20" granularity="week" />
    <event code="W" />
  </column>

  <column name="A" color="#c3010e" id="3" type="Regular">
    <scale type="linear" minCap="0" maxCap="10" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="100" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="1000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="20000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="200000" minOutput="20" granularity="week" />
    <event code="A" />
  </column>

  <column name="F" color="#400004" id="4" type="Regular">
    <scale type="linear" minCap="0" maxCap="10" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="100" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="1000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="20000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="200000" minOutput="20" granularity="week" />
    <event code="F" />
  </column>

  <column name="OE" color="#7d019b" id="5" type="Regular">
    <scale type="linear" minCap="0" maxCap="10" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="100" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="1000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="20000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="200000" minOutput="20" granularity="week" />
    <event code="OE" />
  </column>

  <column name="..." color="#777376" id="6" type="Sink">
    <scale type="linear" minCap="0" maxCap="100" minOutput="20" granularity="minute" />
    <scale type="linear" minCap="0" maxCap="1000" minOutput="20" granularity="quaterOfHour" />
    <scale type="linear" minCap="0" maxCap="20000" minOutput="20" granularity="hour" />
    <scale type="linear" minCap="0" maxCap="200000" minOutput="20" granularity="day" />
    <scale type="linear" minCap="0" maxCap="2000000" minOutput="20" granularity="week" />
  </column>
</columns>

List of signal groups (functional areas) is preconfigured within the groups.xml file. Names and codes are presented within the UI of client applications. The order of particular groups should be also preserved within the UI. Crucial attribute id represents the binding to the database records. Please note the special symbol "_" which represents special system group of signals that are not assigned to any existing group within the data. This group is virtual (not stored within the database). All attributes are required.

Since version 2.0.2 Historian is able to create (if does not exists) this file automatically during startup (based on the data in bpr_fb db table).

<?xml version="1.0" encoding="utf-8" ?>
<groups>
  <group id="G1" code="G1" name="Gas Turbine 1" />
  <group id="G2" code="G2" name="Gas Turbine 2" />
  <group id="S1" code="S1" name="Steam Turbine" />
  <group id="W1" code="W1" name="Water / Steam" />
  <group id="H1" code="H1" name="Heat Recovery Steam Generator 1" />
  <group id="H2" code="H2" name="Heat Recovery Steam Generator 2" />
  <group id="M1" code="M1" name="Unit Control" />
  <group id="A1" code="A1" name="Auxiliary Systems" />
  <group id="T1" code="T1" name="Win_TS 1" />
  <group id="T2" code="T2" name="WINTS_2" />
  <group id="OM" code="OM" name="OM Subsystem" />
  <group id="_" code="XX" name="Not Assigned" />
</groups>

The rest of configuration is contained within the instance.xml file. It should contain the root element instances with exactly one element of instance. Name of the instance (as specified by the attribute name is presented to the users in the client application and may be useful if there are multiple data servers.

Particular elements are as follows:

• accessRestriction - with attribute type having values open or restricted and attribute realm with values apiv1, dashboard, ExtendedDashboardUI or settings. In open mode, the server does not require any credentials and is open to use by anyone. In restricted mode, client apps should ask user for login/password and pass this information to the server along with any operation (with exception of basic info operation). The realm specifies whether the settings applies to the iOS client app or the web dashboard.
• log - configures logging
  • level - 0 for no logging, 1 for error logging, 2 for error and regular info logging, 3 for error, regular info and request logging
• adminKey - secret key which is required to remotely launch some internal operations (cron, heartbeat, etc)
• deploymentNote - inserts text notes to various places of the app. Particular place is specified using the place attribute (available values are SoeList and Index for the moment) - v12 and newer
• allowSoftFailures - whether the application can swallow (=do not crash) some simple errors - for the moment only the signal mapping initialization SQL errors are affected
• eventsSince - start of the analyzed dataset (see below for details)
• lastEventDelay - forces the system to ignore events which are not older that specified value (as the database need not to be complete)
• removeCalculationsOlderThan - automatically removes old calculations in order to manage disk space (removal is done during the CRON process) - v11 and newer
• extendCacheAfterStart - forces the system to automatically update the cache to the latest values immediately after start up
• passwordSaltClient - salt which is added to client password in the client app before calculating the SHA-256 hash. Prevents the password to be sent in plain text.
• passwordSaltServer - salt which is added to the client password hash on server before calculating the SHA-256 hash. Prevents the password to be stored in plain text on server.
• allowedUser - with attribute login and passwordHash. Used mostly when in restricted mode (see above). Subelements allowedRealm specifies which realms (=apps, such as iOS app or dashboard) the user is allowed to use. See element accessRestriction for more details.
• hideFeature - configures the app to hide some of its features. Allowed values are:
  • WebHistorian.Calculations - Calculations tab in Web Historian
  • WebHistorian.Overview - Overview tab in Web Historian
  • WebHistorian.SOEAggregations - SOE Aggregations tab in Web Historian
  • WebHistorian.OneSlide - Database statistics tab in Web Historian
  • WebHistorian.Location - Signal Hierarchy tab in Web Historian
  • WebHistorian.Dislocation - Event Origins tab in Web Historian
  • WebHistorian.Help - Help tab in Web Historian
  • WebHistorian.SOE - Classical SOE tab in Web Historian
  • WebHistorian.ValidateAnalogsBySOEPresence - Prevent export/chart data being marked as invalid because of absent SOE data
  • WebHistorian.Locale.de - Hides given locale from UI (works also for other locale, such as cs); en locale cannot be hidden (available since v2.0.3/=43). Please note the lowercase.
  • WebHistorian.CheckLegacyData - Disables notification about data not being updated (yellow box, available since v2.0.2/=42)
  • WebHistorian.SOETimestampOnLeft - Places timestamp to the right on the Alarm Management page (exports stay the same, available since v2.0.3/=43)
  • WebHistorian.PrecomputeSOE - Disables SOE cache&indexes (not recommended, makes iPad app not working, etc.)
  • WebHistorian.Reports - Reports tab in Web Historian
  • WebHistorian.ReportTemplateCreateUpdateForAnnonymous - Limit anonymous users ability to update/create/delete reports
  • WebHistorian.Help.Video.Offline - Hide link for local videos (available since v2.0.3/=43), mostly for public DEMO deployments. Automatically may show link to online youtube version
  • WebHistorian.Help.Video.Online - Hide link for youtube online videos (available since v2.0.3/=43), works only in connection with WebHistorian.Help.Video.Offline
• connectionString - MySQL database connection string (see https://dev.mysql.com/doc/connector-net/... for details)
• connectionTimeout - timeout for SQL queries in seconds. Some queries may take quite long (precalculations, etc), minimum of 240s is recommended
• longRunningTimeout - timeout for long-running SQL queries (used usually by calculations), default is 1800s (available as of version v1.4=14)
• timeGranularities - list of granularities (levels of zoom) provided by server application. The list is fixed for the moment (since each granularity requires additional implementation on server and client side, one cannot easily add new granularity through this configuration; however removing particular granularity from configuration will remove it also from client application).
  • type - minute, quaterOfHour, hour, day, week
  • calculation - when set to onTheFly, the server calculates overview requests for this granularity directly using SQL server. While for precompute value the server prepares the responses in advance (usually during the startup), for details see section Data cache below.
  • maxQuerySpan - maximum timespan which can be used to get events overview for certain period. This value is mostly for internal use and is tuned in order to provide quick responses for certain client-server interactions
  • description - client apps show this text when switching between different granularities (should be shorter than title)
  • title - client apps show this text in the application title area when particular granularity is selected
• maxQuerySpanForSignalDetails - maximum timespan which can be used to get details for list of signals. This value is mostly for internal use and is tuned in order to provide quick responses for certain client-server interactions
• maxQuerySpanForListSignals - maximum timespan which can be used to get list of signals for certain period. This value is mostly for internal use and is tuned in order to provide quick responses for certain client-server interactions
• relatedLinks - allows specification of one or more links to related systems. Particular address may be specified based on the address which is being used by particular users (allowing different links for access from VPN/office network, etc).
  • relatedLink - particular link with attributes name (link name), defaultUrl (default link destination) and target (optional - may use _blank for opening in new browser window). Since v2.0.3 (=43) there is also an optional attribute requiredRealm available, which may contain one of application realms. (apiv1/settings/dashboard/ExtendedDashboardUI). Links is shown only to users which can access specified realm (default is empty, therefore available to everyone). Since v2.0.4 (=44) there is also an optional attribute addCssClass available, which can insert special css class into the link (for the moment only the value serviceLink makes sense to use).
    • conditionalUrl - alternative destination specified by attribute url, used only when current Historian url starts with content specified by attribute urlStartsWith.
• smtpMailing - SMTP configuration for outgoing e-mails. Available since v2.0.3 (=43). Historian status page provides a simple form to test the sending. Alternatively you may open the Historian url http://HOST:PORT/apiv1/testMail?adminKey=ADMINKEY&recipient=EMAIL in order to send a test e-mail. Attributes:
  • host - SMTP host address (optional, default localhost)
  • port - SMTP host port (optional, default 25)
  • useCredentials - whether to supply credentials to the SMTP connection (true/false), optional
  • useSSL - whether to use SSL for SMTP connection (true/false), optional
  • user - login (when credentials are used), optional unless useCredentials is true
  • password - password (when credentials are used), optional unless useCredentials is true
  • sender - e-mail addres set for the e-mail as sender, required
• invalidDataRanges - list of time ranges which should be considered as invalid within the data (data in these time ranges should be greyed and crossed out in client applications). List may be generated using the invalidRanges method (see API for details)
• signalHierarchies - list of available signal hierarchies, that are presented to the end users in client applications (detail screen). Available choices are: linearHierarchy (just plain list with signals sorted by KKS+SIGNAL_TYPE), kksHierarchy (signals grouped by the KKS they belong to), columnHierarchy (signals grouped by the overview column they belong to), signalGroupHierarchy (signals grouped by their Functional Area/Signal Group). Each hieararchy should contain name attribute with name of the hiearchy that is being shown to the end users.
• signalClassifiers - list of classifiers, that are presented to the end users in client applications (detail screen). There are two classifiers: columnClassifier and signalTypeClassifier.
• columnClassifier allows users to show/hide signals in the detail screen based on the overview column they belong to (Tolerances, Warnings, etc.) Required attributes are:
  • columnId - related column Id. This value should match Id of one of columns configured in columns.xml.
  • name - classifier name which is presented to the end-users
  • menuColor - hexadecimal color value, maybe used as a hint in the menu in client apps
• signalTypeClassifier can distinguish between different types of signal by applying a regular expression onto the signal name (usually KKS_SignalCode).
  • expression - regular expression to match signals (for example _X(.*) to match all signals wich name contains _X substring, that means all Engineered signals)
  • name - classifier name which is presented to the end-users
  • code - unique classifier code
• eventTypes - list of events types, that are available within the application.
  • type - event type name. Is used to match columns in columns.xml
  • ikzPrefix - prefix of the internal identificator (IKZ) which is used to identify this event type
  • userVisible- whether to offer this event in UI (eg. in search filters, etc.)
• maxSearchItems - maximal number of search items returned to the client app (may
• be slightly less due to analog signal exclusion)
• maxRecordsForTimeline - maximal number of records that may a signal have in order to show its timeline (large number may be very slow if the detail of such signal is requested)
• maxRecordsForOPCQuery - maximal number of records that OPCQuery (eg. signal chart/csv in sime web dashboard) may have (soft limit, checked only on client side)
• maxRecordsForSoeList - maximal number of records for SOE CSV exports (v11 and newer)
• searchTips - search tips (shown in the client usually when search is empty)
  • tip - particular tip
    • title - title of the search tip (shown usually on the first line to the users in the client app)
    • description - description of the search tip (shown usually on the second line to the users in the client app)
    • signalId - exact Id of signal (user is navigated to the detail of this signal when he taps on the tip)
• signalJumpEvent - configuration for client app when jumping from the signal dashboard to signal details view
  • previousTime - time before first occurrence of signal (TimeSpan format, as in lastEventDelay)
  • followingTime - time after first occurrence of signal (TimeSpan format, as in lastEventDelay)
  • previousSignals - number of signals that occurred before this event
  • followingSignals - number of signals that occurred after this event
• soeList - various SOE list configurations
  • eventGroup - in the SOE tab UI, the events are grouped into preconfigured groups. Name of the group is within the attribute name, while particular events are contained within elements eventType with attribute type. Referenced event types should be specified in the eventTypes/eventType branch (see above).
• ioopcExport - Integration Objects' Configuration Export
  • enabled - true/false - whether configuration export is enabled. Creates ioopc_config.xml file inside App_Data folder if enabled.
  • maxSignals - if specified, includes only first N signals into the configuration (for situations where only limited license of OPC server is purchased)
  • strategy -strategy to pick first N signals - available choices are: PreferAnalogue (default), PreferBinary, AnalogueOnly, BinaryOnly, SignalNameRegExpression, SignalTypeRegExpression
  • connectionString - required if enabled. Specifies the connection string which is included into the IO OPC configuration file (cannot use default connection string because IO OPC ignores plain text passwords and uses its own format)
  • regExpression - required in combination with SignalNameRegExpression and SignalTypeRegExpression strategies. Provided regular expression is used to filter signals which are included into the resulting configuration

<?xml version="1.0" encoding="utf-8" ?>
<instances xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="instance.xsd">
  <!--Exactly one at a time-->
  <instance name="lin01">
<!--Textual notes presented at various places of the app-->
<deploymentNote place="SoeList">Don't know where to start? Try March 2011 ...</deploymentNote>
    <deploymentNote place="Index">Maximum one year period in this demo. Don't know where to start? Try March 2011 ...</deploymentNote>
    
    <!--open or restricted, realm: apiv1/dashboard/settings/ExtendedDashboardUI-->
    <accessRestriction type="open" realm="apiv1" />
    <accessRestriction type="open" realm="dashboard" />
   <accessRestriction type="restricted" realm="settings" />
    <!--log level 0 ... none, 1 ... errors, 2 ... errors&info messages, 3 ... errors&info messages&requests -->
    <log level="3" />
    <!--administration task keys-->
    <adminKey>---</adminKey>
    <!--whether to swallow soft errors (eg. signal mapping initilization)-->
    <allowSoftFailures>true</allowSoftFailures>
    <!--override first event time (in UTC)-->
    <eventsSince>2006-01-01 00:00:00</eventsSince>
    <!--consider only events older than ... -->
    <lastEventDelay>365.00:00:00</lastEventDelay>
 <relatedLinks>
      <relatedLink name="Sagunto 10" defaultUrl="http://10.114.0.97:8181" requiredRealm="settings">
        <conditionalUrl url="http://192.168.10.20:8181" urlStartsWith="http://192.168.10.20" />
        <conditionalUrl url="http://192.168.10.20:8143" urlStartsWith="https://192.168.10.20" />
        <conditionalUrl url="http://10.114.0.97:8143" urlStartsWith="https://10.114.0.97" />
      </relatedLink>
</relatedLinks>
<smtpMailing host="mail.inflex.cz" useCredentials="true" useSSL="false" user="notifikace@inflex.cz" password="PASSWORD" sender="notifikace@inflex.cz" />
    <!-- automatically extend cache after startup -->
    <extendCacheAfterStart>false</extendCacheAfterStart>
    <!--salt which is automatically added to the password on client before it's being sent over network-->
    <passwordSaltClient>---</passwordSaltClient>
    <!--salt which is automatically added on server to the hashed password sent from client-->
    <passwordSaltServer>---</passwordSaltServer>
    <!--http://www.xorbin.com/tools/sha256-hash-calculator
Hash is created as follows in two steps as sha256(sha256(ORIGINAL_PASSWORDCLIENT_PASSWORD_SALT)+SERVER_PASSWORD_SALT
    sample password: test123-->
    <allowedUser login="test" passwordHash="---">
      <!-- Into which realms (apps - dashboard/apiv1) the user is allowed -->
      <allowedRealm>dashboard</allowedRealm>
      <allowedRealm>apiv1</allowedRealm>
    </allowedUser>
    
<hideFeature>WebHistorian.Overview</hideFeature>
    <!--io opc export configuration-->
    <ioopcExport enabled="true" maxSignals="3000" strategy="PreferAnalogue" connectionString="..." />

<connectionString>SERVER=172.17.90.5;DATABASE=alezzelu10;UID=---;PASSWORD=---;</connectionString>
    <!--In seconds, default 60-->
    <connectionTimeout>240</connectionTimeout>
    <!--Timeout for long running mysql operations (calculations usually) - In seconds, default 1800-->
    <longRunningTimeout>3600</longRunningTimeout>
    <!--Time ranges (available types: minute/quaterOfHour/hour/day/week, calculation: onTheFly/precompute, maxQuerySpan: d.HH:mm:ss) -->
    <timeGranularities>
      <granularity type="minute" calculation="onTheFly" maxQuerySpan="3.00:00:00" description="Minutes" title="Events by Minute" />
      <granularity type="quaterOfHour" calculation="precompute" maxQuerySpan="62.00:00:00" description="15mins" title="Events by Quarter Hour" />
      <granularity type="hour" calculation="precompute" maxQuerySpan="365.00:00:00" description="Hours" title="Events by Hour" />
      <granularity type="day" calculation="precompute" maxQuerySpan="1095.00:00:00" description="Days" title="Events by Day" />
      <granularity type="week" calculation="precompute" maxQuerySpan="7300.00:00:00" description="Weeks" title="Events by Week" />
    </timeGranularities>
    <!--Maximum timespan for SignalDetails query-->
    <maxQuerySpanForSignalDetails>3.00:00:00</maxQuerySpanForSignalDetails>
    <!--Maximum timespan for ListSignals query-->
    <maxQuerySpanForListSignals>20.00:00:00</maxQuerySpanForListSignals>

    <invalidDataRanges>
      <!--<invalidDataRange since="2008-01-01 00:00:00" till="2009-01-01 00:00:00" />
      <invalidDataRange since="2011-01-01 00:00:00" till="2012-01-01 00:00:00" />
      <invalidDataRange since="2010-01-05 00:00:00" till="2010-01-06 00:00:00" />-->
      <invalidDataRange since="2007-03-08 00:00:00" till="2007-04-20 00:00:00" />
      <invalidDataRange since="2007-05-09 00:00:00" till="2007-05-19 00:00:00" />
      <invalidDataRange since="2007-10-11 00:00:00" till="2007-10-25 00:00:00" />
      <invalidDataRange since="2007-12-07 00:00:00" till="2008-01-20 00:00:00" />
      <invalidDataRange since="2008-02-21 00:00:00" till="2008-03-29 00:00:00" />
      <invalidDataRange since="2008-04-26 00:00:00" till="2008-06-26 00:00:00" />
      <invalidDataRange since="2008-11-22 00:00:00" till="2008-12-05 00:00:00" />
      <invalidDataRange since="2009-02-26 00:00:00" till="2009-03-14 00:00:00" />
      <invalidDataRange since="2009-06-08 00:00:00" till="2009-07-04 00:00:00" />
      <invalidDataRange since="2010-08-21 00:00:00" till="2010-08-22 00:00:00" />
      <invalidDataRange since="2012-12-09 00:00:00" till="2013-01-05 00:00:00" />
      <invalidDataRange since="2015-12-06 00:00:00" till="2015-12-07 00:00:00" />
    </invalidDataRanges>

    <signalHierarchies>
      <linearHierarchy name="Sort by KKS" />
      <kksHierarchy name="Group by KKS" />
      <columnHierarchy name="Group by Event Type" />
      <signalGroupHierarchy name="Group by Function Area" />
    </signalHierarchies>>

    <signalClassifiers>
      <columnClassifier columnId="3" name="Alarms" menuColor="#c3010e" />
      <columnClassifier columnId="2" name="Warnings" menuColor="#c39c01" />
      <columnClassifier columnId="1" name="Tolerances" menuColor="#016dc3" />
      <columnClassifier columnId="4" name="Failures" menuColor="#400004" />
      <columnClassifier columnId="5" name="Operator Events" menuColor="#7d019b" />

      <signalTypeClassifier expression="_X(.*)" name="Engineered Signals" code="process" />
      <signalTypeClassifier expression="_[^X](.*)" name="DCS Internal Signals" code="native" />

    </signalClassifiers>

    <eventTypes>
      <eventType type="A" ikzPrefix="0x0002" userVisible="true" />
      <eventType type="C" ikzPrefix="0x0800" userVisible="true" />
      <eventType type="D" ikzPrefix="0x8000" userVisible="true" />
      <eventType type="E" ikzPrefix="0x0001" userVisible="true" />
      <eventType type="EA" ikzPrefix="0x0003" userVisible="true" />
      <eventType type="F" ikzPrefix="0x0040" userVisible="true" />
      <eventType type="FD" ikzPrefix="0x8040" userVisible="true" />
      <eventType type="FI" ikzPrefix="0x0140" userVisible="true" />
      <eventType type="I" ikzPrefix="0x0100" userVisible="true" />
      <eventType type="IS" ikzPrefix="0x4100" userVisible="true" />
      <eventType type="O" ikzPrefix="0x0010" userVisible="true" />
      <eventType type="OD" ikzPrefix="0x8010" userVisible="true" />
      <eventType type="OE" ikzPrefix="0x0200" userVisible="true" />
      <eventType type="OI" ikzPrefix="0x0110" userVisible="true" />
      <eventType type="OMCST-S" ikzPrefix="0x7890" userVisible="false" />
      <eventType type="S" ikzPrefix="0x4000" userVisible="true" />
      <eventType type="SD" ikzPrefix="0xc000" userVisible="true" />
      <eventType type="T" ikzPrefix="0x0008" userVisible="true" />
      <eventType type="TLFCST-S" ikzPrefix="0x7868" userVisible="false" />
      <eventType type="TLFSMCST" ikzPrefix="0x3c68" userVisible="false" />
      <eventType type="TOMCST-S" ikzPrefix="0x7898" userVisible="false" />
      <eventType type="W" ikzPrefix="0x0004" userVisible="true" />
      <eventType type="WOFMCST-" ikzPrefix="0x78d4" userVisible="false" />
    </eventTypes>

    <maxRecordsForTimeline>5000000</maxRecordsForTimeline>

    <maxRecordsForOPCQuery>5000000</maxRecordsForOPCQuery>

    <maxRecordsForSoeList>5000000</maxRecordsForSoeList>

    <soeList>
      <eventGroup name="A">
        <eventType type="A" />
      </eventGroup>
      <eventGroup name="C">
        <eventType type="C" />
      </eventGroup>
      <eventGroup name="D">
        <eventType type="D" />
      </eventGroup>
      <eventGroup name="E">
        <eventType type="E" />
        <eventType type="EA" />
      </eventGroup>
      <eventGroup name="F">
        <eventType type="F" />
        <eventType type="FD" />
        <eventType type="FI" />
      </eventGroup>
      <eventGroup name="I">
        <eventType type="I" />
        <eventType type="IS" />
      </eventGroup>
      <eventGroup name="O">
        <eventType type="O" />
        <eventType type="OD" />
        <eventType type="OE" />
        <eventType type="OI" />
        <eventType type="OMCST-S" />
      </eventGroup>
      <eventGroup name="S">
        <eventType type="S" />
        <eventType type="SD" />
      </eventGroup>
      <eventGroup name="T">
        <eventType type="T" />
        <eventType type="TLFCST-S" />
        <eventType type="TLFSMCST" />
        <eventType type="TOMCST-S" />
      </eventGroup>
      <eventGroup name="W">
        <eventType type="W" />
        <eventType type="WOFMCST-" />
      </eventGroup>
    </soeList>

    <maxSearchItems>20</maxSearchItems>
    <searchTips>
      <tip title="Plant trips" description="12BAC01GS009Y BE/SI" signalId="0x0001.7.22.0[1105.1].610.-1" />
    </searchTips>

    <signalJumpEvent previousTime="0.00:10:00" followingTime="0.00:10:00" previousSignals="20" followingSignals="5" />

    <!--remove calculations older than ... -->
    <removeCalculationsOlderThan>1.00:00:00</removeCalculationsOlderThan>
    
  </instance>
</instances>

In order for the system to provide quick responses, part of the data should be precalculated and stored within memory. This is the case for most overview data for certain granularities (levels of zoom). More precisely, this is true for all granularities which are configured within the file instance.xml with the attribute calculation="precompute" (typically all except the finest level where caching becomes uneffective).

Start of the precalculated data is contained within the eventsSince configuration parameter. End of the data is calculated as minimum(A, B-C) where A is the last event available in the database (column time_stamp, table soe where soe.sig_quality='All okay'), B is the current server time and C is the preconfigured event delay (see lastEventDelay above).

The workflow is as follows:

1. During startup the system checks for precalculated data (stored in a file called cache.json).
   1. If there are some, they are preloaded into memory.
   2. If there's nothing, the system precalculates them, however this may taky minutes to hours based on the size of database.
2. Afterwards, the data are stored within the cache.json file for the next startup.
   1. Technically speaking, they are stored within the cache_aux.json file at first.
   2. Then they are copied into production cache file chache.json. This eliminates most errors happening during long I/O operations.
3. Later during the runtime there may appear new records within the database. In order to get these new records into the database, the regular CRON job should take place. After launching the job, the application checks for new data and if it is required, it extends the cache range, precalculates the data and stores updated cache.json file. This process may take some time (depending on the frequency of the CRON job and on the speed of the machine). During this time the app may respond by "System not ready" error to the client apps. However this response is issued only after certain time, therefore in real, the users should not came across this.

Precalculation progress may be observed within the commonlog.txt file.

As of version 22 (v1.7), the system is able to orientate itself within the database using the information about TAV files. The system during startup checks the existence of table imported_tav in the database. If the table does not exists, it falls back to the original system where first-last records in the SOE are analyzed. If the table exists, the system load information about TAV files and checks if particular files have already been processed (this information is stored within the App_Data\tavs_processed.xml file). If not, the time range specified by the TAV file is analyzed and stored in cache.