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.

The NGA configuration itself (which archive groups exists, segmentation configuration etc.) is different from the configuration of RDB manager or Value Archive and it cannot be converted automatically.

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).

Converting existing projects to NextGen Archiver Project

Currently there is no tool to convert existing projects (based on HDB or RDB) automatically to NextGen Archiver. Here is an overview of the required manual steps to do so (for advanced users) by copying the necessary files from a temporary project:

CAUTION: All existing historical data will be lost.
  1. Update a project to WinCC OA 3.18 if required (in case of a project of an older WinCC OA version).
    Note: Note that an archive group must not be empty for NGA when converting an existing HDB or RDB project to NGA.
  2. Export all archive configs by using the ASCII manager.
  3. Add the config entry useNGA = 1 to the [general] section of the config file of the project.
  4. Add the NextGen Archiver to the start order of the WinCC OA console before the Event Manager.
  5. RemoveValueArchive / RDB manager entries from your project (console) via the WinCC OA console.
  6. Create a new NGA-based project "NGA_Project" that is used to copy the necessary configuration files for NGA. This project can be deleted after successfully converting your project.
  7. Copy file influxdb.conf from the temporarily created "NGA_Project" to the config directory of your project and adjust the paths in the [meta] and [data] sections (“dir”, “wal-dir”) of the file.
  8. Copy the directories "influx" and "nga" from (Path: WinCC_OA_Proj/db/winccoa) from the temporaily created "NGA_Project" to your project at the same location.
  9. Start your project (error messages for the NGA manager may be shown in the log viewer).
  10. Add NGA groups and backends as required.
  11. 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>" to "_NGA_G_<archive group name>").
  12. Import the ASCII file.
  13. When the message "SEVERE, 0, , partial write: max-values-per-tag limit exceeded ... " is shown in the log viewer, the number of archived DPEs is higher than the default limit of 100.000. The file influxdb.conf (in <winccoa_path>/config) contains the entry "max_values_per_tag" to change this value. If the entry is set to 0, the number of archived DPEs is not limited but the performance and resource consumption of the influxDB process will degrade as more new DPEs are added. The influxDB process must be restarted to apply the change.

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.

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.

  • 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 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.
Restriction: The Excel Report does not work with NextGen Archiver (NGA).
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.