Notes and Restrictions

Compatibility

The NGA uses the same configs (_archive and _alert_class) and attributes for configuration of archiving behavior at data point element level as the previous archiving solutions in WinCC OA. Since NGA allows multiple targets for archiving (e.g. two DBs simultaneously), the configuration has been extended for this by allowing multiple archive groups to be defined (RDB and Value Archive allow just one archive group).

Note: Archive smoothing is possible but it can be configured separately for each archive group.

To convert existing archive configurations to NGA, the archive group assignment of each DPE with an archive config must be changed to an NGA archive group. Configuration of Alarm archiving (currently) is identical between NGA and Value Archive / RAIMA / RDB manager. Therefore, no conversion is required.

CAUTION: Note that these procedures should only be executed with respective knowledge of WinCC OA and the components involved.

Importing ASCII files containing "old" archive configs

When importing ASCII files containing archive configs not adapted to NGA usage (i.e. from Value Archive or RDB), proceed as follows:

  • Start a project without the NGA manager to avoid inconsistency.
  • Create archive groups as needed using NGA configuration panels (see chapter Configuration - Archive Group), e.g. one group for each Value Archive / RDB group
  • Then either
    1. Edit the ASCII file and change each reference to the Value Archive / RDB group in all archive config sections of the ASCII file with a reference to the proper NGA group (e.g. change all “_ValueArchive_<archive number>” with “_NGA_G_<archive group name>”).
    2. Start the NGA manager.
    3. Import the ASCII file.
    or
    1. Start the NGA Manager.
    2. Import ASCII files (error messages could be shown in the Log Viewer).
    3. Use PARA to change the archive group to a proper NGA archive group (note that the "old" Value Archive / RDB group is not shown any more).

How to replace an existing InfluxDB® within a project

In case an existing InfluxDB® database should be replaced by an empty one, the WinCC_OA_Proj/db/wincc_oa/influx directory must be removed and replaced with the "/db/wincc_oa/influx" directory located within the WinCC OA installation (default: wincc_oa_path).

After replacing the folder the configuration steps for the database must be performed again, see Configuration - Basics.

Read Consistency Check for Alerts

Resulting from the introduction of the consistency check for pending alarm query data in 3.19 P006, queries of time ranges that overlap with the current time will take longer.

If these increased query times have an active impact on the performance of the project, this check can be deactivated manually. However, this is only recommended if actual problems occur, as it can happen that not all alarms are displayed in the query performed if the check is deactivated, as these have not yet been written to the database.

The check can be deactivated by setting the config entry ../../cfg_doku/all_config_entries.html#NextGenArch__timeoutForAlertReadConsistency to a value of "0".

[NextGenArch]
timeoutForAlertReadConsistency = 0

Restrictions

  • In the emergency mode historical queries are not processed.
  • If a data point is to be renamed in an NGA project, no warning dialog is opened and the archived data will be lost upon renaming.
  • WinCC OA online backup: Currently the WinCC OA online backup does not include data from NGA (i.e. no InfluxDB® backup). Note that the NGA backup only refers to segments. Therefore, it must not be used as disaster recovery backup. A full backup (file copy) of the InfluxDB® can be made when the database is shut down (see chapter Database-specific Configuration). No data will be lost due to the NGA buffering mechanism. For a full backup of PostgreSQL®, consult the PostgreSQL® documentation of the manufacturer.
  • In special constellations and when using NGA, the CPU load might shift slightly from the managers used to archive data (HDB project: Data manager + Archive managers / NGA project: Data manager + NGA manager) to the Event manager.
  • BLOBs/dyn_blobs cannot be stored when using an InfluxDB® backend.
  • Split mode is not available for redundant NGA projects! Split mode will be provided in a future patch.

  • In the event of a network interruption between the redundant hosts, the consistency of the database cannot be guaranteed. It is not clearly defined which of the two hosts writes the buffered data for a specific point in time after the database connections are re-established.

    The data is written directly after the connection to the database is opened without synchronizing the write processes with the redundant partner.

    In the case of duplicates or different values for the same point in time, it depends on the database what happens to the duplicate values.

    • With InfluxDB®, one value is overwritten with the new value.
    • With PostgreSQL®, both values are retained in the database (BRIN index)
    • With PostgreSQL®, the first value is retained in the database. Normally the local database is faster and therefore the local value remains in the database (BTREE index)
    • With MS SQL®, both sides try to write to the database. This means that the first server that can write a value wins and the value written first remains in the database.
  • The keyword FIRST only works if a query is sorted by timestamps. The keyword LAST does not work with NGA.
  • InfluxDB®: You can use an aggregate function for alert queries with dpQuery and SELECT ALERT. However, only the COUNT function is supported - the MIN, MAX, AVG, SUM functions are not supported. In addition, the COUNT function can only be used once in the select statement. The alert time of such a result line is the start time of the query. By default, all alert messages of the entire system are counted as one line. You can group by elements to get one row per data point element (as with event queries) by adding a GROUP BY _EL clause.

  • Some config entries in HDB and RAIMA, in particular those related to history (such as maxAlertRequestCount and maxLinesInQuery), do not apply to SQLite® and NGA. Instead, NGA-specific data points such as limitEventQuerySize and limitAlertQuerySize are used.

  • After a change of the system name/system ID in an NGA project, the historical values archived before the change can no longer be queried.
  • NGA and RDB or HDB cannot be used simultaneously.
  • NGA can be used in a RAIMA or SQLite® project. However, SQLite® can only be used with NGA and not with HDB / RDB Archiving.
  • You can migrate from HDB to NGA - see chapters Conversion Settings and NextGen Archiver (NGA) Importer
  • You cannot migrate:
  • The "_original" config value is not archived.
Note: You can find the WinCC OA Known Bug list in your WinCC OA installation package.
Note:

Note the following for the time values and variables:

  • Runtime values/alarms can be created with an accuracy of up to nanoseconds.
  • Historical databases retain the correct sequence, but only store up to milliseconds, i.e. they discard the parts with higher accuracy.
  • The comparison of WinCC OA time variables only takes milliseconds into account. WinCC OA time variables that only differ in the microsecond or nanosecond range would be considered the same by the built-in comparison methods.

SQL Keywords

  • The signal words "GROUP BY", "COUNT", "SUM", "AVG", "MIN" and "MAX" are also available for NGA.